Hey guys.

So I've been having some serious considerations about the design of my engine, making it simpler and more flexible (Well, that's the dream, right?). So far so good, but, I'd like to share a thought (or a consideration) about the render ques (Just a list of objects needed to be rendered). So I've thought that I would have a class called: RenderModule, which can be instanced by the user, or by the engine itself, consider the following example:

class RenderModule
{
....
}

class Surface
{
    RenderModule mRenderModule;
    void Create()... // Initialises and creates the render module and the e.g. vertices/indices
    RenderModule* GetRenderModule()...
}

int main()
{
    Surface s;
    s.Create(..);
    
    // Now when it's added, the engine will render what's inside of this this render module
    pEngine->AddRenderModule(s.GetRenderModule()); // or some other names...
}

Nothing fancy, trying to keep things simple. Now, each model (or what it would be) would require different sets of data, such as time. So could I go ahead and make a structure called, e.g. DataPackage which contains pointers to all the data that you could ever possibly imagine, and then share a pointer to this Package to all models/rendermodules/etc... Which wouldn't be any problem in terms of performance, I hope.

Is this a terrible way of approaching the issue? Or is it actually ok?

What do you do, how do you keep the simplicity and flexibility?

Thanks, as usual.

-MIGI0027

A render queue (I assume this is what you meant) is not just a list of objects that need to be rendered. It is a list of object parts that have survived the culling phase and are to be sorted (the job of the render queue itself).

I suggest you stick to what is most logical in terms of component interactions and avoid terms that are too abstract in either name or functionality.

For example, what is a “render module”? What should it contain or do? It is very abstract, and it sounds as though it is going to lead to tight coupling between certain modules that do not need to be coupled. For example, it seems to be heading in the direction where the graphics module knows what a model is when it should be entirely the other way around.

The same holds for “DataPackage”. What is it? What does it contain or do?

What you describe it as being is a monolithic container of all kinds of data for all kinds of objects, which again is just inviting a tightly coupled design and unnecessary dependencies.

You are thinking more from a top-down approach.

Why not try a bottom-up approach?

A foundation layer provides typedefs and things you need throughout the engine. Optimized string compares etc., if you want. A timer class. A random number generator. Things you know you will need and depend on nothing else.

Then build a graphics layer on top which at first is just a wrapper for graphics functionality. Wrappers for state commands, vertex buffers, textures, etc.

Maybe it will later do more (such as render queues), but don’t confuse yourself by getting ahead of yourself.

Next up (and remember, each “step up” means the upper layers know about the lower ones but not the other way around) you have a model module which knows what graphics commands and vertex buffers are. The graphics module on the other hand does not know what a model is. At the same level you would have terrain.

This illustrates perfectly the point that the way in which a model renders itself and how GeoClipmap terrain renders itself are totally different, and far too monolithic to be held and managed by one module (the graphics module in your case).

Giving objects the ability to render themselves using a graphics module as a simple tool for doing so ensures you can add any kind of object, from models and imposters to water and GeoMipmap/GeoClipmap terrain. Each type of object can be self-contained within its own module without the need to create a mega-structure such as DataPackage to handle all possible sets of data.

Above that, the primary game-engine module knows about all of these things and inside it there exists a “scene” or “3DSceneManager” and “2DSceneManager”, as well as instances of models and things that can be scattered around the world.

The manager of the scene knows how to partition objects for efficient culling and collision detection, and it knows how to do rendering passes over the objects, or rather orchestrate the overall rendering pipeline while still letting each object handle its own rendering.

The scene manager culls objects, puts them into multiple render queues, sorts opaque and alpha render queues separately, sorts the render queues for shadow-casting lights separately, etc., and basically pulls all the things that need to be to pulled to make everything render in a happy tree friends way.

L. Spiro

Is this a terrible way of approaching the issue? Or is it actually ok?

Personally, I haven't embraced the "render queue" design. My renderer is pretty high-level and still evolving so I couldn't figure out a decent design for the queue information itself. Since I am focusing on something else, I left this out. Maybe you should do the same?

Thank you both for your inputs and thoughts.

Spiro:

Actually my current design has something (I hope) to do with what you mentioned, an example:

Material ---------\

Buffers ---------- Mesh / Terrain / Volume ---- System

Minor things __/

So I have some independent classes such as Material, Buffer (etc...), which are used by several other classes such as Meshes, Terrains and Volumes, which are all used by the System class. Now I'm not entirely sure whether my system class is well organised or just stupid in design, here's what it does (In itself):

• Creates DX (11)
• Manages scene
  Containers of pointers to meshes/terrains/volumes/etc...
• Basically uses wraps it all up to something usable.

Should I split the system class up into the low level (deferred, dx11, etc...) and a high level component which utilizes the low level class? Or not?

The previous thoughts that I've shared with you was just an idea, that I'd like to discuss before trying to implement it, as it might be stupid, as it probably is.

Krohm:

I might have gotten the definition of render ques wrong, sorry about that confusion. My version is basically a simple Group (a class inheriting vectors with additional functionalists) containing pointers to meshes/terrains/volumes/etc... needed to be rendered, maybe this clears it up.

Thank you.

-MIGI0027

so I couldn't figure out a decent design for the queue information itself. Since I am focusing on something else, I left this out. Maybe you should do the same?