Sign in to follow this  
cozzie

Engine design question

Recommended Posts

Hi all,

Up till now I've been using squared paper, MS excel and notepad to create my 3d scenes. Using a DIY file format (which actually works quite well and flexible). Around this I've developed a fine working renderqueue, sorting things for rendering etc.

I create / use meshes and models in 3ds max and export them to X files using Panda exporter (not erfect but doing what I need "today").

So what's wrong then you'd think...

I found out that creating a whole scene/ level in 3ds max actually works pretty well. But when I export the scene to a X file, my engine (through my file format) reads it as 1 mesh. The renderqueue handles it also as 1 mesh, not sorting al the subobjects etc for rendering. The only thing I do with subobjects now is cull them against the frustum right before rendering. Basically not using the renderqueue at all.

So I thought I can develop that all subobjects/ meshes in a X file could be created in my engine as it where normal meshes. This way I can simply use my renderqueue etc. Giving flexibility on how to handle scenes created differently. On the other hand maybe I should just choose one method for creating the scenes and develop everything around that.

What would you do?
(i'm not planning to completely develop a scene editor myself, and reinvent the wheel)

Share this post


Link to post
Share on other sites

The render queue should be sorting on a per-object basis.  A mesh is a collection of objects.  In other words, you are not sorting meshes, you are sorting all the parts of the mesh, for each mesh.  The whole purpose of sorting is to avoid redundant render-state changes, so you sort by the lowest common denominator that requires no state changes to render: the various parts that make up a single mesh.

 

 

I have explained it with graphics here:

http://lspiroengine.com/?p=96

 

 

L. Spiro

Share this post


Link to post
Share on other sites

In my little engine I have meshes like you and they can have multiple subsets. But the rendering queue doesn't work with whole meshes, but rather with something what I call "renderables". Each renderable is given by a mesh (to know which mesh to render), a subset number (to know which subset to render), a material (the whole material properties including effect, colors, textures) and world transform.

Then it's quite simple to sort the rendering queue by effect (shaders), textures, whatever. Which renderable belongs to which mesh suddenly isn't so important.

Share this post


Link to post
Share on other sites

The only thing I do with subobjects now is cull them against the frustum right before rendering. Basically not using the renderqueue at all.

 

To add to what L.Spireo said, in my engine each subset is its own instance being submited to the render queue. Actually a render queue is a very low-level concept, at least in that you don't want to do things like a mesh, and have it process its subsets. IMHO, for the render queue there should not even exist such a thing as a mesh, instead a mesh will submit a render instance with states for setting its vertex, indexbuffers, input layout, etc..., therefore handling subsets is also a part higher up.

Edited by Juliean

Share this post


Link to post
Share on other sites
Thanks, this really helps.
I believe what I call a submesh should be handled as a renderable as described above. Being a part of a mesh, having a world matrix, texture and material (and being part of a index and vertexbuffer).

In my case this means I'll change my renderqueue so it deals with "subeshes"/ renderables instead of the full mesh instances (which it does now).

@Lspiro: great article for reference and practical/ adoptable improvements. Thanks

Share this post


Link to post
Share on other sites


So I thought I can develop that all subobjects/ meshes in a X file could be created in my engine as it where normal meshes. This way I can simply use my renderqueue etc. Giving flexibility on how to handle scenes created differently. On the other hand maybe I should just choose one method for creating the scenes and develop everything around that.

What would you do?
I'd switch to a proper file format. Supporting a small subset of collada takes less than a week with AssImp doing the parsing for you. With AssImp migration, I did it in a little more than a week. Keep in mind that your tech will continue improving over time and you'll have to build a workflow supporting its features. Of course, the less you invest in the process the better, and switching file formats is not something to do in a hurry.

Due to a couple of limitations in Blender and AssImp (maybe they have been removed in more recent builds) I converged to Collada+JSON annotations. The export process is a little ankward but from a DCC standpoint it works pretty well in my opinion.

 

Trying to bolt features on a format that does not support them is wasted effort IMHO.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this