I used to have one CSceneManager which was created by the CGame class, but then I had to make hacks to get multiple cameras working in the same scene when we wanted to draw one 3D scene and then another on top of it. Some objects were tagged to one camera and some to the other.
It didn’t make sense so in my new engine I let users create their own CSceneManager instances and as many of them as they please. This is a lot more elegant and efficient.

The scene is set up in the Init() class on CState.

As for how they are rendered, you have it backwards.
A rendered should never know what a scene is.
A scene knows what a scene is and it should render itself using the abstract and general-purpose functions provided to it by the renderer.

m_smScene.Draw().

The scene culls objects, selects the active camera, applies the projection matrices and other render states that need to be set, and eventually tells objects to draw themselves.
Objects set shaders for themselves, activate vertex and index buffers for themselves, and perform a render.

Btw. do you have to open up your projects? Aren't they always open?

Not this week. I am watching Avatar: The Last Airbender by recommendation from a friend. But only 2 more left to watch.


L. Spiro

You generally don’t load “vertex files” and “index files”.
You load models. Any sharing between vertex and index buffers can be predetermined offline, since it is unlikely any vertex buffers will ever be shared between models.
Trying to share all vertex buffers on a system-wide scale is over-engineering.

This is how mine looks:
LSVOID LSE_CALL CModelTest::Init( CGame * _pgGame, LSINT32 _ui32State, LSINT32 _ui32PrevState, LSUINTPTR _uptrUser ) {
m_dmipInstance = m_sgpScene->CreateDrawableModelInstance( "KinoGirl.lsm" );
m_sgpScene->CreateDrawableModelInstance( "Ground.lsm" )->SetCastsShadow( false );
}


You can probably agree that this would be more preferable for anyone using your engine, including yourself.

There is no need for a global general-purpose resource manager. Resources don’t have enough in common to warrant such a thing.
As far as anything managing resources goes, there are unique ones for the scene, models, etc.
And all of these are handled at a high level. For example you are proposing to share all vertex buffers period. What if I want to load the same one again so I can make changes to it?
A more common example of the same thing is textures. I very easily might want to apply some filter that is expensive if done in a shader, so I want to modify the original. But that would change all instances of it, so I need to be able to load multiple copies of it.

However I know that within my model library I am not modifying those textures. They are shared between each other and only each other. No other system is involved, so while it may be wasteful if a sprite were to later reload the same file, it is the lesser of evils and in practice never happens. And textures within the sprite system are shared amongst each other as well.


L. Spiro

But you're saying that I should share renderables/textures, but still make it possible to load a seperate instance of it?

Basically. The below reply provides a reason as to why.

[quote name='YogurtEmperor' timestamp='1333110537' post='4926652']
...
What if I want to load the same one again so I can make changes to it?
...

Seems to me the best way to handle this would be to have a system which only loads resources once (from disk, DVD, internet, whatever) but employ copy-on-write semantics on your shared resources.
[/quote]
I saw a video about some game that allowed slicing enemies in half and I wanted to support such an ability in my own, and the best way I thought to do that was via copy-on-write.

But later I realized that the problem with copy-on-write is that it is hidden overhead. People might be doing it and incurring a significant amount of overhead without understanding why.
When it comes to game engines, this isn’t acceptable. Users should know what actions they are doing to cause performance issues and be pushed towards a more performant way of accomplishing the same thing.

But this is a perspective unique to myself—not everyone here is planning on making a business out of middleware.
My original mindset allowed copy-on-write because I wasn’t considering other people using my engine (even though that was my goal and I should have been). If you are just making your own personal engine, copy-on-write is a very elegant solution to this problem.


L. Spiro