利用者:Jiri/SummerOfCode2005/Verse Integration

Verse Integration to Blender

User documentation and testing builds

You can find testing builds of my development version and documentation containing lot of screenshots. Feel free and add you comments and criticism:

User documentation for Verse integration to Blender

Proposal

You can look at my proposal of integration verse protocol to Blender.

Data Model

It is absolutly needed to use dynamic data structure, due to real-time fundaments of verse protocol. Two way dynamic list is widely used in Blender and you can easily access items in list using pointers. It has constant time for inserting items at the head and tail of list as well accessing all items in list. The biggest disadvantage of this model is inability to access items with some index. Accessing items with indexes is absolutly neccessery, because verse callback function identify all data with indexes. Due to I improved two way dynamic list and result is two way dynamic list with access array. It has all benefits of two way dynamic list and it allows access all items in list with index (no realloc of items in list :-)).

Blender Data

Object

Object stores informations about position, rotation and scaling. Transformation of object can be easily shared with verse object node. Mesh object as well "points" at own geometry data. This data constraint can be represented with verse link.

Mesh

Main target of integration verse protocol is "sharing" mesh data in real time. It is currently very hard, because mesh data can be in several modes. Mesh is stored in different data structures in object(Mesh) and edit mode(EditMesh).

Verse Data

The verse client API does not store data. No, it does not store data. I need to do that myself. I could use some existing solution, for example: enough library or ample. I decided to use my own solution.

Verse data would be "thin layer" between information comming from verse server and blender data. We cannot change Blender data directly, because geometry data are stored in dynamicaly allocated arrays, when object is in object mode, face select mode, etc.

Implementation

New Files (.c, .h)

Verse wrapper source files are stored in ./source/blender/blenkernel/intern directory. This wrapper contains 5 files now:

• verse_session.c handles session with verse hosts (servers), 2 callback functions, setting of connections, etc.
• verse_node.c basic operations with all node types, related callback functions, etc.
• verse_object_node.c handles operations with object node
• verse_geometry_node.c handles operations with geometry node
• verse_bitmap_node.c handles operations with bitmap node
• BKE_verse.h contains definitions and function prototypes, this files can be found in ./source/blender/blenkernel directory

All these files should be independent at rest of blender as much as possible. It should work only with "verse" data (VerseSession, VerseNode, VerseLayer, VerseVert, etc.) not with "Blender" data (Object, Mesh, EditMesh, etc.)

"Glue" between verse data and blender data will be in different source files. You can find such files in ./source/blender/src),

• verse_common.c offers "common" functions like: "name of verse client"
• verse_object.c offers function like "push object to verse server"
• verse_mesh.c offers function like "push edit face to verse server"
• verse_image.c offers functions for sharing images with some other apps (gimp, etc.)
• BIF_verse.h contains only function prototypes and can be found in ./source/blender/include directory

Some other files will be added in the future, when integration of verse will be extended.

Dependencies with Existing Blender Data

There will be minimal changes in existing blender data. There is no need to store any information about verse data to .blend files. I only added one pointer to EditVert, EditFace and EditMesh, I use one bit in Global->flag ... that's all :-)

Dependencies with Existing Blender Calls

Every adding or deleting of EditVert or EditFace will cause sending some data to verse server. Every change of EditVert position will cause sending data to verse server too ... I will have to do some small hacks in editmesh code.

GUI

Some screenshots showing changes of menus can be found at the end of this page.

We need some manager of verse nodes, links, layers, sessions, etc. User would like to choose for what nodes will be subscribed or not. Outliner window would be ideal for this purpose. It is used for visualisation of blender data now, but it shouldn't be bigger problem to extend outliner functionality and do some visualisation and management of verse data in outliner.

Data/Event Diagrams

• You can see on the following image some simplified visualisation of verse data ("path" to geometry node is highlighted):

Visualisation of Geometry Node

We can see two verse sessions at image. It means, that verse client established connection with two verse servers at the same time. Each session "contains" some list of nodes. One of node is geometry node. Geometry node can contains several layers. This geometry node contains vertex layer, polygon layer an vertex weight layer.

• Graph demonstrating sending Mesh object to verse server:

Graph demonstrating sending Mesh object to verse server

Sending of mesh object isn't as easy as it could looks like. Why? When we call function "verse_send_o_node_create()", then we can receiver back this call from verse server with absolutly different ID of node. Verse server is ID master (not our verse client or anybody else). We have to wait until we receive =verse_send_node_create()= function from verse server ... when "owner" is equal to "VN_OWNER_MINE", then we can be sure, that this is our node and it will have "node_id" "forever" ... we can send next VerseNode waiting in sending queue. Syntax of callback function for "verse_send_node_create()" command:

void callback_node_create(
void *user_data,   /* pointer at some user data */
VNodeID node_id,   /* ID of new created node ... verse server assigns IDs */
VNodeType type,    /* type of new created node */
VNodeOwner owner   /* owner of node: VN_OWNER_MINE or VN_OWNER_OTHER */
);

...

/* set up callback function for verse_send_node_create command,
 * pointer at user_data will be NULL */
verse_callback_set(verse_send_node_create, callback_node_create, NULL);

• Sending other verse data to verse server is implemented similar (verse layers, verse links, etc.). Sending is synchronous, becuase verse server is master of IDs. Sending of verse vertexes and faces is asynchronous and fast, becuase I can identify vertex with it's position and face with vertex indexes.

Problems

Object mode, DerivedMesh, VerseMesh

