Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #719 > unrolled thread

Scene graph?

Back to article view | Back to comp.programming

Contents

  Scene graph? Rui Maciel <rui.maciel@gmail.com> - 2011-07-28 23:51 +0100
    Re: Scene graph? BGB <cr88192@hotmail.com> - 2011-07-28 16:24 -0700
      Re: Scene graph? Rui Maciel <rui.maciel@gmail.com> - 2011-07-29 16:52 +0100
        Re: Scene graph? BGB <cr88192@hotmail.com> - 2011-07-29 12:58 -0700

#719 — Scene graph?

Has anyone developed a scene graph?  If so, what features and aspects do you 
believe are most important in this sort of component?


Thanks in advance,
Rui Maciel

[toc] | [next] | [standalone]

#720

On 7/28/2011 3:51 PM, Rui Maciel wrote:
> Has anyone developed a scene graph?  If so, what features and aspects do you
> believe are most important in this sort of component?
>

if you mean for a 3D engine?...


well, if so, the most basic property is that it is a list of objects to 
be drawn, generally holding:
the origin of each model;
the orientation/rotation of each model;
a link to the model to be drawn.


typically, IMO, it is better to leave the representation of the scene 
(what the renderer sees) as disjoint from the mechanics of the scene 
(and high-level logic associated with the behavior and movement of 
objects), which are often better handled in their own scene-graph.

similarly, it is better to have the entries in the scene-graph as 
disjoint from the objects themselves (object type and geometry, drawing 
handlers, ...).

I have learned both of the above from personal experience, where trying 
to have logic/geometry/rendering all attached to a singular "entity" 
type tended to make a bit of a big mess of things, and it is generally 
"cleaner" if each part exists partly independently of the others (they 
can be linked by pointers, ... FWIW, just better not to make them all be 
the same object).


ideally, models will have generic methods for rendering tasks, but the 
exact methods will depend on the 3D renderer strategy.

in my renderer, the draw methods are more like:
RenderDark, renders a flat-black version of the object;
RenderLight, renders a flat white model with vertex normals;
RenderFlat, draws the model with a flat color;
RenderFinal, draws a texture-map overlay/...
RenderShadow, draws a projected shadow volume;
...

also, it may make sense to have a "context" for each model (separate 
from the model proper), where the context may hold model-type specific 
details (frame numbers, bone positions, precalculated vertex data, ...).


also, maybe a BSP or similar to optimize rendering and lookup tasks.
in my engines, I typically build the BSP in real-time using a 
QuickSort-like algorithm.


or such...

[toc] | [prev] | [next] | [standalone]

#722

BGB wrote:

> On 7/28/2011 3:51 PM, Rui Maciel wrote:
>> Has anyone developed a scene graph?  If so, what features and aspects do
>> you believe are most important in this sort of component?
>>
> 
> if you mean for a 3D engine?...

I was thinking more in general terms, regarding the implementation of any 3D 
visualization component.  It would be nice if the focus was placed on the so 
called scientific visualization, but as it appears that the cutting edge of 
graphics programming lies in games then it is also a good start.  In fact, 
probably there are more things in common between games and scientific 
visualization than not.


> well, if so, the most basic property is that it is a list of objects to
> be drawn, generally holding:
> the origin of each model;
> the orientation/rotation of each model;
> a link to the model to be drawn.
> 
> 
> typically, IMO, it is better to leave the representation of the scene
> (what the renderer sees) as disjoint from the mechanics of the scene
> (and high-level logic associated with the behavior and movement of
> objects), which are often better handled in their own scene-graph.
> 
> similarly, it is better to have the entries in the scene-graph as
> disjoint from the objects themselves (object type and geometry, drawing
> handlers, ...).
> 
> I have learned both of the above from personal experience, where trying
> to have logic/geometry/rendering all attached to a singular "entity"
> type tended to make a bit of a big mess of things, and it is generally
> "cleaner" if each part exists partly independently of the others (they
> can be linked by pointers, ... FWIW, just better not to make them all be
> the same object).

So, it seems it is preferable to implement a scene graph as a view in a 
model-view-controller pattern.  That makes sense.  Maybe it isn't practical 
for games, as this may bring bit of a performance penalty, but it does look 
good.


