[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu3dkit-dev] 3D file formats
Philippe C . D . Robert
Re: [Gnu3dkit-dev] 3D file formats
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
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
- ... 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
It's not as though the database would be relational or anything
dramatic, right? We're just talking about flexible and efficient
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