[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
Working together to make great software.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]