I'm trying to make a toy game engine (just for fun), i'm running into two big problems.
First i have no clue how to organize scene management. I've read a lot about scene graphs, and lately a lot about not using them...
What's the "modern" way of scene management? Should whatever manages the game objects also be responsible for creating a list of drawable objects?
The second issue i'm having is designing a good rendering interface. Ideally i'd like something that has a "mesh" and "animatedMesh" class which can then be added to a render function (rather than having all the vertex info every game object that is drawable). I've been struggling with this for a while and can't seem to get a good grasp on a good renderer design.
I recently read "Ultimate 3D game engine design & architecture" by allen sherrod. While it briefly touched on the topics i'm interested in the book managed to skip all the information that would have been useful for me.
Any advice, web links, book suggestions? All help is welcome!
Scene management and render interface?
I'm trying to make a toy game engine (just for fun), i'm running into two big problems.
First i have no clue how to organize scene management. I've read a lot about scene graphs, and lately a lot about not using them...
What's the "modern" way of scene management? Should whatever manages the game objects also be responsible for creating a list of drawable objects?
The second issue i'm having is designing a good rendering interface. Ideally i'd like something that has a "mesh" and "animatedMesh" class which can then be added to a render function (rather than having all the vertex info every game object that is drawable). I've been struggling with this for a while and can't seem to get a good grasp on a good renderer design.
I recently read "Ultimate 3D game engine design & architecture" by allen sherrod. While it briefly touched on the topics i'm interested in the book managed to skip all the information that would have been useful for me.
Any advice, web links, book suggestions? All help is welcome!
I think this is what you should do: Just have a RenderSystem class that accepts your base class(AddDrawable and RemoveDrawable) that can be rendered and just calls render on all of those objects. When you find you actually need to optimise your rendering techniques then you can easily add frustum culling with octrees or whatever you want.
I don't think that a game object manager (I guess this is really a GameObjectLogicUpdater?) should care about, or create a list of drawable objects. You may want to have a game object that isn't rendered but also controls some logic things, maybe an invisible wall with a sound effect played on collision or something, or something that spawns other objects.
Thanks for the reply CRYP7IK,
I'm trying to stay away from objects having render functions. What i'd like to do is something like
So when a static mesh is added to a game object it is added to the render systems render list (sorted by material properties). When the render list loops trough each renderable object it looks at the transform (in scene graph) to see if the object should be rendered or not. Now i think this is a good start, the issues i'm having: looping trough the set of visible meshes might be too expensive.Should i be constructing my render list each frame? Also, i'm trying to avoid having a scene graph as all i've heard about it is how modern engines don't need one. Should i just keep a big ass object graph? If my visibility determination is handled by the visibility check i don't see the need for a scene graph...
I'm trying to stay away from objects having render functions. What i'd like to do is something like
class StaticMesh : Component {
// static mesh stuff
Transform* object; // in a scene graph, pointer to owner object's transform, has bool for visible
};
class GameObject {
Transform* m_transform;
vector<Component*> m_components;
// ...
void addComponent(StaticMesh* sm) {
// Static mesh specific add function
}
}
So when a static mesh is added to a game object it is added to the render systems render list (sorted by material properties). When the render list loops trough each renderable object it looks at the transform (in scene graph) to see if the object should be rendered or not. Now i think this is a good start, the issues i'm having: looping trough the set of visible meshes might be too expensive.Should i be constructing my render list each frame? Also, i'm trying to avoid having a scene graph as all i've heard about it is how modern engines don't need one. Should i just keep a big ass object graph? If my visibility determination is handled by the visibility check i don't see the need for a scene graph...
mmh I think the articles I wrote I relevant. I'll try to keep an eye on the topic should you have any more questions.
(Keep in mind I wrote that in 2007 even though it got published over time, some things would need an update ^^)
http://www.beyond3d....nt/articles/98/
http://www.beyond3d....t/articles/102/
http://www.beyond3d....t/articles/109/
So there are 3 different representations:
-a simple scene tree for hiearchical animation. (Note that I only have nodes for some joints and not the whole skeleton anymore.)
-a spatial tree/graph for visibility culling/selection. (That can be whatever you need, Sector/Portal, BSP, Octree, Quadtree, kd-tree... Or a combination of them...)
-a rendering queue/flat tree for rendering. (In which you sort by state prior to rendering, includes batching/instancing support.)
I consider the Scene Tree to be the main representation.
atm I have an Entity class that inherits from SceneNode & Spatial to "join" the Scene & Spatial representation, you could decide to do it differently. (for example associate Spatial & Renderable instead)
My Spatial class have a cull(...) function in which it adds its renderables to the Rendering Queue passed as a parameter.
(Keep in mind I wrote that in 2007 even though it got published over time, some things would need an update ^^)
http://www.beyond3d....nt/articles/98/
http://www.beyond3d....t/articles/102/
http://www.beyond3d....t/articles/109/
So there are 3 different representations:
-a simple scene tree for hiearchical animation. (Note that I only have nodes for some joints and not the whole skeleton anymore.)
-a spatial tree/graph for visibility culling/selection. (That can be whatever you need, Sector/Portal, BSP, Octree, Quadtree, kd-tree... Or a combination of them...)
-a rendering queue/flat tree for rendering. (In which you sort by state prior to rendering, includes batching/instancing support.)
I consider the Scene Tree to be the main representation.
atm I have an Entity class that inherits from SceneNode & Spatial to "join" the Scene & Spatial representation, you could decide to do it differently. (for example associate Spatial & Renderable instead)
My Spatial class have a cull(...) function in which it adds its renderables to the Rendering Queue passed as a parameter.
Also, i'm trying to avoid having a scene graph as all i've heard about it is how modern engines don't need one. Should i just keep a big ass object graph?Just make game objects be owned by other objects that have longer lifetimes. e.g. a rocket can add itself directly to the world, and remove itself from the world when it explodes. A 'fire glow' effect object can be owned by the rocket, because it should be removed whenever the rocket is removed etc... Each of these objects can then also own renderables (e.g. [font="Courier New"]StaticMesh[/font]es)
So when a static mesh is added to a game object it is added to the render systems render list (sorted by material properties). When the render list loops trough each renderable object it looks at the transform (in scene graph) to see if the object should be rendered or not.[/quote]I would introduce visibility checking separately from the transform/mesh classes. If Meshes linked to bounding volumes, then two meshes could share the same culling result (i.e. one culling operation covers two meshes) which can be useful, e.g. when one character is made up of several meshes.
Something like:
BoundingVolume has a Transform.StaticMesh has a BoundingVolume.
CullingSystem has BoundingVolumes.
RenderSystem has StaticMeshes.
GameObjects create Transforms, BoundingVolumes and StaticMeshes, and link them together / add them to systems.
UpdateGamePhysics() -- whatever it is that updates transforms / moves things around
CullingSystem.Update() -- loop through all bounding volumes and check which are visible
RenderSystem.Update() -- loop through all meshes and find which ones are attached to visible bounding volumes
RenderSystem.Draw() -- render visible meshesNow i think this is a good start, the issues i'm having: looping trough the set of visible meshes might be too expensive.
Should i be constructing my render list each frame?[/quote]When considering a few-thousand to a-hundred-thousand items... I'd guess that looping through a vector is probably a very fast solution. I wouldn't expect tree/graph optimisation structures to perform much faster on a small contiguous data set.
Building the lists each frame is fine. As a later optimisation, you can try and find places where render-lists can be reused, if it's really necessary.
So there are 3 different representations:I'd represent #1 by allowing the Transform objects to store a link to a parent Transform, a local matrix and a global matrix. When the transform system is updated, a pass is done over the transforms vector to update all of their global matrices (propagating parent's matrices down onto local matrices).
1) a simple scene tree for hiearchical animation. (Note that I only have nodes for some joints and not the whole skeleton anymore.)
2) a spatial tree/graph for visibility culling/selection. (That can be whatever you need, Sector/Portal, BSP, Octree, Quadtree, kd-tree... Or a combination of them...)
3) a rendering queue/flat tree for rendering. (In which you sort by state prior to rendering, includes batching/instancing support.)
The choice for #2 highly depends on the type of game being made. For simple games that are constrained to one 'space', I would recommend a simple vector, which you fully loop over each frame. Games with many rooms/buildings/etc will likely need one of the above structures.
With #3 you can also have as many rendering queues as you require. E.g. you might have your game-world produce a vector of renderables that it needs to draw, and also have your HUD system produce a different vector of renderables. Both render queues can then be submitted for rendering one after the other.
Ingenu,
Thanks for the links, they are indeed relevant to what i am researching, i find them to be more useful than some of the books i have on the topic.
Hodgman,
HOLLY CRAP! That answers verbatim what i wanted to know! I can't thank you enough, your response filled in the gaps i was missing.
Pretty sure i'm going to go with Ingenu's third suggestion, it sounds like a really good general purpose rendering framework.
Thanks so much guys, i'll post my progress when i've made some.
Thanks for the links, they are indeed relevant to what i am researching, i find them to be more useful than some of the books i have on the topic.
Hodgman,
HOLLY CRAP! That answers verbatim what i wanted to know! I can't thank you enough, your response filled in the gaps i was missing.
Pretty sure i'm going to go with Ingenu's third suggestion, it sounds like a really good general purpose rendering framework.
Thanks so much guys, i'll post my progress when i've made some.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement