[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu3dkit-dev] New core API
Re: [Gnu3dkit-dev] New core API
Fri, 27 Dec 2002 09:34:56 -0500
On Thursday, December 26, 2002, at 04:33 PM, Philippe C.D. Robert
On Thursday, December 26, 2002, at 06:48 Uhr, Brent Gulanowski wrote:
General response to this is that I think it makes more sense to
consider general tasks that need to be performed before trying to
assign them to classes or functions.
I am not exactly sure I understand why you say so?
Perhaps its a personal design method, but I'd call it "form follows
function". I'm not very experienced with existing 3D libraries, which
is both an advantage and a disadvantage. You already know some existing
software very well, and perhaps (I'm interpreting) this is where you
get your ideas for the classes you expect to be constructing. I don't
have this, so I'm falling back on what I know from software design.
We're changing 3DKit dramatically from how it existed in v 0.3. It
seems no longer pertinent to take it for granted that the classes will
have much similarity (except for the scene graph hierarchy, the camera,
and a few other things which are very established). It feels like
"going back to the drawing board" -- at which point I re-evaluate
everything from a generalized point of view, and forget classes until
the discrete areas of functionality resolve again out of the larger set
of requirements. Maybe you don't think this way?
The only reason to have a distinct "context" from "manager" is if a
manager could handle multiple contexts at the same time.
Maybe this can be internal only, or even be integrated into the
context class itself?!
Manages rendering contexts
Well, you could always have context class functions which provide the
functionality required to manage this. So I guess it is more a
question of design philosophy and personal flavour...
The frustum used by a camera object.
Maybe this is too much of OO - should we integrate this
functionality into the camera itself? In the old 3DKit this design
approach resulted in some annoying implementation hacks w/o
providing additional value in terms of usability.
A frustum is really a small thing, with hardly any behaviour other
than accessor methods. Moreover the data inside is not particularly
vulnerable. I think you should just fold the frustum into the camera.
Yes and no. A frustum itself is not very much, but for doing
view-frustum culling it may contain some more functionality (see the
3.x 3DKit as an example). But I think this functionality will go into
the G3DCullAction in the new design.
I thought all the frustum did was intersection testing (which seems a
standard functionality of any OOP definition of a volume of space). I
thought the scene nodes culled themselves. I'll have to look at it
The application singleton used to setup a GNU 3DKit application,
specify the threading model and renderer backend
I now think that we should not provide this class in the core API.
Instead we should make sure that the various actions can be
performed using multiple threads. Otherwise the API becomes IMHO too
I don't see why the core application object should have to correspond
to any particular protocol (I don't mean Obj-C protocol necessarily).
The application should do little more than act as the setup and
teardown and the root of the object hierarchy. If you need a way to
ensure that an application has certain properties, make a convenience
class which can have them (possibly delegate class), and otherwise
provide specifications so that developers can design their own
application which satisfies the requirements of 3DKit.
Again, I am not sure I understand you correctly here. The original
reason for me to introduce a G3DApplication singleton was to have a
clean way (API and implementation wise) to handle multithreading setup
and configuration issues. But I changed my mind a little in this
respect as I now believe that the core API of the 3DKit should only
provide the means for implementing a multithreaded rendering app and
not do the multithreading (setup and synchronisation) by its own.
First this makes the design more elegant/flexible and more important
it gives application developers more freedom when implementing their
If later we see that we need to introduce more support for doing
multithreaded rendering then we will still be able to do so.
Is this "G3DApplication" a sub-class of, or replacement for,
NSApplication? That's what I've assumed. This is what I don't think is
necessary. There's nothing stopping you from creating a class to manage
threads, but what is the reasoning which requires that the app object
does it? I'm suggesting that you set design requirements for an object
that will manage the threads, and provide a basic implementation, but
allow the developer to replace it with her own if desired. This object
would be an instance object of the application. Is that unreasonable?
Moreover I'd like to hear from you whether you prefer having
everything packed into an ObjC class or not - think of bounding
boxes, bounding spheres, transformations and so on... Personally I
would go for C constructs here, but maybe this is way too "old
If some construct has a lot of behaviour, make a class out of it.
Also if the data is fragile, make a class out of it. I would like to
use Obj-C semantics whenever possible, but wrapper classes which
don't do anything except put up walls and gates around disposable
data are pointless. But Obj-C messages make for much clearer code, in
my opinion, than function calls which require explicit specification
of the pointer.
I am not sure I agree 100% with the last comment, but overall we do
agree I guess. I think this question will answer itself over time (as
many other questions... ) when real applications will be written based
on the new 3DKit.
I would like as much of the exposed API to be Obj-C, and internal use
C-style wherever convenient, but draw some meaningful borders between
code modules and ensure safety when crossing them. Tiny objects are
overkill, but huge nested structures are dangerous. Let's find a
The question here is where to draw the border line...:-)
Indeed, it's one of the toughest questions (since we're not designing
the math algorithms :-).
Mac game development news and discussion