[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu3dkit-discuss] G3DRenderer - Object
From: |
Brent Gulanowski |
Subject: |
Re: [Gnu3dkit-discuss] G3DRenderer - Object |
Date: |
Sun, 16 Mar 2003 18:15:27 -0500 |
On Sunday, March 16, 2003, at 06:07 PM, Philippe C.D. Robert wrote:
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?
No, this is not what I meant. A render action traverses the graph and
manages the internal gfx states, now whenever it reaches let's say a
shape having a geometry node attached, it sets up all the states
required for drawing as defined by the shape and then tells the
geometry object to draw itself (by passing the correct renderer to be
used by the geometry object). So the render action controls the
rendering process but the geometry objects draw themselves. Does this
make more sense to you?
OK, I see this better now. Much of the work of the *Action is to
request data, but then at the end it tells the shapes to submit
geometric attributes directly to the renderer. This makes sense.
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'll try...
...
Yes, that helped somewhat. It is starting to get easier to get confused
because I am no learning about Open Inventor and RenderMan concepts at
the same time. This is, in some ways, quite the challenge you have set
yourself, to blend the features of these two different systems.
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.
Can you please give me a concrete example showing what you want to
achieve and what is not possible with the current design approach?
See the other email I just sent re: G3DRenderer.h
Thanks, by the way, for your time in answering my questions. I do
appreciate it and the ideal is that I will be able to contribute to the
project much more when I have a deeper understanding of what your
strategy is. It will also enable me to get back to expanding the White
Paper. I have a MUCH clearer idea of where you are headed. Reading the
RenderMan spec and the Inventor Mentor are helping, although it is not
always obvious when you will take your cue from one, the other, or a
new approach altogether.
--
Brent Gulanowski address@hidden
http://inkubator.idevgames.com/
Working together to make great software.