[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu3dkit-dev] Another project to compare ourselves to
From: |
Brent Gulanowski |
Subject: |
Re: [Gnu3dkit-dev] Another project to compare ourselves to |
Date: |
Sun, 10 Nov 2002 17:20:01 -0500 |
On Saturday, November 9, 2002, at 06:46 AM, Lyndon Tremblay wrote:
Providing G3DRemote* or something, notifications and the likes can all
implement what would be generally useful... multiple users working on
a scene, or processing or accessing certain objects by remote means.
And even placeholders for on-demand loading of larger scenes. Textures
provided on an intranet/internet server, rendering a scene onto a
remote display...
You are talking about a distributed, multi-user architecture. I would
love that, although I expect it is quite complicated. I would certainly
like this to be a consideration for the future. How much of the
distributed architecture is already available in Foundation, and how
much would have to be custom built? (Somehow I expect you to say,
"none, and all".)
I think we can certainly prepare for this by keeping the modules
separated by a communication layer -- for now this can simply be a
queue system without network support, or even just a pass-through. We
would also need to account for where these inputs were coming from and
where the outputs were going to. Do you want RK to have to handle such
duties? I would like if the camera class was able to be a proxy for a
renderer on another network node, but if the camera class is written
properly, this can be done at any time in the future. This would still
be different than simply distinguishing between an OpenGL client and
server.
User input is handled, eventually, by the APP action. I can't see how
this would affect RK at all. An application using RK for scene
representation should be able to run a local APP process -- it is free
to include remote user inputs if it wants. There is the issue of having
multiple versions of a scene on different nodes, which have to be kept
in synch. If RK provided that, it would be nice, but it would still not
be a part of the scene rep task per se. We could consider a means of
quickly "check-summing" the scene to test for synchronization
consistency by applications.
--
Brent Gulanowski address@hidden
http://inkubator.idevgames.com/
Working together to make great software.