Propagating scene graph changes to a client


Hello @everyone!


I'm trying to solve a problem in which I got stuck in and want to ask you for some help.

We are in the development of a virtual world application with multiple users moving in the world. Thus I want to keep the clients up to date by sending them parts of the scene graph concerning them.

To achieve this and save network bandwidth I want to send only changes that are applied to the spacial relevant to the client. For an example when a box moves its world coordinates and it can be seen by the user.

Now comes my question: how may I get an event/message, when a spacial is changed in the the scene graph and how do I figure out what kind of change was applied?

Help would be much appreciated!


How far have you gotten? Have you checked this out?

Hello nymon,

thanks for the reply. I know about JGN but to me the project seems not very well documented. There exist examples of how to use it, but no real documentation and analysis on the used technics. If you know better please correct me.

Another reason is, that we are currently in a very early stage and don't want to make a commitment to the networking layer. We rather want to encapsulate it as much as possible.

Maybe I should explain my problem a litle bit more. In the Spatial class there exist methods for rotation, translation etc. . They are called every time when changes happen to my object. What I need is a way to determin if such a change has happend and what kind of change. For example if the rotation matix has been manipulated.

I want to use this information to generate an update for the client object that sends only the necessary informations and not the whole object.

I know one way to accomplish this, by changing the function calls of Spatial and adding a line that tells me that an update has happend. But for this I have to change jME so that our version isn't consistent with the svn anymore.

Still hoping for ideas on how to solve the problem.



i dont think you need to send everytime something changes. Also you dont need to alter the basic classes of JME.

Lets say you want to sync some attributes like translation / rotation from server to client at maximum of 1/25 second (which would be much i think) you can simply check every 1/25 second if an attibute changed and if it did, send the absolute value to the client. So if only translation changed, you send a id for the synced object and only the current location of the object to the client. If it dint change, sync it only 1 time per second. The client has to know what to do if it gets a message with these values.

At client side you'll need something like deadreconing so the user does not see any update from the server, which means interpolating ("guessing") the position / rotation etc of an entity between the syncs.

JGN does just that described in first break (not deadreconing) and much other things more.



There are ways indeed to cut down on data transmitted, if you have many many players and moving entities to keep track of then sending more than the bare minimum of data could impact the performance and pleasure of the game.

A player/monster ( moveable ) would have an ID, possibly a String, perhaps a long or int.

To rotate :- For the majority of moveable things only a z rotation ( z up ) is needed, this can be expressed in degrees for the network packet rather than an array of floats, the client can do the necessary maths to calculate the rotation matrix. If that entity can move in more than one rotation then specialise it.

Movement, where they have moved to. This is probably best as a translation, possibly with an ID of the landmass that this translation relates to. A scalar could even be used from the rotation.

Network packets have a max size ( see MTU ), if a network send were for each player, there would be alot of unutilised bandwidth. There are great benefits in putting many player updates in a single network send. Also, f the messages are larger, compression will work better.

Have a look at , this and other articles may help your architecture.

Its horses for courses, depends how many players and moveable things will be in your game.