Jump to content
  • Advertisement
Sign in to follow this  

3D format

This topic is 4867 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

3D format for what? Storing animated models? Storing static object geometry? Storing levels? Storing molecular structures?

Share this post

Link to post
Share on other sites
Well, usually people create their own formats, to fit their needs at the time, and as those needs change, the format evolves. I don't think anyone here can tell you what to implement into your format, it has to be you to decide what suits your engine/game and implement it.

Here are a few blocks of data you might consider adding to your format:

- Positional data
- Colors
- Texture Coordinates
- Normals

- Indexed format
- Triangle Strips format

If you also want to store animation, there are 2 major schools of mesh animation, "Vertex Interpolation", aka "Vertex Tweening", which involves storing the state of vertices per frame, and "Skeletal", where strips of vertices are grouped hierarchicly, and matrix or quaternion transformations are aplied to motion the model. In this format we store much less data, just the Matrices/Quaternions per frame.

Per-Frame: (v-tweening)
- Vertex positional data
- vertex normals
- (it makes no sense for vertex colors and/or texture coordinates to change on a per-frame basis, so you need not store those)
- (because the number of vertices per frame remains constant, it also makes no sense for the face index information to change, even if using triangle strips, so you need not to save those either. For more on this I advise you to check up on the MD2 format).

Per-Frame: (skeletal)
- Matrix/Quaternion information per node (how this node rotates on this frame).
- (you'll also need to define which vertices are attached to which nodes, but of course you don't do this per-frame)

Skeletal is more complex to implement, but gives you better, smoother results, and a smaller filesize footprint. Both methods can be accelerated using vertex shaders I believe.

You might also look into saving diferent "levels of detail" of the same model, in the same file, that way you'll have it pre-computed, and won't need to calculate it on the fly in-engine.

Regarding game levels, those are usually better saved on a diferent format. No doubt 3D levels have to store 3D information, in many things similar to the 3D model format, but you also have to save specialized data regarding levels, for example in "Binary Space Partioning Tree"-format, Octree format, you might want to save triggers (events that are triggered when the user goes through a certain area, or interacts with the environment in a certain way).

3D Model formats are very cut and dry, because you pretty much have a rough idea of what you want, while Level File formats are very game-dependent, and as such might vary wildly from game to game.

Other things you might look into is the diference between a 3D Object File Format, and a 3D Mesh File Format. The Mesh format stores only the three-dimensional data of the model (like we saw above), while an Object file format stores much more information, like:
- Textures the model uses
- Shaders (Vertex, Pixel)
- Sounds for this model
- Model Parameter Details (things like, physical parameters for the physics engine, AI script to use, what sounds are triggered when event "A" or "B" fires, name of the model, etc, etc, etc)
- etc...

In conclusion, I advise you this book:
- Focus on 3D Models

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!