gnu3dkit-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu3dkit-discuss] Actions as transactions


From: Philippe C . D . Robert
Subject: Re: [Gnu3dkit-discuss] Actions as transactions
Date: Wed, 1 Jan 2003 23:20:36 +0100

Hi,

the NeXT 3DKit and QRM docu is part of NEXTSTEP, maybe you can find it in the peanuts archive or peak.org. If you can't find them let me know.

-Phil

PS: I uploaded an updated UML diagram (and the overview document) to outline what I mean by 'thin API'. If you compare it to earlier versions you notice the change.

On Tuesday, December 31, 2002, at 05:34  Uhr, Brent Gulanowski wrote:
The more I think Scene Actions, the more it gnaws at me that we are in some way talking about a specialized database application. I don't know databases, however, so this is very much just a feeling. But it certainly seems as though there's a lot of searching, sorting, and selecting being done by the Scene Actions. And the threat of multi-threaded or multi-client access is also very database-like. So I thought I should bring it up, as a means of understanding the process distinct from the part about painting pixels.

If a scene were to be treated like a database, what sort of assumptions would the nature of the data allow us to make that would simplify the design of the (programming) interface?

The data is all linked together in a hierarchy
There are only a few kinds of data (groups, shapes, geometry, lights, attributes/appearance) Very large quantities of structured data are regularly requested -- to be rendered
Certain data might be read-only (static and compiled data)

I'm intrigued by the RenderMan RIB as the solution model for transferring large rendering instructions between RenderKit and the Renderer plug-in. If one was loose in one's definitions, it could almost be comparable to a database table in its ASCII form. In any case a serialized representation, as opposed to direct API calls, which is therefore data-driven (i.e.: more database-like), not code-driven. Therefore more versatile, and slower. Does this conceptual approach offer us any new insights or opportunities?

I've downloaded the RenderMan Interface spec (3.2). I can't find anything about NeXT 3DKit yet, so links are requested (or if you have docs, email/instant message me -- brentgulanowski(at)mac.com via AIM will work). I have quite a lot of reading to do this week.

Brent Gulanowski
--
Mac game development news and discussion
http://www.idevgames.com



_______________________________________________
Gnu3dkit-discuss mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/gnu3dkit-discuss


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




reply via email to

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