Hi,
I finally got it working: The scene graph is replicated, and changes
during runtime are also replicated. It took me some time to figure out
the *Ptr->dcast() stuff, I was a bit puzzled at first that I couldn't
simply cast variables the usual way ;-)
Like you suggested, I solved the "finding the root node" problem by
registering a functor with the remote aspect. It took me a while to
figure out that I had to listen for the change of a Name type
FieldContainer, not the creation of a Node (or Name... upon creation the
Name is empty...).
So my first steps in OpenSG are working out well so far, but I still got
one problem: All runs well until I change something on my client side,
e.g. creating a node. I thought about the following:
receiveSync
add client-only nodes
show scene
remove client-only nodes again
clear change-list
However, upon removing the nodes, I get "subChild: not one of my
children"-like warnings. So I changed this to:
receive sync
show scene
clear change list
while managing an additional scene (just a NodePtr) with additional
nodes. However, even without trying to add them to the root node of the
scene graph, my client hangs whenever I try to create a new node. I even
tried clearing the change-list immediately afterwards, before displaying
the scene, and before receiving the next sync, but to no avail. I'm not
using any beginEditCP() and endEditCP() calls on the client side, only
on the server side (I want the server to manage the scene common to all
clients, and the clients just to add some additional individual nodes,
which aren't sent back to the server)...
Any idea on why my client hangs when creating a new node?
Thanks a lot so far, without your (and Rasmus') help, I wouldn't have
realized that I had to search for the root node on the client side!
Cheers,
Robert
PS: the makeTorus() function doesn't seem to add the created node to the
change list, it only worked when I created the geometry and node
separately like in the testRemoteAspect example... Is this on purpose?
Dirk Reiners schrieb:
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
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
