Staticmesh collision optimize

[Veleran]

i wanted to ask if the collision can be optimized using a coll. check type 4,so that the coll. test is done to only the faces that receive a ray that is cast from a pawn,the player,projectile and any actor that moves and bumps on the staticmesh polys,
not testing the rest faces for collision.

The description says this

4 - StaticMesh face - ray starting from the position of the colliding actor

If this is true,even if the staticmesh is somewhat big and has 5000 polygons,
as five pawns walk on 20 of the faces-for instance,the rest 4980 faces will not check for collision yet-is that right?

I know on staticmesh you can have yet bitmap shadows,foliage,and the current collision mak
es the pawns to ignore the slide slope angle and they can climb up almost anyewhere,(hopefully the pawns dont ignore stepheight and they dont fall of short balconies)
this may improve later,and until then i thought to gain some framerate and wanted to be sure.

[bernie]

On staticmesh collisison type 2 is the most efficent. You should always use that.

[Veleran]

If type 2 checks first what the staticmesh bounding box collides,it might test everything inside it-is nt it?
I use some small low poly red imps (flying monsters) in flocks,which hover above the ground and bounce occasionally on the walls,and dont want them to be checked for collision by the terrain when they are not about to touch it.

[bernie]

type 2 checks bounding box first and if there is collision then checks per poly otherwise stops check.Thats how I understand it anyway.

[FridyWorm]

I have a question about 'StaticMesh': When I shoot to the Mesh, the projectile go trought it, is it normal?
Sorry if you already said this, but I don't understand all.

[Jay]

Collision Type 4 is not very efficient, because even if you make a ray-collision, RF has to test the whole mesh for collisions with this ray. The best way to optimize a terrain is to split the terrain into different 'sub-terrains' which are smaller and use collision type 2. This way not all polys have to be tested the whole time (because of smaller BoundingBoxes) and it all gets much faster.

[Veleran]

Not very efficient like if the actor is too small for a vertical poly,it runs through?
Ok,if you have a seperate staticmesh room filled with Staticentity furtinures with no motions (not pushable Sep's) the Sep b. boxes are nt dynamic and they are counted as static Is this right?

[Veleran]

If there is a cave,all inside it collide the cave bounding box.
Type 3 says it skips the b.box:
3 - StaticMesh face - colliding actor OBB (skipping bounding box test)

Is there a preset to check the cave collision only when the player falls down,(and climbs up again)?
Can type 3 check none of the cave polygons before the player falls?

Otherwise,i have to set the cave walls to no collision,place invisible clip brushes to prevent the flying monsters from bumping on the walls and ceiling,and make the cave floor a seperate staticmesh with collision.

Friddyworm,sometimes the projectiles go through,others they do nt.
Federico said that the projectiles ray for collision is nt good,but is better in the ngd rf release with the new physics-which was still in beta testing.

[Jay]

Skipping the bounding box test is the worst thing you can do because then RF will test all meshes every time (even if you aren't near them) and you cannot optimize it. Making invisible brushes and disabling the static mesh collision sure is the best alternative, it always will be faster.

Collision tests sadly don't work in a way that you can say, 'i drop an apple and wait until it drops to the floor. Look! There's collision!'. Collision tests must theorethically test all polygons in a mesh to be sure if there was / was no collision.

[FridyWorm]

Friddyworm,sometimes the projectiles go through,others they do nt.
Federico said that the projectiles ray for collision is nt good,but is better in the ngd rf release with the new physics-which was still in beta testing.

Ok, thanks! I hope it be repaired soon.

[Veleran]

A bridge using type 2 will not test collision untill someone enters its bounding box?

[Jay]

Yes. The collision will only be done if someone or something (an actor, can be anything, projectile, pawn etc...) enters the bounding box of the StaticMesh.

[wooper]

Yes. The collision will only be done if someone or something (an actor, can be anything, projectile, pawn etc...) enters the bounding box of the StaticMesh.

Hi again jay....
ok..if tahst so as you say....why isnt the projectile stopped
once that happens ..as it does when the PLAYER walks
to a staticmesh...he is stopped by it ??

what is the diff beween the two ??

also I tried it with the StaticEntityProxy
and it stops projectiles BUT..we cant walk thru an arch
made from it,,,BECAUSE of the bounding box ??

all weird all in all

what can we do to make a good game with good shapes
that are NOT practical to have invis brushes placed on them for collision...because of the variable shapes. ???

thx all again

Wooper

[Veleran]

If you dont like projectiles collision on staicmeshes as it is now then you have to learn to make levels in the editor with bsp using the available primitives,and all surfaces will be faced (non smooth).
It is not that bad,if you want to have a functional level in which you can hide behind walls and the rest.
You have to also learn to use the shear tool and cut brushes.

In the editor a bridge that is flat on top and curved underneath would be created by boxes for the upper part and a cylinder to cut the curved arch of the lower part.

Another example:An hemispherical dome or a vault can be created in the editor from hollow ring cylinder slices,the one on top of the other using smaller radius for the top of each brush.
You just have to use snaps-switch to 1 texel snap when needed and keep an eye on the circular brushes in the viewports to see if their center is snapped to the grid.

[wooper]

hi again...

thank you veleran..

but thats NOT the problem...

I have no problem making a level using BSP and cut brushes and such
I have been doing that style for over 10 yrs now......
BUT
as we have all seen....in RF...
its not really a good idea to use BSP geometry
as it takes hours or days to compile
only to see you have to make changes in it..
and then wait hours or days again..to see that
you still didnt get it right.

So...for a very basic outline of a map...BSP is excellent...but
for a larger level or a more complicated one...
it gets bogged down very quickly...

also as I noted above.....STATICENTITYPROXY
works perfectly for any shape that you can
walk around...such as pillars and rocks and statues..etc...
but for tunnels or caves or arches it does not work..
so..all that having been said,,.. and since no one
seems to know how to make that work...
I gues my goal now...will be to
make my actors that are arches and tunnels and such
out of basic model PIECES that can be assembled in the RF level
to form a whole actor group--with all the pieces having their own
bounding box....so it will become a passable tunnel or arch...

I will keep you informed if it works and how to do it then

so we can all say good bye to BSP as much as possible.

BTW using STATICENTITYPROXIES...
the lighting and collision BOTH work correctly and look very nice,
for level geometry,

thx again to all for help.....

Wooper