Re: [Gnu3dkit-dev] 3D file formats

[Philippe C . D . Robert]

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

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

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

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