[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu3dkit-dev] New core API
Re: [Gnu3dkit-dev] New core API
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 ....
...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!
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 <???>
[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".