[Verse-dev] Bitmap layer ids

[Eskil Steenberg]

Hi

> that may be because Eskil's server just transports the commands, while 
> Marcus' server also builds up an representation of the scene 
> internally...

My server does store all the data internally, where do you think the 
data comes from when you subscribe to it.? read the source.

> well it sounds a bit screwed up to me. If i have to fool up a system 
> of the server/API then it is a workaround for an bug, because the 
> system is not working properly. Event compression may be a good idea, 
> but not for these events. It would help me a lot (and i think i'm not 
> alone here) if the API would just not compress create calls, so that 
> the user can always choose 0 as node_id and wait for the server to 
> send a valid id back.
> If i have to fool the system, the system isn#t designed properly - in 
> my eyes.

This is not a bug it is a feature. removing event compression for all 
create commands is not an option, since ALL commands that create data 
are essentially create commands.

I dont agree that you have to "fool" the system, you have to understand it.

> this gives an extra layer of difficulty. i have external data with own 
> ids (a 3d data file) and just want to get some nodes created by the 
> server - but how can i be sure that exactly the number of nodes or 
> vertices will be created, when i have to use special schemes to fool 
> the system?

The server is authoritative and that means you have to request things.

I see no problem what so ever in requesting multiple layers. lets say 
you want to create  three layers to  store  vertex colors, you would 
simply call:

verse_send_g_layer_create( node_id, (uint16)-1, "col_r", 
VN_G_LAYER_VERTEX_REAL, 0, 0);
verse_send_g_layer_create( node_id, (uint16)-2, "col_g", 
VN_G_LAYER_VERTEX_REAL, 0, 0);
verse_send_g_layer_create( node_id, (uint16)-3, "col_b", 
VN_G_LAYER_VERTEX_REAL, 0, 0);

Thats it, now all you have to do is wait for the callbacks to come back 
with the server assigned ids, and then you can pour in the data.

> it is more pain (also for clients) to look if a node already exists, 
> that was just named in a received "create"-command than to just create 
> a new node then. If create means create, the code would be more 
> uniform. And - you mentioned it - a type change would be even worse. I 
> would have to search my node storage, and move objects around, because 
> they're now of another type - which ends in destructing the node and 
> creating a new one. Nothing is lost by introducing seperate commands 
> here - but much to win.

YES a lot is lost. what happens if some one deletes node 4 and then 
creates a new node of type different type using id 4, but then the two 
are received out of order?

verse will handle this by  removing the delete command. so you dont need 
to re order the commands. This is a HUGE difference in real time 
performance.

If it is a pain in you implementation to look up a node you may want to 
take a look and optimize that code because it will happen with almost 
every verse command.

I would definitely recommend you to take a look at how the verse server 
and  any of my apps handle this. I thing they are written very much 
straight forward and non of this has given me any performance issues or 
problems, other then having to have to to be aware of it.

Cheers

E