Jump to content

  • Log In with Google      Sign In   
  • Create Account

Getting model from 3DS Max to my game engine

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
14 replies to this topic

#1   Members   -  Reputation: 474


Posted 16 January 2013 - 01:20 PM

For a 3D game engine I wrote,

I currently get models loaded into the engine by parsing files exported from 3DS Max using the ASCII export function.  However, I cannot get this to work usefully for anything other than the geometry.

Specifically, animations and particle systems.

I have tried to export from 3DS Max in most of the formats in the list of export options, but I can't see any useful information in the resulting exported files about the animations and particle systems.

For my engine, I need the actual key frame information for animations.  The engine is designed to just take the keyframe information and then do the interpolation and calculations in real-time.  But I can't seem to figure out how to get 3DS Max to export the animations like that.  Instead, they appear to be exported by just listing the transform at each various sampled frames, instead of listing the keyframes.

This is what I see when I try to export a model in the ASCII format with an animation that just translates a cube.

*NODE_NAME "Box001"
*CONTROL_POS_SAMPLE 0 48.7667 2.7128 0.0000
*CONTROL_POS_SAMPLE 800 37.3693 6.5535 0.0000
*CONTROL_POS_SAMPLE 1600 10.9041 15.4717 0.0000
*CONTROL_POS_SAMPLE 2400 -19.0383 25.5616 0.0000
*CONTROL_POS_SAMPLE 3200 -40.8672 32.9175 0.0000
*CONTROL_POS_SAMPLE 4000 -45.2485 34.3939 0.0000

Also, when I try to export a particle system, I see nothing useful in the resulting file.  My engine is designed to take a bunch of parameters for the system, and then instantiate a particle system with those parameters.  I would like to be able to take the exact parameters of the system in 3DS Max and load them into my engine.

This is all I see when exporting a scene with a particle system:

*NODE_NAME "Spray001"
*NODE_NAME "Spray001"
*TM_ROW0 1.0000 0.0000 0.0000
*TM_ROW1 0.0000 1.0000 0.0000
*TM_ROW2 0.0000 0.0000 1.0000
*TM_ROW3 17.6095 19.0154 0.0000
*TM_POS 17.6095 19.0154 0.0000
*TM_ROTAXIS 0.0000 0.0000 0.0000
*TM_SCALE 1.0000 1.0000 1.0000
*TM_SCALEAXIS 0.0000 0.0000 0.0000
*WIREFRAME_COLOR 0.5490 0.3451 0.8824

I tried looking for guides on how to do this but have found nothing useful yet.

#2   Members   -  Reputation: 1151


Posted 16 January 2013 - 01:30 PM

Export to something like Collada, parse the Collada file (it's xml and well defined) and save the resulting data to your own binary format and load into your engine - you could also consider FBX/Assimp but I haven't used either of those.

There are several threads on gamedev about exporting/importing from DCC tools and converting to one of these formats - it looks daunting but it really isn't when you get into it.

This will tell you most of what you need to know about parsing Collada files and is brilliantly written I think:
<a href='http://thecansin.com/Files/COLLADA.pdf'>http://thecansin.com/Files/COLLADA.pdf</a>

#3   Members   -  Reputation: 474


Posted 16 January 2013 - 02:16 PM

I tried exporting a particle system as Collada, but all it gave me was this: (for reference, the particle system in the scene was just a default Spray system with a few parameters changed).  Am I doing something wrong?

<?xml version="1.0" encoding="utf-8"?>
<COLLADA xmlns="http://www.collada.org/2005/11/COLLADASchema" version="1.4.1">
      <authoring_tool>FBX COLLADA exporter</authoring_tool>
    <unit meter="0.025400" name="centimeter"></unit>
    <visual_scene id="" name="">
      <node name="Spray001" id="Spray001" sid="Spray001">
        <matrix sid="matrix">1.000000 0.000000 0.000000 17.609482 0.000000 0.000000 1.000000 0.000000 0.000000 -1.000000 0.000000 -19.015411 0.000000 0.000000 0.000000 1.000000</matrix>
          <technique profile="FCOLLADA">
        <technique profile="MAX3D">
        <technique profile="FCOLLADA">
    <instance_visual_scene url="#"></instance_visual_scene>

#4   Members   -  Reputation: 264


Posted 16 January 2013 - 05:10 PM

I may be wrong, but I dont think collada supports exporting particle emitters. I did find this http://www.collada.org/mediawiki/index.php/Particle_emitters_FCOLLADA_extension FCollada extention that looks like it can extend collada to export the particle emitters, but dont have any experience with it.

I'm working on a first person zombie shooter that's set in a procedural open world. I'm using a custom game engine created from scratch with opengl and C++. Follow my development blog for updates on the game and the engine. http://www.Subsurfacegames.com

#5   Crossbones+   -  Reputation: 24735


Posted 16 January 2013 - 05:30 PM

Your best bet is with Autodesk® FBX® (.FBX extension).  They export emitters and animations (just the key-frames) and the SDK makes it easy to load and work with all of this information.

Don’t try to parse model files manually unless there is no other way.



L. Spiro

#6   Members   -  Reputation: 474


Posted 16 January 2013 - 08:07 PM

I'm doing everything from scratch for this, so FBX is not an option (wikipedia says the format is not revealed and you have to use Autodesk's importer code).


