Hi Carsten, thanks for your reply! Carsten Neumann ha scritto: > Hello Carlo, > > Carlo Orru wrote: > >> Hi everybody, >> I'm working on a simple clustered application, where the Server has a >> user-defined RenderAction and the Client has the pieces of information >> about the initial state of the geometry to be sent to the Servers >> (including transformations such as translations). >> >> Here is what my application does: >> >> Client side: >> - Create a Cube >> - Create a Torus >> - Create a Cone >> - Apply a translation to the Cube >> - Apply a translation to the Torus >> - Apply a translation to the Sphere >> - Pass the scene to the Server >> >> Server Side: >> - Define a custom RenderAction >> - For every node in the graph containing a Geometry Core: >> - Get the previous translation matrix from the current node's >> parent's Transform Core >> - Define a new rotation matrix >> - Multiply the two previously obtained matrices >> - Apply the result matrix to the current node's parent's >> Transform Core >> >> I found out that the Server loses the initial translation data for every >> node, since it gets overwritten during the last described step and the >> Client sends it only once in the very beginning. >> > > yes, this is intentional. The cluster only transmits changes to keep the > amount of data that has to be transmitted under control. > > >> So my questions are: >> >> 1 - Is there a way for the Server to render the scene applying further >> transformations to it without losing the initial state of the scene (the >> transformation matrices) passed by the client ? >> > > I guess you'd have to keep the initial transformation matrices on the > side, i.e. in some data structure you use for that purpose. > Or maybe you could use a second aspect on the server side and only sync > the initial state to it, but that would make looking up that initial > state rather difficult as you'd have to look into a different aspect > than the one you are working on. > The basic idea behind the cluster is that RemoteAspects are, just like > local aspects, independently modifiable copies of the scene. In this > sense you are attempting something that does not align well with that > idea. Why do you need the servers to work on something different than > the client ? What are you trying to achieve ? Maybe we can come up with > another way of doing it ? > > Well, what I'm trying to do is to make server-side modifications to a scene sent by the client. Such scene can be hardcoded inside the client or read from a file specified by the user. The basic idea is that the server does all the animation stuff using the data received from the client as a starting point. For example: the client reads from a user-specified file the info about the basic scene to animate and the key-frames, and then sends all the stuff to the server which "builds" the animation interpolating the key-frames. So, since the server needs to gain access to every node in the graph, I have defined my own RenderAction method via RenderAction::registerEnterFunction(), which gets called everytime a node containing a Geometry Core is accessed. In this way, I'm able to modify the node's parent's Transform Core by recomputing all the Transform Matrices every frame and applying them to the proper Transform Cores, thus making the animation run. My problem is that, after the first transformations occur, the server loses (overwrites) all the information about the initial state of the Geometry, (and the client sends such info only once in the beginning) while I want the server to be able to get it whenever it wishes without messing too much with the code, which is to be kept as simple as possible.
I hope to have clarified my purpose... So, any suggestions ? Regards, Carlo ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
