[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu3dkit-discuss] UML diagrams
From: |
Brent Gulanowski |
Subject: |
Re: [Gnu3dkit-discuss] UML diagrams |
Date: |
Sun, 10 Nov 2002 23:29:44 -0500 |
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.
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.
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.
How do you want to specify the functionality of each of these classes?
--
Brent Gulanowski address@hidden
http://inkubator.idevgames.com/
Working together to make great software.