[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu3dkit-dev] New core API
Philippe C . D . Robert
Re: [Gnu3dkit-dev] New core API
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 ....
...so 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
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
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
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