Re: [Gnu3dkit-dev] 3D file formats

[Brent Gulanowski]

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.

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

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.

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.

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.

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

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.

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

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.

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.

--
Brent Gulanowski                                address@hidden

"Of course the Universe hates you. You're working to reduce chaos by 
expending a lot of energy to do your job. Thus, you're contributing to 
the eventual heat death of the universe, and it's just protecting 
itself from you."               -- John Batzel