[Top][All Lists]

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

Re: [Gnu3dkit-dev] 3D file formats

From: Philippe C . D . Robert
Subject: Re: [Gnu3dkit-dev] 3D file formats
Date: Mon, 30 Sep 2002 20:53:45 +0200

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:

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

Philippe C.D. Robert

reply via email to

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