Hi David, On Thu, Feb 11, 2010 at 1:44 AM, davidotcom [via Software] <[email protected]> wrote:
> I've been exploring the source and the conclusion is that I need to use > distributed objects to pass scene information around render nodes. Also > since the distributed objects created by all nodes, I'm assuming that the > server will also have a copy of the distributed object too. You own the objects, so no node, including the server, has a copy unless you create and map it. > One thing I'm kind of confused about is how render nodes communicate > distributed object's unique id. I've been looking at eqPly example. It seems > that you have to create your own config, add the framedata id and then you > add the scene/model id to get to the scene information. This seems really > indirect. > > Is there another way to do this? It's really confusing on why you have to > set it up that way. Identifiers are like pointers, just valid across all nodes in a session. For Equalizer applications, your entry point on all nodes is the identifier passed to Config::init (e.g. InitData->FrameData->Camera). Another entry point is data attached to a View, e.g., the model shown in this view. In this case, the views are managed and mapped by Equalizer. Using the underlying network layer, you can also communicate ID's as part of command packets, which you then have to handle. The basic workflow is (see Config::init as an example): - create new unique command ID (client/commands.h) - create packet with command ID (client/packets.h) - register command handler for packet (server::Config::notifyMapped) - implement command handler (server::Config::_cmdInit) - send packet (Config::init) You might also include more information in your packet, so that you don't need Objects at all. To you original question: > The algorithm needs the basic bounding boxes of what's being rendered. Is > there anyway to access that on the server? Right now this is not something where the current code helps you. I'm sure you can find a way to do it using the above information. If you want your work to be incorporated and maintained in the source code, we have to do a proper design and implementation. We've been thinking about some kind of bounding-box interface and (load-)equalizer plug-in API as well, but so far it hasn't reached maturity. Cheers, Stefan. _______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
