Re: [Gnu3dkit-dev] Another project to compare ourselves to

[Brent Gulanowski]

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.