> ideally, models will have generic methods for rendering tasks, but the
> exact methods will depend on the 3D renderer strategy.
> 
> in my renderer, the draw methods are more like:
> RenderDark, renders a flat-black version of the object;
> RenderLight, renders a flat white model with vertex normals;
> RenderFlat, draws the model with a flat color;
> RenderFinal, draws a texture-map overlay/...
> RenderShadow, draws a projected shadow volume;

Sounds good.  Maybe the scene components can benefit from implementing their 
rendering code through a state pattern.


> also, it may make sense to have a "context" for each model (separate
> from the model proper), where the context may hold model-type specific
> details (frame numbers, bone positions, precalculated vertex data, ...).

It sounds reasonable.  There may be a performance penalty with this 
separation of concerns, but it looks that it may help keeping the code 
clean.


> also, maybe a BSP or similar to optimize rendering and lookup tasks.
> in my engines, I typically build the BSP in real-time using a
> QuickSort-like algorithm.

This sounds good.

I've developed a scene graph for a visualization program and it ended up 
considerably similar to your description.  The biggest differences was that 
instead of employing a BSP I've defined a spherical boundary on each scene 
graph component.  Then I've organized the scene graph as a tree, where the 
scene graph components represent the leaf nodes and the parent nodes provide 
a spherical boundary that encloses all child nodes.  It may have it's 
problems (i.e., rebuild the tree structure ) but it appears to help with 
picking operations.

Did your scene graph also handled 2D graphics, such as a HUD?


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#723

On 7/29/2011 8:52 AM, Rui Maciel wrote:
> BGB wrote:
>
>> On 7/28/2011 3:51 PM, Rui Maciel wrote:
>>> Has anyone developed a scene graph?  If so, what features and aspects do
>>> you believe are most important in this sort of component?
>>>
>>
>> if you mean for a 3D engine?...
>
> I was thinking more in general terms, regarding the implementation of any 3D
> visualization component.  It would be nice if the focus was placed on the so
> called scientific visualization, but as it appears that the cutting edge of
> graphics programming lies in games then it is also a good start.  In fact,
> probably there are more things in common between games and scientific
> visualization than not.
>

fair enough. actually, my 3D tools use basically most of the same code.

just with 3D tools, one has a few other issues:
selection;
performing various operations (translate/rotate/scale/...);
...


>
>> well, if so, the most basic property is that it is a list of objects to
>> be drawn, generally holding:
>> the origin of each model;
>> the orientation/rotation of each model;
>> a link to the model to be drawn.
>>
>>
>> typically, IMO, it is better to leave the representation of the scene
>> (what the renderer sees) as disjoint from the mechanics of the scene
>> (and high-level logic associated with the behavior and movement of
>> objects), which are often better handled in their own scene-graph.
>>
>> similarly, it is better to have the entries in the scene-graph as
>> disjoint from the objects themselves (object type and geometry, drawing
>> handlers, ...).
>>
>> I have learned both of the above from personal experience, where trying
>> to have logic/geometry/rendering all attached to a singular "entity"
>> type tended to make a bit of a big mess of things, and it is generally
>> "cleaner" if each part exists partly independently of the others (they
>> can be linked by pointers, ... FWIW, just better not to make them all be
>> the same object).
>
> So, it seems it is preferable to implement a scene graph as a view in a
> model-view-controller pattern.  That makes sense.  Maybe it isn't practical
> for games, as this may bring bit of a performance penalty, but it does look
> good.
>

actually, the strategy roughly as I described is used in games, in 
particular the idTech engines (Quake 1/2/3, Doom 3, ...) seem to follow 
a similar pattern, where typically multiple copies of the scene exist:
one for the 'server';
one for the 'client';
one for the renderer;
models being linked-to objects;
...

admittedly, my current engine is partly an imitation of the idTech 
engines architecture-wise. I don't use idTech for sake of wanting to be 
free of GPL, as I may want to potentially develop something commercial 
based on a lot of this... it is unclear though if it would be better as 
closed-source or proprietary open-source though (where the source code 
is available on purchase, and one may be allowed to modify and recompile 
it for their own uses, but redistribution without permission or the 
creation of derivative works is not allowed).