I'll try the Collada exporter that you linked, thanks.

#7   Crossbones+   -  Reputation: 24735


Posted 17 January 2013 - 02:30 PM

My engine is from-scratch too.  I don’t see how that is related to the Autodesk® FBX® SDK.

You are aware that it is wrong to import directly into your engine from .DAE, .MAX, .3DS, .FBX, etc., right?

You are supposed to make converters from these to your own custom format and then load that by your engine.



L. Spiro

Edited by L. Spiro, 18 January 2013 - 05:13 PM.

#8   Members   -  Reputation: 474


Posted 17 January 2013 - 03:29 PM

Yes I am aware that I should not directly import the intermediate formats to my engine, but it is a necessary step at the moment so I can learn how it works.  I need to be able to parse these intermediate formats if I wish to convert the format to what my engine eventually uses.


I currently parse the ASCII model files directly to my engine.  It is slow, but it is a necessary step for the engine at the moment because I know very little about how files like this are stored in the real world, and how graphics theory translates to practical use. I don't know what the best way to make my own format for use directly with the engine will be.  


It is a better option for me to first load the models directly from human-readable formats so I can understand everything about them.  Once I know exactly what's practical to have in a final format and what needs to be stored, or what's better to calculate in real-time instead, I will settle on a format.


.FBX is useless to me for this because I can't open the file and look at it.


Also, Collada is not working very well either.  I can't figure out how to export a cube the way it should be exported.


With the ASCII format, 3DS Max would not generate duplicate vertices for non-smoothed faces.  So my engine generates additional vertices for faces that are meant to be not smooth based on the smoothing groups.


Collada does not seem to support smoothing groups.  Instead it just duplicates every vertex no matter what -- even if I set the entire object to all be in the same smoothing group.  If I turn off the duplication, then the triangle list in the exported file still tries to use indices of vertices that weren't output by the exporter.


For example:  this is the output of the collada exporter for a model with a cube with all faces set to the same smoothing group:



<triangles count="12"><input semantic="VERTEX" offset="0" source="#Box001-VERTEX"/><input semantic="NORMAL" offset="1" source="#Box001-Normal0"/><input semantic="TEXCOORD" offset="2" set="0" source="#Box001-UV0"/><p> 1 0 1 0 1 0 3 2 3 0 3 0 2 4 2 3 5 3 7 6 7 6 7 6 4 8 4 7 9 7 4 10 4 5 11 5 5 12 11 4 13 10 0 14 8 5 15 11 0 16 8 1 17 9 7 18 15 5 19 14 1 20 12 7 21 15 1 22 12 3 23 13 6 24 19 7 25 18 3 26 16 6 27 19 3 28 16 2 29 17 4 30 23 6 31 22 2 32 20 4 33 23 2 34 20 0 35 21</p></triangles>
The exporter still thinks there are 6 vertices per side of the cube (36 total) even though the output of the vertex list is just 8 vertices total.  This is completely broken.
How do I get around this?
EDIT:  I think I interpreted those lines wrong -- I think the offset tag means the that for each triangle three of those integers are part of a single vertex description, so every 3rd integer in that list is a vertex index, and the indices in that list that go higher than the number of vertices must refer to the normals.
But I still don't understand why there are more normals than vertices.  If they are all smoothed together, why isn't it just exporting a single normal per vertex?  Is it possible to correctly reconstruct the model if I use Collada? How can I know whether or not each triangle needs to have its own three distinct vertices whose normals aren't averaged with those of the surrounding faces?

