Building entire level in 3dMax

You should export all static meshes(the ones which will not change during the game) together as a single mesh and all the dynamic meshes(the ones which moves or change appearance during the game) one in a separate file.

Quote:

Original post by xissburg You should export all static meshes(the ones which will not change during the game) together as a single mesh and all the dynamic meshes(the ones which moves or change appearance during the game) one in a separate file.

Um, no.

If you want to re-use assets for different levels you will want to export props as seperate objects and then place them around the level as needed. If you export everything a 1 mesh not only do you have assets that can't be re-used, but you have completely defeated the purpose of culling, and your entire level will draw all the time.

You could mark objects in max with user properties and then with an exporter or max script export it as a relatively simple level file.

Its also useful to keep objects distinct so that you can use differnet rendering passes on them: for example, in a racing game, you might want a more complex lighting calculation on objects near to the track, where the player will see them, and more basic lighting for distant environmental objects.

As for collision, its normal to have seperate collision objects that are much more basic objects than the ones you need for the visuals. Many of your objects will have dense meshes inorder to look good and for texturing purposes - it doesn't make sense to be calculating collision data from these, when more simple geometry would suffice.......

Titntin, you said that for collision, its normal to have seperate collision objects that are much more basic objects than the ones you need for the visuals.
Is this mean, that I should put inside complex mesh a one more basic object just for testing collision - for example in complex building, I should put a simple box mesh and then later in code, test a collision with this simple box and not with complex mesh ?

Denis

Quote:

Original post by denisnovak Titntin, you said that for collision, its normal to have seperate collision objects that are much more basic objects than the ones you need for the visuals. Is this mean, that I should put inside complex mesh a one more basic object just for testing collision - for example in complex building, I should put a simple box mesh and then later in code, test a collision with this simple box and not with complex mesh ? Denis

I think what he means is, collision meshes, since they aren't seen by the player, are geometrically much more simple than their underlying object meshes. For example, imagine a chair model. The corresponding collision mesh could be a simple cube that simply encompasses the chair.

I don't think you would only test with this, but build all collision meshes similarly (simpler geometry than the collision object).

Perhaps Titntin can elaborate better than I.

Some games have several different collision models. FPS games for example, often use collision geometry that is very accurate to the model for weapon shots, since you wouldn't want a shotgun blast to hit an invisible box around a chair. You'd want it to hit the actual chair, and probably leave a mark and such. Racing games and other game types probably don't need this higher resolution version. Low res collision proxies are especially important for physics systems. Many times a physics system will use low res invisible collision models while other parts of the engine such as weapon hit detection will use higher res versions.

For example, again an FPS example. To a physics system, the players character might be represented as simply a bounding box, sphere, or ellipse. When someone shoots a shotgun, the collision system might test against that first, and if successful, then perform collision with more accuracy, such as against the bounding boxes around each body part. This hierarchy of tests is very important for collision as well as rendering, which is why scene managers such as quad tree and octtree are commonly brought up.