the thing about performance is that it is generally only really critical 
in certain locations, and the rest of the engine can get by fine with 
"simple but effective" code.


>
>> ideally, models will have generic methods for rendering tasks, but the
>> exact methods will depend on the 3D renderer strategy.
>>
>> in my renderer, the draw methods are more like:
>> RenderDark, renders a flat-black version of the object;
>> RenderLight, renders a flat white model with vertex normals;
>> RenderFlat, draws the model with a flat color;
>> RenderFinal, draws a texture-map overlay/...
>> RenderShadow, draws a projected shadow volume;
>
> Sounds good.  Maybe the scene components can benefit from implementing their
> rendering code through a state pattern.
>

admittedly, I haven't really been much into the "design patterns" thing, 
but more "just do what makes sense" (well, and a lot of this is "OO in 
C" as well).


the reason for all these methods though is mostly that a model will be 
drawn different ways at different times.

namely:
RenderDark basically draws all of the opaque unlit base geometry;
RenderLight is usually used with light-sources to basically add in all 
of the lights in the scene (in my case, generally used with a 
phong-lighting shader);
RenderShadow is basically used to draw the shadow volumes, which are 
combined with stenciling to prevent light from being drawn on surfaces.

at this point, one basically has a gray-scale phong-lit scene.

RenderFinal is then used to overlay the final texturemaps/... onto the 
geometry.

note that the above strategy only really works for opaque geometry, 
where for translucent geometry or shader effects (glass, water, ...), 
typically special handling is needed. most common is to draw them "after 
the fact" and call a plain Render method. as a result, translucent 
geometry generally needs to use other strategies, namely vertex 
lighting, instead.


granted, another popular strategy for all of this is "shadow mapping", 
which basically works somewhat differently.



>
>> also, it may make sense to have a "context" for each model (separate
>> from the model proper), where the context may hold model-type specific
>> details (frame numbers, bone positions, precalculated vertex data, ...).
>
> It sounds reasonable.  There may be a performance penalty with this
> separation of concerns, but it looks that it may help keeping the code
> clean.
>

micro-optimizing rarely helps much IME.


it is actually generally a lot better to try to do less work (omit parts 
of the scene early, ...) than it is trying to micro-optimize things 
(like worrying about a few extra pointer indirections here and there, ...).

the main reason though for having a "context" to hold model state, which 
is separate from the model proper, is that there may be many instances 
of a given model in a scene.

this way, the "model" object is shared between all of the instances (no 
need to bulk-copy the geometry of every visible object). the 
"state"/"context" then holds per-instance data (if relevant).

for example, for 3D characters, it may make sense to store precalculated 
bone transformations (essentially, their pose) and also to store 
precalculated vertices for visible objects (mostly because the model may 
be drawn multiple times per frame, and recalculating all of the vertex 
positions and normals for a character model each time it is redrawn may 
become expensive).

however, a static 3D model (a generic scene object, for example) may 
have no need for precalculated bones or vertices (all of its geometry is 
static and its normals stored in the base model).


>
>> also, maybe a BSP or similar to optimize rendering and lookup tasks.
>> in my engines, I typically build the BSP in real-time using a
>> QuickSort-like algorithm.
>
> This sounds good.
>
> I've developed a scene graph for a visualization program and it ended up
> considerably similar to your description.  The biggest differences was that
> instead of employing a BSP I've defined a spherical boundary on each scene
> graph component.  Then I've organized the scene graph as a tree, where the
> scene graph components represent the leaf nodes and the parent nodes provide
> a spherical boundary that encloses all child nodes.  It may have it's
> problems (i.e., rebuild the tree structure ) but it appears to help with
> picking operations.
>

yeah. my BSP nodes also include bounding spheres and bboxes as well, 
mostly to aide in culling.

a copy/pasted version of the code is used in my case on the "server" end 
and is mostly responsible for physics and movement.


> Did your scene graph also handled 2D graphics, such as a HUD?
>

no, these are drawn separately (or, at least, HUD items may be 
eventually part of the client graph, but are not stored with the main 
renderer).

typically, some time after all the 3D stuff completes drawing, things 
are set up for 2D and any visible 2D stuff is drawn, typically by 
independent logic.

currently, this is mostly for things like the console and GUI-widget 
drawing and text and similar.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web