# Some questions about scenegraphes, resources managers, etc.

This topic is 4619 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

##### Share on other sites
virtual void render( CCamera* pCamera ) = 0;

##### Share on other sites
ok, at least it's an answer, but how about an effect that need light infos, an other one that need special parameters, and so on ?
Do I have to pass EVERYTHING in the render method (or an update one, it'd be a little cleaner) ? That's exactly the same thing as my little 2), it's the same as creating a lot of setters.

Maybe it's effectively done like that in big project, but I need to be SURE of that because that's not the method I prefer to be honest : I don't really want to have tons of parameters, most of them never used by derived classes. And moreover, if I forget 1 thing, i'll have to modify all the sources / headers of the derived classes to add a new parameter, even if ONLY the new class that need it use it !

##### Share on other sites
Usually you recurse through the scene graph, and build a list of every thing that needs to be rendered this frame.
Then you sort the list by material state, etc. save on state changes.
And finally you render each object in the list.

The current camera should be globaly accessable, so that things like billboards can access its position.

##### Share on other sites
I have a slightly different scene graph structure, using more generic wrapper nodes and hand-rolled rtti information to determine types. All my individual systems are accessed through static functions on a 'system' class, i.e. I can get the camera manager anywhere in code and access the current player/view camera (or any other camera).

On the lighting side, during traversal of my scene I accumulate all visible lights and objects (and also any lights/objects that are not directly visible but may still have an impact on the view; lights that shine on visible objects, objects outside the view but which cast shadows into the view), then in a separate section of code determine interactions between the different types of elements, i.e. which lights each object is lit by etc. So at render time, the mesh data is passed to the renderer and this data also holds a list of lights that need to be used to light the mesh.

##### Share on other sites
ok, thx for the replies, I hopped a little more infos but that's better than nothing ^^

As it seems to be a critical point in an engine development (how many time did I read something like : "if you go that way, and if you need to add blabla then you'll have to completely refactor your SG ... blablalbal" so I'll continue my readings before implementing something.

And so, if anyone has some links, articles, thesis, books, etc. on these subjects (SG, resource managment, 3D engine architecture in general) please post them, I really need the most information possible !! ^^

##### Share on other sites

virtual void Update (CSceneManager &sman) = 0;virtual void Render (CRenderer &renderer) = 0;

The scene-manager stores the scenes camera, frustum, timer, etc so now Update has access to these almost as if they were global and you only pass 1 parameter, this seems a much better solution.

CRenderer is pretty vague, it could be an abstraction layer to a rendering API (D3D or Opengl) or it could be a rendering queue (or at least have access to the rendering queue) which allows renderable nodes to insert themselves into the queue for sorting and rendering.

##### Share on other sites
yep, it could work. I need a little more thinking on the subject, but I'm leaning toward these kind of approach.

did anyone read this article http://triplebuffer.devmaster.net/articles/scene_graph_dx/ ?? They do something that I like : the transformations, renderstates, etc. are just some nodes inserted in the SG. They say they can even have a node which is a function applied to all the children.

I like that idea very much. I'm still reading the article, so i'll see if it's usable in practice (in my case) but it's pretty clever I think : for example, shadows can be handled by simply registering / deregistering some nodes.

Did someone read this article, and what do you think about it ? (I've read the article on SG here on GDNet, but I found a thread where a guy says it's not usable in big project, although I thought it was a good tutorial ... so I don't know what to think now ^^)