Hi all,

As a part of my new framework/ 3D engine I've arrived at the point to go beyond nice cubes and spheres

My plan is to create a tool that will convert DCC output (I.e 3ds max) to a straight forward format I can load up in my engine (binary). The format will basically consist of sets of: vertices (in one defined format), face indices, material ID's and a transform to parent.

My question is about the transform. Would you store a position, rotation and scale? Or just a 4x4 matrix (I think assimp provides the latter).

For the tool to convert (pipeline), I aim to use assimp.

Besides the question on the transform, of course any feedback on the approach in general is appreciated.

I've actually written (well attempted to write) my own modelling component of a game framework, and I can say from experience that it's a wheel not worth reinventing. It takes a lot of work, and you end up with more or less the same end product as something that you could just get off the internet and integrate into you engine/framework. Unless you truly have some optimization that has not been thought of before (or you just REAAALLLLYYY want to write this), why not borrow from the collective experience of the gamedev ancients, and either (1) use someone else's 3ds max importer, or (2) at worst, maybe get someone else's converter/exporter code to maybe convert models into a different format that you can use (e.g., Blender)?

There's no shame in that. As a comp sci professor once taught me: "Don't shade your eyes, plagiarize" :-D

Thanks. I think I'm not far off that track. My tool will use assimp to load the DCC format, the only thing I'll do afterwards, is extract only the data I need to the format my engine will "eat".

Any thoughts on storing the child transform data? (Matrix versus individual offsets)

1 hour ago, masskonfuzion said:

and either (1) use someone else's 3ds max importer

Are there any max file importer ?

AFAIK I only saw 3ds importers. And whereas I like 3ds, it is however very old and lacks useful recent things like per vertex normals, TBN, meta materials...

At the moment of visual rendering you will use the composed matrix. If the the parenting transform is static, then importing already composed matrices is sufficient and effective. On the other hand, having the transform components separated makes sense if they are altered separately**, i.e. if animation is done, and the transform matrix is composed in the animation engine on the fly.

For static transforms it also may make sense to think about baking the transform into the geometry, so not using child transforms at all.

** Although interpolating matrices is possible, IMO interpolating more native representations is better.

@_Silence_ : assimp can import .max according to the documentation.

I think I'll make a branch for the transform (offsets versus matrix), depending on animated or not. I also like the idea to "pre-transform" static mesh children, this can save quite some realtime matrix muls.

I don't think assimp handles importing .max files. It's not listed here:

https://github.com/assimp/assimp

nor here:

http://assimp.sourceforge.net/main_features_formats.html

4 hours ago, cozzie said:

My question is about the transform. Would you store a position, rotation and scale? Or just a 4x4 matrix (I think assimp provides the latter).

What format do you need the data to be in later? Are you going to send 4x4 matrices to a shader later? If yes, do you want to just copy the data directly into a constant buffer? If yes, then sure, that sounds great!
Are you going to send positions/rotations/scales into some kind of skeleton class that operates on that data? If yes, then sure, that sounds great!

Figure out where the data is flowing to and it will tell you how it should be formatted. Work backwards, start with the consumers of the data, then design the producers to fit.

Also, lots of engines restrict scaling to uniform / one-dimensional, while others support non-uniform / three-dimensional scaling. If you decide to allow the latter, that impacts how you write your shaders (normals cannot be transformed by your regular matrices -- you also need to pass the inverse-transpose of your matrices to your shaders). There's nothing wrong with limiting the kind of data that's permitted to be imported, and it's probably good to do some sanity checks over the input data and make some noisy errors if artists try to create content that your engine can't handle.

1 hour ago, haegarr said:

For static transforms it also may make sense to think about baking the transform into the geometry, so not using child transforms at all.

FWIW in my engine, I use a naming convention on the nodes in our DCC tool. If the artists create a node that begins with "M_", then I flag is as dynamic / important at runtime. If their nodes don't begin with that prefix, then I flag it as static / not required at runtime. Static nodes are collapsed into their parents, and their transforms are applied directly to the vertex data (a.k.a. baking). Dynamic nodes write out two 4x4 matrices -- an absolute node-to-world matrix (which can be copied directly into a constant buffer and used for rendering), and a relative node-to-parent matrix (which can be copied into my skeletal animation / ragdoll system).

4 hours ago, cozzie said:

@_Silence_ : assimp can import .max according to the documentation.

I think I'll make a branch for the transform (offsets versus matrix), depending on animated or not. I also like the idea to "pre-transform" static mesh children, this can save quite some realtime matrix muls.

Well, according to this, no. Really, I never saw a max importer  

My bad, appearantly I misread.

Thanks all, enough thinking; time to experiment