I talked with Daniel Dunbar about DerivedMesh and potential benefit for Verse integration to Blender. He said, that DerivedMesh propably wouldn't help me much. He suggested change Mesh (in object mode) directly using realloc, but there will be many problems with verse indexes, because verse could create "white spaces" in dynamic allocated arrays. I don't know what solution should I use, because I have some doubts about every solution :-(.

Python API

Mesh data structures has its own python API. I assume, that python API works with data stored in dynamic allocated arrays. When some other client willinge verse data, then data in dynamic allocated arrays will not be up to date. (Toni Alatalo notes: that is probably the case with the thick wrapper NMesh that was prominent when Jiri wrote this, but AFAIK is not with the thin / direct wrapping Mesh module that was introduced in 2.40 - there py api stores no mesh data, so what is shown to py code is always up to date)

Face select mode, vertex paint mode, etc.

Similar problem occures, when mesh object is, for example, in face select mode and other verse client change geometry of this mesh in the same moment.

Proposal of Temporary Evil Hack

When object is in face select mode, vertex paint mode, etc. or python API works with mesh data structure, then verse data would be "locked" ... blender would keep mesh geometry in the same state. It would revert any changes from other clients ... Mesh in object mode/face select mode/etc. would be still up to date. It breaks concept of verse client application little bit, but keep in mind, that it is only temporary solution until verse will not be implemented for other modes and python API.

TODO

• support for undo (object mode)
• renaming of geometry node (renaming in Outliner)
• verse update and verse callback function in seperated thread (to get rid of terminated connections)
• Add support for 'verse edges' at least as internal data structure
• Better handling of verse sessions (reconnect, etc.)
• Visualisation of verse layers in Outliner
• Support for subsurf
• Smoothness
• Vertex color
• Vertex weight
• UV
• Armatures, Bones
• RVK
• etc.

Compilation of source code

Make Build System

You will have to modify your user-de.mk configuration file. You will have to add folowing line:

export WITH_VERSE=true

because verse integration is optional feature. Every line of verse source code is in

#ifdef WITH_VERSE
 ...
#endif

or

#ifdef WITH_VERSE
 ...
#else
 ....
#endif

Scons Build System

Edit config/[insert your os here]config.py and set 'use_verse' = true

Links

[1] http://verse.blender.org
[2] http://purple.blender.org
[3] http://www.blender.org/modules/verse
[4] http://www.uni-verse.org
[5] http://www.quelsolaar.com
[6] http://www.blender.org/modules/verse/verse-spec
[7] http://www.elmindreda.org/verse/pitfalls.html

Jiří Hnídek 19 July 2005

Comments

With regards to the face select mode, vertex paint mode, etc. problems. Could you have some kind of write privilege which the server kept track of? What I imagine is when the user tries to change the geometry their client requests the write privilege. While they have it no other client can change the data on the server, but they still receive updates as the changes occur. For small edits like moving a vert you would only need the privilege for the amount of time it takes to update the server, but for long edits (Python scripts, UV unwrap, etc.) you would hold onto the privilege until the action is complete. You would also need some form of time out to keep people from keeping it too long, and some form of fair sharing would be good (no hoarding the write permission).-- EB

Reply

Hi, verse server or verse specification doesn't support any type of permisions or locking :-( and it will be very hard to convince Eskil about needfulness of this stuff :-( . Style of development of verse specification should be changed in the future! -- JH

Reply

Darn, here is the line on the verse page that lead me astray: "Any Verse host is free to deny any client from connecting, subscribing to data and changing data."-- EB

Another Comment

I just tried it and it worked well, but it is really slow, even on localhost. I think it could be nice to be able to tune the refreshrate, or to be able to send modifications only when the edit-action is done. Permissions also seems to me an important thing, Take the case of a complex decimator script, you don't want the mesh to be modified when you are applying the script. . Another case where permissions would be usefull is when you are using verse to teach stuff, it would really be a mess if any student can screw any shared mesh anonymously. On the Verse FAQ i saw that permissions aren't supported in the server implementation but are allowed in the specification. I'm sure you can convince Eskil about it :) FE

Another Reply

Hi, thanks for feedback. Did you try run blender as well verse server with redirection of stdout: =./blender > /dev/null= and =./verse > /dev/null=. Blender as well verse generate lot of debuging messages and it is real bottle neck now. You can find this information in user documentation too. Did you read it? I will commit support for deleting of vertexes and faces. Then I will to do cvs merger and then I will try to implement synchronous sending of vertex position. It should remove flickering, when verse server is too far away and it shoudl improve performance. It is really very hard (impossible) to convince Eskil about anything :-( JH

Reply I did read your documentation, it was really helpfull, i just didn't thought that a suzanne was considered as "huge data" :) It works much faster now, thanks for the tip :) . It's sad that Eskil can't work on the "Permissions" issue. Anyway I'll test the new version as soon as i can. FE

Some Feedback

Hi, I tested verse for the first time today. I experienced two segfaults, but none when I was under gdb :( When I push a mesh, UV information is lost and "set smooth" disapears, and can't be re-set. When I edit a mesh, if the other isn't in edit mode, sometimes he don't see the changes. If I do very fast changes, I exit edit mode, my mesh is Ok, the other mesh havn't synced all the changes, if I "tab tab" to enter/exit edit mode, I lose my last changes. Modifier stack isn't managed at all, if you export a mirrored mesh with subsurf it will appear as an ugly half ;) In fact, it's pretty fun, looks like a good start, sorry if I sound a bit serious here. -- FD