SWBFGamers

I am currently working on some storm commando units and I really wanted incorporate some commando inspired equipment. I thought it would be a cool idea to get some new probe droid models to work as recon droids. So I tried re-skinning the BF2 auto turret model and  replaced the geometry on the remote probe droid's ord odf. Unfortunately there is a problem with collision with that model, it can move but it cant go through doors and has problems moving over some objects.  My Request if possible  for this is if someone would be willing to fix the collision for this model to work as a recon droid. And if possible get rid of those square things underneath the droid please. I know Republic Commando(the user) released a auto turret model to be used a probe droid, but that has the same problem as the Bf2 version.

Specific Auto turret Model:
http://www.mediafire.com/download/o8c54d491r6mbgb/auto_turret_recon.rar


(https://www.swbfgamers.com/proxy.php?request=http%3A%2F%2Fimageshack.com%2Fscaled%2Fmedium%2F849%2Fgp00.png&hash=796c38f3100c27d25e1d0cee602f5bd11e877c54)


My second request is for a new model like this to be made and to work as a recon droid replacement for the rebels:

(https://www.swbfgamers.com/proxy.php?request=http%3A%2F%2Fimageshack.com%2Fscaled%2Fmedium%2F834%2Frvxb.jpg&hash=b2d27a314fcf2d38f9bee7da16299baf0e6e0b7d)

I think this one could have the potential as well to be used by other modders beside myself. Does not necessarily have to be skinned like it, the overall structure is what interests me. If any of these requests can be met, I would be very grateful.

Quote from: 411Remnant on August 21, 2013, 10:47:15 AM
Unfortunately there is a problem with collision with that model, it can move but it cant go through doors and has problems moving over some objects.  My Request if possible  for this is if someone would be willing to fix the collision for this model to work as a recon droid. And if possible get rid of those square things underneath the droid please.

For the first one, here is a test model. (test_com_weap_inf_dropturret2.rar)
-edit removed, cause RC did it below
Just a test, mind you.
I just removed the collisions from it. The mungers should be able to compensate.
If it's moving through doors correctly, then I'll try to pull the boxes off the bottom.

I pulled the boxes off for you Tirps :P
-Since you're doing that, I'll see if I can get a good collision primitive working (an accurate one atleast)
-edit: Added finished link to last post.

Trying tirpider's first then moving onto republic commando's thing. :tu: I honestly didn't think I would get this fast of a response . Give me 3 more minutes from now, munging.

Edit: Sweet RC, well ill have to remunge now.  :P may take 10 minutes to test . Thank you both for this!

Quote from: 411Remnant on August 21, 2013, 11:27:44 AM
Trying tirpider's first then moving onto republic commando's thing. :tu: I honestly didn't think I would get this fast of a response . Give me 3 more minutes from now, munging.

The one I uploaded is just the MESH without the boxes (3D object, which doesn't include what it needs to move, have collision, gun points, Shadow volume, or gun rotate axis), So tirpider doesn't have to hex them off, if it worked ingame by itself, I'd be greatly amazed :O

I'm testing the full one now.

Interesting, well it doesn't have as much trouble going over objects. When he encounters a door, he seems to go under the map and pops back up kinda like a mole. Its a great start! I can get video of it if you need it.

heh.. wow.. I had to re-install a program to see the boxes and just got them off.

com_weap_inf_dropturret2(no coll no boxes).rar
-edit removed, cause RC did it below

So we know what's going on, this model:
- has had the collisions removed
- has the boxes removed from the mainmesh ans the lowrez
- has had the goofy geometry removed from dummyroot

Current issues:
- when it comes to a door, it ducks below the map. (this has to be because the collisions were removed.)

thinking.....

-edit
Ok, the normal probedroid does have collisions.
com_weap_probedroid.msh collisions:
p_sphere
p_buildingsphere

This one
com_weap_inf_dropturret2.msh collisions:
p_-so_sphere
p_-vbt_cube

This is where we look in the docs for collision naming conventions.

I see a few possibilities:
- rename the collisions -> happily ever after
- hack the original probedroid's collisions in (may not be lined up appropriately)
- learn how to actually make collisions (not enough hacking)

Any one of them could work.. going to read the docs now.

-edit
Adding the relevant part of the artguide here for all of us:
[spoiler]
Appendix C
Collision Meshes

Collision meshes are simple low-poly meshes that are used by the game engine to calculate when and how objects collide with each other. There are 2 types of collision meshes used in SW BattleFront: collision meshes and collision primitives.

Collision Mesh
1. This is usually a low-poly yet fairly conforming version of the original mesh. It is most often used for soldier and ordnance collision since those are most obvious ways to see collision mesh correctness. For example, you can see the ordnance collision on an object by shooting at it with any weapon. If the collision is sloppy and covers gaps or is not correctly aligned with the original mesh, then you will see the laser blasts hit empty space or inside the actual geometry of the model. The collision mesh has to be named "collision", or if there are more than one, "collision", "collision1", "collision2", etc. Multiple collision meshes will all get merged into one when munged. This is very important when considering rule #3. Do make the collision mesh a child of the root node or its corresponding node, and make sure its global center is at 0,0,0.

2. Enabling the Collision Mesh: if the vehicle .MSH file has a corresponding .OPTION file, then it might contain the argument "-nocollision". This is to prevent generation of a default collision mesh using the model's full geometry. If you have specified a collision mesh in XSI, you will need to remove this argument from the .OPTION file.

3. Collision meshes can NOT be used on moving parts (turrets, bones etc). When the vehicle is munged, all collision mesh nodes are merged into a single non-articulated collision mesh. If a moving part on a vehicle requires collision, it will have to be specified with a primitive.

4. If a vehicle has a collision mesh, it will automatically be used when colliding with soldiers and ordnance. Collision meshes (on vehicles) are not used for any other type of collision. Primitives must be used when vehicles collide with terrain, buildings, and other vehicles.

Collision Primitives
--- Collision Primitives are a cheaper and faster way of computing collision for the game engine. It is also the only way to have collision on moving parts such as turrets or bones. 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. Also very important, primitive collision pieces CANNOT be frozen or lose their primitive properties. This information is taken directly into the game engine and if it is lost, the engine will most likely ignore the primitive collision. Lastly, DO NOT move the center of primitive collision either or else the proper information will be lost as well.

---There is a limit of 32 collision primitives per model (or 31 primitives + 1 collision mesh).

---Colliding with buildings (including bridges, stairways, etc) is a little tricky with primitives. It is best to use spheres and cylinders on the vehicle for building collision. Boxes just get converted to spheres in the code so long skinny boxes end up colliding as if they were large spheres. ***Note: if you must use boxes for the vehicle, you can instead create primitives for the building msh. In the building's odf file, you can then specify to use these primitives for VehicleCollision***

******** Specifying Collision in ODF file ********
---For any game object (true for vehicles and buildings), you can specify which collision primitives will be used when colliding with another object. For example, the AAT ODF file has the following:

TerrainCollision = "p_base"

VehicleCollision = "p_base"
VehicleCollision = "p_tank"
VehicleCollision = "p_barrell"
VehicleCollision = "p_turrett"

SoldierCollision = "p_base"
SoldierCollision = "p_tank"
SoldierCollision = "p_barrell"
SoldierCollision = "p_turrett"

BuildingCollision = "p_ball1"
BuildingCollision = "p_ball2"
BuildingCollision = "p_ball3"
BuildingCollision = "p_ball4"
BuildingCollision = "p_ball5"
BuildingCollision = "p_ball6"
BuildingCollision = "p_guns"
BuildingCollision = "p_turrett"
BuildingCollision = "p_barrell"
If you wanted to, you could also use OrdnanceCollision = "p_whatever" to specify what primitives to use when ordnance collide with the object.

---Finally, if
1. a vehicle has a collision mesh, AND
2. SoldierCollision and/or OrdnanceCollision is specified in its ODF file,

then the primitives specified in the ODF file will be used (for SoldierCollision and OrdnanceCollision) as well as the collision mesh. In this way, you can create a collision mesh for the non-moving parts of the vehicle, and add collision primitives for the moving parts, and use them both when colliding with soldiers or ordnance.
[/spoiler]

Actually, I added an accurate collision, and it sort of (not as much as) has that same issue. But it has perfect collisions with people and vehicles.

edit: as the last post says, it still needed a primitive.

Ok.
If it's colliding with people and such ok, but still dips below the map when going through doors....
Does it's ODF have a BuildingCollision line?
Seems like that would fix it.

Quote from: tirpider on August 21, 2013, 12:01:40 PM
Ok.
If it's colliding with people and such ok, but still dips below the map when going through doors....
Does it's ODF have a BuildingCollision line?
Seems like that would fix it.

Well what do you know! Fixes it, works just fine.
The one collision primitive I created "Collision" is a lower-poly shape of the model itself, when I edit the ODF, I just labeled all the Collisions from what they are to "Collision."  - This replaces all the old funky ones.
-
Is there anything we can do about camera angle, or is this ODF specified?

Cool!
Camera is all in the ODF. (usually toward the end.)

Now, about that 2nd probe.
I've seen one somewhere, but don't remember if it was a SWBF, SWBF2, TCW, or JK asset...


(btw, I'm comming to you with all my future collision issues, RC :P )

can I get that collision fix line please?  :P

Also I could have sworn I saw a model like that to but could never find it on gametoast.

View last post for fixed model.

After searching through my archive, all I could find in the way of the practice droid is a very low poly one from the Raven_Animation_and_Model_Source_Files (I got them from gamefront)

It's in MD3 format and appears to just be a sphere with a simple skin.

It needs to be scaled and set up with collisions and hard_points and such. (and converted from md3, of course.)

Would probably be easier to build from scratch.. don't know.

-edit.. oh yeah.. the source files include the .xsi
Added them to the rar

And for those interested in source links:
[spoiler]http://jediknight3.filefront.com/file/Raven_Animation_and_Model_Source_Files_Part_1;26624
http://jediknight3.filefront.com/file/Raven_Animation_and_Model_Source_Files_Part_2;26625
http://jediknight3.filefront.com/file/Raven_Animation_and_Model_Source_Files_Part_3;26626[/spoiler]

hmm, im still getting some odd stuff. ill go ahead and record some video, this droid must really hate doors  :rofl:

Quote from: 411Remnant on August 21, 2013, 01:46:42 PM
hmm, im still getting some odd stuff. ill go ahead and record some video, this droid must really hate doors  :rofl:

.. That isn't good.
Seems to work fine over here(except camera angle, which is confusing), on the other hand, the remote droid seems to hate UV mapping (as does anything I touch).

How on earth did the UV get messed up... Grr

ive used rends Mark4 probe droid model, same method with just switching the geometry. It seems to work flawlessly, maybe it can be studied and the same properties from this model can be transferred over to the storm recon. also I noticed that the box things still seem to be present in BF2(testing it in BF1). ill see what happens.

Rends Mark IV probe droid:

http://www.mediafire.com/download/k8ik8kgmohdtdtg/rend_mark_4.rar


you could try these heights for it:
[spoiler]SetAltitude     =1.5
Acceleraton     = 15.0
MaxSpeed        = 6.5
MaxStrafeSpeed  = 8.0
MaxTurnSpeed    = 3.6

CameraHeight    = 2.3
CameraDistance  = 4.5

TrackOffset     = "0.0 0.0 4.5"
NormalDirection = "0.0"
AimValue        = "1.0"[/spoiler]

Looks like this one's going to be more than a quick fix.
Got the rends model for reference.
Using the model from the first post and RC's latest as a base.

I'm kinda useless regarding xsi work at the moment, but I'll continue to look for stable hacky solutions.

Have to find an appropriate door to put in my test level.
(I'll probably just crash a tantive iv deck into my desert.. heh ... wait.. idea for a map....)

I'm thinking the shadow volume is goofy (its actually showing up ingame), which I didn't remove the boxes on.
Are the boxes black or white?

http://www.youtube.com/watch?v=YXLACXx0si4&feature=youtu.be

Also what you said is true about the shadow boxes because they appear the same way in both games. RC, try jabba's palace on BF1 and go through the that dark hallway that had those mini rooms with the doors that openup/close. you can go through the door but you can't come the same way out(or at all for that matter, kinda like a trap :p). If it's ok with you guys, I am thinking about posting this at gametoast to, could get some more insight on it.

Sounds like a good plan

You need to add collision primitive sphere to your recon droid. Without it, the game, will be generate overhuge collision.

*Facepalm* wow....
What a failure I am.

The model isn't the problem, its the ODF.
This is the original ODF collision lines we've been using BuildingCollision = "p_buildingsphere"
VehicleCollision = "p_buildingsphere"
OrdnanceCollision = "p_sphere"
SoldierCollision = "p_sphere"

The original (like Tirpider said before) has the primitive sphere named as p_-so_sphere
p_-vbt_cube

I have deleted p_vbt_cube in that update (it still has issues with the shadow volume black/white boxes sticking out, I cannot seem to get the hierarchy to hide in XSI) But like Sereja said, we needed the Sphere primitive.
-Now when I put the collision in, it wasn't quite the same as a primitive, so it acted funny

So for buildings, it should be BuildingCollision      ="p_-so_sphere"
The rest can still use "Collision" that I added.
=================================
English:
Replace Collision lines in your ODF to

BuildingCollision      ="p_-so_sphere"
VehicleCollision      = "Collision"
OrdnanceCollision      = "Collision"
SoldierCollision      = "Collision"

And that permanantly fixes all your collision bug issues, and if you see a collision is funky for one of the collision types, change it to p_-so_sphere, and it should correct it because of the slight difference between mine and the stock one.

Thank you for slipping that into my head, Sereja :P
Now for the shadow volume..

remove the sv_  null and just add -hiresshadow to the .option?
It isn't that complex a model so I don't think it would cause too much trouble.

Quote from: tirpider on August 21, 2013, 08:42:53 PM
remove the sv_  null and just add -hiresshadow to the .option?
It isn't that complex a model so I don't think it would cause too much trouble.

Good idea.

Tested ingame, and great news! Thanks to the adjustments you guys made, he can go through doors now.  :cheers: Still a few problems, but that was my main concern. one funky thing I found was that he can phase through some walls and sink under the map, though I may have re-munge to see if I missed anything.

Edit: Interesting, adding "p_-so_sphere" to all the collision makes it goes through doors, but it also enable it to clip through walls and people now. 

Well, it needs it for building collision, or else you will get almost no collision at all...
The "Collision" one works fine for everything else, but if you were to use it on buildings then you get what you just got.

Its as good as can get unfortunately. Do the black mesh pieces still stick out the bottom?

That actually is gone, great job with the model! I guess if this works with BF1 perfect, then that's great too. Its becoming a hassle to get it to work with BF2 like it should, im going to try a few more things before I give up. Thank you guys for all the help! Ill update in a bit.

Edit: Hey republic commando if you want to release it as an asset or an update to your auto turret model for BF1 be my guest.

It's quite a change, so I'll release it in a new topic.
- http://www.swbfgamers.com/index.php?topic=6995.msg74513;topicseen#new
Thanks yall, it's 10x better than the original now.