Re: [Gnu3dkit-dev] New core API

[Philippe C . D . Robert]

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

-Phil
--
Philippe C.D. Robert
http://www.nice.ch/~phip