[Verse-dev] questions about the verse.h interface

[Emil Brink]

On Fri, 13 Aug 2004 20:40:10 +0200
Thorsten Jordan <Thorsten_Jordan@gmx.de> wrote:

> Hello,
> 
> it's me again with more questions.

Hi! I love the interest/feedback,  it's very encouraging and stimulating.
I will try to answer to some of the questions, since I'm not sure if
Eskil is online or not. I hope he will read what I say, and correct
me and/or further expand on the subjects if necessary.

> The verse_command_o_transform_unsubscribe command takes a node_id and a 
> VNRealFormat type argument. Why do we need an type for UNsubscribe? The 
> type is already known.

I think this is either because we don't want to look up at what precision
you're subscribing, or because you can subscribe to both precisions at 
the same time. The latter sounds... slightly useless, though. From my
reading of the code, there seems to be no checks against subscribing at
both precisions.

> Why there are two verse_command_g_vertex_delete commands, namely 
> verse_command_g_vertex_delete_real32 and 
> verse_command_g_vertex_delete_real64? The type should be implicitly 
> given with the layer_id.

Yes, this is very confusing. It's simply an artefact of the way the
command system works. The set_real32 and set_real64 commands are two
different commands, using unique 8-bit command IDs in the network.

The delete-commands are "aliases" of the set-commands, meaning they use
the same command IDs but otherwise unique parameters to be identified.

Since we have two distinct set-commands, we also get two distinct delete-
commands. In the server end, they are both handled by the exact same
code, so there really is no semantic difference.

> There is a command to set a bone, and one to destroy it, but how can 
> users change bone values (position and rotation)?

Good question. I think "curves" are the answer, although I really have
to pass this one on to Eskil.

> The use of the target_id parameter in verse_send_o_link_set is unclear 
> to me, the spec doesn't help me either.

Ehum. Me, too... I've mentioned that to Eskil a couple of times but not
with sufficient force to get a (good) reply. :) I think the text in the
spec now is the result of one such attempt, and I can sort of semi-
understand it.

I feel the parameters should be renamed, in any case. The parameter now
called "link" should be called "target", and the "target_id" should become
"option", "index", "subtarget", or something along those lines. Perhaps
something for R4?

> The explanation why the type is send again in 
> verse_send_b_layer_set_tile is a bit mysterious. I know the type of my 
> layers... does this parameter allow to send tiles with different types?

No. *You* know the type of your layers, but Verse does not. That is,
the library code that is to take your tile and build a network packet
from it, does not have a look-up table where it can check the type of
that layer. Still, it needs to know what data is present in the tile,
so the only way is for you to tell it.

> Why has the verse_send_g_vertex_delete_real32 command no layer_id? Well, 
> vertices are always in layer 0, i know, but how do i delete values from 
> other layers then?  (the same question for delete_real64 and delete_polygon)

Whoa. This is a rather scary question, since it calls the attention to a
hole in the spec.

The answer is that you don't need to delete values from other layers,
since all the layers always have the same length as their "base" layer.

All vertex layers are sized to provide one value of their respective type
per vertex in the base vertex layer, and the same holds for polygon
layers.

Thus, when you delete a polygon (or vertex), you also delete all other
values associated with that polygon/vertex but held in the other layers.

There should be some semi-graphical way of communicating this that needs
to go into the spec, I'll see what I can do.

I hope that helped a bit. Regards,

/Emil