[Top][All Lists]

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

Re: [Gnu3dkit-dev] New core API

From: Brent Gulanowski
Subject: Re: [Gnu3dkit-dev] New core API
Date: Tue, 31 Dec 2002 10:21:42 -0500

On Tuesday, December 31, 2002, at 09:21  AM, Philippe C.D. Robert wrote:

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!

These are all goals I support strongly. I see your point about not making "yet another 3D API", let alone "the 3D API to end all 3D APIs". I'll amend my statements by saying that re-tooling efforts such as class re-design will still be feasible in areas which are not directly exposed to application developers -- if there are any such areas. If 3DKit is that thin, I guess _everything_ will end up being exposed. "Exposed" is not exactly what I mean, but come up with your own word for classes/methods which are part of the API proper and those which, while certainly visible, will mostly not be touched by developers. But intra-framework APIs are an aspect of my idea of code modules, which have a monolithic quality we perhaps will not want to use in 3DKit.

... Just read your revisions to the white paper, so I have some more idea where I am missing understanding. Have to read up on NeXT 3DKit now I guess. I'll search Google. I have to think more on the Action concept, especially the idea of custom Actions. You are definitely quite a few steps ahead of me, since you've apparently gone past the "what 3DKit does" stage to the "how 3DKit does it" stage. All of my attempts to predict "how" in the white paper are surrounded by <???> </???> tags.

[snipped Frustum stuff]

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.

So solutions for thread management are still a completely open question, I gather. I'm optimistic that we might be able to find a simple solution wherein the scene ADTs in RenderKit can manage multi-threaded access with a minimum of fuss, and the Action code won't have to know anything about threads (paraphrasing your words). At least, that is how I think of thread safety: the data containers declare themselves thread safe and code which accesses the containers need not waste a thought on it. I'll admit that is simplistic when performance is an issue, but like the man says, "optimise later".


reply via email to

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