[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu3dkit-dev] New core API

From: Philippe C . D . Robert
Subject: Re: [Gnu3dkit-dev] New core API
Date: Tue, 31 Dec 2002 15:21:02 +0100

On Friday, December 27, 2002, at 03:34  Uhr, Brent Gulanowski wrote:
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?

I do think so, but maybe at a different level ( I might be already one step ahead, excuse me if I do not communicate enough ) and maybe not for this kind of API. It is my intention *not* to reinvent yet another 3D toolkit (this time written in ObjC), my goals are to provide a flexible foundation for 3D application writers which use Cocoa/GNUstep. Thus the 3DKit should IMHO really be as thin as possible and it should avoid introducing new, heavy programming paradigms wherever possible - this is esp. important in 3D graphics as you simply cannot expect users to adopt new ways of describing their existing data or program flow, they just won't use the API then (of course this does not apply to tiny apps or only to a lesser extent to new apps). This is why there cannot be The One SceneGraph API .... in a few words, the 3DKit's core API is not about providing as many classes or functions or revolutionary new functionalities as possible but about providing a thin API which lets the user develop advanced 3D stuff using the 3DKit. But it must be possible to use the 3DKit to implement such revolutionary ideas and moreover the 3DKit should facilitate the design and implementation of such ideas!

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

It depends in what coordinate system you intend to cull and who the action finally performs - this is mainly an implementation issue though, as I see it.

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

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?

The original G3DApplication class was a new class, not a subclass of NSApplication. The reason why I decided to drop it was that I did not want to manage threads at this level. Again I want the 3DKit's core to be as simple as possible. By using the action paradigm it will be possible to create a controller which uses multiple threads for action execution w/o altering the 3DKit, such a controller might even become part of a utility library. Of course this implies that the parts of the 3DKit's core must be thread safe.

Philippe C.D. Robert

reply via email to

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