Hi Haeyong,
some minor additions to Carsten's and Marcus' mails.
Carsten Neumann wrote:
>>
>> Q1. Does every server node hold the exactly same scenegraph?
>
> yes, unless you modify it in the code running on the server of course.
Scenegraph, yes. There are some changes inside the ClusterWindow (to draw the
different cameras for the different tiles), but they are not visible to the
outside.
>> Q4. What is inside the scenegraph change list? I know that it is
>> changes of the scenegraph for a new frame, but I would like to know
>> what is exactly included. Transformation matrix or projection matrix?
Both actually. Given that the cameras are part of the scenegraph, all camera
changes are automatically transmitted.
> an entry in the changelist contains:
> - id of the container that changed
> - a BitVector indicating which fields of the container changed
>
> As you can see this alone would not be sufficient to recreate the
> scenegraph on the remote side, so when transmitting the changelist over
> the network additionally the contents of all modified fields of are sent
> so that the remote side also has the data that was modified. This last
> part is handled by the RemoteAspect.
> Also, the format of the changelist is considered an implementation
> detail so it can change if needed.
There is also some information about object creation, object deletion and
reference count changes that is transmitted with the CL. But as Carsten says,
the format of the CL is tied to the internal data structures and we make no
guarantee about it changing in the future. Do you think you need access at that
level?
>> Q5. In comparison with graphics primitives, what kind of benefits can
>> we get by sending the scenegraph chages over the network? network
>> bandwidth?
>
> basically yes, after the first synchronization (where the initial
> scenegraph has to be transmitted) the amount of data required for
> transmitting changes is usually much smaller. For example if you only
> change the point of view, only the modified matrix has to be transmitted.
> The dissertations of Marcus Roth and Dirk Reiners contain analysis and
> details for these aspects of OpenSG, however they are in German and
> therefore (probably?) not much help to you.
Mine is actually in English, but given that the clustering was not my work I
say
very little about it.
Haeyong Chung wrote:
>
> Does the client broadcast the entire rendering data (including
> graphics primitives, lights, texture, and shade information) to the
> servers while syncing the scenegraph?
> Do you mean every node holds the same whole rendering data, regardless
> of which part a node draws?
Yes, in general. So for large model sort-first this won't work. To work around
that we have the ProxyGroup, which only loads the data once it is needed. By
setting up the main graph on the master with ProxyGroups each slave will only
load the parts of the model it needs to render, which for Sort-Last will be
much
smaller than the whole model.
It's not the best solution, but the one that was the easiest to implement,
given
that Marcus' was more interested in the image composition than large data
management.
In the long run my plan is have an out-of-core data management system that
would
handle loading the right data on the right nodes automatically based on the
view
and visibility masks.
Yours
Dirk
------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
