Re: [Gnu3dkit-dev] Rendering Pattern

[Philippe C . D . Robert]

On Thursday, November 7, 2002, at 01:39  Uhr, Brent Gulanowski wrote:
> On Wednesday, November 6, 2002, at 04:46  PM, Philippe C.D. Robert 
> wrote:
>
> > I hope this was somehow understandable...:-)
>
> It made excellent sense, thank you. Nice to hear from you btw, I was 
> getting worried ;-). I'm also very busy, although I long to be done 
> with the term so I can work on 3DKit prototypes and test work.
> > -Phil
> >
> > PS: It is way to early to talk about optimisations wrt ObjC features 
> > such as IMPs and so on...:-)
>
> OK. I am just concerned about whether the boundary between RK and the 
> renderer will itself be a problem. It's one thing to optimize under 
> the surface, but once an API is designed, it seems so much work to 
> re-design it if it is flawed. Anyway, it is only my inexperience which 
> causes the worry.
>
> I will go a few steps higher into the abstraction, though, and think 
> more about just simplifying the message passing or "transactions" if I 
> can call them that.
>
> I can't even decide which component is best to take responsibility for 
> initiating data passing, how much overhead there will be, or in what 
> form to have the data. Is the renderer the front end of a pipe that RK 
> throws things into, or is RK a container that the renderer reaches 
> into to take what it needs? The latter sounds better from an OOP 
> standpoint, but it is also sounds more fidgety, and avoids the fact 
> that the there is a pipeline into which stuff eventually gets dropped, 
> never to be seen again -- not very OOP at all.
>
> I may have already mentioned I lately have been thinking of software 
> using a workforce analogy. So I'm trying out different organization 
> strategies, management strategies, and job responsibilities. Asking 
> questions like, "How does this task get initiated?", "How can this 
> task be broken up?", "What order do the tasks have to be done, or can 
> they be done in parallel?", "Who decides if a task was completed 
> properly?", "Who sets deadlines? How are they enforced?", "Which 
> groups of tasks can be set apart in a separate department/module?", 
> "What are the lines of communication between departments/modules?"
>
> Anyway, some tasks are appropriate to offices, and some are 
> appropriate to assembly lines -- and painting pictures at 30fps on a 
> monitor is definitely the latter. But lots of stuff requires 
> management and flexibility, and looser organization -- I am thinking 
> about how tasks of one sort interface with tasks of the other sort. 
> This is why I am so fixated on the details of the interface, even 
> though it seems premature. I was being a bit backwards to think of 
> using lower level interfaces between RK and a renderer, though. I 
> should think in terms of how to send larger ADT objects across the 
> interface, since a rendering system has to be able to move large 
> amounts of data very quickly to get its job done. We can't transfer it 
> in little tiny packages -- too much overhead!

This is exactly the point where I believe we can Think Different to 
distinct the 3DKit from other "normal" scene graph APIs. Maybe not as 
part of the core implementation but definitely on the higher level 
interface side.

> But when the time comes to submit the geometry to the pipeline, I'm 
> wondering how to avoid any message passing. It would be neat if the 
> ADT objects could be sent from the RK to the renderer, at the 
> renderer's request, and then be plugged into the low-level pipeline, 
> while the pipeline settings are modified by the renderer as it reads 
> some kind of manifest in parallel with the data's being unloaded down 
> the conveyor belt...

This is where I want to use the special scene representation for, 
created by the CULL stage. Since this won't have to be exposed it can 
be pretty lowlevel and straight forward. This will hopefully lead to 
optimal performances.

-Phil
--
Philippe C.D. Robert
http://www.nice.ch/~phip