Hi Robert,
sorry for the late response, I and some other people took some time off
over Christmas and are just slowly getting back into the rhythm.
On Thu, 2003-12-25 at 06:53, Robert Hinn wrote:
> Hi,
>
> I'm fairly new to OpenSG. I tried the clustering example (rendering one
> scene in multiple windows) and it worked fine.
That's a good start.
> However, I'd like to have a server that manages a scene graph (all
> changes will be handled by this server) which is connected to several
> rendering servers (one per client), which render this central scene for
> the client. I'd like the rendering servers to be able to render from
> different perspectives, and I'd like to be able to add stuff to their
> (local) scene graphs (e.g. highlight parts of the scene only for one
> client).
>
> So basically I want to replicate a scene graph from a central server and
> make local changes that are not sent back to the server...
That sounds absolutely doable.
> I thought the RemoteAspect class could replicate a scene graph for me,
> but I'm not quite sure how. I know that I can register functors for
> certain changes. Do I have to do this to replicate a scene graph, or is
> this only for changes that I want to handle in a special way?
You only need to do that for special cases, in general the RemoteAspect
does that for you.
It ensures that all changes to the OpenSG structures, that means not
only the scene graph but everything derived from FieldContainer like
Windows, Viewports, Materials etc., including creation and deletion of
objects, are replicated on the remote side. But it's a way connection,
so change on the remote side are not automatically reported back, which
is apparently exactly what you want.
Rasmus was already explained a lot of the mechanics involved in
RemoteAspects (Thanks a lot for that! ;). Questions beyond that I will
have to refer to Marcus, as this part of the system is his baby.
On Mon, 2003-12-29 at 16:49, Robert Hinn wrote:
>
> I read a VRML scene from a file, and added it to my scene graph between
> beginEditCP() and endEditCP() calls in my server (before setting up the
> connection, but also before clearing the change list).
Before clearing the CL might be a probblem. Only changes that are actually
stored in the CL are transferred. So if you clear the CL, everything up to this
point just doesn't happen on the remote side.
> I've got begin-/endEditCP calls around all my scene graph changes on the
> server side, but how does the RemoteAspect know where to apply those
> changes? I mean, I create a node (which my SimpleSceneManagers use as
> root) in both server and client via Node::create(), but how does the
> RemoteAspect know these are my root nodes?
As Rasmus said, it doesn't. The RemoteAspect just makes sure that all changes
to the objects are replicated, but it doesn't actually do anything with
these objects. That's up to the actual application.
> > I mean, I create a node (which my SimpleSceneManagers use as
> > root) in both server and client via Node::create(), but how does the
> > RemoteAspect know these are my root nodes?
>
> It doesn't!!! You shouldn't create a root node on the receiving side.
> After a succesfull sync, you have the full scene graph at the receiving
> side. Then you'll have to figure out how to get hold of the root node.
> You could use the registerCreated function to get hold of a node (any
> node will do), and then use getParent to do a backward traversal until
> there is no parent. Then that node must be the root. I haven't done
> this, so you're on your own here... take a look at the
> testRemoteAspect.cpp file!
You could do that, but it might get interesting when you have more than one
graph or some temporary nodes that are not part of the graph.
There are different ways to solve this. One is to make the root node
identifiable,
e.g. by naming it ROOT, and then on the client side check all created nodes for
their name. You can get a hold of all created FieldContainers from the
FieldContainerFactory via getContainer(id). Right now I'm not sure how to get
the
number of created containers, though. Gerrit, can you answer that?
An alternative is to create your own FC to hold all the information you need
(like Root nodes or other parameters) and create a single instance of the on
the
server side. The client will get that through the RemoteAspect and can then
either
add a callback to the RemoteAspect to get a hold of it, or use the above
mentioned
search to find it.
Marcus, to simplify that, would it make sense to have a single FCPtr variable
in
the remote aspect, that could be used to pass data around and is synced
together
with the CL?
> Absolutely. At least I know I'm on the right track. The clustering
> chapter in the documentation is a bit too brief for me to get a deeper
> understanding...
Yeah, that's primarily written for people who just want to use the cluster
for simple remote rendering, not at the level you're looking at.
> By the way, how does the developer doc differ from the
> user doc anyway, I couldn't find any changes on first glance (apart from
> the user doc .pdf being a few KB shorter...) ;-)
The User Doc hides a bunch of classes and explanations that are
necessary to understand the internal workings of the system. The Dev
Docs have some more explanations about how things work internally, and
about classes that the user cannot use. Admittedly, not a lot more, we
spent the effort that we did spent on documentation primarily on the
user doc, as that benefits more people. For deeper questions just ask
here. ;)
Hope it helps and Happy New Year everyone!
Dirk
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
