theoretical questions

[super-truite 54]

Just some questions I am trying to find an answer to out of curiosity:

1) Why does the geometry need to be a convex hull? I don't remember much about convexity in mathematics, but I would say that you can define easily the interior of the volume with an equation of the type f(x,y,z)<0 ? If this is true, it could help to compute wether an other geometry hits the geometry or enters inside the geometry which would allow to make the engine "understand" collisions. Is there a engine-guru who can comfirm that?

I think it is interesting to understand that because from my understanding, most of the annoying glitches in video games come from a mismatch between the geometry and what you see.

2)I know nothing about physX, so what is the difference between the geometry LOD and the PhysX geometry LOD? Same question: why does it have to be convex? Any pedagogical reference to understand PhysX?

3)Vertex limit and proxies: Why is there a very limited number of vertices allowed per models while you can in fact add a bunch of new vertices via proxies?

Is it because the proxy are somehow processed in a different thread when displayed? Is there a limit on the number of proxies or a limit on the number of vertices in a model+proxies set?

[PuFu 4600]

Notes from my own observations, the only ones able to give you a proper answer all your questions is one of the BI developers.

1. Most of the time, in order to keep the collision calcs real time and have them work that way, you need to have a rough approximation. The convex rule is not that bad, since you can use multiple simple geometric forms to cover the visual LOD shapes. I get what you are saying, regarding a better collision shape would mean better collision behavior. In theory, you could have lower level LOD (i am not talking about RV engine here, but physics models in general) for those sort of stuff. But as far as the SDKs i messed with, most use convex shaped for collision geometry - or the game engine "cooks" it automatically for the user anyways.

2. I think the overall information and detail can be found by browsing (i agree, to some degree aimlessly) here: https://developer.nvidia.com/sites/default/files/akamai/physx/Index.html

For differences between physix LOD and normal geo LOD, your best bet is to open a sample. What i gather is that physix needs its own LOD for physix calcs (i gather it is active no matter if the class is defined or not as a physix class), but for non physix calc (collision should come here for instance), you need to normal geo lod.

3. I would assume that is O2 legacy issue to be perfectly honest, or a hard limit defined by BI for whatever reason(it is the same as A2, which was there due to being DX9). I have explained numerous times the limit and the reason behind A2 hardlimit for polygon count (in fac the vert normals associated with indices buffer yada yada - http://forums.bistudio.com/showthread.php?120471-Model-Requirements-for-ArmA3&p=1950430#post1950430). Acording to m$ info around dx11, while for dx9 the limit is 2^15, if i understand corectly, due to 32-bit float, it is closer to 2^32.

That being said, cryengine for instance, supports 2^16 triangles per mesh (a single mesh object, if you are familiar to any 3d software package our there you understand what i am talking about ), but can push over 500k if you have multiple individual meshes on a single export. Mind you those are not proxies.

Proxies are not processed differently, the limit (if there is one) is related to draw calls(also known in arma community as section counts), not individual meshes. To test it out, push in the scene in game as many heavy polygon assets per square meter. See that the game dips in FPS after quite large number of those models are in (it will firstly try and keep FPS up by lowering to secondary visual LOD).

AFAIK, there is no limit to number of proxies used. Might be wrong here, never tried to test out and see how many i can stick in a single p3d. The number of vertices for p3d used as proxy remains the same as any other p3d.

Hope that helps

Edited February 14, 2014 by PuFu

[super-truite 54]

Thank you Pufu!

1)I guess for the first question, the ideal would be a better algorithm which automatically make slices of models to reduce the mismatch between the geometry LOD and the "display" LOD (don't know how to call it), because it can be painful to do that by hand. I was just curious if the mathematical interpretation was right (for non convex geometries, I would say that you cannot define a unique function which describe the surface and it becomes tedious to find in real time intersections of models). But I kind of think my guess is correct.

2)Ok, I thought the PhysX LOD was used for collision stuff as well. It is still not clear to me why it should be convex, but if my curiosity is too strong, I guess I will find the answer in the doc you linked. Must be again because of the non degenerate equations of the model surface which would probably ease up the computation of moment of inertia and so on. I am a bit confused by the fact that it is so easy to set up (seeing the doc on the biki). It would be more logical to me to give some volume info (mass points inside the convex Hull) in order to tweak the physical behavior, but I guess you can acheive a realistic behavior by tweaking some parameters rather than making a perfect mass distribution of the model.

3) From what I have seen, it is indeed pretty close to 2^15/mesh even in Arma 3. Sometimes it can be even lower because of a subtlety with hard/soft edges from what I read in similar posts as the one you linked.

OK, I thought the different LOD where used only depending on the distance. Didn't know that the engine would switch to another to keep the FPS rate.

Thanks for the explanations.

indiscreet question: did you work on the video game industry or are you just an experience modder?

[x3kj 1247]

I think it is interesting to understand that because from my understanding, most of the annoying glitches in video games come from a mismatch between the geometry and what you see.

