[Top][All Lists]
[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Gnu3dkit-discuss] Actions as transactions,
Philippe C . D . Robert <=