[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
Tue, 8 Oct 2002 21:52:13 +0200
On Dienstag, Oktober 8, 2002, at 04:19 Uhr, Brent Gulanowski wrote:
Here, I've written yet another long-winded piece. Sorry for the
workload of reading! Feel free to put big X's through anything which
is clearly rubbish or irrelevant, so at least I'll know for the future
On Monday, October 7, 2002, at 04:35 PM, Philippe C.D. Robert wrote:
I tried to answer this mail in detail several times but I then
noticed that I need some more brainstorming cycles on it...:-) So
expect a 'real' answer to come later.
Why would you want to use more than one world class?
Well, I wouldn't call it a world class exactly. Maybe the word "world"
is a misnomer regarding my thinking. The idea of the G3DWorld is that
it represents the absolute root of a scene. I'm curious whether this
is necessary. Perhaps it depends upon whether the static and dynamic
sub-trees have to be completely distinct from one another. I'm sure
you'd want to distinguish them, but I don't have enough experience to
know if they require being fully broken out.
The only thing which makes the root node different from a group node is
that .. well, it has no parent. In 0.3.x the world node did also handle
more rendering issues related to implementation details, but this was
mainly because the design was not thought through to the end, ie. the
traversal code was optimised for one specific need, not necessary
So this said, I still do not see a reason why you would like to have
several world nodes in a graph.
BTW as I said in a previous email, I will probably drop the G3DWorld
class and replace it maybe by a pure G3DRoot node, if at all. Note that
this will require some dramatic changes in the camera design...
When something is defined as being part of the world, that thing is
then universal. I don't see that anything should be universal in a
modeled environment. The idea of having no absolute world root would
be that you simply have sub-worlds. The top of the tree is only
special because it's the top of the tree, descriptive not
prescriptive: the last world container
Exactly, and this is why a root node is nothing else than a group node
w/o a parent.
defaults to being the universe. A sub-world over-rides certain aspects
of the parent, or containing, world, if those aspects are defined.
It's a way to define scope of attributes. Possible attributes: dynamic
lights, fog, environmental forces (wind and gravity, say), shaders,
LOD thresholds and hints, other rendering hints, and visibility
information (portals, octrees, quadtrees, BSPs and the like).
In 0.4 there will be the feature that you can push/pop some state
information in group nodes while traversing. This might be usable
exactly for this purpose. I do not yet know how (and how much) this
will be customisable though.
Most of my ideas about sub-worlds or sub-scenes come out of my
interest in exceedingly large environments, where all kinds of
organization would be required to ensure the content could be managed.
Have you ever considered the question of the upper limit of content
which the RenderKit could manage? How scalable do you want it to be?
Best to know in advance.
Well, it should be generic and not be limited by design constraints.
Coming from a SGI/Irix world I have the habits to not introduce
'artificial' limitations...:-) This said, I hope the new 3DKit will
support very large datasets.
The other benefit of sub-scenes with their own localized root node is
that they can be built and used individually, or added directly into a
super-scene with no additional work required. Artists could build
components and then assemble them together, dropping a self-contained
building model into a landscape, or connecting one room to another,
each having its own scene-wide attributes take precedence. I'm hoping
to make better use of limited resources in this way.
Again, just use normal group nodes, there is no need for a root which
is not a root...
The reason I am so interested in very large quantities of content is
that I hope to do some research, in the next few years, on procedural
generation of environments. There are a lot of existing projects
underway, and many of them have produced impressive results. There are
programs which can generate entire cities from a topological map.
There are programs which can generate entire planets down to a metre
of resolution or less, including vegetation. One military project has
the entire Earth mapped in 3D including rough city maps, down to a
resolution of 10cm in some places. I'm not suggesting that RenderKit
be able to perform such tasks. I would just like to consider if it is
possible to make it compatible with back-end systems that could.
This is interesting, and I can assure you that I will not forget about
this issue because I am concerned by it as well.
In any case, maybe I need a reality check 8^). The current
documentation touches on how RenderKit works, but I don't recall any
material which states what RenderKit's actual objectives are. Will it
be able to load and unload scenery dynamically (ie: while rendering)?
If not, what is the maximum forseeable size of a scene in terms of
objects and polygons? Will it be able
If you will be able to load scenes into an optimised scene rep or not,
I don't know yet. This will also be depending on the
G3DSceneRep/G3DScene concept. In general, one of the highest priorities
is to keep it simple and flexible so that it can be used for many
I personally plan to use it for rendering relatively large scenes.
to load and unload classes dynamically? (Personally I think classes
are over-used, and most class definitions can be replaced by
data-driven generic objects, but just for the record.) How does
RenderKit support behavioural modeling of the objects it manages Would
they be plugged into it (and controlled by it), or would they be
independent and work alongside? Will RenderKit play nice in a
multi-threaded app, specifically where there are threads which
RenderKit does not control? I've mentioned previously my interest in
A.I. being integrated with RenderKit. I never did follow up on that,
but that's an example of a system which would be a natural to run in
parallel with the renderer and need access to the same data the
renderer is using.
The new 3DKit will be prepared for multi threading, yes. Further it
will be tightly integrated into the Cocoa and GNUstep APIs so that it
follows the same design philosophy.
I ask these questions as much to learn if they are valid questions at
all, but I've heard of these issues and would be interested to know
which ones are relevant and which are irrelevant, and what priority
they are, etc.
Well, I hope I could give you some helpful answers then...:-) Maybe you
should split the questions into multiple emails the next time, this
makes it easier to read them (and answer them properly).
BTW I am intending to replace the G3DWorld class by a simpler
G3DSceneRoot class or maybe even remove it completely (if this is
possible at all, this is not yet completely clear to me though).
I'm personally of the idea that everything not a leaf is a group, and
moreover that a leaf is really just a group of one. I'd be interested
in your thoughts on whether there could simply be one G3DScene class,
which would be a node, a group, and a world all in one, depending on
what attributes were present. Then the propagation of recursive calls
down the tree would involve a message to the node followed by a
message to the appropriate attribute. No attribute of that type means
no message is sent, but the general call is still propagated to the
child nodes. Even a pile of geometry is just another attribute.
Well, there are 2 kinds of nodes, leaves and branch nodes. So what is
not a leaf has to be a group...
Of course I'm afraid of how slow this might be. But if it's workable,
every node would in fact be a sort of dictionary. Maybe even a
standard NSDictionary. It would be sent a message asking if it had a
key matching the attribute. If so, work with the attribute. If not,
ask for the children attribute and do the same with them, if they
exist. Do you think that that would just be impossibly slow and too
generic to be workable? I mean, the attributes would have unique
classes, and they would be optimized.
Well, a scene graph should just be what it is, a data structure. The
question how to traverse it etc. is then more a matter of design than
concept. What you don't want is to have slow traversal code, especially
for large environments.
I am fascinated by the dynamism of Objective-C, and I am very curious
how far it can be taken before it runs away with itself.
Believe me, this can lead very far and in general this really is good
and interesting, but 3D rendering has some constraints, one of them
being performance. The challenge is to find the optimal balance between
a clean OO design and raw optimisation, I guess ( just compare
Performer with Inventor...).
Philippe C.D. Robert
- Re: [Gnu3dkit-dev] 3D file formats, (continued)
- Re: [Gnu3dkit-dev] 3D file formats, Brent Gulanowski, 2002/10/08
- Re: [Gnu3dkit-dev] 3D file formats, Philippe C . D . Robert, 2002/10/10
- [Gnu3dkit-dev] Documentation Project, Matt Brandt, 2002/10/10
- Re: [Gnu3dkit-dev] Documentation Project, Philippe C . D . Robert, 2002/10/11
- Re: [Gnu3dkit-dev] Documentation Project, Brent Gulanowski, 2002/10/11
- Re: [Gnu3dkit-dev] Documentation Project, Philippe C . D . Robert, 2002/10/13
- [Gnu3dkit-dev] General goals and strategies?, Brent Gulanowski, 2002/10/14
- Re: [Gnu3dkit-dev] 3D file formats, Brent Gulanowski, 2002/10/11
- Re: [Gnu3dkit-dev] 3D file formats, Philippe C . D . Robert, 2002/10/11
- Re: [Gnu3dkit-dev] 3D file formats, Philippe C . D . Robert, 2002/10/09
- Re: [Gnu3dkit-dev] 3D file formats,
Philippe C . D . Robert <=