Re: [Gnu3dkit-discuss] G3DRenderer - Object

[Brent Gulanowski]

On Sunday, March 16, 2003, at 02:53  PM, Philippe C.D. Robert wrote:

> Sorry to follow up myself...
>
> On Sunday, March 16, 2003, at 07:58  Uhr, Philippe C.D. Robert wrote:
> > On Saturday, March 15, 2003, at 12:29  Uhr, Brent Gulanowski wrote:
> > > How well can Objects be leveraged to provide performance 
> > > improvements? For example, can a group in the scene graph be 
> > > designed to automatically create an Object the first time the group 
> > > is instanced (say, with an array of children)? Would this be an 
> > > application-specific optimization? Then the object could be drawn 
> > > instead of traversing the group's children.
> >
> > Sorry, I don't understand your question. What do you mean by 'Object' 
> > here?
>
> Do you mean an aggregation of arbitrary, geometric primitives by 
> 'Object'? The idea here is to use a compile action on the respective 
> subtree which would generate an optimised (internal!) represenation 
> for the renderer of choice. This is hence not an application specific 
> optimisation, but application specific optimisations on the scene 
> graph level will still be required to maximise rendering performances.

I meant the Object in the Renderman sense (beginObject: etc.). Whether 
that is created using a compile action, I cannot tell from the current 
interface.

On Sunday, March 16, 2003, at 02:33  PM, Philippe C.D. Robert wrote:

> Talking MVC, a scene graph is a data type and hence it provides the 
> model only, actions such as the G3DRenderAction are the controllers 
> which operate on this data, and the camera/view duo is the view which 
> is used to visualise the data.

In MVC as I know it, a model is more than just data, it is also 
behaviour. A model object stores its own data and acts upon it. 
Controllers communicate with the model objects -- they do not operate 
on the data. If they do, it violates data hiding.
> In other words, the scene graph only contains the data to be used by 
> the renderers to visualise the respective scene, this includes the 
> geometry but also transformations, shaders and likewise data. 
> Therefore you can for example render the same scene using different 
> renderers to generate different results (in any aspects) without 
> touching the scene data at all. So the model is indeed completely 
> separated from the view.

This sounds somewhat contradictory. On the one had, the scene graph is 
little more than a container -- in which case, why have classes at all? 
On the other hand, you claim that the renderer never touches the data. 
How is that possible? Something must be able to access it, while 
guaranteeing that the data is preserved and internally consistent. The 
renderer cannot take on that responsibility. In which case, the scene 
classes provide mutator and accessor methods, and nothing else? If a 
shape holds in it a set of polygon (attribute)s, say ten thousand, is 
this really going to be copied into a dictionary, and then read back 
out?

You could help me in my confusion by describing the steps necessary to 
access a scene and draw something in a frame buffer, by sketching the 
call tree if possible, because I really cannot visualize it.

I want to draw a sharp distinction between what I consider the real 
scene data -- the things in the scene and their relation to one 
another, including scene level attributes -- and the -representations- 
of the things in the scene. You have me questioning whether such a 
distinction is possible, but I am confident that it *is* possible, and 
that the distinction is very important and could make a big difference 
in the design and performance of the software. If I can find that 
difference, I want to pull out all the representation data and let the 
renderer itself manage it, with help from data/file controllers. This 
will make the scene smaller and lighter, and leave the RenderKit to 
manage it more intelligently. It will make it easier to use different 
renderers to present the same scene, and even allow other kinds of 
views to pose as a renderer to present the scene data in a completely 
different fashion. But this is dependent on things that I cannot know 
by looking at the interface.