Re: [Gnu3dkit-dev] New core API

[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?

> > > o G3DContextManager
> > >   Manages rendering contexts
> > Maybe this can be internal only, or even be integrated into the 
> > context class itself?!
> The only reason to have a distinct "context" from "manager" is if a 
> manager could handle multiple contexts at the same time.

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

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

> > > o G3DApplication
> > >   The application singleton used to setup a GNU 3DKit application, 
> > > ie. to
> > >   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 heavy.
>
> 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 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.

> > 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 
> > school"...:-)
>
> 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 
> middle ground.

The question here is where to draw the border line...:-)

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