Sign in to follow this  

Building entire level in 3dMax

This topic is 4340 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I start making a level - outdoor - for car race game in 3d max. Now I wonder if it is smart way to do entirely level in 3d max. I mean everything - form landscape,tunnels, buildings, trees,etc. I will use engine which can import DirectX files. If this is a good way, how should I export a level. As one big mesh or as few smaller meshes - separate landscape, buildings, trees, etc.??? Is any way in 3d max to mark collision object or points? What is your suggestion for making a game level? I know that one solution is in making my own level editor, but at the moment I try to avoid this solution. Thx, Denis

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.......

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

This topic is 4340 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this