[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu3dkit-discuss] UML diagrams
From: |
Philippe C . D . Robert |
Subject: |
Re: [Gnu3dkit-discuss] UML diagrams |
Date: |
Mon, 11 Nov 2002 22:13:20 +0100 |
On Monday, November 11, 2002, at 05:29 Uhr, Brent Gulanowski wrote:
On Sunday, November 10, 2002, at 07:22 AM, Philippe C.D. Robert wrote:
FYI I added a first UML diagram and updated the 3DKit info file on
the website. More diagrams may follow later. Please be aware that
this diagram is not complete nor very detailed, its intention is to
give a rough idea of the new design approach.
Feedback is welcome, of course!
Shall we make a relationship between nodes and cameras? It's not
strictly necessary but to me it is intuitive, and then the camera
would not need to remember it's own location, but could be attached to
some shape or group. Groups will have transformation information, yes?
Ah! Perhaps this is what all nodes share.
No, I do not consider this a good idea. I know that some scene graph
APIs connect cameras to nodes, but IHMO this means connecting 2
entities together which do not belong together.
What is the general reasoning behind restricting geometry to leaf
nodes? I'm wondering what happens if we ignore that restriction, have
only one node class, and then have a light class that would be at the
same level as a geometry container class, of which a node can have as
many as it wishes.
This is a valid argument and it is interesting. The NeXT 3DKit had
something similar. The problem with this kind of scene graphs is that
they are commonly very hard to tune and optimise. I think we should
find a compromise here, looking at scene graphs having hundreds of
classes frightens me...:-)
Scene Rep vs. Node: is a scene rep sneaking in as a replacement for a
world-type class? What if a node *is* a scene rep? Then any scene rep
can have other types of scene reps (nodes or BSPs or Octrees) as
children. The node class could adopt a SceneRep Protocol. And a
G3DNode would be better called a G3DSceneNode. Or does a scene rep do
very different things from a node? I guess the problem with mixing
different types of Rep in the same tree is that you might have to have
multiple scene managers.
Nope, the original idea was to have the means to differentiate between
representation techniques such as octrees, scene graphs and so on.
-Phil
--
Philippe C.D. Robert
http://www.nice.ch/~phip