gnu3dkit-dev
[Top][All Lists]
Advanced

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





reply via email to

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