Re: [Gnu3dkit-dev] 3D file formats

[Brent Gulanowski]

On Saturday, September 28, 2002, at 10:44 AM, Philippe C.D. Robert 
wrote:

> Hi,
>
> I am back from my trekking trip and ready to do some 3D work again... 
> One crucial part of the new 3DKit will be its flexibility wrt 3D file 
> formats. I believe it is very important to have a generic mechanism in 
> place which easily allows programmers to write and integrate 3D file 
> format readers/writers. I see several possibilities for this:
>
> - a G3DDatabase class which uses special reader and writer classes to 
> import and export 3D scenes
>
> - a class cluster similar to image handling in the AppKit
>
> - no special mechanism but many readers/writers as part of a 3DKit 
> utility framework
>
> - ... other proposals?
>
> I favour the G3DDatabase approach because this offers more power than 
> just import and export functionality, ie. scene rep optimisations or 
> conversions could be integrated as well.


I would vote for a database approach, under the assumption that this 
would allow 3dkit applications to work with virtually unlimited amounts 
of stored content as dynamically as possible.

Is the idea then that the database imports or exports to flat file 
formats by calling translators, but 3dkit works with an internal fomat 
that is more intelligent and includes better structural information 
about the scene? And would the database have the ability to store 
different sorts of data in a way that you could access them 
individually? So that, say, you imported some model with jpeg textures, 
then those textures would immediately be available as general 2D 
texture assets for re-use? Or would artistic assets be kept outside of 
the database proper (say in a virtual directory, like a .pak file), and 
only references to them kept inside along with scene information?

It's not as though the database would be relational or anything 
dramatic, right? We're just talking about flexible and efficient 
organization.

In 3dkit 0.3, there was a distinction made between dynamic and static 
scene elements, but this was not overtly represented in the class 
heirarchy, which I liked. (Of course I am familiar with games, which 
usually make this distinction quite sharp.) I would want to take this 
to its logical conclusion, which is that every element of a scene is 
itself a scene. By maintaining all assests as scenes in a database, it 
should be easier to assemble new scenes quickly from existing assets, 
simply by retrieving sub-scenes from the database. Also, you could 
produce as many scenes as you wanted without needlessly duplicating 
assets inside of flat files when you go to save a scene. The scene 
structure is saved in the database, but the actual vertex and other 
data would be accessed with references. When I talk about assets, I 
mean the unstructured lists of vertex and texture data which we 
consider an atom of 3D content. It might make sense to identify what a 
good size would be for the smallest and the largest piece of array 
vertex data, because the smaller the atoms of raw content, the bigger 
the database, and vice versa.

Phil, are you suggesting that the database will be ideally able to 
identify when it is possible to merge small atoms into larger atoms, 
such as when they are tagged as static, or at least relatively static 
with respect to one another? And would these optimizations be 
restricted to in-memory operations, or also affect on-disk operations, 
say during an export, or when a scene is transferred from an 
in-progress state to a finished-artwork state? I've become very 
interested in the nature of 3D content as it relates to the way it is 
being used. If it is merely being drawn and shoved around a scene, you 
can make assumptions that you can't make if it's individual parts still 
need to be distinguished.

I'm really using my intuition here, so I hope its alright if in fact I 
don't know the detailed implications of what I'm talking about. One 
thing that seems to me important is if 3dkit applications will be both 
the producers and consumers of the imported and exported scenes, or if 
there would be some kind of flow. Is it hoped that 3dkit will be used 
for all sorts of 3d applications (modelling, offline animation, 
realtime animation) or targeted at some specialty? I can guess that 
realtime is a high priority from your emphasis on performance and 
optimization, but I'm sure these are desired across the board. I 
suppose the trend in the industry is to make scene management tools 
able to handle all applications.

> -Phil
>
> PS: Expect the (non functional) new source tree to appear on Savannah 
> within days.

Great!

--
Brent