Edited by Vexal, 17 January 2013 - 08:05 PM.

#9   Members   -  Reputation: 1151


Posted 18 January 2013 - 04:00 AM

I think it depends on the texture coordinates. If you create an organic shape in 3ds max and uv wrap it correctly, vertices should be shared.

For the cube example, it may be that 3ds max creates it with texture coordinates different on each face, meaning that you'll need duplicated vertices (unless you're using an atlas) and that's what it'll export.

The offset thing, yes that just means that for each consecutive group of 3 indices in the p element, the first is the vertex lookup, the second is the normal lookup and the third is the texture coordinate lookup.

That link I sent explains all this very well.

#10   Members   -  Reputation: 474


Posted 18 January 2013 - 07:30 PM

So is there no way to just have 3DS Max export a list of the exact vertices the triangles should use?  Meaning, if I export a cube with each face in a different smoothing group, it will export three vertices per triangle (totaling 2 triangles per face * 6 faces * 3 vertices = 36 vertices), while at the same time any edges in the same smoothing group will not have their vertices duplicated?  I've tried every option I could, and it seems that I can either just export a list of non-duplicated vertices and completely rely on smoothing groups for knowing whether my engine should duplicate them, or I can export a list with every single vertex duplicated for each triangle, and then the engine doesn't have to duplicate anything to render the model correctly, but it wastes a lot of memory.


Also, apparently you can export FBX in ASCII.  However, the C++ SDK for FBX doesn't work with VS2012 (my main IDE).  There's a link for a beta version, but they have to manually add you to it when you email them (they haven't gotten back to me yet).  VS2012 lets you edit FBX, Collada, and OBJ models inside the IDE.  It's pretty cool.

Edited by Vexal, 18 January 2013 - 08:20 PM.

#11   Members   -  Reputation: 1561


Posted 19 January 2013 - 03:26 AM

I need to be able to parse these intermediate formats if I wish to convert the format to what my engine eventually uses.


Or, you can use Assimp to load the files for you. You will then get a general purpose data representation of the animation. The data will be organized into something like this:



It takes some effort to understand why a structure like this is needed. Possibly, depending on your requirements, you can simplify your layout. Some of the data can be intermediate.


Eventually, as was stated earlier in the discussion thread, you will want to use your own data format to load.

Current project: Ephenation.
Sharing OpenGL experiences: http://ephenationopengl.blogspot.com/

#12   Members   -  Reputation: 474


Posted 19 January 2013 - 04:37 AM

I already explained exactly the reason I am doing things the way I am, and that I am aware of the downsides of directly using an intermediate format, but why it still makes sense for me to use it anyway.


I do not want to use a third-party tool.  It's a waste to me because I have no development goal other than I'm bored.  If I eventually do pick a direction I want to take this project, any third-party tool I've decided to use will probably be obsolete.


A prime example of this is the fact that I can't even use the FBX SDK with my engine because I'm using Visual Studio 2012.

#13   Members   -  Reputation: 136


Posted 20 January 2013 - 07:55 PM

You can also ask the Autodesk support, as every legit customer has support.

#14   Members   -  Reputation: 474


Posted 23 January 2013 - 01:08 PM

I contacted them and they gave me the link to download the beta for the FBX SDK that supports VS 2012, so I have decided to use that because I discovered that parsing the file myself makes me hate life.


Thanks for the suggestions.

#15   Members   -  Reputation: 1168


Posted 23 January 2013 - 05:41 PM

A prime example of this is the fact that I can't even use the FBX SDK with my engine because I'm using Visual Studio 2012.


Have you looked at 2013 beta version. It does support VS2012.

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.