[Top][All Lists]

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

[Gnu3dkit-discuss] Actions as transactions

From: Brent Gulanowski
Subject: [Gnu3dkit-discuss] Actions as transactions
Date: Tue, 31 Dec 2002 11:34:34 -0500

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) via AIM will work). I have quite a lot of reading to do this week.

Brent Gulanowski
Mac game development news and discussion

reply via email to

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