think I've figured out what the AI meshes do and how they work. It seems they
interact with the physical mesh, probably the collision, of the actual object
and tell the path mapper where the objects that need to be avoided are. Take a
look at the barracks with the AI mesh overlaid on it:
I've removed the roof of the building so you can see inside. It's plain that wherever the AI mesh intersects the physical mesh, an avoidance point for the bots is "projected down" to the path map that is being created. This is why it's important to align complex buildings like this as closely with the pathmap grid as possible, to allow accuracy when creating pathmaps, especially internal ones.
It seems that creating a new AI mesh for a custom building would be no more work than creating a sheet object and placing it at the right spot in the building so that the walls and objects inside the building intersect properly to create a pathmap. The problem would be to think of the most logical 2D projection of the 3D building, and to remember the 2D limitation and not allow bots to have access to the upper floors. Unless the the building was designed to not have any overlapping areas from one floor to another.
If anyone knows how to "subtract" the AI mesh from the physical mesh in 3dsmax or gmax, so that only the overlapping areas are left, let me know. I'd like to create a custom object of the result, place it in a map with the pathmap on the terrain to see exactly how they line up to each other. I tried booleans and all sorts of stuff, but none worked.
Interesting. That was quick Dweller.
Ok so basically this is just a flat plane the same size as the outside dimensions of the object and aligned by coordinates to set just above the floor (would this even be necessary?). What I am seeing from the above image and from what you are saying that anything that intersects with it in the vertical gets pathed out. In the case of the stairs for the barracks they have a a plane attached to the main mesh but rolled vertically 90 degrees. Looking at the image you see the treads of the stairs intersect on the horizontal axis. Are we to assume from this maybe that these meshes tell BF, since pathmaps are 2 dimensional only, that anything in the horizontal axis does not get pathed but if it intersects in the vertical axis path it out? To me the pathing of the treads of the stairs is interesting. Even thought the handrails interact with the mesh in the same axis they get pathed, but the treads interact in the horizontal. If this is true all you would have to do is create a mesh to fit your object, align it right and name it as an AiMesh? Thatís probably to simple lol ... for EA/Dice anyhow.
Interesting Idea about placing it in map with the object to see how things interact. We would have to insert it as a custom object and give it a texture I assume? Then place it much like place it like other multipart objects like the Defgun..by coordinates?
As an adder Dweller, I asked CamelNel to look at this also and maybe he will have a way to "Subtract" the Aimesh from the main object.
I think you may be onto something here.
One other interesting thing here is the bridge. Notice that instead of being a single flat plane it is broken up into four planes and each angled to the slope of the bridge roadway. This seems to be so the side walls of the bridge intersect in the vertical to get pathed out.
The way it appears,
anything in the AI mesh can be at any angle - look at the Eagle's Nest villa, a
real complex AI mesh, the most complex one I looked at. They carefully meshed it
so that the bots wouldn't get stuck on various railings and walls, and let them
go down the stairs. Though it looks like one small piece was missing, I don't
know if that would cause a problem. It seems, after looking at the bot path from
that map, that the bots can go inside the cellar of the villa, and come
out the stairs. A clever bit of pathing there, and careful design of the
building to let the bots use it. That's why the railings of the barrack are
pathed out, so the bots don't get stuck on them but can go up the stairs and
into the building, since the stairs don't intersect anything in the AI mesh,
they are allowed in the pathmap. Only the interior stuff in the building is then
In the case of the bridges, you want the bots to "know" where the edges of the bridge are so they don't walk/drive into the railings or even fall off. That's why there are four pieces to the bridge you show, so that the railings on each segment get pathed correctly. If you look at the Omaha bunker you'll see that the bots can only go where the trenches are - they aren't allowed on the concrete segments above. Which is why in the SP version of the Omaha map, the middle flag is in the open space of the trench where the bots can get at it easily.
You want to set the AI mesh above the floor so the floor doesn't get pathed out and keep the bots from entering the building, but you don't want to raise it too high so that any obstructions on the floor like the beds and lockers in the barracks get missed in the pathing. One of the other bunkers I looked at had a single sheet mesh, but it was slanted. The bunker has the one door in the back, then stairs down to the floor, then the long low window. The AI mesh included the door, but it's slant left it under the window, so the wall under the window would be included.
The only thing I can't figure out is why the AI meshes were included with the game. If the bots only go by the pathmap, then the AI mesh isn't needed by a person who is just playing the game. They would only be used in the development of pathmaps by mappers. Either DICE had a lot of forethought and left them in so we could all easily get pathmaps, or more likely, they were just too lazy (or too pressed for time) to take them out.
To me it still looks like anything that interacts with the meshes in the vertical or "Y" axis is pathed out and anything above it no mater the axis is pathed.
If you look at the one for the Omaha Bunker you will see it slants also. I think this is to compensate for the difference in height of the floor of the bunker to the bottom of the trenches. It also extends up to catch to window like you explained above.
I guess a way to test this theory is to take a custom object and make a mesh, alighn it and see if it paths. You could even use a stock object and replace the stock mesh with the one you made and see if it works. Now I have not learned Gmax or 3Dsmax and even have both (shame on me huh) to the point where I understand the process of doing this. If one of you that have this knowledge to make one I will set up the test bed if needed. Though Dweller may be ahead of us on this.
Creating AI meshes for
single floor plans seems fairly easy, please excuse how arrogant that sounds.
I recreated the aimesh for the barrack that started this thread using 3ds 6 and the pluggin from the latest MDT. The aimesh consists of 2 objects, COL01, LOD01, and there material is Battlefield-RS supplied by the pluggin.
First import the structure for which you wish to create and aimesh, in this case Barack_m1.sm. Then select Plane on the right and reduce the segments to 1 on both dimensions. Now using the top view drag/create a plane that just follows the outside of the structure, now slide the plane up to just above floor level using the move gizmo. From the side view draw a verticle plane arround the stairs, ensuring that a portion of it penetrates the floor plane, then right click the new plane and select clone. Repeat for the other steps. From the top view, using the move gizmo, slide each verticle plane till they align with the rails.
We are done with the Standardmesh object now so press 'H' and select the objects with m1 attached, leaving the objects with 'plane' in there name unselected. From the Edit menu select delete.
Now select all the planes you created by using the select gizmo or by using the'H' key, then right click and select Convert -> Edit Mesh. Next select Plane01 then click Attach List on the right, select all planes in the list and click Attach, you should have only one object now, Plane01.
Now press 'M', select the second material (default 02) then click the button with "standard" on it, then from the list double click Battlefield-RS. Click-drag the new material onto plane01. Close the material window and rename plane01 to COL01. Right click COL01, select clone and name the clone LOD01.
Click Battlefield Tools from the menu bar, besides Export being select you should also have "Use Object Names For Export" selected. Now export using the name of the original object but replace tha 'm' with an 'a', so in this case it would read barack_a1.
Heres the pathmap for the barrack with my aimesh:
(I have no idea why this image is so small but you get the idea)
And heres the aimesh:
Attachment: Barack.zip ( 449bytes )
There are two other aimesh variations. One appears to be possibly an experiment to make multi-level dwelling mappable ? (SuburbHouse_...). Another has multiple instances of the Battlefield-RS material, I suspect its different way that another 3d program handles material as it dosen't seem to make any difference.
This is fantastic news. You seem to be the first to do this from all my reading and inquiring in many forums.
Can this be done in GMAX? The reason I ask is many do not have access to 3Dsmax and my purpose in all of this is to get more people involved. I have 3Dsmax but do not know how to use it yet. I have completed all the tutorials in 3d plus gmax and can get around. I have so many other projects in the works that to set to learning a new program is out of the question. Especially one that complex. I think this fits a lot of people in general. If this can be done with GMAX (I do not see why it could not be) and a step-by-step tutorial could be written to make a basic AiMesh then it would open doors for pathmapping.
Whatís your slant on how they work?
To me they act like a mask in that anything in the horizontal plane below the main mesh is not pathed. Anything that intersects in the vertical gets pathed. The stairs for the barracks is an interesting example. They extend beyond and below the main mesh. You could have created a plane sloping with the steps like the stone bridge but the handrails would not path right because they are not a solid wall. So the vertical planes were added and attached to path the handrails. Itís interesting to note that even though the stairs extend beyond the main mesh they are pathed. Is it because they intersect the vertical AiMesh planes in the horizontal axis? Or am I not seeing something?
If you want to look at an interesting AiMesh look at the "O_HueCitadel_A1.sm mesh in BFV. Itís a large complex mesh that covers all three-citadel objects. It uses sloping planes attached to the top and bottom planes to create the ramps. This is a good example of where the ability to create/modify AiMeshes could come to play. If you wanted to use just one of the citadel objects you would have to modify the original mesh or make another.
As far as you can see there is nothing special about how they are made or the materials? This still points to how the Battlefield Refractor II engine interacts with them.
To post your images or screens do this. Go to Photobucket.com and get an account, its free. You upload your images here and hot link them back to the forums. Make them "forum friendly" and reduce to a 640x480 or smaller jpg.
I'm downloading GMAX to
have a look-see.
"The stairs for the barracks is an interesting example. They extend beyond and below the main mesh. You could have created a plane sloping with the steps like the stone bridge but the handrails would not path right because they are not a solid wall. "
I can't see why simply having a plane sloping with the stairs wouldn't work, I tried experimenting with this but my limited knowledge of 3ds has held me up and I wanted to get this post off. Essentially I have to figure out Attaching/Welding for this, it was easy to attach verticles as the program just accepted them but other angles it seems to need some other criteria.
I have looked at O_HueCitadel_A1.sm and others from BFV, they seem to have abandoned there experimetal ways of aimeshing and gone strictly with horizontal and sloping planes, and keeping the interior wall in line with above and below.
"As far as you can see there is nothing special about how they are made or the materials? This still points to how the Battlefield Refractor II engine interacts with them."
As long as the mesh is in 'aiMeshes' and the file has 'a' instead of 'm' then the engine will simply treat it as special pupose, saving it from the need of special materials. It should be noted that the process of exporting with the MDT 3ds max plugin does alter object names slightly but the materials remain the same. Its also interesting to see the difference in file sizes, I think it may come from "settings debris" and so encouraging me to think the ai looks for very little to satisfy it.
Thanks inxs. I figured
gmax would be able to do it..made no since that it wouldn't.
Well howdy CamelNele!
I do appreciate your time as well.
Heres the thing, these meshes are only used to make pathmaps or possibiliy troubleshoot them. They are not, as far as anyone knows used in game.
They work like the .samples files do during the shadow/lightmap process to tell the raytrace how and where to shadow and how to create the lightmaps. It has to have something to go by. I have never seen one of the samples files but I assume it like the AiMesh is a simple low detail model that has just enough information for the BF/Refractor engine to do its job.
To me it acts like a mask, just as you would cut the numbers out of a piece of cardboard and put it over the mailbox and spray in front of it the debugger slaps down these masks (AiMeshes) and gets its can of white Krylon paint and goes to spraying. Anything sticking up out of the mask gets whited out so the Bots do not run into it.
The fact the AiMeshes are even in the game archive is interesting. Dweller brought this up in fact, it seems that EA/DICE had planned some form of AI support with Battlecraft early in the design process but never carried it out for some reason or the other. Ben Lehman's Botinator is proof that it could have been done with little trouble. That would be the only reason for them being there.
I have my ICQ number posted but need to put it on the install as Artic has already fussed me about this. Will get this done and be in touch.
One of the curiosities I
hope to solve is the Pegasus bridge (Caen) and the bots falling through it,
basically I'm looking for a concensus that it does/doesn't have any thing to do
with the aiMesh, I don't think it does but it is a real head scratcher. I don't
think its the job of the aiMesh to give the bot something to walk on, but only
something for the ai to path the object and to tell bots the object can be
traversed, provided there is a valid path.
Thanks CamelNele for the invite to get in touch with you when I have some questions, I'll try to dig in to the multi-level aiMeshes in the next day or two and I'm sure I will have some questions.
The only time the AiMesh
is used is when you activate the Ai-dubugger in the AIpathfinding.con file for
the purpose of creating pathmaps. Once these pathmaps are generated and placed
in the levels Pathfinding.con directory you turn off the debugger by removing
the lines or by rem'ing in the AIpathfinding.con file. The Pathmaps
that are created are what tells the SAI and the bots where they can and cannot
go. They can only go where it is pure black. Not only does it path the objects
but the slopes as well from the call in the map-type searchmap call. Here it
tells what percent grade Tanks, Cars, and Infantry can climb and paths the
slopes for each.
I thought it might be
fairly simple to create an AI mesh, just don't have the 3ds skills to know how
to do it.
I'll have to look at that suburb house one and see what's up with it. I've always wondered why DICE used an 8bit file for pathfinding when a 1 bit (black and white) file would be all you need, and much smaller. Maybe they were going to try to get the bots to "go upstairs" with variable shades of grey in the 8bit file?
The pathmaps can only be pure black (0,0,0) and pure white (255,255,255) to work.
D'oh! Never mind, they
are 1 bit files, it's just when you convert them, they come out 8 bit. I wonder
why all the converters do that? And why this stupid RAW format when TIF or TGA
would be much easier to use, cause less problems, and probably also be smaller?
While I'm at it, why are we here? What is the universe for?
I looked at the AI mesh files for the suburban houses and there is an extra collision mesh in them, a COL2, which looks to be the normal collision for the regular model. I'm 99.9999999999999999999% positive this is completely ignored by the AI engine and they are just there by accident when an overworked DICE modeler exported the files and added the COL2 due to lack of sleep and the coffee pot was broken.
So, it seems an AI mesh is no harder to do than to create a sheet object that intersects the collision of the building where you want the pathmap to be created. Your analogy of a stencil and spray paint works as well as anything to visualize how they work. For infantry, the stencil is fairly exact. Cars, a bit more fuzzy, and tanks even more fuzzy. That's all taken care of by the AI engine, according to the AI properties that are defined in each object.
Hmmm... that sounds
about right - anything that has a collision mesh and contacts the ground gets a
path drawn around it. It's only under special circumstances where the AI mesh is
used. For the interior of the building, since it doesn't contact the ground, the
AI mesh takes over, and that is projected onto the ground like we've discussed
before, overriding the path that would have been created had there been no AI
mesh and the game just traced around the collision mesh where it contacts the
I don't think the game "knows" where XPack (or any mod) components are, unless you tell it. It only reads the files it is told to in it's init files. In the case of a plain BF map, it reads the main init.con and that tells it to load the regular BF files, nothing else. Then, in the case of a custom object in a map, it reads the mesh to find the collision, and decides what to draw depending on how that collision mesh is positioned in realtion to the heightmap. I bet when you do pathmaps for a mod like DC, you get generic paths around the outside edge of a building?
I saw a post you made about the 76 easting map and the tents - I bet with careful pathmapping, you could get the bots to leave the tents after they spawn, and not have to move the SP spawns outside the tent. I did pretty much the same on that test map I worked on, only the bots spawned inside the little guard hut. Once I had the path right, they found their way nicely outside and went about their business.
Well, i think i found
where the meshes are read for pathing.
I have read the ai-tuts from EA/Dice. There is a line mentioned:
addTemplate.addType flag enum
Here we can put various IT names, like ITUnit, ITTransport, ITGround, ITCover, ...
There is an ITStructure too. In the tut, it reads like this:
ITStructure. This flag marks the object as a structure. This must be set for any object that should be rendered as a house on the path finding map.
Well, when i looked into the .con-files, i found that most bridges have another IT set.
That one explains like this:
ITScaleRender. If this flag is used, the object will be rendered on the path finding maps with a smaller brush than normal. This is used to make bridges possible/easier to traverse.
There are more IT's like ITNoRender and ITNoChildRender.
I think, this might need further experiments.
File extensions: http://www.filext.com/detaillist.php?extdetail=vso&Submit3=Go%21