What glitches do you have in mind? I don't think the "mismatch" between full visible geometry and physx mesh is the reason for many glitches. The difference is only noticeable in very specific, precision moments like driving through a gap that is basically the width of the vehicle.

From what i've seen so far (e.g. vehicle suddenly jumping) it's mainly if 2 collision geometries either intersect each other for whatever reason, or if they are forced into each other in an overstraint situation

E.g. if you put a tank between two buildings that have exactly the same width as the tanks collision geometry in a non-simulated state. If you place them that way and hit the imaginary "simulate" Button weird things will happen because all the collision geometries will want to repell each other to prevent intersection.

Also the underlying system for animation is partly fault. E.g. you can turn a whole tank if you collide with the tank barrel on a building. The rotation animation has infinite force, so it turns the tank no matter what if the user moves his mouse in the turret. So there's a chance to wedge collision geometry between the tanks own geometry again leading to "freakouts"

For tanks driving behaviour you also have to keep in mind that the tracks are not simulated at all with PhysX. For simulation it's only a vehicle with many wheels, which creates great discrepancy between real behaviour and simulated behaviour.

Edited February 14, 2014 by Fennek

[PuFu 4600]

Thank you Pufu!

1)I guess for the first question, the ideal would be a better algorithm which automatically make slices of models to reduce the mismatch between the geometry LOD and the "display" LOD (don't know how to call it), because it can be painful to do that by hand. I was just curious if the mathematical interpretation was right (for non convex geometries, I would say that you cannot define a unique function which describe the surface and it becomes tedious to find in real time intersections of models). But I kind of think my guess is correct.

2)Ok, I thought the PhysX LOD was used for collision stuff as well. It is still not clear to me why it should be convex, but if my curiosity is too strong, I guess I will find the answer in the doc you linked. Must be again because of the non degenerate equations of the model surface which would probably ease up the computation of moment of inertia and so on. I am a bit confused by the fact that it is so easy to set up (seeing the doc on the biki). It would be more logical to me to give some volume info (mass points inside the convex Hull) in order to tweak the physical behavior, but I guess you can acheive a realistic behavior by tweaking some parameters rather than making a perfect mass distribution of the model.

3) From what I have seen, it is indeed pretty close to 2^15/mesh even in Arma 3. Sometimes it can be even lower because of a subtlety with hard/soft edges from what I read in similar posts as the one you linked.

OK, I thought the different LOD where used only depending on the distance. Didn't know that the engine would switch to another to keep the FPS rate.

Thanks for the explanations.

indiscreet question: did you work on the video game industry or are you just an experience modder?

1. There are scripts (at least for max and maya) out there that would do exactly that (voxelor based solutions and pro slicers comes to mind).Truth be told, bar the voxeletors scripts i have used, for any other slice script it should do more than simply slice your model up: it should do it keeping all your angles >180 degree, thus having multiple slices where you have concavity.

Quick example for you:

http://i.imgur.com/IOBteZO.jpg

PS: my math is not all that great in the recent years, but that i guess function should do it yes.

2. I am assuming it is not used for collision, based on the fact that models done for A2 with no physx LOD do work in A3 without issues related to collision. Characters as well, not only vehicles btw. I wasn't able to find a conclusive answer by quickly searching through it for you. The information regarding convex meshes is how to set it up to use buffers and what not. There is no overall information around there after a quick look, but i am certain google could help you here, via numerous forums for other SDK solutions (UE3/4, CE3, Unity etc).

Regarding physical behavior, i would say it is better left outside the physx LOD, unless you can actually change general phx behaviour. I read on the nvidia developer page that 256 verts is the upmost that can be used by default (and i am pretty sure BI didn't alter this default setting).

3. Yeah i know. It is the same. I can't tell if it is O2 or game engine limit since you cannot push O2 further.

Sometimes LOD1 remains the same if it is in your face, but game engine will adjust the distance it changes to a lower lod based on drawcalls as far as i can tell. For instance having secondary visual LOD level in named LOD010 doesn't mean the engine will change it further than having it named LOD002. As well, there is no relation between the number at the end of a visual LOD and the distance game switches to it. Or better said it is arbitrary and, just like with polygon max number, it is based on a number of factors (in this very case dynamic changing factors, including vram and video settings).

Indiscreet answer:

i have done work for the video game industry, but i have not worked in it per se :P. And I am working in related environments and fields - 3d sides of things anyways ;) + if i can't get something, i read it up, and i conduct some experiments on my own.

As a disclaimer, all the above, as previously said is based on my own findings and test. Unless BI does reply to you, all is a bit of an assumption really.

---------- Post added at 17:17 ---------- Previous post was at 17:10 ----------

For tanks driving behaviour you also have to keep in mind that the tracks are not simulated at all with PhysX. For simulation it's only a vehicle with many wheels, which creates great discrepancy between real behaviour and simulated behaviour.

