Hello Xavier,
On 04/25/2012 03:45 AM, Xavier Martin wrote:
> I am currently exploring ways to control the scenegraph over the
> network, i.e. add nodes, create boxes, move them, apply a material, etc.
>
> I was wondering whether anyone pulled that off successfully before,
> and whether OpenSG provides a mechanism to make this easier.
>
> Right now, I am contemplating "flattening" all commands, as in,
> sending a command "CREATE NODE" that creates a node on the rendering
> machine, and sends back a GUID to the distant caller for further
> reference. Setting a node's core would look like "ID 1423 SETCORE ID
> 201".
> You can guess how painful this will get when I'll have to remap the
> entirety of the API, and even more so when the API will change a tiny
> bitsy between versions.
hmm, one way I could imagine this could be made to work is by using the
(experimental!) python bindings. You encode a command pretty much like
the above as a string and to execute it you:
- find the object with id 1423
- get its class's dict
- look up function "setCore" in the dict
- find the object with id 201
- call the function with the two objects as arguments
The advantage would be that no code has to be written to map the string
"setCore" to a call to the Node::setCore() function. I haven't fully
thought this through so there probably are issues in the details ;)
> I have read a little about the changelist mechanism used in OpenSG,
> and it looks like it could be used to handle my issue far more
> elegantly.
>
> Ideally, I would have one or multiple clients sending commands, and
> the rendering would occur on a single target machine.
>
> Would it be possible to have a "shallow" copy of the scenegraph on a
> client machine?
> A client would modify his scenegraph, flatten his changelist to a
> bitstream, send it over the network and then the server would inflate
> it and apply the client's changes. The server would broadcast this
> changelist to other clients if necessary.
>
> Is this scenario possible?
The way OpenSG's cluster implementation works is by distributing a
scenegraph to render nodes. That means that usually the client and each
render node have a full copy of the scene graph. The ChangeList records
which Fields in which FieldContainers have been modified (it does not
store the new or old data that is modified). When the RemoteAspect is
asked to transmit a ChangeList it goes through the entries in it and if
data needs to be sent it transmits the contents of the modified Field along.
The concept is mostly geared towards use with one client making changes
and distributing those to (multiple) render nodes. Having multiple
clients making changes is possible, but there is not much experience
with it since changes one client makes also have to be shared with the
other clients and merged with their own ones. That last part is
difficult to do in an application neutral way.
Cheers,
Carsten
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
