Re: [Gnu3dkit-dev] 3D file formats

[Philippe C . D . Robert]

On Sunday, September 29, 2002, at 02:21 AM, Brent Gulanowski wrote:
> 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

Somehow this is the idea, yes - or at least the long-term plan...

>  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?

All this is yet to be discussed...:-) I only started with some simple 
API design...

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

Nope, nothing like that.

> 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.

Once a DB structure is in place you can do a lot of things, but first it 
has to be able to serve as a scene import/export controller.  The 
database representation will maybe be used later to be able to optimise 
a scene for a specific renderer/target device. The information about 
static/non-static elements is IMHO more part of the scene description 
itself (room walls are always room walls).

> 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.

I am interested in realtime rendering stuff and some visualisation 
research topics, but since I strongly believe that simplicity is the key 
to the success I fail to see a reason why others couldn't use the 3DKit 
for sth else...

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