Jump to content

  • Log In with Google      Sign In   
  • Create Account


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


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 Helixirr   Members   -  Reputation: 141

Like
0Likes
Like

Posted 22 March 2013 - 05:12 PM

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, 22 March 2013 - 05:14 PM.


Sponsor:

#2 Danicco   Members   -  Reputation: 449

Like
0Likes
Like

Posted 22 March 2013 - 07:09 PM

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, 22 March 2013 - 07:10 PM.


#3 Krohm   Crossbones+   -  Reputation: 3047

Like
2Likes
Like

Posted 23 March 2013 - 03:02 AM

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, 23 March 2013 - 03:03 AM.


#4 Poigahn   Crossbones+   -  Reputation: 518

Like
0Likes
Like

Posted 23 March 2013 - 04:42 AM

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!


Your Brain contains the Best Program Ever Written : Manage Your Data Wisely !!





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS