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

Philippe C.D. Robert

reply via email to

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