How to create models in XSI and other 3D applications and make them work in Battlefront 1 & 2. Post models, tips for application usage and share anything XSI, 3DMax, SketchUp, etc.
I made a simple low poly object (a troop transport vehicle).
Duplicated the polymesh and named it collision. And also added nulls.
As a prop the collision works perfectly. I can get in the transportvehicle. When animated (object animation in ZE) the soldier stays inside the vehicle.
When using the same msh but now with a vehicle odf, the collision doesn't work anymore. There is no way to get inside the vehicle.
Are there any differences between prop and vehicle collisions?
If so, how should the vehicle collision be designed to make it work properly.
Last edited by DarkHelmet on Thu Dec 21, 2006 5:25 pm, edited 1 time in total.
The first 2 entries are already in the odf, the other 2 not.
Does this mean the entry SoldierCollision="collision" (that's what it's called in xsi explorer view) has to be added?
I can asume the option VehicleCollision is used for collisions with other vehicles and needs to be added as well
According to the "art_guide.doc" that came with "BF2_modtools", you don't need to define any collision in the odf if you use the naming convention in the information below:
art_guide.doc wrote:NEW BFII UPDATE FOR COLLISION AND USING PRIMITIVES
The game now supports the use of new naming conventions in XSI – no more ODF magic required!
The old naming conventions are still valid – naming primitives “p_name” and mesh “collision_name” - but if you use these you still need to do soldier/vehicle/etc separation the old way through ODFs. Nothing old will break, but there’s no reason to do anything new using ODF definitions.
New names:
Primitives – p_-xxx-name ---- (“p” underscore hyphen [types] hyphen name)
Mesh – collision_-xxx-name --- (“collision” underscore hyphen [types] hyphen name)
xxx is replaced with the type definitions below…
[Types] is any combination of the following:
s – Soldier (soft) collision
v – Vehicle (rigid) collision
b – Building (static) collision
o – Ordnance (ordnance :^) collision
t – Terrain collision
f - Flag collision for Space CTF flyers to pick up the flag
So if you made a cube and wanted it to be used for soldier and vehicle collision, you’d name it
“p_-sv-SomeName”
Or if you wanted it to be used for ordnance collision only, you’d name it
“p_-o-SomeName”
Typicly ordnance collision needs to be more accurate so you could make a mesh and, you’d name it
“collision_-o-SomeName”
Apparently, you can use primitive collision geometry and name them accordingly in XSI and it will work without ODF editing.
animated in XSI, the star viper used all collision primitives and i just dropped them under teh bone i wanted them to follow and used an option file to keep teh collisions from merging into one mesh.
I played around with different type of cillisions.
The collision meshes didn't work (get default collision).
I named it in xsi as "collision_crewtransport" and specified it in odf (SoldierCollision = "collision_crewtransport").
Tried again.
Removed the entry from odf and named in xsi as "collision_-sv-crewtransport"
Still same problem.
Then removed the collision mesh and defined a couple of collision primitives
like this: SoldierCollision = "p_collision_main1" and named them accordingly in xsi.
Now only 2 of the 6 defined primitives work.
The 2 that work have their actual shapes. The other 4 are for some reason not rendered at all.
They all are cubes (with length=1 and all subdivisions=1) and only the vertices are moved to fit the required shape.
And the're all specified in the odf for soldier, vehicle, building and ordinance collisions.
Any idea what causing this?
There were no errors when munging or in the bfront2.log.
well for primitives to work thier transforms cannot be modified (freezing them will mess them up) and they must keep thier primitive properties so that when you select the object and hit enter the primitives property editor comes up, also make sure all your names are right and the collisions are under the bone that they follow in XSI.
You can use a low-poly collision mesh in XSI for soldier and ordnance because of the accuracy of where shots hit the object or where a soldier may jump onto the object without falling through, simply named:
collision_1
If you create more than 1 collision mesh, they will be merged into 1 during the munge process.
So if you created more than 1 collision mesh and specified each of them for different types of collision, you may not get the results you were hoping for, but you can create multiple collision meshes specifying the same collision types and simply name them:
collision_1, collision_2 .........and so forth, and of course they will merge into 1 collision mesh during the munge process.
You can use primitives for vehicle, terrain, and building collision where accuracy is not an issue, which basically only have to be an outline of your model, simply named:
p_-vtb-1, p_-vtb-2 ........and so forth
You can have up to 64 collision primitives per model or 63 primitives and 1 collision mesh .
Collision primitives can be either cubes, cylinders, or spheres.
Cubes can be scaled in x,y, and/or z to better fit the geometry they are conforming to. It is best to leave the original size of 8 units as is and scale the cube from there.
On the other hand, cylinders and spheres CANNOT be scaled. Instead, use the polygon properties such as radius and length to control the size of those 2 primitives.
All 3 primitive shapes can be moved up, down, side to side, forward or backward, and rotated.
You can freeze the transforms on a collision mesh, but not collision primitives.
If you use the collision naming convention specified above in XSI, you don't need to add anything to the ODF.
I removed all the non-working primitives.
Placed new ones and only rescaled/positioned them as objects and not the separate vertices.
Now the collisionprimitives work ok, so this problem is solved.
The problem of the collisionmeshes i'll save for another time or only use them for props.