Jump to content
  • Advertisement
Sign in to follow this  

What should be taken into consideration when making 3D models into a game?

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

Hi, folks! smile.png


As I've tried to create my own game, I have slowly got into 3D modeling. I have created my 3D model, which looks pretty good. But if it looks good, it doesn't mean it's well compatible with the game itself.


The subject of this topic is both artistic and technical, although main focus is on the technical side. What should a 3D model artist take into consideration, when he's making 3D models to a game? huh.png I know this is somewhat game specific, since each game functions differently. I'd like to know what you think about this, though.


Some suggestions what to cover here: happy.png

- file formats

- physics integration

- polygon count

- skeletal animation

- textures

- tools

- vertex painting


It would also be nice to know how can one implement some of these features in both the editors and in game engine itself.

Edited by Helixirr

Share this post

Link to post
Share on other sites

It can be in anyway you want, since it depends on the engine/editor's features.


As for implementation, let's say you pick the FBX format. First, it's different from OBJ because it can also export animations, and a bunch of more informations. You also have the option of exporting it in ASCII for easier reading and see what you have available, but you can also export it in binary and use a binary reader (ex. notepad++).


After reading the file content's, you'll know what information you have available there. There's a bunch of numbers, some characters, etc... then it's time to figure these values out. You can google, and you can export different models, comparing values and figuring what each value means.

With that information fully figured out you are able to build the exact scene you exported from your 3D modeling program in your engine/editor.


You should take note, however, that even though you can achieve the same results through different techniques, it doesn't mean they're the same.

For example, if you animate a mesh by moving it's vertex each frame, you'll have this information in the file in a specific manner, and your engine/editor should be able to read it and duplicate it if you want it in your game. If you animate it using bones but you do the exact same thing, the information will be different so you'll have to make your engine/editor be able to read this as well.


If it's your first game though, I think it's better to define a single method, and work with it until the end, such as "for animated models, they must be Editable Meshes and have SkinWrap and Bones", so you can focus on working on the game than creating readers and figuring all sorts of possible information from the 3d program you choose.

Edited by Danicco

Share this post

Link to post
Share on other sites

Hello Helixirr, I am also doing a game all by myself. My advice is: screw the technical part.

What do we need to make our games? It is imperative you start from a design and a clear target. The only features we need to support are those required to make the game work. On top of that, we want to support all those features which can be implemented at low cost (to avoid adding them in a rush when we need them) and those we need to avoid go crazy.

When I stopped thinking about my design, I figured out I really required very little. Here are some lessons learned anyway.


File formats.

There are two variations. First is the aforementioned FBX. I've never used it myself but everyone keeps telling me I should. FBX has its own loading SDK and it appears to be very functional, especially when it comes to animation. There have been quite some threads about FBX in the forum and I'd say it's a very solid option.


What I'm currently using is Collada, accompanied by a JSON file. I use AssImp to load it up but the AssImp developers are focused on the graphics options only. Therefore, I had to find a way to encode my engine-specific data with the asset. There's a major issue with Collada (or perhaps with AssImp, I'm not really sure). Due to coordinate system transforms, you cannot really be sure about how to transform your vertices. The only robust solution I've found so far is the presence of special annotations.


OBJ is very old and relatively basic most of the time. You can get quite some mileage out of it but animations are a no-go.


Regardless of what you import from, runtime must use a condensed engine-specific representation.


Physics integration.

Every rigid mesh is to be enclosed in a bounding volume. In practice, hulls are sufficient in most cases. I suggest against using your physics API blob directly. Using an intermediate representation isn't very costly in terms of effort and buys some independence in my opinion. On top of everything, there's no need to wander through the API code (supposing you can for first) to figure out what's in the blob.


Polygon count and textures.

Supporting "nearly arbitrary" textures should take very little compared to supporting a fixed number. Such as 4. My models currently don't support textures at all, they rather pull up a shader for each draw-call and the shader itself causes the textures to load. Ideally each shader supports an unlimited amount of textures but of course this is a different thing in practice.

I've set the limit to 64*1024-4 vertices per-drawcall, I've set an hard limit of 1024 drawcalls per-model.


Skeletal animation.

Believe it or not, it wasn't necessary for my game so I left it out!


Tools, vertex painting.

Leave those to the DCC tool of choice. Your artist will be at home, will have all the tools he needs, access to all the documentation he needs and likely be happier. Mesh editing is hard. Leave it to the pros.


edit: minor layout

Edited by Krohm

Share this post

Link to post
Share on other sites

Hello Helixirr, I am also doing a game all by myself. My advice is: screw the technical part.

What do we need to make our games? It is imperative you start from a design and a clear target. The only features we need to support are those required to make the game work.

  I whole heartily agree. I to am starting to delve into 3D.  Keep it as simple as possible at first.  Concentrate on getting your model into a scene.  Move it around, without animation.  I started with Airships,  you know, Blimps, hotair balloons, Planes and spaceships.  Once Texturized they look good.  Then you can learn to animate those objects without animation.  Make a plane turn, Bank, and Flip.

  From there I moved onto adding animation to the planes through the modeling software's animation sequence by making the propellers spin on the plane, then wrote a small test code to watch it happen.

  Then just keep building.  Small blocks make big houses!

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!