That is weird because afaik this was the main reason for the switch from sdk2.x to sdk3.x:

from: https://developer.nvidia.com/sites/default/files/akamai/physx/Docs/Vehicles.html#wheeled-n-wheeled-cars-and-n-wheeled-tanks

he PhysX vehicle SDK also supports tanks through the use of the PxVehicleDriveTank class. Tanks are different to multi-wheeled vehicles in that the wheels are all driven through the differential in a way that ensures that all the wheels on the left-hand side have the same speed, and all the wheels on the right-hand have the same speed. This extra constraint on wheel speed mimics the effect of the caterpillar tracks but avoids the expense of simulating the jointed track structure. Adding the geometry of the caterpillar tracks is as easy as adding an actor shape down each side and setting up the collision and query filters as appropriate for the tracks. The motion of the caterpillar tracks could be rendered with a scrolling texture, safe in the knowledge that all wheels have the same speed, just as though they were properly constrained by the track rotation.

Creating a PxVehicleDriveTank instance is very similar to creating a PxVehicleDrive4W instance with the exception that tanks have no concept of extra wheels that are not connected to the differential: all tank wheels are driven. The following code illustrates how to set up a 12-wheeled tank:

PxVehicleWheelsSimData* wheelsSimData = PxVehicleWheelsSimData::allocate(12);
PxVehicleDriveSimData4W driveSimData;
setupTankSimData(wheelsSimData,driveSimData);
PxVehicleDriveTank* tank = PxVehicleDriveTank::allocate(12);
PxRigidDynamic* vehActor=createVehicleActor12W();
tank->setup(&physics,vehActor,*wheelsSimData,tankDriveSimData,12);

Controlling a tank is quite different to controlling a car because tanks have a completely different steering mechanism: the turning action of a tank arises from the difference in left and right wheel speeds, while cars turn by the action of a steering wheel that orientates the front wheels relative to the forward motion of the vehicle. This requires quite a different set of helper classes and functions to smooth the control inputs. Instead of a PxVehicleDrive4WRawInputData for N-wheeled cars, PxVehicleDriveTankRawInputData is used for N-wheeled tanks. Further, instead of PxVehicleDrive4WSmoothDigitalRawInputsAndSetAnalogInputs/PxVehicleDrive4WSmoothAnalogRawInputsAndSetAnalogInputs for N-wheeled cars, PxVehicleDriveTankSmoothDigitalRawInputsAndSetAnalogInputs and PxVehicleDriveTankSmoothAnalogRawInputsAndSetAnalogInputs are used to smooth the keyboard and gamepad inputs for tanks.

PhysX tanks currently support two drive models: eDRIVE_MODEL_STANDARD and eDRIVE_MODEL_SPECIAL. The drive model eDRIVE_MODEL_SPECIAL allows the tank tracks to rotate in different directions, while eDRIVE_MODEL_STANDARD does not. These two modes result in quite different turning actions. Drive model eDRIVE_MODEL_STANDARD simulates the usual turning action of a tank: pushing forward on the left(right) stick drives the left(right) wheels forward, while pulling back on the right(left) stick applies the brake to the right(left) wheels. eDRIVE_MODEL_SPECIAL, on the other hand, simulates a more exotic turning action where pushing back on the right(left) stick drives the right(left) wheels backwards. This can result in a turning circle focused at the centre of the tank. The smallest possible turning circle of a tank in eDRIVE_MODEL_STANDARD will have a focus at a point along one of the caterpillar tracks, depending on whether the tank is turning left or right.

[super-truite 54]

@Fennek: I was thinking of glitches like being unable to walk on some rocks, seing through stuff ect. It is quite common to see those kind of glitches.

@Pufu,

Thanks for the info on the scripts (I already tried one for 3dsmax, but it was kind of the same as the O2 "convexify tool").

I read a bit the PhysX doc too, but from what I have seen, there is not much info about why things are done that way and in particular why the LODs need to be convex. But again, it must be just because it is easier to compute stuff in real time like for the collisions.

More precise wrong "handwaving" mathematical statement about convexity ;):

I guess a good definition to apply convexity to our problem is that if you take a point inside a convex closed surface and you point one direction, you hit exactly once the surface. For a concave closed surface like a cup, there exists no such "inside" points (you see that wherever you put your point, you will be able to hit the surface at least twice in one direction). It is then easy to parametrize the surface with a unique function of the spherical coordinates (r(theta,phi)). To check if a point hits the surface, you then just have to check if the distance from it to the center of the model is above r(theta,phi) or not (the angles are defined by the direction formed by the center and the point).

[x3kj 1247]

@Fennek: I was thinking of glitches like being unable to walk on some rocks, seing through stuff ect. It is quite common to see those kind of glitches.

If the rock doesnt has a road geometry LOD it can't be walked on. Seeing through stuff is most likely because of the camera. Objects that are too close to it are sliced off. Most notably when you try to create custom weapons and misplace them somehow.