From verse-dev@blender.org Tue Aug 3 12:44:01 2004 From: verse-dev@blender.org (Emil Brink) Date: Tue, 3 Aug 2004 13:44:01 +0200 (MEST) Subject: [Verse-dev] Loq Airou Message-ID: Hello. I just uploaded Eskil's brand new "port" of the Loq Airou modeling/sketch tool to the homepage, replacing the old one. Care to describe the changes, Eskil? /Emil From verse-dev@blender.org Tue Aug 3 15:08:17 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Tue, 03 Aug 2004 16:08:17 +0200 Subject: [Verse-dev] Loq Airou In-Reply-To: References: Message-ID: <410F9C51.3060303@obsession.se> hi >I just uploaded Eskil's brand new "port" of the Loq Airou >modeling/sketch tool to the homepage, replacing the old one. > >Care to describe the changes, Eskil? > > > Sure! First of all it brings Loq up to speed with verse and all the new versions of the libs (enough, seduce and betray). That means new pop up menus and new and the new font. I have also made some updates to the select tool that has a slightly nicer appearance, and a bug was also fixed in "revolve" and "tube". Loq no longer requires a edge crease layer and a vertex select layer. The browser has been removed and you can now change object or create new objects via the pop up menus. The only thing really missing is the subdivision rendering code. im working on it, its up and running in a test version of Connector and i hope to have it in soon. Cheers E From verse-dev@blender.org Wed Aug 4 22:24:55 2004 From: verse-dev@blender.org (ingrid eubank) Date: Wed, 04 Aug 2004 21:24:55 +0000 Subject: [Verse-dev] Loq Airou Message-ID:

Cheers indeed!  Thanks for all your hard work!

Ingie

>From: Eskil Steenberg <eskil@obsession.se>
>Reply-To: verse-dev@blender.org
>To: verse-dev@blender.org
>Subject: Re: [Verse-dev] Loq Airou
>Date: Tue, 03 Aug 2004 16:08:17 +0200
>
>hi
>
>>I just uploaded Eskil's brand new "port" of the Loq Airou
>>modeling/sketch tool to the homepage, replacing the old one.
>>
>>Care to describe the changes, Eskil?
>>
>>
>>
>Sure!
>
>First of all it brings Loq up to speed with verse and all the new
>versions of the libs (enough, seduce and betray). That means new pop
>up menus and new and the new font. I have also made some updates to
>the select tool that has a slightly nicer appearance, and a bug was
>also fixed in "revolve" and "tube". Loq no longer requires a edge
>crease layer and a vertex select  layer. The browser has been
>removed and you can now change object or create new objects via the
>pop up menus.
>
>The only thing really missing is the subdivision rendering code. im
>working on it, its up and running in a test version of Connector  
>and i hope to have it in soon.
>
>Cheers
>
>E
>_______________________________________________
>Verse-dev mailing list
>Verse-dev@blender.org
>http://www.blender.org/mailman/listinfo/verse-dev

Don’t just search. Find. Check out the new MSN Search! From verse-dev@blender.org Fri Aug 6 10:17:16 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Fri, 06 Aug 2004 11:17:16 +0200 Subject: [Verse-dev] New releases, with new uv app In-Reply-To: References: Message-ID: <41134C9C.6010805@obsession.se> Hi Im leaving tomorrow morning for siggraph, and Emil just uploaded a new zip with all my application code (including 3 win32 exe files). What is so great about this code is that it should be compilable under Linux and OSX. Im currently running all apps under OSX. several bugs have emerged during the porting and have been fixed. Im going to run the OSX version for an other week so im sure more stuff will emerge. My big Siggraph surprise is a new verse app! its a uv editor that I wrote last week. Admittedly it is lacking some features (such as undo) but it is actually a useful tool. it has basic zoom, pan, selection, transform, rotate, scale, snap, collapse, and projection. But it also have some new innovative features such as "unfold" and a edge collapse features. My plan is to finish the tool of when i get back from siggraph, and then get back to verse development. So there wont be a R4 for at least 3 weeks. There are some Api concerns that needs to be worked at, but my main interest is to change some things on how verse does login and data transfer. I want verse to be a lot faster then it is today. I will also begin working on encryption to make verse more secure. Cheers E From verse-dev@blender.org Mon Aug 9 00:03:23 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Mon, 09 Aug 2004 02:03:23 +0300 Subject: [Verse-dev] at Siggraph Message-ID: <200408090003.i7903Oc02744@tessla.levonline.com> Hi Im sitting at the 2004 AGUA (alias global users assosiation) meeting fixing Loq bugs... whearing a blender t-shirt... Im sure they will kick me out any time now... Well Im off to the blender BOF in a minute but i have found some bugs in loq, and in enough that is very serious, so why not mail in and fix it now. on line 60 and 105 in e_storage_geometry.c the lines: if(layer->data != NUL) should be if(layer->data != NULL && layer->name[0] != 0) in la_draw_overlay.c on the lines folowing 405 the dot product is just wrong making some polygons apper white. the corect code should be: x = y2 * z3 - z2 * y3; y = z2 * x3 - x2 * z3; z = x2 * y3 - y2 * x3; Siggraph has just started and i have so fare not got around much. I did go to a color course so now i know why Nil sucks, not just that it does ;-) E From verse-dev@blender.org Mon Aug 9 15:59:02 2004 From: verse-dev@blender.org (Emil Brink) Date: Mon, 9 Aug 2004 16:59:02 +0200 (MEST) Subject: [Verse-dev] Numerical IDs [R4] Message-ID: Eskil, how about specifying that no valid numerical ID can ever be 0 in Verse? This is true for nodes, I think (for historical reasons, as far as I know), but could also be convenient for e.g. layers, method groups, and methods, and all other places where things are assigned numerical IDs. It would provide an obvious, simple, and fairly natural way to check if e.g. an ID has been set by the server or if the client is still waiting for it, and not use any extra space. Sure, it would mean that the effective number of layers (or method groups, or methods) would be reduced by one, but I really can't see that as a real practical problem. It could also perhaps be possible to include "knowledge" of this in the event compression code, so that code like this: verse_send_o_method_group_create(node, 0, "foo"); verse_send_o_method_group_create(node, 0, "bar"); could work. Today, the event compressor will consider these two calls to refer to the same ID (zero), and replace the former with the latter in many cases. /Emil From verse-dev@blender.org Mon Aug 9 20:26:22 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Mon, 09 Aug 2004 22:26:22 +0300 Subject: [Verse-dev] Numerical IDs [R4] In-Reply-To: Message-ID: <200408092026.i79KQM727660@tessla.levonline.com> Hi! As it turns out Tuesday turns out to be a day when nothing interesting happens at siggraph... > how about specifying that no valid numerical ID can ever be 0 in > Verse? This is true for nodes, I think (for historical reasons, as > far as I know), but could also be convenient for e.g. layers, method > groups, and methods, and all other places where things are assigned > numerical IDs. OK, here is the reason. All node references in verse use node ids, while in most other references verse uses names, (layers, groups, buffers and so on). So only for the object links does one need to be able to set a link to nothing. as i think about it there are a few other id systems where one references to ids, namely material fragments and vertex ids. in these cases invalid references are references to non existing data. (if intentional usually set to -1 cast to uint32 or uint16) i would probably like there to be some mention in the spec that this id is reserved. MAX_UINT is a very natural number since verse ids usually starts at 0 and grows. However please note that having an explicit invalid id doesnt mean that all other values are valid. So if i where to make a change i would rather alow the node id zero, and use MAX_UINT32 as the reserved invalid node id. It is also a smaller change for developers. E From verse-dev@blender.org Tue Aug 10 08:02:15 2004 From: verse-dev@blender.org (Emil Brink) Date: Tue, 10 Aug 2004 09:02:15 +0200 (MEST) Subject: [Verse-dev] Numerical IDs [R4] In-Reply-To: <200408092026.i79KQM727660@tessla.levonline.com> References: <200408092026.i79KQM727660@tessla.levonline.com> Message-ID: On Mon, 9 Aug 2004, Eskil Steenberg wrote: > Hi! > > As it turns out Tuesday turns out to be a day when nothing > interesting happens at siggraph... > > > how about specifying that no valid numerical ID can ever be 0 in > > Verse? This is true for nodes, I think (for historical reasons, > as > > far as I know), but could also be convenient for e.g. layers, > method > > groups, and methods, and all other places where things are > assigned > > numerical IDs. > > OK, here is the reason. All node references in verse use node ids, > while in most other references verse uses names, (layers, groups, > buffers and so on). So only for the object links does one need to be > able to set a link to nothing. as i think about it there are a few > other id systems where one references to ids, namely material > fragments and vertex ids. in these cases invalid references are > references to non existing data. (if intentional usually set to -1 > cast to uint32 or uint16) i would probably like there to be some > mention in the spec that this id is reserved. MAX_UINT is a very > natural number since verse ids usually starts at 0 and grows. > However please note that having an explicit invalid id doesnt mean > that all other values are valid. > > So if i where to make a change i would rather alow the node id zero, > and use MAX_UINT32 as the reserved invalid node id. I was not talking about *node IDs*, I was talking about _all_ numerical IDs. And I propose zero rather than MAX_UINT32 because zero is the same regardless of the width of the IDs type. For instance, if you have a method ID, which is a uint8, and you do this: void something(..., uint8 method_id, ...) { if(method_id == ~0) /* Invalid? */ { ... } } you've just shot yourself in the foot, since "~0" is of type int, and the smaller type of the method_id will mean you're comparing (assu- ming it's indeed invalid) 255 against 4294967295, which fails. Zero does not have this problem. I think having to *repeat* the type of the ID in a cast, like this: if(method_id == (uint8) ~0) is a lot worse for everybody. I think that designing things so that the number of casts that is required is minimized, is a good thing in general, so I prefer reserving zero (which is, to me, a lot more natural than MAX_UINT32 simply because of analogy with the NULL used for pointers). Also, I would find it ugly to use a constant containing a type name for variables not of that type. Comparing a VNodeID variable to a constant called MAX_UINT32 looks very wrong to me. Introducing a set of four (or more?) MAX_xxx constants seems rather inelegant, too. Regards, /Emil From verse-dev@blender.org Tue Aug 10 09:22:00 2004 From: verse-dev@blender.org (Marcus Hoffmann) Date: Tue, 10 Aug 2004 10:22:00 +0200 Subject: [Verse-dev] Numerical IDs [R4] In-Reply-To: Message-ID: Hi, Thats why i decided on the server to use int values for ids and not unsigned... I initialize all id-related vars with -1 - internally. So i can start with 0 and have another state (-1) that describes an unitialized state. but if you would like to change that i would prefer emils version... MAX_INT really isn't a good idea. and its not a big deal to start numbering with 1 instead of 0. greets M > -----Original Message----- > From: verse-dev-admin@blender.org [mailto:verse-dev-admin@blender.org]On > Behalf Of Emil Brink > Sent: Tuesday, August 10, 2004 9:02 AM > To: verse-dev@blender.org > Subject: Re: [Verse-dev] Numerical IDs [R4] > > > > > > On Mon, 9 Aug 2004, Eskil Steenberg wrote: > > > Hi! > > > > As it turns out Tuesday turns out to be a day when nothing > > interesting happens at siggraph... > > > > > how about specifying that no valid numerical ID can ever be 0 in > > > Verse? This is true for nodes, I think (for historical reasons, > > as > > > far as I know), but could also be convenient for e.g. layers, > > method > > > groups, and methods, and all other places where things are > > assigned > > > numerical IDs. > > > > OK, here is the reason. All node references in verse use node ids, > > while in most other references verse uses names, (layers, groups, > > buffers and so on). So only for the object links does one need to be > > able to set a link to nothing. as i think about it there are a few > > other id systems where one references to ids, namely material > > fragments and vertex ids. in these cases invalid references are > > references to non existing data. (if intentional usually set to -1 > > cast to uint32 or uint16) i would probably like there to be some > > mention in the spec that this id is reserved. MAX_UINT is a very > > natural number since verse ids usually starts at 0 and grows. > > However please note that having an explicit invalid id doesnt mean > > that all other values are valid. > > > > So if i where to make a change i would rather alow the node id zero, > > and use MAX_UINT32 as the reserved invalid node id. > > I was not talking about *node IDs*, I was talking about _all_ > numerical IDs. And I propose zero rather than MAX_UINT32 because zero > is the same regardless of the width of the IDs type. For instance, if > you have a method ID, which is a uint8, and you do this: > > void something(..., uint8 method_id, ...) > { > if(method_id == ~0) /* Invalid? */ > { ... } > } > > you've just shot yourself in the foot, since "~0" is of type int, and > the smaller type of the method_id will mean you're comparing (assu- > ming it's indeed invalid) 255 against 4294967295, which fails. Zero > does not have this problem. I think having to *repeat* the type of > the ID in a cast, like this: > > if(method_id == (uint8) ~0) > > is a lot worse for everybody. I think that designing things so that > the number of casts that is required is minimized, is a good thing in > general, so I prefer reserving zero (which is, to me, a lot more > natural than MAX_UINT32 simply because of analogy with the NULL used > for pointers). > > Also, I would find it ugly to use a constant containing a type name > for variables not of that type. Comparing a VNodeID variable to a > constant called MAX_UINT32 looks very wrong to me. Introducing a set > of four (or more?) MAX_xxx constants seems rather inelegant, too. > > Regards, > > /Emil > _______________________________________________ > Verse-dev mailing list > Verse-dev@blender.org > http://www.blender.org/mailman/listinfo/verse-dev > From verse-dev@blender.org Tue Aug 10 15:55:07 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Tue, 10 Aug 2004 17:55:07 +0300 Subject: [Verse-dev] Numerical IDs [R4] In-Reply-To: Message-ID: <200408101555.i7AFt8323087@tessla.levonline.com> Hi > I was not talking about *node IDs*, I was talking about _all_ > numerical IDs. I know, my arguing was that, its not that the way node ids work is the standard way of handeling ids, Node id are the ones that are different form the rest, so my arguing is that if you compani about conssistency, the node ids are the ones that has to change. > if(method_id == (uint8) ~0) I assume this was a typo, you meant: if(method_id == (uint8) ~1) But my main question is when would you ever need to do this test? verse would never send you a value that was -1, so the variable method_id wouldent ever come from verse. And the test you do does not garantee that the failiure of the test means that the id is valid. In other wordts the only reason for theis test is the slight optimization of an early detection of a broken reference. So the invalid id is never used by verse, and are not very usefull in any client end either. if zero was reserverd it would force especialy host apps to have special code to handle this. I can agree that the cast -1 isnt that nice so perhaps we would like to add defines for it in verse.h Next reason is that verse uses -1 internaly as an invalid valuee for a lot of things. A change would upset a lot of things in areas where you wouldent want them to change. Cheers E From verse-dev@blender.org Tue Aug 10 16:03:46 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Tue, 10 Aug 2004 18:03:46 +0300 Subject: [Verse-dev] Numerical IDs [R4] In-Reply-To: Message-ID: <200408101603.i7AG3kE25496@tessla.levonline.com> Hi > Thats why i decided on the server to use int values for ids and > > not unsigned... Just so you know, if you are host you CAN internaly use signed ints, but it meens they will only make use of half of the range of the nodes cahat can be created in verse. How ever if you in your client application would do this it would render your application invalid. Since the host is in charge it could atempt to send you a id larger then a signed id can handle this may chouse you app to break. Obviusly this problem is rather a theoretical one since it would require you to have two billion nodes before the problem would show up. Cheers E From verse-dev@blender.org Tue Aug 10 17:30:23 2004 From: verse-dev@blender.org (Emil Brink) Date: Tue, 10 Aug 2004 18:30:23 +0200 Subject: [Verse-dev] Numerical IDs [R4] In-Reply-To: <200408101555.i7AFt8323087@tessla.levonline.com> References: <200408101555.i7AFt8323087@tessla.levonline.com> Message-ID: <20040810183023.13d2ad93@frontal> On Tue, 10 Aug 2004 17:55:07 +0300 Eskil Steenberg wrote: > Hi > > > I was not talking about *node IDs*, I was talking about _all_ > > numerical IDs. > > I know, my arguing was that, its not that the way node ids work is > the standard way of handeling ids, Node id are the ones that are > different form the rest, so my arguing is that if you compani about > conssistency, the node ids are the ones that has to change. Well, I'm partly complaining about consistency, it's one of my super powers. But, I argued in the direction that I did, towards making the value 0 reserved for all numerical IDs, because it is very handy. > > if(method_id == (uint8) ~0) > > I assume this was a typo, you meant: > > if(method_id == (uint8) ~1) Um, no? That's a tilde (~) character, not a minus... > But my main question is when would you ever need to do this test? > verse would never send you a value that was -1, so the variable > method_id wouldent ever come from verse. And the test you do does > not garantee that the failiure of the test means that the id is > valid. In other wordts the only reason for theis test is the slight > optimization of an early detection of a broken reference. Hm... I wasn't thinking about broken references at all. What I was (am) doing, in Purple, is create a method group and a bunch of methods on my avatar. I then need to track when these have been created, and set my internal variable holding e.g. a method ID to the value given to me by the server. Because I use a rather coarse "node structure has changed" internal notification system simliar to Enough's, I need to check for multiple changes in my callback, it is not a pure o_method_create callback. When doing these tests, I want to make sure that I only care about and look for changes that are not already known, to avoid doing re- dundant string comparisons against method names, for instance. Thus, I want to check if my local method_id variable has been set to a valid ID already, or (if it has not) I am still waiting to learn about that method. I might add that a static variable in C can be guaranteed to be initialized to 0, so I don't need to have initialization code that first sets the ID to ~0 as I do otherwise. This, in my book, is a huge win, since it not only shortens the code, it removes one thing that can be forgotten and thus makes the code more robust. > So the invalid id is never used by verse, and are not very usefull > in any client end either. I disagree. I find it very useful to be able to set an ID variable (or structure field) to a known invalid value, to mark that I am still waiting for the server to assign it. > if zero was reserverd it would force especialy host apps to have > special code to handle this. I can agree that the cast -1 isnt that > nice so perhaps we would like to add defines for it in verse.h Such defines would have to include the type of value, which is not very elegant, compared to just using zero. > Next reason is that verse uses -1 internaly as an invalid valuee for > a lot of things. A change would upset a lot of things in areas where > you wouldent want them to change. Hm... Yeah, I guess, but I think it's worth it to get a cleaner and more easily used API. :) BTW, I don't think I was officially "aware" that all-ones ("-1" as you put it, although I find that confusing and wrong for values of an unsigned data type so I use ~0 instead) is reserved for numerical IDs. Is it? /Emil From verse-dev@blender.org Wed Aug 11 08:35:29 2004 From: verse-dev@blender.org (Marcus Hoffmann) Date: Wed, 11 Aug 2004 09:35:29 +0200 Subject: [Verse-dev] Numerical IDs [R4] In-Reply-To: <200408101603.i7AG3kE25496@tessla.levonline.com> Message-ID: > How ever if you in your client application would do this it would > render your application invalid. Since the host is in charge it > could atempt to send you a id larger then a signed id can handle > this may chouse you app to break. hmmm... the client gives me some id number but I set the node id and give it back to him, so i don't think that the server can crash because a client gives me a number that is to large. > Obviusly this problem is rather a theoretical one since it would > require you to have two billion nodes before the problem would show > up. yes... thats what i thought about in the beginning... this case is a really theoretical one and i have caught it in an if case. and i re-use deleted ids for my nodes so its getting more theoretical to reach the end of the int range... so i don't think thats a big problem. if i get to that point any day i can think of a different implementation. ;) greets M From verse-dev@blender.org Wed Aug 11 14:56:50 2004 From: verse-dev@blender.org (Brecht Van Lommel) Date: 11 Aug 2004 13:56:50 +0000 Subject: [Verse-dev] unique owner id's Message-ID: <1092232609.4394.39.camel@localhost> Hi, The method to check if node is created by the client (owner_id == avatar), doesn't work in all cases. If a client gets destroyed, it's node id can be assigned to a new client, which would then suddenly get ownership of all the nodes created by the other client. I haven't found anything on this in the spec or the server code. I think it would be best to assign all nodes created by a destroyed client an invalid owner id. Whether that invalid id would be 0 or MAX_UINT32 is up to you guys to decide :P. Cheers, Brecht From verse-dev@blender.org Wed Aug 11 15:04:04 2004 From: verse-dev@blender.org (Emil Brink) Date: Wed, 11 Aug 2004 16:04:04 +0200 (MEST) Subject: [Verse-dev] unique owner id's In-Reply-To: <1092232609.4394.39.camel@localhost> References: <1092232609.4394.39.camel@localhost> Message-ID: On Wed, 11 Aug 2004, Brecht Van Lommel wrote: > Hi, > > The method to check if node is created by the client (owner_id == > avatar), doesn't work in all cases. True. As a sidenote, it doesn't work for the avatar itself which is kind of annoying. :/ > If a client gets destroyed, it's node id can be assigned to a new > client, which would then suddenly get ownership of all the nodes created > by the other client. Whoa. That's certainly true, and it's an aspect I haven't given much thought, personally. This "assigning" of ownership is passive though, I'm fairly sure the host doesn't re-send the node_create command for all affected nodes. As you note (below), perhaps it should. > I haven't found anything on this in the spec or the server code. I think > it would be best to assign all nodes created by a destroyed client an > invalid owner id. Whether that invalid id would be 0 or MAX_UINT32 is up > to you guys to decide :P. I agree, and would prefer an ID of zero of course. :) Eskil? /Emil From verse-dev@blender.org Wed Aug 11 17:22:49 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Wed, 11 Aug 2004 19:22:49 +0300 Subject: [Verse-dev] Numerical IDs [R4] In-Reply-To: <20040810183023.13d2ad93@frontal> Message-ID: <200408111722.i7BHMnV25289@tessla.levonline.com> Hi, still at Siggraph, I have the OpenGL and verse BOF today. >Um, no? That's a tilde (~) character, not a minus... Oh sorry. >When doing these tests, I want to make sure that I only care about >and look for changes that are not already known, to avoid doing re- >dundant string comparisons against method names, Again this is what i said, it is mainly use full from optimization stand point. havinga invalid value _is_ ussefull, but i just think that zero is the wrong one. >> So the invalid id is never used by verse, and are not very usefull >> in any client end either. >I disagree. I find it very useful to be able to set an ID variable >(or structure field) to a known invalid value, to mark that I am >still waiting for the server to assign it. I agree it is usefull in your app, but not for the network protocol. Actiually not only wound the host never send you invalid values, it usualy even cant, since this triggers function aliases. >Such defines would have to include the type of value, which is not >very elegant, compared to just using zero. Yes, it would need to have types. (just a question: dont you have issiues against all nunbers typed in to the code that arent defines?) Ok Lets go beyond this and let me explain just how much this would break existing apps, and make them a hole more more complicated: The first main reason is that in C the first element of an array is numberd wero. Imagine that you allocate and array of vertexes, polygons, layers or buffers. Now either you dont use the first element and waist memory or you have to make lookups in to the array with ids minus one. This makes the code way more error prone. Next consider this, If i have a look-up in to a array i must always check for this. For example lets read out a vertex from a a polygon reference. this is how its done now: if(polygon[id * 4] < vertex_length && vertex[polygon[id * 4] * 3] != E_REAL_MAX) this the same code if the zero is reserved: if(polygon[(id - 1) * 4] != 0 && polygon[(id - 1) * 4] < vertex_length && vertex[(polygon[(id - 1) * 4] - 1) * 3] != E_REAL_MAX) This extra test have to be done for every corner in the polygon and is just a hazzle. It compleatly breaks all my apps (in more then one place). and it is likely to introduse a lot of bugs even if fixed. This doesnt just hurt polygon and vertex code, it require an extra test (and a subtract) for every, layer, fragment and buffer look up. Again breaking all apps and further complicate the apps. Yes the hole NULL-zero thing makes having zero be an invalid look nice. But thees are ids not pointers! And when it comes to array lookups, the id zero is about as valid as you can get. Making zero invalid will make so much code so much uglyer. Cheers E From verse-dev@blender.org Thu Aug 12 10:55:21 2004 From: verse-dev@blender.org (Emil Brink) Date: Thu, 12 Aug 2004 11:55:21 +0200 (MEST) Subject: [Verse-dev] Numerical IDs [R4] In-Reply-To: <200408111722.i7BHMnV25289@tessla.levonline.com> References: <200408111722.i7BHMnV25289@tessla.levonline.com> Message-ID: > Hi, still at Siggraph, I have the OpenGL and verse BOF today. Cool, I hope that went well! > >I disagree. I find it very useful to be able to set an ID > >variable (or structure field) to a known invalid value, to mark > >that I am still waiting for the server to assign it. > > I agree it is usefull in your app, but not for the network protocol. Well, I have to know that whatever ID I set my variable to cannot be sent by a host of course, otherwise there is no point. > Actiually not only wound the host never send you invalid values, it > usualy even cant, since this triggers function aliases. I know, that's the very idea behind knowing that one ID value is reserved and cannot appear. > >Such defines would have to include the type of value, which is not > >very elegant, compared to just using zero. > > Yes, it would need to have types. (just a question: dont you have > issiues against all nunbers typed in to the code that arent > defines?) Well... I do have such issues, but zero and one are rather okay to use literally, I think. They are commonly used with variuos APIs already. > Ok Lets go beyond this and let me explain just how much this would > break existing apps, and make them a hole more more complicated: > > The first main reason is that in C the first element of an array is > numberd wero. I know. :) > Imagine that you allocate and array of vertexes, polygons, layers or > buffers. Now either you dont use the first element and waist memory > or you have to make lookups in to the array with ids minus one. This > makes the code way more error prone. Well.. That depends on how you organize your code, of course. If you wrap the concept of "an array that has a different base than zero" in a suitable data structure, the problem goes away. > Next consider this, If i have a look-up in to a array i must always > check for this. For example lets read out a vertex from a a polygon > reference. this is how its done now: > > if(polygon[id * 4] < vertex_length && vertex[polygon[id * 4] * 3] != > E_REAL_MAX) > > this the same code if the zero is reserved: > > if(polygon[(id - 1) * 4] != 0 && polygon[(id - 1) * 4] < > vertex_length && vertex[(polygon[(id - 1) * 4] - 1) * 3] != > E_REAL_MAX) Heh. Of course, noone half sane would ever write code like that. In stead, what you do is stick a simple id--; before the if(), to con- vert the logical ID into a physical array index. Simple, and I dare day the performance overhead is neglible, it should be on the order of 1-3 instructions or something. The risk of forgetting to do this is, again, removed by wrapping it. > This extra test have to be done for every corner in the polygon and > is just a hazzle. It compleatly breaks all my apps (in more then one > place). and it is likely to introduse a lot of bugs even if fixed. That's a problem, of course. But wouldn't the same places in the code need to be looked over if there was some other reserved value? > This doesnt just hurt polygon and vertex code, it require an extra > test (and a subtract) for every, layer, fragment and buffer look up. > Again breaking all apps and further complicate the apps. Yeah, well, I'd argue that the extra subtract is very cheap indeed. The test is not "extra", you need to test against whatever value is reserved. Assuming it's the maximum and never happens isn't very nice, imo. > Yes the hole NULL-zero thing makes having zero be an invalid look > nice. But thees are ids not pointers! And when it comes to array > lookups, the id zero is about as valid as you can get. Making zero > invalid will make so much code so much uglyer. Yeah, well... It might be a point to keep the IDs zero-based just so that they can be used to directly index arrays, I guess. It's just too bad that it then requires a bunch of other uglyness, casts and/or a set of macros to handle the reserved values. We need to sketch out a solution for R4, I think. /Emil From verse-dev@blender.org Thu Aug 12 16:22:14 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Thu, 12 Aug 2004 18:22:14 +0300 Subject: [Verse-dev] Numerical IDs [R4] In-Reply-To: Message-ID: <200408121622.i7CGMED00806@tessla.levonline.com> Hi > Cool, I hope that went well! No not realy, Siggraph failed to book the room, so no one at the site knew we where coming, and then they kicked us out. Im going to have words with Siggraph today... > Well, I have to know that whatever ID I set my variable to cannot be > sent by a host of course, otherwise there is no point. Sure, we need a invalid value, the question is what should it be. > Well.. That depends on how you organize your code, of course. If you > wrap the concept of "an array that has a different base than zero" in > a suitable data structure, the problem goes away. Yes and no. in my exaple I can agree that i was extra mean. But take an example like Enough, i could wrap this beaoutefully. but still this would introduse problems for the user of enough. if read out a vertex or polygon form an array given by Enough and want to send a cange to verse you need to add 1 to the id of the elemnet you want to change. To wrap this i would have to wrap the entire verse send api too. not the smalest thing to do. > That's a problem, of course. But wouldn't the same places in the code > need to be looked over if there was some other reserved value? > Yeah, well, I'd argue that the extra subtract is very cheap indeed. sure, but it is also a add one, if you want to send changes. To me, the biggest hassle is that you store localy a set of data that is addressed differently form the remote data. this conversion, is trivial but it WILL introduce bugs. > The test is not "extra", you need to test against whatever value is > reserved. Assuming it's the maximum and never happens isn't very > nice, imo. no, the test if the reference id is smaler then the length of the vertex array does this test automaticly, since the length of the vertex array can never be longer then (uint32)-2 . > Yeah, well... It might be a point to keep the IDs zero-based just > so that they can be used to directly index arrays, I guess. It's > just too bad that it then requires a bunch of other uglyness, > casts and/or a set of macros to handle the reserved values. I agree. you do have good points, but im afraid this may be the Im- writing-a-verse-app-so-i-would-like-to-change-verse phenomenom... E From verse-dev@blender.org Thu Aug 12 17:29:01 2004 From: verse-dev@blender.org (Thorsten Jordan) Date: Thu, 12 Aug 2004 18:29:01 +0200 Subject: [Verse-dev] Bitmap layer ids In-Reply-To: References: <200408111722.i7BHMnV25289@tessla.levonline.com> Message-ID: <411B9ACD.1000901@gmx.de> Hi! I'm working with the r3p2 server. I noticed that when creating layers with verse_send_b_layer_create and using an layer_id of 0 and waiting for the server to send the layers, nothing happens, it just stops/sleeps after one received layer. When i use my own values (1,2,3) all is fine. The code: verse_send_b_layer_create(node_id, 1, "col_r", VN_B_LAYER_UINT8); verse_send_b_layer_create(node_id, 2, "col_g", VN_B_LAYER_UINT8); verse_send_b_layer_create(node_id, 3, "col_b", VN_B_LAYER_UINT8); if i use 0,0,0 instead of 1,2,3 here, the server seems to lock up. The tutorial suggests doing it that way, though. Is this a bug? any help? -- Greetings, Thorsten From verse-dev@blender.org Thu Aug 12 18:10:37 2004 From: verse-dev@blender.org (Emil Brink) Date: Thu, 12 Aug 2004 19:10:37 +0200 Subject: [Verse-dev] Bitmap layer ids In-Reply-To: <411B9ACD.1000901@gmx.de> References: <200408111722.i7BHMnV25289@tessla.levonline.com> <411B9ACD.1000901@gmx.de> Message-ID: <20040812191037.7d9793ed@frontal> On Thu, 12 Aug 2004 18:29:01 +0200 Thorsten Jordan wrote: > Hi! > > I'm working with the r3p2 server. > I noticed that when creating layers with verse_send_b_layer_create and > using an layer_id of 0 and waiting for the server to send the layers, > nothing happens, it just stops/sleeps after one received layer. But you do get one layer created, right? > When i use my own values (1,2,3) all is fine. > The code: > verse_send_b_layer_create(node_id, 1, "col_r", VN_B_LAYER_UINT8); > verse_send_b_layer_create(node_id, 2, "col_g", VN_B_LAYER_UINT8); > verse_send_b_layer_create(node_id, 3, "col_b", VN_B_LAYER_UINT8); > > if i use 0,0,0 instead of 1,2,3 here, the server seems to lock up. > The tutorial suggests doing it that way, though. > Is this a bug? any help? This is not quite a bug, it is a _very_ unexpected side-effect of a feature, actually. Heh. Honest! The Verse protocol has a feature we like to refer to as "event com- pression", which means (roughly) that two commands that address the same piece of data are never sent in the same packet. Instead, the last command passed to Verse replaces any previous ones. This is what happens here; the "address" part of the b_layer_create command is the tuple, so any time you use the same numerical value for the layer_id in e.g. three subsequent commands, they will all compress in the outgoing queue and only the last one will actually reach the host. in the spec talks a bit more about this. See any command specification page, such as , too see what part of a command's parameters make up its address. The workaround is to use a set of different, known-unused, IDs when sending create commands. I typically use ~0, ~1, ~2, and so on if in a loop. I would very much wish for a better solution to this situation, but am not aware of any easy fix. Perhaps Eskil has some ideas? Regards, /Emil From verse-dev@blender.org Thu Aug 12 21:09:36 2004 From: verse-dev@blender.org (Thorsten Jordan) Date: Thu, 12 Aug 2004 22:09:36 +0200 Subject: [Verse-dev] verse-server bugs and problems In-Reply-To: References: <200408111722.i7BHMnV25289@tessla.levonline.com> Message-ID: <411BCE80.7000800@gmx.de> Hi! I have noticed odd behaviour of the verse server in two different ways: 1) the client should send verse_send_node_create with a node_id of 0 (zero), wait for the server to send this callback and get the real node_id from there, right? Well, the server just doesn't do so. Instead it locks up. When I use verse_send_node_create with my own numbers (always incrementing the node_id when creating a node) then it works, sending any number twice with create causes the server to crash/lockup. 2) When sending large amount of data, and i mean more than 300 faces, the udp buffer seems to overflow or anything similar. E.g. when receiving a verse_send_node_create for a geometry node or an verse_send_b_layer_create for an bitmap layer I start to send vertex data or bitmap data. If i do an verse_callback_update(50000) every 100 send vertices/tiles or so, the server seems to handle the data (although transmission is slowed down obviously), but sending more than roughly 200 vertices without an update in between seems to lockup the server. Same for bitmap tiles or polygon indices. It also seems that sending server output to an file or /dev/null instead of printing it to the console helps a bit against the lockups. Maybe this is some sort of timing problem. (I am using Debian/unstable on i386 - the client runs also on Windows2k and WindowsCE, it is the same everywhere) It is very annoying to work with this server, as it took me a long time to detect these errors. I thought the server would be complete. Especially the node_id bug is a bad surprise. Please focus your work on things that matter, like these, and not wether node_ids start at 0 or 1. ;-) Ah, another thing: the server seems to reverse the order of commands he receives. Sending layers 1,2,3 from a client leads to an retrieval of 3,2,1 (very often) at the same client. This is not really a bug, but keeping the order would be great for many reasons: the clients could create layers/vertices/indices in a sane order, creating nodes/layers before referencing it, or creating vertices before creating face indices that reference the (not yet existing) vertices. The client could then e.g. create vertex n first and then vertices 0...n-1, so that an array resize can be done only once and not n times on another client who receives the vertices. Thanks in advance for your help. -- Greetings, Thorsten From verse-dev@blender.org Thu Aug 12 21:31:17 2004 From: verse-dev@blender.org (Thorsten Jordan) Date: Thu, 12 Aug 2004 22:31:17 +0200 Subject: [Verse-dev] verse-server bugs and problems, additional info In-Reply-To: References: <200408111722.i7BHMnV25289@tessla.levonline.com> Message-ID: <411BD395.40706@gmx.de> Hi! Just read Emil's mail that explains the node_id problems, thanks ;-) An addition to the lockup with large data: the behaviour is a bit random. Sometimes all data seems to make its way to the server and back to the client, but a few triangles are always missing, no matter how many the object has. When enabling PRINT_SEND_COMMANDS and PRINT_RECEIVE_COMMANDS and sending output to the console then the transmission seems to be more affected (output takes much more time than passing it to a file or /dev/null). Small meshes (like an icosahedron, up to ~ 200 faces) are ok, but larger meshes miss faces. Any idea? -- Greetings, Thorsten From verse-dev@blender.org Thu Aug 12 20:37:53 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Thu, 12 Aug 2004 22:37:53 +0300 Subject: [Verse-dev] Bitmap layer ids In-Reply-To: <20040812191037.7d9793ed@frontal> Message-ID: <200408122037.i7CKbrs04472@tessla.levonline.com> hi > Perhaps Eskil has some ideas? No, not realy. I ususaly think of if as if your id is valide untill the host gives you back the real id. I dont know if this helps. even tinyer detail: Using the ids like 0, 1, 2 my give you issiues too. imagine the you send two comands with the ids 0, and 1, but they arive at the order 1, and then 0. then the server will first create the first layer, and give it the id of 0. Then the second command will arive and and it will modefy an existing layer (layer 0) not create a new one. So do as emil says use -1, -2, -3 (i guess we are back in the invalid discussion here....) Cheers E From verse-dev@blender.org Thu Aug 12 21:55:29 2004 From: verse-dev@blender.org (Emil Brink) Date: Thu, 12 Aug 2004 22:55:29 +0200 Subject: [Verse-dev] Bitmap layer ids In-Reply-To: <200408122037.i7CKbrs04472@tessla.levonline.com> References: <20040812191037.7d9793ed@frontal> <200408122037.i7CKbrs04472@tessla.levonline.com> Message-ID: <20040812225529.5885ede6@frontal> On Thu, 12 Aug 2004 22:37:53 +0300 Eskil Steenberg wrote: > hi > > > Perhaps Eskil has some ideas? > > No, not realy. I ususaly think of if as if your id is valide untill > the host gives you back the real id. I dont know if this helps. It's certainly a way to look at it. The problem is that then you have to pick multiple IDs that are not in use, and that is (in *theory*) not very simple. You don't want to actually consult your local data- base copy for a simple thing like this... > even tinyer detail: > > Using the ids like 0, 1, 2 my give you issiues too. imagine the you > send two comands with the ids 0, and 1, but they arive at the order > 1, and then 0. then the server will first create the first layer, > and give it the id of 0. Then the second command will arive and and > it will modefy an existing layer (layer 0) not create a new one. True. Ouch. > So do as emil says use -1, -2, -3 Heh. Or ~0, ~1, and so on, since I prefer not using what looks like negative numbers in an unsigned "context". It confuses my simple mind. > (i guess we are back in the invalid discussion here....) Yes, this is what I meant when I suggested, in my initial mail about invalid IDs, that it would be lovely if the event compression code could be made aware of invalid IDs, and *not* consider two commands to the same, invalid, address to be identical. That would solve the problem for the client-side, it seems? /Emil From verse-dev@blender.org Fri Aug 13 07:07:50 2004 From: verse-dev@blender.org (Emil Brink) Date: Fri, 13 Aug 2004 08:07:50 +0200 (MEST) Subject: [Verse-dev] verse-server bugs and problems In-Reply-To: <411BCE80.7000800@gmx.de> References: <200408111722.i7BHMnV25289@tessla.levonline.com> <411BCE80.7000800@gmx.de> Message-ID: On Thu, 12 Aug 2004, Thorsten Jordan wrote: > Hi! > > I have noticed odd behaviour of the verse server in two different ways: > > 1) the client should send verse_send_node_create with a node_id of 0 > (zero), wait for the server to send this callback and get the real > node_id from there, right? Well, the server just doesn't do so. Instead > it locks up. When I use verse_send_node_create with my own numbers > (always incrementing the node_id when creating a node) then it works, > sending any number twice with create causes the server to crash/lockup. As I explained in my other message yesterday, this is due to event compression. Your follow-up indicated you understand the issue now, so hopefully we can leave it for the moment. > 2) When sending large amount of data, and i mean more than 300 faces, > the udp buffer seems to overflow or anything similar. E.g. when > receiving a verse_send_node_create for a geometry node or an > verse_send_b_layer_create for an bitmap layer I start to send vertex > data or bitmap data. If i do an verse_callback_update(50000) every 100 > send vertices/tiles or so, the server seems to handle the data (although > transmission is slowed down obviously), but sending more than roughly > 200 vertices without an update in between seems to lockup the server. > Same for bitmap tiles or polygon indices. I have no insights here, I'm afraid. Perhaps Eskil has, he certainly has worked a lot more with the current server implementation than I have, plus also having written it might be a benefit. One question, though: you use the wording "lock up" a lot, does this mean the server does indeed freeze, i.e. stop responding to e.g. other clients attempting to connect? If so, that is a "pure" bug and it would be interesting to learn where in the code it is sitting when this happens. > It also seems that sending server output to an file or /dev/null instead > of printing it to the console helps a bit against the lockups. Maybe > this is some sort of timing problem. Could be simple network starvation, I'm not at all sure how sensitive it is to such problems. > (I am using Debian/unstable on i386 - the client runs also on Windows2k > and WindowsCE, it is the same everywhere) > > It is very annoying to work with this server, as it took me a long time > to detect these errors. I thought the server would be complete. > Especially the node_id bug is a bad surprise. You mean the over-ambitious event compression? It has been documented in the spec for a while, but probably not long enough. Sorry for the inconvenience. > Please focus your work on things that matter, like these, and not wether > node_ids start at 0 or 1. ;-) Heh. > Ah, another thing: the server seems to reverse the order of commands he > receives. Sending layers 1,2,3 from a client leads to an retrieval of > 3,2,1 (very often) at the same client. This is not really a bug, but > keeping the order would be great for many reasons: > > the clients could create layers/vertices/indices in a sane order, > creating nodes/layers before referencing it, or creating vertices before > creating face indices that reference the (not yet existing) vertices. > The client could then e.g. create vertex n first and then vertices > 0...n-1, so that an array resize can be done only once and not n times > on another client who receives the vertices. Well... I'd say you can't, since vertex IDs are assigned by the host and not by the client. Also, any dependency on the order of things should be avoided, since Verse cannot guarantee that commands sent are processed in the order they are sent; the underlying UDP network protocol is (by design) too "weak" to preserve such order anyway. Regards, /Emil From verse-dev@blender.org Fri Aug 13 09:18:59 2004 From: verse-dev@blender.org (Thorsten Jordan) Date: Fri, 13 Aug 2004 10:18:59 +0200 Subject: [Verse-dev] verse-server bugs and problems In-Reply-To: References: <200408111722.i7BHMnV25289@tessla.levonline.com> <411BCE80.7000800@gmx.de> Message-ID: <411C7973.7020107@gmx.de> Emil Brink wrote: > > As I explained in my other message yesterday, this is due to event > compression. Your follow-up indicated you understand the issue now, > so hopefully we can leave it for the moment. ok for me, but we should keep it in mind, it should be done another way ;-) > One question, though: you use the wording "lock up" a lot, does this > mean the server does indeed freeze, i.e. stop responding to e.g. > other clients attempting to connect? If so, that is a "pure" bug and > it would be interesting to learn where in the code it is sitting when > this happens. yes by lock up i meant it doesn't react to any further requests. this seems to depend on how many data is sent and how long does the output take... ok, in the meantime i have new results, see below. >>Please focus your work on things that matter, like these, and not wether >>node_ids start at 0 or 1. ;-) > Heh. sorry, i had been coding and debugging too long ;-) for me, i think it's not that important with what number the ids start, when compared to other pending decisions or problems. > Well... I'd say you can't, since vertex IDs are assigned by the host > and not by the client. Also, any dependency on the order of things ah, ok then this is my fault. i just use my own numbers and send them to the server... could explain why some triangles are missing, i will fix that and report the results. > should be avoided, since Verse cannot guarantee that commands sent > are processed in the order they are sent; the underlying UDP network > protocol is (by design) too "weak" to preserve such order anyway. ok, then we have to live with it ;-) !!addendum, important!! i have two clients, one is a tool that pushes geometry and materials, the other just views the scene. i have changed the pusher code so that it uses decreasing node_id/layer_id/vertex_id numbers (starting at 0xffffffff). The server receives the data. When i connect the viewer to the server, the client receives the node list and subscribes to geometry nodes. The server receives the susbcribe calls and does nothing. It hasn't crashed, because i can stop and rerun the clients, the pusher will push all data again, the viewer will again try to connect - without success. When i use my own vertex ids starting at zero, it works! This is embarassing! -- Greetings, Thorsten From verse-dev@blender.org Fri Aug 13 08:37:16 2004 From: verse-dev@blender.org (Thorsten Jordan) Date: Fri, 13 Aug 2004 09:37:16 +0200 Subject: [Verse-dev] Bitmap layer ids In-Reply-To: <200408122037.i7CKbrs04472@tessla.levonline.com> References: <200408122037.i7CKbrs04472@tessla.levonline.com> Message-ID: <411C6FAC.6080702@gmx.de> Eskil Steenberg wrote: > hi > > > even tinyer detail: > > Using the ids like 0, 1, 2 my give you issiues too. imagine the you > send two comands with the ids 0, and 1, but they arive at the order > 1, and then 0. then the server will first create the first layer, > and give it the id of 0. Then the second command will arive and and > it will modefy an existing layer (layer 0) not create a new one. > > So do as emil says use -1, -2, -3 (i guess we are back in the > invalid discussion here....) ok, i have understand. Although the workaround helps here, this IMHO not a clean solution... -- Greetings, Thorsten From verse-dev@blender.org Fri Aug 13 19:40:10 2004 From: verse-dev@blender.org (Thorsten Jordan) Date: Fri, 13 Aug 2004 20:40:10 +0200 Subject: [Verse-dev] questions about the verse.h interface In-Reply-To: References: <200408111722.i7BHMnV25289@tessla.levonline.com> <411BCE80.7000800@gmx.de> Message-ID: <411D0B0A.9050302@gmx.de> Hello, it's me again with more questions. 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. 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. There is a command to set a bone, and one to destroy it, but how can users change bone values (position and rotation)? The use of the target_id parameter in verse_send_o_link_set is unclear to me, the spec doesn't help me either. 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? 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) Thanks for you help. -- Greetings, Thorsten From verse-dev@blender.org Fri Aug 13 20:17:34 2004 From: verse-dev@blender.org (Emil Brink) Date: Fri, 13 Aug 2004 21:17:34 +0200 Subject: [Verse-dev] questions about the verse.h interface In-Reply-To: <411D0B0A.9050302@gmx.de> References: <200408111722.i7BHMnV25289@tessla.levonline.com> <411BCE80.7000800@gmx.de> <411D0B0A.9050302@gmx.de> Message-ID: <20040813211734.3ccd0532@frontal> On Fri, 13 Aug 2004 20:40:10 +0200 Thorsten Jordan 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 From verse-dev@blender.org Sun Aug 15 01:38:30 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Sun, 15 Aug 2004 02:38:30 +0200 Subject: [Verse-dev] Bitmap layer ids In-Reply-To: <411C6FAC.6080702@gmx.de> References: <200408122037.i7CKbrs04472@tessla.levonline.com> <411C6FAC.6080702@gmx.de> Message-ID: <411EB086.2060101@obsession.se> Hi Im back form Siggraph! > ok, i have understand. Although the workaround helps here, this IMHO > not a clean solution... This is not a bug its a feature.... But i understand that it may not be obvious. It has to be that way. you may actually want to first create a layer and then rename it. Since verse doesnt store data it doesnt know what ids are confirmed or not, thats something you have to keep track of. (remember verse.h is designed to be low level, in higher level APIs like Enough you can have functions like e_nsg_find_empty_vertex_slot(ENode *node, uint start); to solve the problem). if you call thees two commands: verse_send_g_layer_create(node_id, 2, "my_layer", VN_G_LAYER_VERTEX_XYZ, 0, 0); verse_send_g_layer_create(node_id, 2, "others_layer", VN_G_LAYER_VERTEX_XYZ, 0, 0); This is fully legal to do, and it means you want to create a layer and then rename it. If the user actually wanted to create two layers he or she used the api in the wrong way. I would argue that in this case Verse knows very well what it is doing because it is likely only to send the later call in order to optimize the network usage since it knows that the first will be over written by the second. E From verse-dev@blender.org Sun Aug 15 02:37:34 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Sun, 15 Aug 2004 03:37:34 +0200 Subject: [Verse-dev] questions about the verse.h interface In-Reply-To: <411D0B0A.9050302@gmx.de> References: <200408111722.i7BHMnV25289@tessla.levonline.com> <411BCE80.7000800@gmx.de> <411D0B0A.9050302@gmx.de> Message-ID: <411EBE5E.7080405@obsession.se> Thorsten Jordan wrote: > Hello, > > it's me again with more questions. Sure i will try to fill in the blanks form Emils answers. Thees are some really good questions. > 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. As Emil said it is known to you not verse. This is not a clear case. As verse us built now you can subscribe to both (the same goes for precision in the geometry node). then you need to have the ability to have a type on the un subscribe command too. We could change this, but im not sure it it is the right thing to do, its not a very useful feature, but on the other hand it doesnt cost anything. Just so you know, You cant have the ability to subscribe to both and remove the type from the unsubscribe command. Consider if we wanted to switch form subscribing form one to the other precision. We would then first send a command to unsubscribe to the current subscription and then subscribe to the new one. but the two commands may come in the wrong order, resulting in first subscribing to both then remove the subscription of both. > There is a command to set a bone, and one to destroy it, but how can > users change bone values (position and rotation)? you simply set it again. > The use of the target_id parameter in verse_send_o_link_set is unclear > to me, the spec doesn't help me either. Ah, it is needed to clarify if you refer to a specific sub part of an object. if you have multiple materials on one geometry node or an object is under an other objects transformation of a specific bone. I will talk to Emil about this and we will work on clarifying the spec. Cheers E From verse-dev@blender.org Sun Aug 15 03:21:31 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Sun, 15 Aug 2004 04:21:31 +0200 Subject: [Verse-dev] verse-server bugs and problems In-Reply-To: <411BCE80.7000800@gmx.de> References: <200408111722.i7BHMnV25289@tessla.levonline.com> <411BCE80.7000800@gmx.de> Message-ID: <411EC8AB.50708@obsession.se> Hi > Please focus your work on things that matter, like these, and not wether > node_ids start at 0 or 1. ;-) I will ;-) The lock up is something i have not experienced that i know of. But i will look in to it. Emil could you do the same? please you are running linux. The not so great performance is a known problem. I was planing to take a crack at it in about two weeks. Right now it works but is not optimal, so you should be able to survive. Optimizing UDP turns out to be a bit of black magic but i will get to work on it. > Ah, another thing: the server seems to reverse the order of commands he > receives. Sending layers 1,2,3 from a client leads to an retrieval of > 3,2,1 (very often) at the same client. This is not really a bug, but > keeping the order would be great for many reasons: I know... this is actually meant to be annoying.... Verse has a very special network system that removes the need to have network packets deliver in the right order. this is especially important when packets are lost, because no data has to wait for a lost packet to be re-sent. So no properly written app should not require stuff to be delivered in order. Hence the huge id debate on why strange things happen when things are out of order (Ha! it DID turn out to matter! ;-)). Verse used to send everything in the right order but, due to some things taking up very much cpu I rewrote some stuff that caused the commands to come in a different order even if the network delivers all packets in order. At first this annoyed me too. But it did not brake any of my apps because i was aware of this when i wrote them. But it did turn out to break other peoples apps because they where not aware of the out of order problem. So this made everyone aware of the issue and this is why we have all this email traffic to fix it (and thats a good thing). If verse would not have reordered it the network might have and the bug would still be there but it would be a lot harder to find the bugs because they are so rare. In a way verse has become less forgiving in that sense. If you want to you can change the define in v_network_que.c: #define V_NQ_OPTIMIZATION_SLOTS 4096 to #define V_NQ_OPTIMIZATION_SLOTS 1 to get it to work like it used to. But then again it will be slower and any bugs you are experiencing now will still be in you code just show up more rarely. > the clients could create layers/vertices/indices in a sane order, > creating nodes/layers before referencing it, or creating vertices > before creating face indices that reference the (not yet existing) > vertices. The client could then e.g. create vertex n first and then > vertices 0...n-1, so that an array resize can be done only once and > not n times on another client who receives the vertices. vertices and polygons are numbered by you and not the server. so you are allowed to create polygons that reference vertices that doesnt exist. it will not be a legal polygon to draw but to store . (just like you can delete a vertex used by a polygon without deleting the polygon) When you send vertices(or polygon) you are expected to create them roughly from zero and up. Creating a vertex with a id substantially higher the the highest existing one may be declined by the host. (since people are expected to allocate memory in arrays it would be an exploit to create a vertex with a so high id it would require clients to allocate too much memory) when I allocate/reallocate i always allocate a bit too much (see Enough source) this helps against too many reallocations. Cheers E From verse-dev@blender.org Sun Aug 15 03:40:09 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Sun, 15 Aug 2004 04:40:09 +0200 Subject: [Verse-dev] verse-server bugs and problems In-Reply-To: <411C7973.7020107@gmx.de> References: <200408111722.i7BHMnV25289@tessla.levonline.com> <411BCE80.7000800@gmx.de> <411C7973.7020107@gmx.de> Message-ID: <411ECD09.6020200@obsession.se> This is a multi-part message in MIME format. --------------000908030607020604070005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi! > When i use my own vertex ids starting at zero, it works! I looked in the code and it turns out you could not create a vertex/polygon with an id 256 higher then the currently highest one. With the unordered sending style this value may have been too low. Try this patch. Good luck! E --------------000908030607020604070005 Content-Type: application/zip; name="poly_patch.zip" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="poly_patch.zip" UEsDBBQAAAAIAOsjDzHBGON59A4AAEeRAAASAAAAdnNfbm9kZV9nZW9tZXRyeS5j7R1rT9tK 9nOQ+A8DV1slIdA4qSp2KUiol3KvlkJFKWr3ClkhMWAakioOj7Tlv+88PeN5eezYECArbe8w c+bMzHnNOcfH8ev64kId/f/14sLiwh/hoNu/7gXgXTTuhcO1iy2prx+e4k6he/nG7171/PNg sHaxTEbOwFIvOAsHQQ8c+7s7+zuH20c7/ocv++/9jwd/7kjTg1EU4KlCX+RHwQiOMJQEHTj+ 7O/6e9vfdg7993992f8vaLekwe3Dw+1vdNBrrWtHd7c/gXXv3y2EeXFhPPkRQBgQjUfX3TH4 tbhQOd7f3etMgtERHKqg8Q3Y2b3ojCqVQecq+Md7e4J6boZhr1Kp9xEo+vv48+fr06g7Cn+M w+FgL4zGoB6RnlN4SAeQHoK5HsAhtI3KdTgYt1sA/huckyUqveH1aT8Ao6DTR3/fA7h12LiH 56Ob3jAd6vP+sBf8FXR6lQv4D9kNnSMcAq3pva1UcIffHV4Pxqy73apUIE/GwZ0fhT8DsfvH sD8hnRWhtwu3GQU+mcNpmOj28UKMpNLMoHceKPNQZ2IWPjw8224wvArGowmmQLIL1AGUqXMf oRgH/gAOVa8HUXiOZBSuCYa3g2BUW1zglOJTETTbBaiTbYNNLLmwtcyHEBXOhwM0RpvLhKHC QmEMjkXpzTo+N1oCTrvq9PvDbhURcnhGFq5hSYv8Tq/nD4JbsvVX6N/VLcTHBlSx/SOoZQcf d44Ov2Hw6McILnVWRSs0wDI7iY+O5f/rerkB+Py1sIfnCJTxUX9yDYKJEIntd3ULM4FvO7Fv OlqDlPfeynOIXMGZ3ls+IogWHJFVncPFsqaHgnBnw1E1hKPNDUCQ/hOegCX8d7iyUkN6JGzm n+bJGuYFBNrkE6QtJ6GamlGkc2hL+/GWjncOj3a++l+//U8DLhGP0K5K9BtRTbF1ddDGdBRO F4J3Wjh+zirFCOo13fo1cpxj/3Bne+/tG//j9lfNVgULBSD0/pe9vY3XdSiUVGgiwab5fWjU qrUNdKFY8PSmwQMt2xqygIgIa02F51T37Ez3RHbyGfLpPSvXPR3XPx3sfds92PffHxzCm8// 8vf+UbulmakXAGIBDQLwxlEA3ogCQG+RpAB4SQFY9TQbFNmel1uenusqFOIpvegopYWTtshJ obVg5/ol8zOMWUHOIg9iLjZjLsrDjBlsd/K4hhZ2qJ4FTD1r5T6mSOJ2TAqd7uJsnmhh0CVp HFCmjoLx9WgA6EV3j2iPnBtyZ/YC6EUMJ+Tm0d2N9NoU4ZQrhAjuKAiq7FKTVolJZ1tCvUkl XVDuGK4I4VlVy/MlwqcaclywfwOJFAUD6NH6FA8W92riymyAKnGUamEDaCRN6USyqXQKcqAd QzaO3P/irigjo2BMJUHemlFYtEPWBZC0WNFzcdIMJNnchXbutNP9zpaBzIx5jgHq1xFCc4zY //efGJ0PvRO7U6aKBPWlFDmqITmDZ8JyTJHrvCcqKGCTCgaSC6IgpQhc5I+Cq+GNYE/hCma7 wvxB4yTMJ2kCZkI07ozDLtDyIiHpFmbADhwwwB4yBXUR55eIPdKKdUCknV48UJJ91GwA6oqg DizaWTjbAJdwJRaOlMpjMs7OB5ncwuNxB7tinEXhl4M4gFevIBb4B1sGr4ln4oUuyUL4Grs8 QRvXXXBwBOJhTeL9XMJN4FsIbyFtPl5WFHh8Nd1LNNnaVI8Lfv9O4GTA8eXKaY2PhU4l0BTu VCC5ih2dy4KdkpEjYacWt72p2bZAZ2E3KjMxhLqtFRbEJAYhBiThyK8TeuGtYQiR1F1txJxH IsZ2lmp06EnsrlGqc2R0jwzDBu/IyT+CUBj2nslaRc/m5Bp2N5RKrKSggvtoWIO7+rQVWwM9 PCYrlDz0X5OiS9Cbhgixxm4D5kap50qlC/GyDGejIsDSWdwZM2gUwRXdhuPuRZUdkIpXF97w +mOA/6iMVwyBMeZVEwEs6BV0IWFuJVhBEYyxr3xOwnCHQJns4xSK3fcNGxlIxJeHEjz4U07n SgWJAtrgT08Bdk9rVJdPSIYuySnplEFZhoIlJCddMkgGc1dS6UJTEkl4C1G0iYIixIZnyFjK wESgBORsio5EpaJEqBgazZIYfdh+v4OFaD2vDK1ryONGGo3orM+M5MSEKVi7cpNmhrQK06Zw ncpFmUfQJRba0McRFRo9xq4X8a4tgbV8Qk3ch59lijijIIqgT2fA2gAhoZ49E4XjWh6Ck+Cb hN1CvM0CbeYQ47yBfjcZ0gTUQ82YJ8gY7bOgq/SETkFhLQJTUgZC2sjF27brni5xLoUucjLY EAOQMHC6WEOkbJ5Qp4BI5+koLtMYRXML1kynhKo2h8fzdlo9rVRiReVFA9bSh0q9jlgpyK2a qX3gRN6USStBm1/Xwaew+x2IkgvwccdD0On1AJcL2LMG8GMxpsevtOvRwwiK8+Hg8OP2EX0y i9Jf5CSrW1bliu2QDQ5f+L9/wyUB/J8ZXOd7W/ErbkUtVicqDfrTJ3Sb6UTQj4JMMwnLIXO2 IQsGwS0QsuOIM7cXYfcigPpJeHXbiUD3Ygg1CJxOwI9R0A2Rwq2OobaCzunwJlgD7/GVS+DD M4i0C7WyM5pQniLxwrszXS11ZZipRWoGSyj6ELP8eD41fzQ7I/AjJndqisYibIlMYqbAGiJN T6SgRA1OTotlBwxD0nyydaAlQI4MBL2b/NQ5QNBjEBamBEksmAYAVoDnAtQ6od7tPZPPWaRU u2Wj1Fl/2BnX0gnmAsfo5gjLySf54i7JtCwUzk9gbGt5oCad4yR+SLO6JQRfjCsmphB0RtE1 rkaolUomIYSDB58FhSZUNEmDTEX6PNDFBGRW/8dW2JIoYZamNFVMqKBZtGz5SffIHtMtrQYJ pdYwIeJsy6qHyLZUNasGmbOpU0a7BqOJ2GpNMbk1zeS2YXJNa0RocRrme3c4GkBG5zQmmGJp APE9mEoBB6B2qv0yp3dz2TF9cmlqGbRcaooM4pyTVeVNAug8U5E+55mK6GFzo7c3GsHLaYFj wUuliANQywWonc3oz8WmdLHJf10x6XGBy+CNxrLkCNvOeG0qz2Me6M7kj1+m8FxFJp51ugG+ ctatN45uRVfrrz6ieVBiTevna6lVhrdvemwzK3dlEW6uQswHcfufEjGK9vzvnRPMjjW7qOPj h1Hn/CoYjGH3GW1mfyz0JJ79SFjTS3o5nmKfqORZthc/XzgdDvtBZ4Ayk6d+cDdGjO+MRp1J pK3Jb4B4Ag5MGyCZ4WesVep46Tlp+fmiXDYnlnStyO9tvgO0Mpa9s/Bhe+/zzoYRwZYMf3T4 BYMzq5Bcm9d65FqZTzevK7+t5FY6TKklV8Gy0s53qXF7DclydcmOZiv9RaaaUAZI088aTInL J71a0FRuqqmhjYcbQKlCqEI1XlHeA66JRYRxLbUqKrh88BKS0oKGVFMzS23IB4Xx1XApltQK 1RhulYNTUYVXrRiOk04RKzVkSmgvSYkS0pDgVbmTSKxVKVdsCiaQi6hoCCSUudioY60lLFeQ xAI6iVZS6Zxdud48uEhZSgtLt0jlkOxhhEytNJxawtazK6LgsWe0U3JpYhkypSk6fBR7np9K D6J6Sv3ho9j0fEQqVNni11/uZe9Y+/MI2h0iTCzYla2JZUrSQ02NBPVPmvMUHEEJo8hQD45d wR1rTFjjZ87KwacRO5rB2MtF5ogvsZklTdhGwjTE2AandE2dm/pgM55MHnBuqhUJ2Nd3fzn2 F0tbSQrCyhjRq4umKMVY+qTCE1IvCQxkQUmq+spHBncbeWbShD2Y5J2Nkvbgp2QkxFcVm0o4 61pLbThirunJc+ZFwQ/rXJadltqYvtLTtoK+6tO5bEkwf+zyuuPNCW/+rBVFlNJp4kQSc32S QBJICkgCfvRpi2T1bJn+5qKyfhe3JnFrfnnNL6/55fWCLy/wIi4v2VK/oEuKPnO7i1uTuFX4 zdUL+sGYPAO0X1vyHTWztxDXoS1NgrXA394p3zZnN8ryz+5l0JpmaerSdNcTQRzFR9Jc6nKY g2Z5RrCZwfoJRxNLD9SjFeiT0qKR6f1R1tPpX+tf55oFzX8s/5M+xizOBXV9pztGgH9mFPEm o87P6E1prnUSRJLIYmmBXHFB3FxpTC8MFqoyGT3sZ6Yy5iIu1bFMas7zSYk9psEo5JYlTyfm 9mJW7QVLnb40u/FCDUaC3YUZDvPLVzkNCEMo2pQmb3q82eLN9tzA2IsSzfuCa5Bi7Jsmat94 aDX4L2q3cLuF223cbuN2E7ebAgyBb2uyz2abhutDGwLD8wYOHAN9bwjuLf98luu88abCgZOd N62pcOAkyE37CdvmTO9miqqPdB4pO9Lym3aZ5mq6AEncM4uQmrzp8WaLN+fmylZimN0vspkQ N8fIbELyzJdNSE4cCROSE8ezNCFmN09URxYfNnnT480Wb7afvjOY6VXkx7OzxbiFNLBsxi0v brXi1tzGzr6NjUOSAmxtjKsAmxvjKsD2xrhepA02mJeXZ2e5qAttT2i3hHY5dlh4Tb2g2Hx9 nt3TW1r+AkgJAXHqD0dzBM/hsYD7Ly0kDE9pWS7x9wsKzHHNFenBFSlLRubZapLDHV6uKhWf f5mrkv0nZ4vVpKzO8bPUpGwZiefxACrD79A8sDkpNM0wtyazbk2ey4PsnFblZZuTch9rkzJX p1pyQapn1VoU7zF7luwe+YpGBnn0SlNCL4P2UZbHdBZoUpR0qV8otgoY+X4sPknio7EEzWxK G6G+/K1uvmsNc9XPT+q+542/b8SazgL2mJ840X+Pmpu0hsjMEkQMf6P6eQsY/Zp7PvESvvj+ pIUr/hZ5AaLFvzsfC1Y4CMdYjKg8kG0IcjeuGj/J1bB+ULtB+LvhjJR+LsiENR7OiDYmtgmx AJARtfC7kCbkCRBn9No38tQlDGB5lyHvPKYuw8DyLEPMkHUJBpKfWA6EmoZIDgTKjj7xUplx BQFqqiUsh8i3hLEiTF3HAjrNcibKWUCnXU5HRQtoruX4sxH7WiLcdAulETEBmH8pF34lAKdb Ko1XCcDMSxGlMa/Axp0RK96lilsDkgc98i+syAkAQ439iD8gUHi2uPB/UEsBAhQAFAAAAAgA 6yMPMcEY43n0DgAAR5EAABIAAAAAAAAAAQAgAICBAAAAAHZzX25vZGVfZ2VvbWV0cnkuY1BL BQYAAAAAAQABAEAAAAAkDwAAAAA= --------------000908030607020604070005-- From verse-dev@blender.org Sun Aug 15 10:08:40 2004 From: verse-dev@blender.org (Thorsten Jordan) Date: Sun, 15 Aug 2004 11:08:40 +0200 Subject: [Verse-dev] verse-server bugs and problems In-Reply-To: <411ECD09.6020200@obsession.se> References: <200408111722.i7BHMnV25289@tessla.levonline.com> <411BCE80.7000800@gmx.de> <411C7973.7020107@gmx.de> <411ECD09.6020200@obsession.se> Message-ID: <411F2818.1060908@gmx.de> Eskil Steenberg wrote: > Hi! > >> When i use my own vertex ids starting at zero, it works! > > > I looked in the code and it turns out you could not create a > vertex/polygon with an id 256 higher then the currently highest one. > With the unordered sending style this value may have been too low. Try > this patch. i have tried it, but it doesn't help. I create and fill a geometry node with my "pusher" app, the server receives the data. When i connect a second client (the viewer), it receives the g_layer_create calls and then subscribes itself, the server receives the subscribe command and does nothing. The server reacts to further commands from the pusher (or further runs of it). But the viewer doesn't get any geometry (the server doesn't send commands). I retested it with sending vertex/polygon id's from 0 upward, it works. The proposed way (i do sending from 0xfffffffe downwards), still fails. -- Greetings, Thorsten From verse-dev@blender.org Sun Aug 15 10:01:18 2004 From: verse-dev@blender.org (Thorsten Jordan) Date: Sun, 15 Aug 2004 11:01:18 +0200 Subject: [Verse-dev] Bitmap layer ids In-Reply-To: <411EB086.2060101@obsession.se> References: <200408122037.i7CKbrs04472@tessla.levonline.com> <411C6FAC.6080702@gmx.de> <411EB086.2060101@obsession.se> Message-ID: <411F265E.9050500@gmx.de> Eskil Steenberg wrote: > Hi > > if you call thees two commands: > > verse_send_g_layer_create(node_id, 2, "my_layer", VN_G_LAYER_VERTEX_XYZ, > 0, 0); > verse_send_g_layer_create(node_id, 2, "others_layer", > VN_G_LAYER_VERTEX_XYZ, 0, 0); > > This is fully legal to do, and it means you want to create a layer and > then rename it. If the user actually wanted to create two layers he or > she used the api in the wrong way. I would argue that in this case Verse > knows very well what it is doing because it is likely only to send the > later call in order to optimize the network usage since it knows that > the first will be over written by the second. i wasn't aware that it is legal to send a create command twice for the same object. Now it is clear to me... The same solution applies to bones then. -- Greetings, Thorsten From verse-dev@blender.org Sun Aug 15 10:00:19 2004 From: verse-dev@blender.org (Thorsten Jordan) Date: Sun, 15 Aug 2004 11:00:19 +0200 Subject: [Verse-dev] questions about the verse.h interface In-Reply-To: <20040813211734.3ccd0532@frontal> References: <200408111722.i7BHMnV25289@tessla.levonline.com> <411BCE80.7000800@gmx.de> <411D0B0A.9050302@gmx.de> <20040813211734.3ccd0532@frontal> Message-ID: <411F2623.7060409@gmx.de> Emil Brink wrote: > On Fri, 13 Aug 2004 20:40:10 +0200 > Thorsten Jordan wrote: >>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. ah, that makes sense! ok, one problem solved ;-) -- Greetings, Thorsten From verse-dev@blender.org Sun Aug 15 13:13:45 2004 From: verse-dev@blender.org (Brecht Van Lommel) Date: 15 Aug 2004 12:13:45 +0000 Subject: [Verse-dev] verse-server bugs and problems In-Reply-To: <411EC8AB.50708@obsession.se> References: <200408111722.i7BHMnV25289@tessla.levonline.com> <411BCE80.7000800@gmx.de> <411EC8AB.50708@obsession.se> Message-ID: <1092572024.3412.18.camel@localhost> Hi, > > the clients could create layers/vertices/indices in a sane order, > > creating nodes/layers before referencing it, or creating vertices > > before creating face indices that reference the (not yet existing) > > vertices. The client could then e.g. create vertex n first and then > > vertices 0...n-1, so that an array resize can be done only once and > > not n times on another client who receives the vertices. > > vertices and polygons are numbered by you and not the server. so you are > allowed to create polygons that reference vertices that doesnt exist. it > will not be a legal polygon to draw but to store . (just like you can > delete a vertex used by a polygon without deleting the polygon) > > When you send vertices(or polygon) you are expected to create them > roughly from zero and up. Creating a vertex with a id substantially > higher the the highest existing one may be declined by the host. (since > people are expected to allocate memory in arrays it would be an exploit > to create a vertex with a so high id it would require clients to > allocate too much memory) > > when I allocate/reallocate i always allocate a bit too much (see Enough > source) this helps against too many reallocations. Maybe it's a good idea to let the server send the vertices (and faces) in reverse order on subscription? Seems like an easy chance for optimization. It would reduce the number of allocations (and copy operations related to reallocations) for big meshes quite a bit, when the client is not subscribed during creation. Brecht. From verse-dev@blender.org Sun Aug 15 18:25:07 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Sun, 15 Aug 2004 19:25:07 +0200 Subject: [Verse-dev] verse-server bugs and problems In-Reply-To: <411F2818.1060908@gmx.de> References: <200408111722.i7BHMnV25289@tessla.levonline.com> <411BCE80.7000800@gmx.de> <411C7973.7020107@gmx.de> <411ECD09.6020200@obsession.se> <411F2818.1060908@gmx.de> Message-ID: <411F9C73.9030907@obsession.se> Hi > i have tried it, but it doesn't help. > I create and fill a geometry node with my "pusher" app, the server > receives the data. When i connect a second client (the viewer), it > receives the g_layer_create calls and then subscribes itself, the > server receives the subscribe command and does nothing. The server > reacts to further commands from the pusher (or further runs of it). > But the viewer doesn't get any geometry (the server doesn't send > commands). I retested it with sending vertex/polygon id's from 0 > upward, it works. The proposed way (i do sending from 0xfffffffe > downwards), still fails. Well as i said it should fail. When you send the data from 0 and up does any polys/vertices still get lost? Cheers E From verse-dev@blender.org Sun Aug 15 19:08:30 2004 From: verse-dev@blender.org (Thorsten Jordan) Date: Sun, 15 Aug 2004 20:08:30 +0200 Subject: [Verse-dev] verse-server bugs and problems In-Reply-To: <411F9C73.9030907@obsession.se> References: <200408111722.i7BHMnV25289@tessla.levonline.com> <411BCE80.7000800@gmx.de> <411C7973.7020107@gmx.de> <411ECD09.6020200@obsession.se> <411F2818.1060908@gmx.de> <411F9C73.9030907@obsession.se> Message-ID: <411FA69E.8090301@gmx.de> Eskil Steenberg wrote: > Hi > >> i have tried it, but it doesn't help. >> I create and fill a geometry node with my "pusher" app, the server > Well as i said it should fail. When you send the data from 0 and up does > any polys/vertices still get lost? (sorry, i was in a hurry this morning, i missed that) Well, the models i used recently seem to work now, no triangles are missing. Then i collected any .3ds file on my hdd (my pusher pushes 3ds files) and tried them. I found several models that show missing triangles, sadly :-( So the fix seems to help a bit, but not for all models. -- Greetings, Thorsten From verse-dev@blender.org Sun Aug 15 19:43:55 2004 From: verse-dev@blender.org (Thorsten Jordan) Date: Sun, 15 Aug 2004 20:43:55 +0200 Subject: [Verse-dev] question about geometry fragment In-Reply-To: <411F9C73.9030907@obsession.se> References: <200408111722.i7BHMnV25289@tessla.levonline.com> <411BCE80.7000800@gmx.de> <411C7973.7020107@gmx.de> <411ECD09.6020200@obsession.se> <411F2818.1060908@gmx.de> <411F9C73.9030907@obsession.se> Message-ID: <411FAEEB.80106@gmx.de> Hello, more questions... The geometry fragment allows to define colors for each vertex, corner or face, e.g. if one uses glColor3f(r, g, b); glVertex3f(x, y, z); to draw a model, one creates a geometry fragment that uses geometry layers where r,g,b are stored. Am i right? Well then, when i want to use texture mapping, i set up the texture fragment, give a geometry fragment as control value (which is named mapping in verse.h, but control in the spec!), but how do i set up which layer holds u and which v coordinates? Do i set (in the geometry fragment) layer_r to the u-coordinate layer and layer_g to the v-coordinate layer? If it is so, it should be made more clear in the spec... The fragment is the same for both modes, but the usage seems quite different. So this layout is a bit confusing. Wouldn't it be better to just store two layer names in the texture fragment instead of a geometry fragment id (ok, three names for 3d-textures)? And, btw, why do we have standard names col_r/col_g/col_b/tex_u/tex_v, when layers are referenced via material names anyway? -- Greetings, Thorsten From verse-dev@blender.org Sun Aug 15 20:49:04 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Sun, 15 Aug 2004 21:49:04 +0200 Subject: [Verse-dev] verse-server bugs and problems In-Reply-To: <411FA69E.8090301@gmx.de> References: <200408111722.i7BHMnV25289@tessla.levonline.com> <411BCE80.7000800@gmx.de> <411C7973.7020107@gmx.de> <411ECD09.6020200@obsession.se> <411F2818.1060908@gmx.de> <411F9C73.9030907@obsession.se> <411FA69E.8090301@gmx.de> Message-ID: <411FBE30.7080607@obsession.se> Hi! > > Well, the models i used recently seem to work now, no triangles are > missing. Then i collected any .3ds file on my hdd (my pusher pushes > 3ds files) and tried them. I found several models that show missing > triangles, sadly :-( > So the fix seems to help a bit, but not for all models. Humm. Could you turn on the the print out for both incomming and out going calls. and send me the loggs for all three apps? (send it to me personaly and not the list, lets not fill up the list) E From verse-dev@blender.org Sun Aug 15 21:34:31 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Sun, 15 Aug 2004 22:34:31 +0200 Subject: [Verse-dev] question about geometry fragment In-Reply-To: <411FAEEB.80106@gmx.de> References: <200408111722.i7BHMnV25289@tessla.levonline.com> <411BCE80.7000800@gmx.de> <411C7973.7020107@gmx.de> <411ECD09.6020200@obsession.se> <411F2818.1060908@gmx.de> <411F9C73.9030907@obsession.se> <411FAEEB.80106@gmx.de> Message-ID: <411FC8D7.2090901@obsession.se> Hi > The geometry fragment allows to define colors for each vertex, corner > or face, e.g. if one uses > glColor3f(r, g, b); > glVertex3f(x, y, z); > to draw a model, one creates a geometry fragment that uses geometry > layers where r,g,b are stored. Am i right? Sorry it is a bit more complicated then that. The parsing of the material node starts at the output fragment and then you evaluate along the tree. Each fragment can be evaluated at any point on the surface. so a color fragment outputs a plane color, but it doesnt have to be used to color an object, it can just as well be used to as uv. A good idea is to run Connector to experiment with how the different fragments interact. The shader tree is very easy to implement in software and fairly easy on programmable hardware, while making a good evaluation on non-programmable hardware is harder. > (which is named mapping in verse.h, but control in the spec!) Ah, thank! > , but how do i set up which layer holds u and which v coordinates? > Do i set (in the geometry fragment) layer_r to the u-coordinate layer > and layer_g to the v-coordinate layer? If it is so, it should be made > more clear in the spec... Yes thats how you do it. But the geometry node is not exclusively used for textures thats why it is named r g b and not u v w. > The fragment is the same for both modes, but the usage seems quite > different. So this layout is a bit confusing. Wouldn't it be better to > just store two layer names in the texture fragment instead of a > geometry fragment id (ok, three names for 3d-textures)? No because textures are a recursive and can be connected to a lot of different fragments to get different effects. The most common one is to stick a matrix in between the texture and the geometry to transform the the mapping of the texture. If you want to evaluate a texture fragment on a point on the surface you take the input color an use it as look-up position in to the texture. > And, btw, why do we have standard names col_r/col_g/col_b/tex_u/tex_v, > when layers are referenced via material names anyway? > You dont need to use the standard names but it is recommended because some applications can then more easily figure out what the layers contain. Say you are writing a uv editor (like I am) then it is very useful to be able to identify the uv layers form a geometry layer alone. E From verse-dev@blender.org Mon Aug 16 09:55:49 2004 From: verse-dev@blender.org (Marcus Hoffmann) Date: Mon, 16 Aug 2004 10:55:49 +0200 Subject: [Verse-dev] Bitmap layer ids In-Reply-To: <411EB086.2060101@obsession.se> Message-ID: Eskil wrote: > if you call thees two commands: > > verse_send_g_layer_create(node_id, 2, "my_layer", VN_G_LAYER_VERTEX_XYZ, > 0, 0); > verse_send_g_layer_create(node_id, 2, "others_layer", > VN_G_LAYER_VERTEX_XYZ, 0, 0); > > This is fully legal to do, and it means you want to create a layer and > then rename it. If the user actually wanted to create two layers he or > she used the api in the wrong way. I would argue that in this case Verse > knows very well what it is doing because it is likely only to send the > later call in order to optimize the network usage since it knows that > the first will be over written by the second. This is hell for the server.... How will i know the users intention?? What if he wants to create two layers??? And the next thing: if you (the client) send a create command, its my (the servers) task to find a new id for it and send it back to the user. If your idea is to do the renaming (or maybe other changes too) with a create command, i have to search the hole id lists EVERY TIME to look if the client-sent ID is already existing or not! And another thing: What if a second user that is creating offline a geometry using first his internal client IDs. Then he starts to upload the hole scene. And he has one or more layers with his internal IDs that correspond to IDs on the server....... What I'm going to do now (in my current version of the server) is to ignore his IDs and give him new ones that are unique in my verse world. If I would look for existing IDs if a create command arrives this would end up in overwriting another geomtry!! So this is really a thing that has to be discussed i think! M From verse-dev@blender.org Mon Aug 16 16:41:18 2004 From: verse-dev@blender.org (Emil Brink) Date: Mon, 16 Aug 2004 17:41:18 +0200 (MEST) Subject: [Verse-dev] Bitmap layer ids In-Reply-To: References: Message-ID: On Mon, 16 Aug 2004, Marcus Hoffmann wrote: > Eskil wrote: > > > if you call thees two commands: > > > > verse_send_g_layer_create(node_id, 2, "my_layer", VN_G_LAYER_VERTEX_XYZ, > > 0, 0); > > verse_send_g_layer_create(node_id, 2, "others_layer", > > VN_G_LAYER_VERTEX_XYZ, 0, 0); > > > > This is fully legal to do, and it means you want to create a layer and > > then rename it. If the user actually wanted to create two layers he or > > she used the api in the wrong way. I would argue that in this case Verse > > knows very well what it is doing because it is likely only to send the > > later call in order to optimize the network usage since it knows that > > the first will be over written by the second. > > This is hell for the server.... It seems to work fairly well in Eskil's reference server code, or at least the code is not huge or so. > How will i know the users intention?? What if he wants to create two > layers??? The above example does not include timing information, so it's a bit hard to parse. If both commands are to be emitted at once, then the client needs to "fool" the event compression system by using differ- ent IDs, as mentioned earlier. If the commands happen with "long" time inbetween, then event compression won't be a problem and the command will act as a rename. This sounds more complicated than it is in practice. > And the next thing: if you (the client) send a create command, its my (the > servers) task to find a new id for it and send it back to the user. If your > idea is to do the renaming (or maybe other changes too) with a create > command, i have to search the hole id lists EVERY TIME to look if the > client-sent ID is already existing or not! Well... Yes, but since the address of the command includes only the numerical ID, and not the name, this is a rather simple operation. Since you, the server, are responsible for assigning layer IDs, and they are assumed to be in 0,1,2,... order (this might need to be made into a requirement by the spec), the "search" is supposed to be a simple array look-up. > And another thing: What if a second user that is creating offline a geometry > using first his internal client IDs. Then he starts to upload the hole > scene. And he has one or more layers with his internal IDs that correspond > to IDs on the server....... Hm.. If you create data intended for Verse offline, then of course you must use some kind of mapping scheme between whatever layer IDs you need in the static (offline) data and the ones assigned to the layers by the server once the data "goes live". The "VNF" simplistic file format and loader tool used in Verse1 had a simple name-based scheme for this. > What I'm going to do now (in my current version of the server) is > to ignore his IDs and give him new ones that are unique in my verse > world. If I would look for existing IDs if a create command arrives > this would end up in overwriting another geomtry!! So this is > really a thing that has to be discussed i think! Well, yes, this is the correct way to do it. I believe, after having talked to Eskil a bit today, that I (too) was confused. All IDs are server-assigned, *except* vertex and polygon IDs, which are pickable by the client. The ID in a layer (or node) creation command that comes from a client is used to check if the layer already exists, in which case the command becomes a rename (or possibly type-change, depending on the node). If it does not exist, then the command is in fact a "true" creation, and the server will create the layer and pick a new ID to use in the subsequent notification to subscribers of the node. I hope that further clears it up. Regards, /Emil From verse-dev@blender.org Mon Aug 16 18:04:18 2004 From: verse-dev@blender.org (Thorsten Jordan) Date: Mon, 16 Aug 2004 19:04:18 +0200 Subject: [Verse-dev] Bitmap layer ids In-Reply-To: References: Message-ID: <4120E912.4090002@gmx.de> Marcus Hoffmann wrote: > Eskil wrote: > > >>This is fully legal to do, and it means you want to create a layer and >>then rename it. If the user actually wanted to create two layers he or >>she used the api in the wrong way. I would argue that in this case Verse >>knows very well what it is doing because it is likely only to send the >>later call in order to optimize the network usage since it knows that >>the first will be over written by the second. [...] > What I'm going to do now (in my current version of the server) is to ignore > his IDs and give him new ones that are unique in my verse world. If I would > look for existing IDs if a create command arrives this would end up in > overwriting another geomtry!! > So this is really a thing that has to be discussed i think! That is exactly what i think. For me, sending a second create for a node to update it, doesn't make any sense, because there are no values that can be changed/updated by the second create command - only type and owner. And changing that information is not a clean solution, especially for the type! Would it be that big change to just add a change/set command, not only for creating but also for bones? It is a lot easier if a create just means create... I have more questions about fragments. I have to implement a viewer that interpretes the fragment tree and tries to display the closest approximation of the given material (and this on a very limited environment - the PocketPC/klimt ca do ONE texture and ONE color at most). The spec says for the geometry fragment "There is no node reference in this fragment; this is because the layers being referenced are always (implicitly) taken to be in the current object's geometry node" But an object code can have links to more than one geometry node... Next one: for the output fragment "string type; What type of surface property is described by this output fragment. Very often, this will be set to "color" which is the standard name for fragments that generate surface color." Very often? what else for a type can the user choose here? Why are layer references in fragments realized with strings and not with layer IDs? -- Greetings, Thorsten From verse-dev@blender.org Mon Aug 16 20:29:48 2004 From: verse-dev@blender.org (Thorsten Jordan) Date: Mon, 16 Aug 2004 21:29:48 +0200 Subject: [Verse-dev] Bitmap layer ids In-Reply-To: References: Message-ID: <41210B2C.90201@gmx.de> Emil Brink wrote: > > It seems to work fairly well in Eskil's reference server code, or at > least the code is not huge or so. that may be because Eskil's server just transports the commands, while Marcus' server also builds up an representation of the scene internally... >>How will i know the users intention?? What if he wants to create two >>layers??? > The above example does not include timing information, so it's a bit > hard to parse. If both commands are to be emitted at once, then the > client needs to "fool" the event compression system by using differ- > ent IDs, as mentioned earlier. If the commands happen with "long" > time inbetween, then event compression won't be a problem and the > command will act as a rename. This sounds more complicated than it is > in practice. 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. > Hm.. If you create data intended for Verse offline, then of course > you must use some kind of mapping scheme between whatever layer IDs > you need in the static (offline) data and the ones assigned to the > layers by the server once the data "goes live". The "VNF" simplistic > file format and loader tool used in Verse1 had a simple name-based > scheme for this. 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 ID in a layer (or node) creation command that comes from a client > is used to check if the layer already exists, in which case the > command becomes a rename (or possibly type-change, depending on the > node). If it does not exist, then the command is in fact a "true" > creation, and the server will create the layer and pick a new ID to > use in the subsequent notification to subscribers of the node. 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. -- Greetings, Thorsten From verse-dev@blender.org Tue Aug 17 02:48:59 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Tue, 17 Aug 2004 03:48:59 +0200 Subject: [Verse-dev] Bitmap layer ids In-Reply-To: <4120E912.4090002@gmx.de> References: <4120E912.4090002@gmx.de> Message-ID: <4121640B.8090908@obsession.se> Hi > > For me, sending a second create for a node to update it, doesn't make > any sense, because there are no values that can be changed/updated by > the second create command - only type and owner. And changing that > information is not a clean solution, especially for the type! > Would it be that big change to just add a change/set command, not only > for creating but also for bones? It is a lot easier if a create just > means create... The rules in my mind are very simple, they are: 1: If the server receives command that creates data in an unused id (and is not a polygon or vertex id). it picks the lowest possible id and creates the data (node, layer, bone, fragment, buffer or what ever). 2: if the server receives a command that creates a new polygon or vertex in an unused id if the id is LOWER then the highest existing poly/vertex id + x (in my implementation x = 8192) it creates that vertex poly and gives it the user assigned id. 3: if the server receives a command that creates a new polygon or vertex in an unused id if the id is HIGHER then the highest existing poly/vertex id + x (in my implementation x = 8192) it ignores the command. 4: if the server receives a command using ids referencing to already existing data, the command modifys the existing state. If the change changes the type of under lying data that is cleared. (if you change the type of a geometry layer, the layer data is cleared) Due to the rules 1 and 4 it makes sense to create data using ids that the user is sure the server wont pick as layer ids. Cheers E From verse-dev@blender.org Tue Aug 17 03:12:47 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Tue, 17 Aug 2004 04:12:47 +0200 Subject: [Verse-dev] Bitmap layer ids In-Reply-To: <41210B2C.90201@gmx.de> References: <41210B2C.90201@gmx.de> Message-ID: <4121699F.1030708@obsession.se> 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 From verse-dev@blender.org Tue Aug 17 03:26:37 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Tue, 17 Aug 2004 04:26:37 +0200 Subject: [Verse-dev] Material fragments In-Reply-To: <4120E912.4090002@gmx.de> References: <4120E912.4090002@gmx.de> Message-ID: <41216CDD.6050803@obsession.se> Hi I started a separate thread for this discussion. > > I have more questions about fragments. I have to implement a viewer > that interpretes the fragment tree and tries to display the closest > approximation of the given material (and this on a very limited > environment - the PocketPC/klimt ca do ONE texture and ONE color at > most). > Yes, on a platform like that you cant do much more then try to make a simple look-up if you can find a texture or color that is essential for the look of the object. > The spec says for the geometry fragment "There is no node reference in > this fragment; this is because the layers being referenced are always > (implicitly) taken to be in the current object's geometry node" > But an object code can have links to more than one geometry node... > Well obviously, the data should be taken from the geometry you render. > Next one: for the output fragment "string type; What type of surface > property is described by this output fragment. Very often, this will > be set to "color" which is the standard name for fragments that > generate surface color." > Very often? what else for a type can the user choose here? Say you would like to use the material node for things like displacement, temperature or acoustic propertys. > Why are layer references in fragments realized with strings and not > with layer IDs? > One material node may be used by more then one geometry node. Because layer ids are chosen by the server the client can not make sure for instance uv data would use the same ids in two different nodes. Also it explains where the content of the layers and makes easy to connect material and geometry nodes that where authored separately. As a rule, internally in the verse data, all references to layers are done by name rather then ids for this reason. Cheers E From verse-dev@blender.org Tue Aug 17 08:15:26 2004 From: verse-dev@blender.org (Emil Brink) Date: Tue, 17 Aug 2004 09:15:26 +0200 (MEST) Subject: [Verse-dev] Bitmap layer ids In-Reply-To: <4121640B.8090908@obsession.se> References: <4120E912.4090002@gmx.de> <4121640B.8090908@obsession.se> Message-ID: [semantics of "create"] > The rules in my mind are very simple, they are: > > 1: If the server receives command that creates data in an unused id (and > is not a polygon or vertex id). it picks the lowest possible id and > creates the data (node, layer, bone, fragment, buffer or what ever). Is this something that should be in the spec using words to that effect? I mean, is it a specified requirement of a server that IDs are always picked to be as numerically low as possible? This has not been my impression so far, and if it is I really think it must be mentioned. > 2: if the server receives a command that creates a new polygon or vertex > in an unused id if the id is LOWER then the highest existing poly/vertex > id + x (in my implementation x = 8192) it creates that vertex poly and > gives it the user assigned id. The number 8,192 here is very arbitrary. I was not aware of the "window", and it seems to have been 256 in recent code (still is, in CVS). It feels kind of problematic, since this limit controls how many vertex/polygon creations can be sent "ahead", but is not known by clients. Should the number be a hard specification, so clients can rely on it? Or should it be somehow possible to ask a server what its geometry creation window size is? Or something? It doesn't feel quite right to just have a magic number in there... > 3: if the server receives a command that creates a new polygon or vertex > in an unused id if the id is HIGHER then the highest existing > poly/vertex id + x (in my implementation x = 8192) it ignores the command. Right. > 4: if the server receives a command using ids referencing to already > existing data, the command modifys the existing state. If the change > changes the type of under lying data that is cleared. (if you change the > type of a geometry layer, the layer data is cleared) Is changing the type of a node a supported operation? *Reads reference server code*. Nope, doesn't look like it... Should it be? > Due to the rules 1 and 4 it makes sense to create data using ids that > the user is sure the server wont pick as layer ids. Yes, but one can't be "sure" about the numbers, even if using IDs from the top. It's rather easy to fool it, and I personally would much prefer something a bit more robust. This goes back to my first message about invalid IDs; I would love it if the event compression code could somehow recognize that some value of the ID, it might be 0 or it might be ~0, is not equal to any other value of the ID, including the value itself of course. This would change the semantics to mean "a create sent with id ~0 is always a create, and never needs to look for an existing node/layer/ buffer/fragment" before doing the create. Regards, /Emil From verse-dev@blender.org Tue Aug 17 10:42:12 2004 From: verse-dev@blender.org (Marcus Hoffmann) Date: Tue, 17 Aug 2004 11:42:12 +0200 Subject: [Verse-dev] Bitmap layer ids In-Reply-To: Message-ID: Emil wrote: > > And another thing: What if a second user that is creating offline a geometry > > using first his internal client IDs. Then he starts to upload the hole > > scene. And he has one or more layers with his internal IDs that correspond > > to IDs on the server....... > > Hm.. If you create data intended for Verse offline, then of course > you must use some kind of mapping scheme between whatever layer IDs > you need in the static (offline) data and the ones assigned to the > layers by the server once the data "goes live". The "VNF" simplistic > file format and loader tool used in Verse1 had a simple name-based > scheme for this. If you think this scenario to the end this will lead to the point, that every client HAS to get the hole server world first! Then it has to parse all the ids it got from the server, and finally the client has to change its offline-created ids so that no ID exists twice. After all that processing it loads its new nodes up to the server and the server has to look for every new id sent with the create command if this id is still existing in the system, becaus we could have a change request and not a create request. And then you talk about realtime? Imagine the server runs 3 days and 50 people loaded 100000 or more nodes to the server..... And now every one who's connecting has to parse these 100000 ids... and me as server while getting the upload too - so we do the same lookup on client and server! This all could be avoided if the create command just creates... then any client could give me ids as it wants - even if they all would be 0 - i would create one valid ID on the server and send it back to the client and thats it! No time wasting searches - not at the server and not at the client. I agree with thorsten that its not a big deal to introduce a change command... then it can be simply integrated and these two operations would be separated. This is not about changing the verse system, just improving it for easier use and maybe better performance! We are in an early state of development, so better do such discussions now and solve it then in 1 year... greets Marcus From verse-dev@blender.org Tue Aug 17 13:24:50 2004 From: verse-dev@blender.org (Emil Brink) Date: Tue, 17 Aug 2004 14:24:50 +0200 (MEST) Subject: [Verse-dev] Bitmap layer ids In-Reply-To: References: Message-ID: On Tue, 17 Aug 2004, Marcus Hoffmann wrote: > Emil wrote: > > > And another thing: What if a second user that is creating offline a > geometry > > > using first his internal client IDs. Then he starts to upload the hole > > > scene. And he has one or more layers with his internal IDs that > correspond > > > to IDs on the server....... > > > > Hm.. If you create data intended for Verse offline, then of course > > you must use some kind of mapping scheme between whatever layer IDs > > you need in the static (offline) data and the ones assigned to the > > layers by the server once the data "goes live". The "VNF" simplistic > > file format and loader tool used in Verse1 had a simple name-based > > scheme for this. > > If you think this scenario to the end this will lead to the point, that > every client HAS to get the hole server world first! Theoretically, yes. But since it's almost always OK to just assume that the top part of the ID space is unused, i.e. that the node doesn't actually contain more than 65,000 layers, Eskil's method of using ~0, ~1 etc works in practice with the reference server. *I* sure agree that this is ugly, and would greatly prefer a known-invalid ID, as stated several times. > Then it has to parse all the ids it got from the server, and > finally the client has to change its offline-created ids so that no > ID exists twice. Well... I guess that's one way of doing it, but it's easier to just use a dynamic mapping, so that the content-creating client maps its local layer to whatever actual numerical ID got assigned to it by the server. This is fairly easy, in my experience. > After all that processing it loads its new nodes up to the server > and the server has to look for every new id sent with the create > command if this id is still existing in the system, becaus we could > have a change request and not a create request. For every addressed object, the server needs to look it up to see if it exists, that in itself should be a very cheap operation. > And then you talk about realtime? Imagine the server runs 3 days > and 50 people loaded 100000 or more nodes to the server..... And > now every one who's connecting has to parse these 100000 ids... and > me as server while getting the upload too - so we do the same > lookup on client and server! Well, again assuming that the top of the numerical space is not used, you don't need to have the server's contents in order to create a new layer. When this assumption doesn't hold, however, you do. Eskil seems to often take a "that's not going to happen" view of this situation, which can annoy me a bit... Again, I would greatly prefer if this was resolved by simply reserving an ID. > This all could be avoided if the create command just creates... then any > client could give me ids as it wants - even if they all would be 0 - i would > create one valid ID on the server and send it back to the client and thats > it! No time wasting searches - not at the server and not at the client. Well. The number of actual creation calls is almost insignificant when compared to the content-setting calls, for which the server needs to do the very same kind of lookup, so I'm starting to fail to see the point here. > I agree with thorsten that its not a big deal to introduce a change > command... then it can be simply integrated and these two operations would > be separated. This is not about changing the verse system, just improving it > for easier use and maybe better performance! True. It would, however, add quite a few new commands, and the 8-bit command space is a limited resource. Granted, there is still room to spare so I guess this is not a very poweful argument. > We are in an early state of development, so better do such > discussions now and solve it then in 1 year... It's all relative, I guess. The Verse protocol is roughly five years old, although the current implementation ("Verse2") is younger of course, and there have been significant changes from the old days. Oh well. /Emil From verse-dev@blender.org Tue Aug 17 15:48:34 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Tue, 17 Aug 2004 16:48:34 +0200 Subject: [Verse-dev] Bitmap layer ids In-Reply-To: References: <4120E912.4090002@gmx.de> <4121640B.8090908@obsession.se> Message-ID: <41221AC2.8020508@obsession.se> Hi >Is this something that should be in the spec using words to that >effect? I mean, is it a specified requirement of a server that IDs >are always picked to be as numerically low as possible? This has not >been my impression so far, and if it is I really think it must be >mentioned. > > Yes there should be some thing about this in the spec. but i think that lowest possible is a little hard. It should be low, i dont know how low but perhaps not higher then twice the number of existing ids, or something like that. (a scenario with big gaps can still occur since people can delete layers, o having a stringent rules that clients can cont on is not very useful. What the spec should intend to mean is: storing your data in arrays is a good idea because the the host will attempt to peep it reasonably short.) > > >>2: if the server receives a command that creates a new polygon or vertex >>in an unused id if the id is LOWER then the highest existing poly/vertex >>id + x (in my implementation x = 8192) it creates that vertex poly and >>gives it the user assigned id. >> >> > >The number 8,192 here is very arbitrary. I was not aware of the >"window", and it seems to have been 256 in recent code (still is, in >CVS). > > No its not very arbitrary, its twice the number of the send slots. this would minimize the risk of loss due to packet loss. >Should the number be a hard specification, so clients can rely on it? >Or should it be somehow possible to ask a server what its geometry >creation window size is? Or something? It doesn't feel quite right to >just have a magic number in there... > > > Let me think about how this should be expressed in the spec. >Is changing the type of a node a supported operation? > >*Reads reference server code*. > >Nope, doesn't look like it... Should it be? > > Yes and no. The server doesnt have to, but a client does. If a node id is deleted and the re-used quickly. the two comands may come out of order so the client must be able to handle this. (humm perhaps someting i should fix in enough...) >This would change the semantics to mean "a create sent with id ~0 is >always a create, and never needs to look for an existing node/layer/ >buffer/fragment" before doing the create. > > We defenetly agree that a reserved id is something we need. how about reserving the last 16 or 256 ids? then -2, -3 wont be a problem either even if one has many many layers? E From verse-dev@blender.org Tue Aug 17 16:10:58 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Tue, 17 Aug 2004 17:10:58 +0200 Subject: [Verse-dev] Bitmap layer ids In-Reply-To: References: Message-ID: <41222002.6000900@obsession.se> Hi > >If you think this scenario to the end this will lead to the point, that >every client HAS to get the hole server world first! > > No, not at all, The client knows that the id -1 is reserved and can use that id. >I agree with thorsten that its not a big deal to introduce a change >command... > Maybe not for you but for verse its a huge deal. And any way how would the tow commands differ? not at all. my code would become a lot more clumsy if i had to handle that many more callbacks. a change and a set is almost the same. You still have to run the same checks for both so one isnt much faster then the other. >We are in an early state of development, so better do such discussions now and solve it then in 1 year... > I have been working with verse for about 6-7 years... E From verse-dev@blender.org Tue Aug 17 16:28:12 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Tue, 17 Aug 2004 17:28:12 +0200 Subject: [Verse-dev] Bitmap layer ids In-Reply-To: References: Message-ID: <4122240C.4080100@obsession.se> Hi >When this assumption doesn't hold, however, you do. Eskil seems to >often take a "that's not going to happen" view of this situation, >which can annoy me a bit... Again, I would greatly prefer if this was >resolved by simply reserving an ID. > > I dont take that assumption, I think, and have thought for some time that we should have reserved ids, i just argued against the ids beeing 0. E From verse-dev@blender.org Tue Aug 17 20:04:54 2004 From: verse-dev@blender.org (Thorsten Jordan) Date: Tue, 17 Aug 2004 21:04:54 +0200 Subject: [Verse-dev] Material fragments In-Reply-To: <41216CDD.6050803@obsession.se> References: <4120E912.4090002@gmx.de> <41216CDD.6050803@obsession.se> Message-ID: <412256D6.6080204@gmx.de> Eskil Steenberg wrote: > Hi > >> The spec says for the geometry fragment "There is no node reference in >> this fragment; this is because the layers being referenced are always >> (implicitly) taken to be in the current object's geometry node" >> But an object code can have links to more than one geometry node... >> > Well obviously, the data should be taken from the geometry you render. That isn't obviously. An object node can have links to more than one geometry node AND more than one material node. How can i know which geometry node uses which material? >> Next one: for the output fragment "string type; What type of surface >> property is described by this output fragment. Very often, this will >> be set to "color" which is the standard name for fragments that >> generate surface color." >> Very often? what else for a type can the user choose here? > Say you would like to use the material node for things like > displacement, temperature or acoustic propertys. so this is just not mentioned in the spec yet? the sentence is a bit embarassing... >> Why are layer references in fragments realized with strings and not >> with layer IDs? >> > One material node may be used by more then one geometry node. Because > layer ids are chosen by the server the client can not make sure for > instance uv data would use the same ids in two different nodes. Also it > explains where the content of the layers and makes easy to connect > material and geometry nodes that where authored separately. ah, ok, that's a good idea. -- Greetings, Thorsten From verse-dev@blender.org Tue Aug 17 20:15:38 2004 From: verse-dev@blender.org (Thorsten Jordan) Date: Tue, 17 Aug 2004 21:15:38 +0200 Subject: [Verse-dev] Bitmap layer ids In-Reply-To: References: Message-ID: <4122595A.3040804@gmx.de> Emil Brink wrote: > On Tue, 17 Aug 2004, Marcus Hoffmann wrote: > > Theoretically, yes. But since it's almost always OK to just assume > that the top part of the ID space is unused, i.e. that the node > doesn't actually contain more than 65,000 layers, Eskil's method of > using ~0, ~1 etc works in practice with the reference server. > > *I* sure agree that this is ugly, and would greatly prefer a > known-invalid ID, as stated several times. "assuming" in general is bad for software design. Never assume that users won't use a number, they will ;-) >>I agree with thorsten that its not a big deal to introduce a change >>command... then it can be simply integrated and these two operations would >>be separated. This is not about changing the verse system, just improving it >>for easier use and maybe better performance! > > > True. It would, however, add quite a few new commands, and the 8-bit > command space is a limited resource. Granted, there is still room to > spare so I guess this is not a very poweful argument. Well, sounds like the year 2000 problem... 8 bit for a command id?! network bandwith isn't THAT limited. But, why not change that with the next release? releases aren't binary compatible either, so you can safely change the opcode size. >>We are in an early state of development, so better do such >>discussions now and solve it then in 1 year... > It's all relative, I guess. The Verse protocol is roughly five years > old, although the current implementation ("Verse2") is younger of > course, and there have been significant changes from the old days. Well, it may sound a bit hard, but the cases we are discussing currently aren't that special, so if they haven't occoured and discussed in the last five years, then verse couldn't have been used very often... -- Greetings, Thorsten From verse-dev@blender.org Tue Aug 17 20:32:38 2004 From: verse-dev@blender.org (Thorsten Jordan) Date: Tue, 17 Aug 2004 21:32:38 +0200 Subject: [Verse-dev] Bitmap layer ids In-Reply-To: <41222002.6000900@obsession.se> References: <41222002.6000900@obsession.se> Message-ID: <41225D56.7020703@gmx.de> Eskil Steenberg wrote: > Hi > > Maybe not for you but for verse its a huge deal. And any way how would > the tow commands differ? not at all. my code would become a lot more > clumsy if i had to handle that many more callbacks. a change and a set > is almost the same. You still have to run the same checks for both so > one isnt much faster then the other. well, isn't it one of the important things you learn about designing interfaces: design always from the outside. Do not let the internal structure determine the interface structure. If your code has a problem with adding commands, then your code is the problem. I have a clean design and adding commands or nodes can be done straightforward in my code. This is not ment as flame or anything the like! But giving the limits of any code as a reason for not implementing a feature isn't a good argument either... -- Greetings, Thorsten From verse-dev@blender.org Tue Aug 17 20:02:49 2004 From: verse-dev@blender.org (Thorsten Jordan) Date: Tue, 17 Aug 2004 21:02:49 +0200 Subject: [Verse-dev] Bitmap layer ids In-Reply-To: <4121699F.1030708@obsession.se> References: <41210B2C.90201@gmx.de> <4121699F.1030708@obsession.se> Message-ID: <41225659.7000208@gmx.de> This is a multi-part message in MIME format. --------------040004050902040906020608 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Eskil Steenberg wrote: > Hi > > 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. oh, i understand how to send ids, my problem is that 1) the proposed way doesn't work (it should be a bug and can be fixed ok) 2) the proposed way is a workaround to assure another subsystem is working. For me, the subsystem (here the event compression) isn't designed well enough if i have to use tricks to make it work. Ok, but let's stop that. The system is like it is. I would like to get my clients working with the proposed way, but they don't and it seems not my fault. I've attached the output of the server and my two client apps to this mail, and the code of the pusher. Maybe this helps. What i did: i started the server. i started the pusher and let it push all geometry. the server receives the data. i started then the viewer who connects itself and sends subscribe commands to the server, who receives them and ... nothing happens. All three apps are sleeping then. Look at the code lines 95 and 100, if i use numbers from 0 up here (the commented code), then it works (but with larger models, some triangles will be missing). > 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? i think the server should ignore a client's ids for a create and send new legal ids back... we already discussed that. When the client can change a node by sending a create command then this case can happen. Which is a further proof that create and change should be two commands! > 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. well i used the tutorial as base code and created layers/nodes as you proposed... please have a look at the output and my code. Maybe i've missed something but maybe the server implementation has a bug. (note: the code isn't complete as you will need further files to compile, i will release it later - for now the main file shows the verse interaction, which is of interest here) -- Greetings, Thorsten --------------040004050902040906020608 Content-Type: text/x-c++src; name="push_3ds.cpp" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="push_3ds.cpp" // test app for verse, pushes 3ds files (geoemtry + textures) extern "C" { #include } #ifdef WIN32 #include #endif #include #include using namespace std; #include "model.h" VNodeID my_avatar = 0; model* mymodel = 0; // store node ids for each node i created vector objectnodes; vector geometrynodes; vector materialnodes; vector bitmapnodes; vector materialmaps; set matmapnames; unsigned nodeidnr = 0xfffffffe; // server "feature" (bug) workaround model::material::map* get_bitmap_by_node_id(VNodeID node_id) { unsigned i = 0; for ( ; bitmapnodes[i] != node_id /* && i < bitmapnodes.size() */; ++i); return materialmaps[i]; } VNodeID get_node_id_by_bitmap(model::material::map* matmap) { unsigned i = 0; for ( ; materialmaps[i] != matmap /* && i < materialmaps.size() */; ++i); return bitmapnodes[i]; } void cb_connect_accept(void *user, VNodeID avatar, const char *address) { my_avatar = avatar; // we don't need a list of current nodes here, we just want to create new ones // but we have to subscribe here or we miss our nodes // (fixme - maybe implement replace algorithm - or use connector for that) unsigned mask = (1 << V_NT_OBJECT) | (1 << V_NT_GEOMETRY) | (1 << V_NT_BITMAP) | (1 << V_NT_MATERIAL); // do we really need to subscribe? fixme test that, yes we do! verse_send_node_list(mask); // create central object node as parent of all objects verse_send_node_create(nodeidnr--, V_NT_OBJECT, avatar); // create an object and a geometry node for each mesh for (unsigned i = 0; i < mymodel->get_nr_of_meshes(); ++i) { verse_send_node_create(nodeidnr--, V_NT_OBJECT, avatar); verse_send_node_create(nodeidnr--, V_NT_GEOMETRY, avatar); } // create an material node for each material for (unsigned j = 0; j < mymodel->get_nr_of_materials(); ++j) { verse_send_node_create(nodeidnr--, V_NT_MATERIAL, avatar); const model::material& mat = mymodel->get_material(j); // has material a (bit)map? if (mat.tex1) { // check wether bitmap already exists (multiple references) if (matmapnames.find(mat.tex1->filename) == matmapnames.end()) { // isn't referenced yet, so create bitmap node verse_send_node_create(nodeidnr--, V_NT_BITMAP, avatar); materialmaps.push_back(mat.tex1); matmapnames.insert(mat.tex1->filename); } } } } //fixme: send node names! send transforms! send lights! //fixme: send test bones/test transforms/test changes for geo/bitmaps void send_geometry_node(VNodeID node_id, const model::mesh& mesh) { // layer 0 is always the base vertex layer for (unsigned j = 0; j < mesh.vertices.size(); ++j) { verse_send_g_vertex_set_real32_xyz(node_id, 0, /*j*/ nodeidnr--, mesh.vertices[j].x, mesh.vertices[j].y, mesh.vertices[j].z); //if (j % 100 == 0) verse_callback_update(50000); } // layer 1 is always the base index layer for (unsigned k = 0; k < mesh.indices.size(); k += 3) { verse_send_g_polygon_set_corner_uint32(node_id, 1, /*k/3*/ nodeidnr--, mesh.indices[k], mesh.indices[k+1], mesh.indices[k+2], (unsigned)-1); //if (k % 100 == 0) verse_callback_update(50000); } // the tex coordinate layers are missing, so create layers for them verse_send_g_layer_create(node_id, nodeidnr--, "tex_u", VN_G_LAYER_VERTEX_REAL, 0, 0); verse_send_g_layer_create(node_id, nodeidnr--, "tex_v", VN_G_LAYER_VERTEX_REAL, 0, 0); } void send_material_node(VNodeID node_id, const model::material& mat) { VMatFrag fragment; // we need an output fragment as root fragment.output.front = 2;//# of alternative, fixme fragment.output.back = 0; // unused strcpy(fragment.output.type, "color"); // ?? tutorial suggests it so verse_send_m_fragment_create(node_id, 1, VN_M_FT_OUTPUT, &fragment); // the output fragment points to an alternative fragment.alternative.alt_a = 3; // a oder b complex? fixme fragment.alternative.alt_b = 3; // a oder b simple? fixme verse_send_m_fragment_create(node_id, 2, VN_M_FT_ALTERNATIVE, &fragment); // fixme: we have to set up light influence per hand by creating blender fragments!!! // the simple fragment: just a texture if (mat.tex1 == 0) { // just a color fragment.color.red = mat.diffuse.r / 255.0f; fragment.color.green = mat.diffuse.g / 255.0f; fragment.color.blue = mat.diffuse.b / 255.0f; verse_send_m_fragment_create(node_id, 3, VN_M_FT_COLOR, &fragment); } else { fragment.texture.bitmap = get_node_id_by_bitmap(mat.tex1); strcpy(fragment.texture.layer_r, "col_r"); // ? strcpy(fragment.texture.layer_g, "col_g"); // ? strcpy(fragment.texture.layer_b, "col_b"); // ? //fragment.texture.mapping = fragid von einem geo-fragment, das angeben soll, wie von was gemappt wird (uv coords) //wie soll das gehen, fixme, Eskil?! geofrag layer_r,g als tex u,v oder was?! //aber es gibt doch default names für u,v! //also ein quasi leeres geo-frag nehmen?! //was soll dann das geofrag sonst noch? so für sich hat es eine ganz andere //bedeutung als in kombination mit dem texture-frag. //und mehrere tex-coords pro geo-node? wie das? beide mit namen tex_u/v //aber verschiedene layer_r/g daten im geofrag?! //ahhh, doch: referenziere geonodes, wenn jeder vertex ne andere farbe haben //soll... wozu dann noch col_r/g/b als namen für layers?! //das geo-frag sagt dann welches layer des geonodes welche farbe liefert... //geo-layer müssen ja net nur 3d-daten sein. aua, ist das panne. //aber wie müßte man dann das geo-frag für texmapping benutzen? //zeigt layer_r auf texu und layer_g auf texv oder was, Eskil? //welche fragments können wir umsetzen? //color, light (nur rudimentär, siehe tutorial), [transparency nicht mit klimt], //geometry,texture,[blender nicht mit klimt],alternative,output verse_send_m_fragment_create(node_id, 3, VN_M_FT_TEXTURE, &fragment); } #if 0 tutorial: /* lets create a few fragments */ { VMatFrag fragment; uint i; char *output = "color"; /* wfirst we need a output fragment */ fragment.output.front = 4; /* the front of this material should start here */ fragment.output.front = 0; /* the back of this material should black */ for(i = 0; i < 15 && output[i] != 0; i++) /* this output describes the color of the material*/ fragment.output.type[i] = output[i]; fragment.output.type[i] = 0; verse_send_m_fragment_create(node_id, 1, VN_M_FT_OUTPUT, &fragment); /* now lets create a color fragment, i like red! */ fragment.color.red = 1; fragment.color.green = 0.1; fragment.color.blue = 0.1; verse_send_m_fragment_create(node_id, 2, VN_M_FT_COLOR, &fragment); /* i want my materia to be influenced by the incomming light so lets create a light fragment*/ fragment.light.brdf = 0; /* we are not going to use any of that...*/ fragment.light.brdf_r[0] = 0; fragment.light.brdf_g[0] = 0; fragment.light.brdf_b[0] = 0; fragment.light.normal_falloff = 0; /* the surface is perffectly smooth */ fragment.light.type = VN_M_LIGHT_DIRECT_AND_AMBIENT; /* this material is lit by both direct and ambient light */ verse_send_m_fragment_create(node_id, 3, VN_M_FT_LIGHT, &fragment); /* ok lets now mix the red color whit the incomming light! */ fragment.blender.data_a = 2; /* the red color */ fragment.blender.data_b = 3; /* the light */ //fragment.blender.control = 0; /* this blend mode does not use control */ fragment.blender.type = VN_M_BLEND_MULTIPLY; /* we want the two to be multiplyed togeter */ verse_send_m_fragment_create(node_id, 4, VN_M_FT_BLENDER, &fragment); /* the material example above is not fool prof, to be crrect you should not as ihave done here assume that the fragments will get the numbers that i have assigned to them, It may work in this implementation but is wery good. what you shuld do is send the fragments out and then wait for them to come back to see what is they got, and after that you can create the fragments that points to them. This requies quite a lot more round trip and would be too hard to folow for a simple tutorial as this one.*/ #endif } void send_bitmap_node(VNodeID node_id, const model::material::map& matmap) { verse_send_b_init_dimensions(node_id, matmap.mytexture->get_width(), matmap.mytexture->get_height(), 1); //fixme: shouldn't users send a 0 for layer id here? 0,0,0 doesn't work, 1,2,3 does?! verse_send_b_layer_create(node_id, nodeidnr--, "col_r", VN_B_LAYER_UINT8); verse_send_b_layer_create(node_id, nodeidnr--, "col_g", VN_B_LAYER_UINT8); verse_send_b_layer_create(node_id, nodeidnr--, "col_b", VN_B_LAYER_UINT8); } void cb_node_create(void *user, VNodeID node_id, VNodeType type, VNodeID owner_id) { if (owner_id != my_avatar) return; switch (type) { case V_NT_OBJECT: objectnodes.push_back(node_id); verse_send_node_subscribe(node_id); // we just collect the nodes and add links later, because // we need all others node to exist before we can add links! break; case V_NT_GEOMETRY: geometrynodes.push_back(node_id); cout << "received geometry node " << node_id << "\n"; verse_send_node_subscribe(node_id); send_geometry_node(geometrynodes.back(), mymodel->get_mesh(geometrynodes.size()-1)); break; case V_NT_MATERIAL: materialnodes.push_back(node_id); verse_send_node_subscribe(node_id); // we just collect the nodes and add links later, because // material nodes could possibly reference geometry nodes! break; case V_NT_BITMAP: bitmapnodes.push_back(node_id); verse_send_node_subscribe(node_id); send_bitmap_node(bitmapnodes.back(), *(materialmaps[bitmapnodes.size()-1])); break; default: break; } // do all bitmap nodes exist? if (bitmapnodes.size() >= materialmaps.size() && geometrynodes.size() >= mymodel->get_nr_of_meshes()) { // send all material nodes for (unsigned i = 0; i < materialnodes.size(); ++i) send_material_node(materialnodes[i], mymodel->get_material(i)); // do all nodes exist? if (materialnodes.size() == mymodel->get_nr_of_materials() && objectnodes.size() >= mymodel->get_nr_of_meshes()+1) { // send all links unsigned nrobjs = mymodel->get_nr_of_meshes(); for (unsigned i = 0; i < nrobjs; ++i) { // link from object to geometry and material // fixme, we use own link id's here... verse_send_o_link_set(objectnodes[i], 1, geometrynodes[i], "geometry?", 0); verse_send_o_link_set(objectnodes[i], 2, materialnodes[i], "material?", 0); // link from parent to this object verse_send_o_link_set(objectnodes[nrobjs], i+1, objectnodes[i], "(sub)object?", 0); } } } } void cb_g_layer_create(void* user, VNodeID node_id, VLayerID layer_id, const char *name, VNBLayerType type, uint32 def_uint, real64 def_real) { // find mesh from node_id unsigned i = 0; for ( ; geometrynodes[i] != node_id /* && i < geometrynodes.size() */; ++i); const model::mesh& mesh = mymodel->get_mesh(i); // normals are generated by each client (catmull clark obsoletes user defined normals) // tangents are only useful for bump mapping, which isn't used here, so only // texture coordinates remain if (string(name) == string("tex_u")) { for (unsigned j = 0; j < mesh.texcoords.size(); ++j) { verse_send_g_vertex_set_real32(node_id, layer_id, nodeidnr--, mesh.texcoords[j].x); } } else if (string(name) == string("tex_v")) { for (unsigned j = 0; j < mesh.texcoords.size(); ++j) { verse_send_g_vertex_set_real32(node_id, layer_id, nodeidnr--, mesh.texcoords[j].y); } } } void cb_b_layer_create(void* user, VNodeID node_id, VLayerID layer_id, const char *name, VNBLayerType type) { model::material::map* matmap = get_bitmap_by_node_id(node_id); // send tile data for this layer unsigned tilesx = matmap->mytexture->get_width()/VN_B_TILE_SIZE; unsigned tilesy = matmap->mytexture->get_height()/VN_B_TILE_SIZE; vector& data = matmap->mytexture->get_data(); unsigned bpp = matmap->mytexture->get_bpp(); unsigned texw = matmap->mytexture->get_width(); unsigned layeroffset = (string(name) == string("col_r")) ? 0 : ((string(name) == string("col_g")) ? 1 : ((string(name) == string("col_b")) ? 2 : 3)); // check that layeroffset is lower than bpp, fixme! for (unsigned y = 0; y < tilesy; ++y) { for (unsigned x = 0; x < tilesx; ++x) { //verse_callback_update(20000);//fixme: crude test hack, is this safe?! VNBTile tile; for (unsigned yy = 0; yy < VN_B_TILE_SIZE; ++yy) for (unsigned xx = 0; xx < VN_B_TILE_SIZE; ++xx) tile.vuint8[yy*VN_B_TILE_SIZE+xx] = data[bpp*((y*VN_B_TILE_SIZE+yy)*texw+(x*VN_B_TILE_SIZE+xx))+layeroffset]; verse_send_b_layer_set_tile(node_id, layer_id, x, y, 0, VN_B_LAYER_UINT8, &tile); } } } int main(int argc, char** argv) { if (argc < 2) { printf("usage: %s 3ds_file [0|1(change geo)] [0|1(change xform] [0|1(change texdata)] [servername] [port] [username] [password]\n", argv[0]); return -1; } const char* filename = argv[1]; bool changegeo = (argc > 2) ? bool(atoi(argv[2])) : false; bool changexform = (argc > 3) ? bool(atoi(argv[3])) : false; bool changetex = (argc > 4) ? bool(atoi(argv[4])) : false; const char* servername = (argc > 5) ? argv[5] : "localhost"; unsigned port = (argc > 6) ? atoi(argv[6]) : 4950; const char* username = (argc > 7) ? argv[7] : "nobody"; const char* password = (argc > 8) ? argv[8] : "anonymous"; mymodel = new model(filename, true, false); verse_set_connect_port(port); verse_callback_set((void*)verse_send_connect_accept, (void*)cb_connect_accept, NULL); verse_callback_set((void*)verse_send_node_create, (void*)cb_node_create, NULL); verse_callback_set((void*)verse_send_g_layer_create, (void*)cb_g_layer_create, NULL); verse_callback_set((void*)verse_send_b_layer_create, (void*)cb_b_layer_create, NULL); VSession* vs = verse_send_connect(username, password, servername); verse_session_set(vs); // double morphfac = 0.0, morphfacadd = 0.01; while (true) { cout << "calling update\n"; verse_callback_update(50000); /* morphfac += morphfacadd; if (morphfac <= -0.75 || morphfac >= 0.75) morphfacadd = -morphfacadd; if (morph) { for (int i = 0; i < myoff->nr_vertices; ++i) { const vector3& v = myoff->vertices[i].pos; vector3 tmp = vector3(v.x + v.y*morphfac, v.x*morphfac + v.y, v.z); verse_send_g_vertex_set_real64_xyz(mygeo, 0, i, tmp.x, tmp.y, tmp.z); } } */ } } --------------040004050902040906020608 Content-Type: text/plain; name="pusheroutput.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pusheroutput.txt" send: verse_send_connect(name = nobody pass = anonymous address = 0x8066e7f); calling update calling update send: verse_send_node_list(mask = 15 ); send: verse_send_node_create(node_id = 4294967294 type = 0 owner_id = 1 ); send: verse_send_node_create(node_id = 4294967293 type = 0 owner_id = 1 ); send: verse_send_node_create(node_id = 4294967292 type = 1 owner_id = 1 ); send: verse_send_node_create(node_id = 4294967291 type = 2 owner_id = 1 ); calling update receive: verse_send_node_create(node_id = 1 type = 0 owner_id = 0 ); callback = 0x8052a30 receive: verse_send_node_create(node_id = 2 type = 2 owner_id = 1 ); callback = 0x8052a30 send: verse_send_node_subscribe(node_id = 2 ); receive: verse_send_node_create(node_id = 3 type = 1 owner_id = 1 ); callback = 0x8052a30 received geometry node 3 send: verse_send_node_subscribe(node_id = 3 ); send: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967290 x = 0.001000 y = 0.001000 z = 0.001000 ); send: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967289 x = 0.201000 y = 0.001000 z = 0.001000 ); send: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967288 x = 0.101000 y = 0.001000 z = -0.172205 ); send: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967287 x = -0.099000 y = 0.001000 z = -0.172205 ); send: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967286 x = -0.199000 y = 0.001000 z = 0.001000 ); send: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967285 x = -0.099000 y = 0.001000 z = 0.174205 ); send: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967284 x = 0.101000 y = 0.001000 z = 0.174205 ); send: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967283 x = 0.001000 y = 0.501000 z = 0.001000 ); send: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967282 x = 0.001000 y = 0.501000 z = 0.001000 ); send: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967281 x = 0.001000 y = 0.501000 z = 0.001000 ); send: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967280 x = 0.001000 y = 0.501000 z = 0.001000 ); send: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967279 x = 0.001000 y = 0.501000 z = 0.001000 ); send: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967278 x = 0.001000 y = 0.501000 z = 0.001000 ); send: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967277 x = 0.001000 y = 0.501000 z = 0.001000 ); send: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967276 v0 = 0 v1 = 2 v2 = 1 v3 = 4294967295 ); send: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967275 v0 = 0 v1 = 3 v2 = 2 v3 = 4294967295 ); send: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967274 v0 = 0 v1 = 4 v2 = 3 v3 = 4294967295 ); send: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967273 v0 = 0 v1 = 5 v2 = 4 v3 = 4294967295 ); send: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967272 v0 = 0 v1 = 6 v2 = 5 v3 = 4294967295 ); send: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967271 v0 = 0 v1 = 1 v2 = 6 v3 = 4294967295 ); send: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967270 v0 = 1 v1 = 8 v2 = 7 v3 = 4294967295 ); send: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967269 v0 = 1 v1 = 2 v2 = 8 v3 = 4294967295 ); send: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967268 v0 = 2 v1 = 9 v2 = 8 v3 = 4294967295 ); send: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967267 v0 = 2 v1 = 3 v2 = 9 v3 = 4294967295 ); send: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967266 v0 = 3 v1 = 10 v2 = 9 v3 = 4294967295 ); send: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967265 v0 = 3 v1 = 4 v2 = 10 v3 = 4294967295 ); send: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967264 v0 = 4 v1 = 11 v2 = 10 v3 = 4294967295 ); send: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967263 v0 = 4 v1 = 5 v2 = 11 v3 = 4294967295 ); send: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967262 v0 = 5 v1 = 12 v2 = 11 v3 = 4294967295 ); send: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967261 v0 = 5 v1 = 6 v2 = 12 v3 = 4294967295 ); send: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967260 v0 = 6 v1 = 7 v2 = 12 v3 = 4294967295 ); send: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967259 v0 = 6 v1 = 1 v2 = 7 v3 = 4294967295 ); send: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967258 v0 = 13 v1 = 7 v2 = 8 v3 = 4294967295 ); send: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967257 v0 = 13 v1 = 8 v2 = 9 v3 = 4294967295 ); send: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967256 v0 = 13 v1 = 9 v2 = 10 v3 = 4294967295 ); send: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967255 v0 = 13 v1 = 10 v2 = 11 v3 = 4294967295 ); send: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967254 v0 = 13 v1 = 11 v2 = 12 v3 = 4294967295 ); send: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967253 v0 = 13 v1 = 12 v2 = 7 v3 = 4294967295 ); send: verse_send_g_layer_create(node_id = 3 layer_id = 65492 name = tex_u type = 2 def_uint = 0 def_real = 0.000000 ); send: verse_send_g_layer_create(node_id = 3 layer_id = 65491 name = tex_v type = 2 def_uint = 0 def_real = 0.000000 ); send: verse_send_m_fragment_create(node_id = 2 frag_id = 1 type = 12 fragment = 0xbfffeae0 ); send: verse_send_m_fragment_create(node_id = 2 frag_id = 2 type = 11 fragment = 0xbfffeae0 ); send: verse_send_m_fragment_create(node_id = 2 frag_id = 3 type = 0 fragment = 0xbfffeae0 ); receive: verse_send_node_create(node_id = 4 type = 0 owner_id = 1 ); callback = 0x8052a30 send: verse_send_node_subscribe(node_id = 4 ); send: verse_send_m_fragment_create(node_id = 2 frag_id = 1 type = 12 fragment = 0xbfffeae0 ); send: verse_send_m_fragment_create(node_id = 2 frag_id = 2 type = 11 fragment = 0xbfffeae0 ); send: verse_send_m_fragment_create(node_id = 2 frag_id = 3 type = 0 fragment = 0xbfffeae0 ); receive: verse_send_node_create(node_id = 5 type = 0 owner_id = 1 ); callback = 0x8052a30 send: verse_send_node_subscribe(node_id = 5 ); send: verse_send_m_fragment_create(node_id = 2 frag_id = 1 type = 12 fragment = 0xbfffeae0 ); send: verse_send_m_fragment_create(node_id = 2 frag_id = 2 type = 11 fragment = 0xbfffeae0 ); send: verse_send_m_fragment_create(node_id = 2 frag_id = 3 type = 0 fragment = 0xbfffeae0 ); send: verse_send_o_link_set(node_id = 4 link_id = 1 link = 3 name = geometry? target_id = 0 ); send: verse_send_o_link_set(node_id = 4 link_id = 2 link = 2 name = material? target_id = 0 ); send: verse_send_o_link_set(node_id = 5 link_id = 1 link = 4 name = (sub)object? target_id = 0 ); calling update calling update calling update receive: verse_send_g_layer_create(node_id = 3 layer_id = 1 name = polygon type = 128 def_uint = 0 def_real = 0.000000 ); callback = 0x8052df0 receive: verse_send_o_link_set(node_id = 4 link_id = 1 link = 2 name = material? target_id = 0 ); callback = (nil) receive: verse_send_m_fragment_create(node_id = 2 frag_id = 2 type = 0 ); callback = (nil) receive: verse_send_g_layer_create(node_id = 3 layer_id = 2 name = tex_v type = 2 def_uint = 0 def_real = 0.000000 ); callback = 0x8052df0 receive: verse_send_g_layer_create(node_id = 3 layer_id = 3 name = tex_u type = 2 def_uint = 0 def_real = 0.000000 ); callback = 0x8052df0 receive: verse_send_node_name_set(node_id = 2 name = Material_Node_2 ); callback = (nil) receive: verse_send_g_layer_create(node_id = 3 layer_id = 0 name = vertex type = 0 def_uint = 0 def_real = 0.000000 ); callback = 0x8052df0 receive: verse_send_node_name_set(node_id = 4 name = Object_Node_4 ); callback = (nil) receive: verse_send_m_fragment_create(node_id = 2 frag_id = 1 type = 11 ); callback = (nil) receive: verse_send_node_name_set(node_id = 5 name = Object_Node_5 ); callback = (nil) receive: verse_send_m_fragment_create(node_id = 2 frag_id = 0 type = 12 ); callback = (nil) receive: verse_send_g_crease_set_vertex(node_id = 3 layer = def_crease = 0 ); callback = (nil) receive: verse_send_o_link_set(node_id = 4 link_id = 0 link = 3 name = geometry? target_id = 0 ); callback = (nil) receive: verse_send_o_link_set(node_id = 5 link_id = 0 link = 4 name = (sub)object? target_id = 0 ); callback = (nil) receive: verse_send_g_crease_set_edge(node_id = 3 layer = def_crease = 0 ); callback = (nil) receive: verse_send_node_name_set(node_id = 3 name = Geometry_Node_3 ); callback = (nil) calling update calling update calling update calling update calling update calling update calling update calling update calling update calling update calling update calling update calling update calling update calling update calling update calling update calling update calling update calling update --------------040004050902040906020608 Content-Type: text/plain; name="verseoutput.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="verseoutput.txt" Verse Server r3p2 By Eskil Steenberg send: verse_send_connect_accept(avatar = 1 address = 0xbffff240); receive: verse_send_node_list(mask = 15 ); callback = 0x80542f5 send: verse_send_node_create(node_id = 1 type = 0 owner_id = 0 ); receive: verse_send_node_create(node_id = 4294967291 type = 2 owner_id = 1 ); callback = 0x80541c9 send: verse_send_node_create(node_id = 2 type = 2 owner_id = 1 ); receive: verse_send_node_create(node_id = 4294967292 type = 1 owner_id = 1 ); callback = 0x80541c9 send: verse_send_node_create(node_id = 3 type = 1 owner_id = 1 ); receive: verse_send_node_create(node_id = 4294967293 type = 0 owner_id = 1 ); callback = 0x80541c9 send: verse_send_node_create(node_id = 4 type = 0 owner_id = 1 ); receive: verse_send_node_create(node_id = 4294967294 type = 0 owner_id = 1 ); callback = 0x80541c9 send: verse_send_node_create(node_id = 5 type = 0 owner_id = 1 ); receive: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967277 x = 0.001000 y = 0.501000 z = 0.001000 ); callback = 0x804dba4 receive: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967278 x = 0.001000 y = 0.501000 z = 0.001000 ); callback = 0x804dba4 receive: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967279 x = 0.001000 y = 0.501000 z = 0.001000 ); callback = 0x804dba4 receive: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967280 x = 0.001000 y = 0.501000 z = 0.001000 ); callback = 0x804dba4 receive: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967281 x = 0.001000 y = 0.501000 z = 0.001000 ); callback = 0x804dba4 receive: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967282 x = 0.001000 y = 0.501000 z = 0.001000 ); callback = 0x804dba4 receive: verse_send_node_subscribe(node_id = 2 ); callback = 0x8050e31 send: verse_send_node_name_set(node_id = 2 name = Material_Node_2 ); receive: verse_send_node_subscribe(node_id = 3 ); callback = 0x8050e31 send: verse_send_g_layer_create(node_id = 3 layer_id = 0 name = vertex type = 0 def_uint = 0 def_real = 0.000000 ); send: verse_send_g_layer_create(node_id = 3 layer_id = 1 name = polygon type = 128 def_uint = 0 def_real = 0.000000 ); send: verse_send_g_crease_set_vertex(node_id = 3 layer = def_crease = 0 ); send: verse_send_g_crease_set_edge(node_id = 3 layer = def_crease = 0 ); send: verse_send_node_name_set(node_id = 3 name = Geometry_Node_3 ); receive: verse_send_node_subscribe(node_id = 4 ); callback = 0x8050e31 send: verse_send_node_name_set(node_id = 4 name = Object_Node_4 ); receive: verse_send_m_fragment_create(node_id = 2 frag_id = 1 type = 12 ); callback = 0x80511eb send: verse_send_m_fragment_create(node_id = 2 frag_id = 0 type = 12 fragment = 0xbfffebb0 ); receive: verse_send_node_subscribe(node_id = 5 ); callback = 0x8050e31 send: verse_send_node_name_set(node_id = 5 name = Object_Node_5 ); receive: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967283 x = 0.001000 y = 0.501000 z = 0.001000 ); callback = 0x804dba4 receive: verse_send_o_link_set(node_id = 4 link_id = 1 link = 3 name = geometry? target_id = 0 ); callback = 0x80525a4 send: verse_send_o_link_set(node_id = 4 link_id = 0 link = 3 name = geometry? target_id = 0 ); receive: verse_send_m_fragment_create(node_id = 2 frag_id = 2 type = 11 ); callback = 0x80511eb send: verse_send_m_fragment_create(node_id = 2 frag_id = 1 type = 11 fragment = 0xbfffebb0 ); receive: verse_send_o_link_set(node_id = 5 link_id = 1 link = 4 name = (sub)object? target_id = 0 ); callback = 0x80525a4 send: verse_send_o_link_set(node_id = 5 link_id = 0 link = 4 name = (sub)object? target_id = 0 ); receive: verse_send_o_link_set(node_id = 4 link_id = 2 link = 2 name = material? target_id = 0 ); callback = 0x80525a4 send: verse_send_o_link_set(node_id = 4 link_id = 1 link = 2 name = material? target_id = 0 ); receive: verse_send_m_fragment_create(node_id = 2 frag_id = 3 type = 0 ); callback = 0x80511eb send: verse_send_m_fragment_create(node_id = 2 frag_id = 2 type = 0 fragment = 0xbfffebb0 ); receive: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967284 x = 0.101000 y = 0.001000 z = 0.174205 ); callback = 0x804dba4 receive: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967285 x = -0.099000 y = 0.001000 z = 0.174205 ); callback = 0x804dba4 receive: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967286 x = -0.199000 y = 0.001000 z = 0.001000 ); callback = 0x804dba4 receive: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967287 x = -0.099000 y = 0.001000 z = -0.172205 ); callback = 0x804dba4 receive: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967288 x = 0.101000 y = 0.001000 z = -0.172205 ); callback = 0x804dba4 receive: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967289 x = 0.201000 y = 0.001000 z = 0.001000 ); callback = 0x804dba4 receive: verse_send_g_vertex_set_real32_xyz(node_id = 3 layer_id = 0 vertex_id = 4294967290 x = 0.001000 y = 0.001000 z = 0.001000 ); callback = 0x804dba4 receive: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967253 v0 = 13 v1 = 12 v2 = 7 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967254 v0 = 13 v1 = 11 v2 = 12 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967255 v0 = 13 v1 = 10 v2 = 11 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967256 v0 = 13 v1 = 9 v2 = 10 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967257 v0 = 13 v1 = 8 v2 = 9 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967258 v0 = 13 v1 = 7 v2 = 8 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_layer_create(node_id = 3 layer_id = 65491 name = tex_v type = 2 def_uint = 0 def_real = 0.000000 ); callback = 0x804c0a2 send: verse_send_g_layer_create(node_id = 3 layer_id = 2 name = tex_v type = 2 def_uint = 0 def_real = 0.000000 ); receive: verse_send_g_layer_create(node_id = 3 layer_id = 65492 name = tex_u type = 2 def_uint = 0 def_real = 0.000000 ); callback = 0x804c0a2 send: verse_send_g_layer_create(node_id = 3 layer_id = 3 name = tex_u type = 2 def_uint = 0 def_real = 0.000000 ); receive: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967259 v0 = 6 v1 = 1 v2 = 7 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967260 v0 = 6 v1 = 7 v2 = 12 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967261 v0 = 5 v1 = 6 v2 = 12 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967262 v0 = 5 v1 = 12 v2 = 11 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967263 v0 = 4 v1 = 5 v2 = 11 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967264 v0 = 4 v1 = 11 v2 = 10 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967265 v0 = 3 v1 = 4 v2 = 10 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967266 v0 = 3 v1 = 10 v2 = 9 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967267 v0 = 2 v1 = 3 v2 = 9 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967268 v0 = 2 v1 = 9 v2 = 8 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967269 v0 = 1 v1 = 2 v2 = 8 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967270 v0 = 1 v1 = 8 v2 = 7 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967271 v0 = 0 v1 = 1 v2 = 6 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967272 v0 = 0 v1 = 6 v2 = 5 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967273 v0 = 0 v1 = 5 v2 = 4 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967274 v0 = 0 v1 = 4 v2 = 3 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967275 v0 = 0 v1 = 3 v2 = 2 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 3 layer_id = 1 polygon_id = 4294967276 v0 = 0 v1 = 2 v2 = 1 v3 = 4294967295 ); callback = 0x804ea42 send: verse_send_node_create(node_id = 6 type = 0 owner_id = 0 ); send: verse_send_connect_accept(avatar = 6 address = 0xbffff240); receive: verse_send_node_list(mask = 15 ); callback = 0x80542f5 send: verse_send_node_create(node_id = 1 type = 0 owner_id = 0 ); send: verse_send_node_create(node_id = 4 type = 0 owner_id = 1 ); send: verse_send_node_create(node_id = 5 type = 0 owner_id = 1 ); send: verse_send_node_create(node_id = 6 type = 0 owner_id = 0 ); send: verse_send_node_create(node_id = 3 type = 1 owner_id = 1 ); send: verse_send_node_create(node_id = 2 type = 2 owner_id = 1 ); receive: verse_send_node_subscribe(node_id = 3 ); callback = 0x8050e31 send: verse_send_g_layer_create(node_id = 3 layer_id = 0 name = vertex type = 0 def_uint = 0 def_real = 0.000000 ); send: verse_send_g_layer_create(node_id = 3 layer_id = 1 name = polygon type = 128 def_uint = 0 def_real = 0.000000 ); send: verse_send_g_layer_create(node_id = 3 layer_id = 2 name = tex_v type = 2 def_uint = 0 def_real = 0.000000 ); send: verse_send_g_layer_create(node_id = 3 layer_id = 3 name = tex_u type = 2 def_uint = 0 def_real = 0.000000 ); send: verse_send_g_crease_set_vertex(node_id = 3 layer = def_crease = 0 ); send: verse_send_g_crease_set_edge(node_id = 3 layer = def_crease = 0 ); send: verse_send_node_name_set(node_id = 3 name = Geometry_Node_3 ); receive: verse_send_g_layer_subscribe(node_id = 3 layer_id = 1 type = 0 ); callback = 0x804cb87 receive: verse_send_g_layer_subscribe(node_id = 3 layer_id = 0 type = 0 ); callback = 0x804cb87 --------------040004050902040906020608 Content-Type: text/plain; name="vieweroutput.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="vieweroutput.txt" verse thread construct vis-thread construct Trying to connect to server: borsiator send: verse_send_connect(name = nobody pass = anonymous address = 0x80773c4); verse session created send: verse_send_node_list(mask = 15 ); receive: verse_send_node_create(node_id = 2 type = 2 owner_id = 1 ); callback = 0x8054fe0 receive: verse_send_node_create(node_id = 3 type = 1 owner_id = 1 ); callback = 0x8054fe0 receive: verse_send_node_create(node_id = 4 type = 0 owner_id = 1 ); callback = 0x8054fe0 receive: verse_send_node_create(node_id = 5 type = 0 owner_id = 1 ); callback = 0x8054fe0 receive: verse_send_node_create(node_id = 6 type = 0 owner_id = 0 ); callback = 0x8054fe0 receive: verse_send_node_create(node_id = 1 type = 0 owner_id = 0 ); callback = 0x8054fe0 send: verse_send_node_subscribe(node_id = 3 ); receive: verse_send_g_layer_create(node_id = 3 layer_id = 0 name = vertex type = 0 def_uint = 0 def_real = 0.000000 ); callback = 0x8055180 receive: verse_send_g_layer_create(node_id = 3 layer_id = 1 name = polygon type = 128 def_uint = 0 def_real = 0.000000 ); callback = 0x8055180 receive: verse_send_g_layer_create(node_id = 3 layer_id = 2 name = tex_v type = 2 def_uint = 0 def_real = 0.000000 ); callback = 0x8055180 receive: verse_send_g_layer_create(node_id = 3 layer_id = 3 name = tex_u type = 2 def_uint = 0 def_real = 0.000000 ); callback = 0x8055180 receive: verse_send_g_crease_set_vertex(node_id = 3 layer = def_crease = 0 ); callback = (nil) receive: verse_send_g_crease_set_edge(node_id = 3 layer = def_crease = 0 ); callback = (nil) receive: verse_send_node_name_set(node_id = 3 name = Geometry_Node_3 ); callback = 0x8055070 send: verse_send_g_layer_subscribe(node_id = 3 layer_id = 0 type = 0 ); send: verse_send_g_layer_subscribe(node_id = 3 layer_id = 1 type = 0 ); --------------040004050902040906020608-- From verse-dev@blender.org Tue Aug 17 22:30:53 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Tue, 17 Aug 2004 23:30:53 +0200 Subject: [Verse-dev] Material fragments In-Reply-To: <412256D6.6080204@gmx.de> References: <4120E912.4090002@gmx.de> <41216CDD.6050803@obsession.se> <412256D6.6080204@gmx.de> Message-ID: <4122790D.70401@obsession.se> Hi > How can i know which geometry node uses which material? This however has not been defined, its is one of the things i want to nail down for R4, there are more issiues whit how links work that need to be sorted out. >> Say you would like to use the material node for things like >> displacement, temperature or acoustic propertys. > > so this is just not mentioned in the spec yet? the sentence is a bit > embarassing... It should be, emil? the two dtat should be defined are "color" and "displacement", the others will be user defined. E From verse-dev@blender.org Tue Aug 17 22:38:56 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Tue, 17 Aug 2004 23:38:56 +0200 Subject: [Verse-dev] Bitmap layer ids In-Reply-To: <4122595A.3040804@gmx.de> References: <4122595A.3040804@gmx.de> Message-ID: <41227AF0.8040706@obsession.se> Hi >> >> True. It would, however, add quite a few new commands, and the 8-bit >> command space is a limited resource. Granted, there is still room to >> spare so I guess this is not a very poweful argument. > > Well, sounds like the year 2000 problem... 8 bit for a command id?! > network bandwith isn't THAT limited. But, why not change that with the > next release? releases aren't binary compatible either, so you can > safely change the opcode size. > Its not a year 2000 problem, as you said different releases are not binary compatible any way so there is no reason to change this before the change is needed. My stance against more API calls has almost nothing to do with the number of comand ids. It has to do with the fact that the API will be more difficult to use, and that event compression will break. > Well, it may sound a bit hard, but the cases we are discussing > currently aren't that special, so if they haven't occoured and > discussed in the last five years, then verse couldn't have been used > very often... > We have discussed this A LOT. E From verse-dev@blender.org Tue Aug 17 23:07:16 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Wed, 18 Aug 2004 00:07:16 +0200 Subject: [Verse-dev] Bitmap layer ids In-Reply-To: <41225659.7000208@gmx.de> References: <41210B2C.90201@gmx.de> <4121699F.1030708@obsession.se> <41225659.7000208@gmx.de> Message-ID: <41228194.2010205@obsession.se> Hi > well i used the tutorial as base code and created layers/nodes as you > proposed... please have a look at the output and my code. Maybe i've > missed something but maybe the server implementation has a bug. Im not sure but i think i have found some issues in the function send_geometry_node the out commented j and k / 3 are correct. vertex and polygon ids are defined by the user. you use verse_send_g_vertex_set_real32_xyz typo upload data, that is ok. But it is recommended that you use verse_send_g_vertex_set_real64_xyz. some servers may not accept low precision data. (its not really a big deal...) Other then that i cant find any major flaws except the obvious issue whit illegal commands. You use one global value counting down from 0xfffffffe. (should be 0xffffffff for 32 bit ids) you should know that this value is local to the functions that use it and can be re set when ever the commands reach the server. Let me start a new tread to explain, in depth how the ids relate to functions and commands. Cheers E From verse-dev@blender.org Wed Aug 18 01:28:17 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Wed, 18 Aug 2004 02:28:17 +0200 Subject: [Verse-dev] [Verse-dev]understanding event collapse In-Reply-To: <41225659.7000208@gmx.de> References: <41210B2C.90201@gmx.de> <4121699F.1030708@obsession.se> <41225659.7000208@gmx.de> Message-ID: <4122A2A1.7050506@obsession.se> Hi This has turned out to be an issue that is hard to shake, and I have perhaps been too quick to dismiss proposed changes with out properly explaining how this works. (i think i have written something like this in the past but anyway....) The basis of this system is that UDP network packets can arrive out of order. or get lost (if a packet gets lost it will be resent and hence out of order, so in this mail i will only refer to this as out of order.) if we now consider us sending thees 2 commands: verse_send_g_layer_create verse_send_b_init_dimensions if thees two commands arrive out of order it doesnt matter because the deal with two different parts of the data set that can be updated independently. However, what if the two commands are the same commands? lets imagine that we send the following two commands: verse_send_b_init_dimensions(1, 128, 128, 1); verse_send_b_init_dimensions(2, 256, 256, 1); if thees two commands arrive out of order it doesnt matter either because even if they use the same command they deal with two different nodes. The problem comes when you have two commands that deals with the same data: verse_send_b_init_dimensions(2, 128, 128, 1); verse_send_b_init_dimensions(2, 256, 256, 1); Now this would be parsed as the bitmap should have a size of 128*128*1 and then it is changed to 256*256*1. If the two arrive out of order there will be a problem, because the node will first be 256*256*1 and then 128*128*1. In other word we would get the wrong result and the two sides would be out of sync. As far as i know there is only 2 ways of solving this, the first and obvious one is to wait for both commands and the re-order them before parsing them. This is what TCP does and it works fine for file transfer. The problem with this is that you have to wait for the later packet before you can parse any of the data that should have came after it, so it creates a lock up. (the most common reason for out of order packets are packet re-send so the round trip to request a re-send and then get it can be quite long) In verse this problem had to be solved in a different way for performance reasons. Here is how we do it: If we take a closer look at the commands used in the earlier examples we see that we can divide each command in to two parts, address and data: Address: verse_send_b_init_dimensions(VNodeID node_id, data: uint16 width, uint16 height, uint16 depth); Any two commands with the same address will over write each others data. therefore we define the address and data block of all commands. (you can actually see the definitions of the commands in the v_cmd_def_ files in verse, wherever the enum VCGP_END_ADDRESS is used) We can now quickly take any two commands and compare their address to see if they over write each other. So how do we use this to fix the out of order problem? well if we send: verse_send_b_init_dimensions(2, 128, 128, 1); verse_send_b_init_dimensions(2, 256, 256, 1); and they arrive in the wrong order and the sender is asked to re-send the first command. The sender can then simply look in to its history and see that the second command over writes the first one. so it ends up ignoring the resend request to avoid delivering the two out of order. So all the receiver will only get is: verse_send_b_init_dimensions(2, 256, 256, 1); clear? It gets a little more complicated. Lets take a look at thees two commands: verse_send_g_layer_create(2, 3, "heat", VN_G_LAYER_VERTEX_REAL, 0, 0); verse_send_g_layer_destroy(2, 3); If you think about it the two functions have the same address (they both deal with node 2 layer 3), but they are not the same API call. That is true, but they are the same command in the network! internally in the spec the verse_send_g_layer_destroy is called an "Alias" of verse_send_g_layer_create. so lets see what this means. lets say we send these three commands. verse_send_g_layer_create(2, 3, "heat", VN_G_LAYER_VERTEX_REAL, 0, 0); verse_send_g_layer_destroy(2, 3); verse_send_g_layer_create(2, 3, "cold", VN_G_LAYER_POLYGON_FACE_REAL, 0, 0); they would set one layer, then destroy it and then re set it. but lets say this came out of order: verse_send_g_layer_create(2, 3, "heat", VN_G_LAYER_VERTEX_REAL, 0, 0); verse_send_g_layer_create(2, 3, "cold", VN_G_LAYER_POLYGON_FACE_REAL, 0, 0); verse_send_g_layer_destroy(2, 3); then the network protocol would remove the last call to get the correct output: verse_send_g_layer_create(2, 3, "heat", VN_G_LAYER_VERTEX_REAL, 0, 0); verse_send_g_layer_create(2, 3, "cold", VN_G_LAYER_POLYGON_FACE_REAL, 0, 0); This means that the last command received rules disregarding what came before. a callback has to be ready to change the state disregarding of what was before. if the client is asked to create a layer where there already is a layer, it has to overwrite the current state. you would get the exact same state if you only sent: verse_send_g_layer_create(2, 3, "cold", VN_G_LAYER_POLYGON_FACE_REAL, 0, 0); In this text i have used commands that you may not use too often as examples, but this system is in place for 90% of the API (the exceptions are mostly connection commands) Now it becomes obvious why verse thinks that: verse_send_g_layer_create(2, -1, "heat", VN_G_LAYER_VERTEX_REAL, 0, 0); verse_send_g_layer_create(2, -1, "cold", VN_G_LAYER_POLYGON_FACE_REAL, 0, 0); verse_send_g_layer_create(2, -1, "moist", VN_G_LAYER_POLYGON_CORNER_REAL, 0, 0); is the same as: verse_send_g_layer_create(2, -1, "moist", VN_G_LAYER_POLYGON_CORNER_REAL, 0, 0); I have been contemplating how to fix the illegal id problem, to make it side step the event compression as emil suggested, but this doesnt change the basic idea of one address per data, and that any command over writes all previous state disregarding of what was before. If we break that we break everything. There are some things that you have to think about when you code verse that is in its very nature. when verse was designed we did not just take in to account usability, there where many factors. such as performance. Verse is and was designed to be a low level API, and that means that you sacrifice ease of use for performance and control. I dont mind this because i know the a higher level API can be implemented on top of verse that fixes that. Every one who writes apps for verse at some point or an other wants to change the API (me included, for every app Ive written) This is why I have implemented Enough and other tools so that i more easely can do what i want whit verse. You are free to use my higher level API too, but to force people to use it just wrong. Purple is an example of an app that doesnt fit very well with how Enough was written so Emil is free not to us it and that is a good thing. E From verse-dev@blender.org Wed Aug 18 07:50:57 2004 From: verse-dev@blender.org (Emil Brink) Date: Wed, 18 Aug 2004 08:50:57 +0200 Subject: [Verse-dev] Material fragments In-Reply-To: <4122790D.70401@obsession.se> References: <4120E912.4090002@gmx.de> <41216CDD.6050803@obsession.se> <412256D6.6080204@gmx.de> <4122790D.70401@obsession.se> Message-ID: <20040818085057.654771ab@treebeard> On Tue, 17 Aug 2004 23:30:53 +0200 Eskil Steenberg wrote: [material usage] > > so this is just not mentioned in the spec yet? the sentence is a bit > > embarassing... > > It should be, emil? the two dtat should be defined are "color" and > "displacement", the others will be user defined. I'm not 100% sure which sentence you are referring to any more, but I did update the text about the 'type' field of the material node's out- put fragment. I'll upload a new version of the spec shortly. Thanks for the feedback. /Emil From verse-dev@blender.org Wed Aug 18 09:09:18 2004 From: verse-dev@blender.org (Marcus Hoffmann) Date: Wed, 18 Aug 2004 10:09:18 +0200 Subject: [Verse-dev] Bitmap layer ids In-Reply-To: <41222002.6000900@obsession.se> Message-ID: Hi, > >If you think this scenario to the end this will lead to the point, that > >every client HAS to get the hole server world first! > > > No, not at all, The client knows that the id -1 is reserved and can use > that id. What id -1? As far as i understood you defined ids as unsigned ints. A client can use what ever it wants, but how will you transfer a -1 via verse to the server with unsigned ints? This all is not about the internal view of a client or a server - its about the interacting between them. > >I agree with thorsten that its not a big deal to introduce a change > >command... > > > Maybe not for you but for verse its a huge deal. And any way how would > the tow commands differ? not at all. my code would become a lot more > clumsy if i had to handle that many more callbacks. a change and a set > is almost the same. You still have to run the same checks for both so > one isnt much faster then the other. But the improvement would be to have a sepereated command structure for creating and for changing... I think tha is really useful in programming and makes developing verse applications much more easy and i think more easy to understand. greets M From verse-dev@blender.org Wed Aug 18 09:30:25 2004 From: verse-dev@blender.org (Marcus Hoffmann) Date: Wed, 18 Aug 2004 10:30:25 +0200 Subject: [Verse-dev] [Verse-dev]understanding event collapse In-Reply-To: <4122A2A1.7050506@obsession.se> Message-ID: > The basis of this system is that UDP network packets can arrive out of > order. or get lost (if a packet gets lost it will be resent and hence > out of order, so in this mail i will only refer to this as out of order.) > > if we now consider us sending thees 2 commands: > > verse_send_g_layer_create > verse_send_b_init_dimensions > > if thees two commands arrive out of order it doesnt matter because the > deal with two different parts of the data set that can be updated > independently. > > However, what if the two commands are the same commands? lets imagine > that we send the following two commands: > > verse_send_b_init_dimensions(1, 128, 128, 1); > verse_send_b_init_dimensions(2, 256, 256, 1); > > if thees two commands arrive out of order it doesnt matter either > because even if they use the same command they deal with two different > nodes. The problem comes when you have two commands that deals with the > same data: > > verse_send_b_init_dimensions(2, 128, 128, 1); > verse_send_b_init_dimensions(2, 256, 256, 1); > > Now this would be parsed as the bitmap should have a size of 128*128*1 > and then it is changed to 256*256*1. If the two arrive out of order > there will be a problem, because the node will first be 256*256*1 and > then 128*128*1. In other word we would get the wrong result and the two > sides would be out of sync. So this is another good example where a change command would be a benefit. If you send the first create command and after that a change command may looking like that: verse_send_b_init_dimensions(2, 128, 128, 1); verse_send_b_change_dimensions(2, 256, 256, 1); you would have no problems with overwriting something. If the change command arrives before the create command nothing will happen! and then the create command arrives and will create a layer. Yes - the change is lost, but you won't have wrong data. But what you then can think of is a stack that holds the change command for a short time. and looks for an arriving create command that contains the layer or node that you wish to change...... But its in my eyes a clearer solution and much easier to implement and to understand. The Problem with the out-of-order-incoming-commands will be a problem anyway, no question, but catching those events is much easier in the way i thought of. > The basis of this system is that UDP network packets can arrive out of > order. or get lost (if a packet gets lost it will be resent and hence > out of order, so in this mail i will only refer to this as out of order.) This "or get lost" is a really scaring thing. maybe in most cases it doesn't matter, but for compression its really a hard thing. If i loose vertices or a structure information, every compression algorithm will crash. if you want to compress a mesh with holes (because vertices are lost) or a polygon that references to non-existing vertices because they were lost, i will have a big problem... And the thing is: If the compression crashes, every application that uses a compressed geometry will maybe have a crash too. A really new thing here - and different from the above discussed problems - is that i would like to have any information about a mesh. verse does give me a polygon structure, but no information what is a mesh and where another one begins. This is really immportant for good compression. Is there something included that i've not found? Or do we make the internal (or in the spec) agreement, that every geometry node is one mesh, or every polygon layer describes one? And if we do so, really everyone should follow this order. Because i would then implement the compression on the server relying on that. From verse-dev@blender.org Wed Aug 18 09:47:07 2004 From: verse-dev@blender.org (Thorsten Jordan) Date: Wed, 18 Aug 2004 10:47:07 +0200 Subject: [Verse-dev] Material fragments In-Reply-To: <4122790D.70401@obsession.se> References: <4120E912.4090002@gmx.de> <41216CDD.6050803@obsession.se> <412256D6.6080204@gmx.de> <4122790D.70401@obsession.se> Message-ID: <4123178B.4040809@gmx.de> Eskil Steenberg wrote: > Hi > > This however has not been defined, its is one of the things i want to > nail down for R4, there are more issiues whit how links work that need > to be sorted out. this is important for my clients... e.g. 3ds has objects that consist of several meshes, each with own material. That could be modelled with multiple links to geometry and material nodes. For now i use one link per object node and create one object node per mesh additionally. This could be one solution to the problem: just allow one link of type geometry/material per object node. -- Greetings, Thorsten From verse-dev@blender.org Wed Aug 18 09:59:34 2004 From: verse-dev@blender.org (Thorsten Jordan) Date: Wed, 18 Aug 2004 10:59:34 +0200 Subject: [Verse-dev] Bitmap layer ids In-Reply-To: <41228194.2010205@obsession.se> References: <41210B2C.90201@gmx.de> <4121699F.1030708@obsession.se> <41225659.7000208@gmx.de> <41228194.2010205@obsession.se> Message-ID: <41231A76.2030308@gmx.de> Eskil Steenberg wrote: > Hi > > in the function send_geometry_node the out commented j and k / 3 are > correct. vertex and polygon ids are defined by the user. Ouch, that was my fault. I replaced the IDs in every send command from the 0-up code to the nodeidptr code ... and just comletely missed that this won't work for vertices and indices. Ok then the pusher seems to work with some meshes. As i have written, some triangles are missing on large meshes, i will explore the situation the next days, e.g. count what and how many triangles are send and later received. > you use verse_send_g_vertex_set_real32_xyz typo upload data, that is > ok. But it is recommended that you use > verse_send_g_vertex_set_real64_xyz. some servers may not accept low > precision data. (its not really a big deal...) That sounds not very sensible. If the API offers the call why shouldn't i am allowed to use it?! Your server can handle it, Marcus' server will be able to handle it - what else servers should exist? And what is with clients? The pocketpc uses real32 everywhere, because real64 performance is too low... > Other then that i cant find any major flaws except the obvious issue > whit illegal commands. You use one global value counting down from > 0xfffffffe. (should be 0xffffffff for 32 bit ids) you should know that > this value is local to the functions that use it and can be re set when > ever the commands reach the server. i've used this scheme to assure that NEVER two IDs are the same when creating objects and now illegal ID is used (0xffffffff = illegal). This brings up another question: if i create some vertices (using IDs -1,-2,-3,...), then the indices (using again IDs -1,-2,-3... as you suggested) and after that i create more vertices, which IDs should i use for them? again beginning at -1? will the create commands of the first section of vertices be compressed with some create commands of the second section, i.e. do i have to use -1000,-1001,-1002 etc. for the second vertices, or can only adjacent commands of the same type be compressed? What is safe then? -- Greetings, Thorsten From verse-dev@blender.org Wed Aug 18 09:50:29 2004 From: verse-dev@blender.org (Thorsten Jordan) Date: Wed, 18 Aug 2004 10:50:29 +0200 Subject: [Verse-dev] Bitmap layer ids In-Reply-To: <41227AF0.8040706@obsession.se> References: <4122595A.3040804@gmx.de> <41227AF0.8040706@obsession.se> Message-ID: <41231855.10105@gmx.de> Eskil Steenberg wrote: > Hi > > Its not a year 2000 problem, as you said different releases are not > binary compatible any way so there is no reason to change this before > the change is needed. My stance against more API calls has almost > nothing to do with the number of comand ids. It has to do with the fact > that the API will be more difficult to use, and that event compression > will break. more calls doesn't mean that the API will be more difficult to use, at least if the number is low. How many new calls would that be? one per node type, one for the bones, maybe one for material fragments. That would be less than 10. And why should event compression break? What is different then? Calls are calls... -- Greetings, Thorsten From verse-dev@blender.org Wed Aug 18 10:52:42 2004 From: verse-dev@blender.org (Emil Brink) Date: Wed, 18 Aug 2004 11:52:42 +0200 Subject: [Verse-dev] New spec online Message-ID: <20040818115242.1950637e@treebeard> Hello. I just uploaded a new version of the Verse specification to the Blender-hosted project site. It looks different from how it used to, but that is simply because I upgraded the DocBook toolchain used to build it, there are no changes in document structure. The only content change is that I added a sentence in about the "type" field of material output fragments, here: http://www.blender.org/modules/verse/verse-spec/n-material.html#m-f-output This was triggered by some talk on the mailing list, and I hope this makes things at least slightly clearer. Also, the main front page has been renamed, it used to be "book1.html" but is now a more normal "index.html". I symlinked it to preserve any bookmarks you might have, but recommend updating them anyway. Regards, /Emil From verse-dev@blender.org Wed Aug 18 07:47:30 2004 From: verse-dev@blender.org (Emil Brink) Date: Wed, 18 Aug 2004 08:47:30 +0200 Subject: [Verse-dev] Material fragments In-Reply-To: <4122790D.70401@obsession.se> References: <4120E912.4090002@gmx.de> <41216CDD.6050803@obsession.se> <412256D6.6080204@gmx.de> <4122790D.70401@obsession.se> Message-ID: <20040818084730.3f6e4289@treebeard> On Tue, 17 Aug 2004 23:30:53 +0200 Eskil Steenberg wrote: [material usage] > > so this is just not mentioned in the spec yet? the sentence is a bit > > embarassing... > > It should be, emil? the two dtat should be defined are "color" and > "displacement", the others will be user defined. I'm not 100% sure which sentence you are referring to any more, but I did update the text about the 'type' field of the material node's out- put fragment. I'll upload a new version of the spec shortly. Thanks for the feedback. /Emil From verse-dev@blender.org Wed Aug 18 16:08:00 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Wed, 18 Aug 2004 17:08:00 +0200 Subject: [Verse-dev] Material fragments In-Reply-To: <4123178B.4040809@gmx.de> References: <4120E912.4090002@gmx.de> <41216CDD.6050803@obsession.se> <412256D6.6080204@gmx.de> <4122790D.70401@obsession.se> <4123178B.4040809@gmx.de> Message-ID: <412370D0.8020202@obsession.se> Hi > this is important for my clients... e.g. 3ds has objects that consist > of several meshes, each with own material. That could be modelled with > multiple links to geometry and material nodes. For now i use one link > per object node and create one object node per mesh additionally. > > This could be one solution to the problem: just allow one link of type > geometry/material per object node. > As I said, I dont really know how this is to be done. Perhaps one can only connect one real geometry node to a object node, but you could connect more then one object children that in turn could connect to more geometry nodes. Then you can give each geometry their own transform as well. I think it may be a good idea but i have to think more about the details of it. Does this solution look good? E From verse-dev@blender.org Wed Aug 18 16:38:48 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Wed, 18 Aug 2004 17:38:48 +0200 Subject: [Verse-dev] [Verse-dev]understanding event collapse In-Reply-To: References: Message-ID: <41237808.2000405@obsession.se> Hi! >So this is another good example where a change command would be a benefit. >If you send the first create command and after that a change command may >looking like that: > >verse_send_b_init_dimensions(2, 128, 128, 1); >verse_send_b_change_dimensions(2, 256, 256, 1); > >you would have no problems with overwriting something. If the change command >arrives before the create command nothing will happen! and then the create >command arrives and will create a layer. >Yes - the change is lost, but you won't have wrong data. But what you then >can think of is a stack that holds the change command for a short time. and >looks for an arriving create command that contains the layer or node that >you wish to change...... > > > You dont seem to have under stood what the event compression does, because the event compression as it is right now deals with this so that you do get the right data, and that data arrives securely, with no look-ups.and you dont always have to wait for re-sends. (anything else is a bug in the implementation) The example you describe above will get you, non-secure state (since the state is wrong in the receiving end), more API where there is no difference in arguments. Then you describe how you have to wait for the init command to be re sent to be able to apply the change command (in other words a look-up). And how the user should do this, giving way more responsibility to the programmer to actually see to that the data gets there. (right now the client may not get the same data back from the server as it set to it, but if it doesnt there is no reason to resend the data because the client will know that the changes got rejected by the servers security system and not because it didnt get there). To me it is very clear that you have not understood how the event compression works despite my long winding mail. I dont know how to explain it in other terms. Does any one besides me and Emil understand this? The tip I can give is for you to re-read the my mails, read the spec, read the verse source, and the page on networking on the site. (http://www.blender.org/modules/verse/network.htm) I dont see much point in discussing changes when you dont understand how thing work right now. Cheers E From verse-dev@blender.org Wed Aug 18 18:02:09 2004 From: verse-dev@blender.org (Thorsten Jordan) Date: Wed, 18 Aug 2004 19:02:09 +0200 Subject: [Verse-dev] Material fragments In-Reply-To: <412370D0.8020202@obsession.se> References: <4120E912.4090002@gmx.de> <41216CDD.6050803@obsession.se> <412256D6.6080204@gmx.de> <4122790D.70401@obsession.se> <4123178B.4040809@gmx.de> <412370D0.8020202@obsession.se> Message-ID: <41238B91.1090409@gmx.de> Eskil Steenberg wrote: > Hi > >> this is important for my clients... e.g. 3ds has objects that consist >> of several meshes, each with own material. That could be modelled with >> multiple links to geometry and material nodes. For now i use one link >> per object node and create one object node per mesh additionally. >> >> This could be one solution to the problem: just allow one link of type >> geometry/material per object node. >> > As I said, I dont really know how this is to be done. > > Perhaps one can only connect one real geometry node to a object node, > but you could connect more then one object children that in turn could > connect to more geometry nodes. Then you can give each geometry their > own transform as well. I think it may be a good idea but i have to think > more about the details of it. > > Does this solution look good? that is what i already have proposed... one geometry link and one material link for each object node, but multiple object links. Sounds simple and ok. -- Greetings, Thorsten From verse-dev@blender.org Wed Aug 18 19:47:11 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Wed, 18 Aug 2004 21:47:11 +0300 Subject: [Verse-dev] Material fragments In-Reply-To: <41238B91.1090409@gmx.de> Message-ID: <200408181947.i7IJlCP14727@tessla.levonline.com> Hi > one geometry link and one material link for each object node, but > multiple object links. Sounds simple and ok. There will be more then one material per geometry node. And it is likely that there will only be a key word for the one geometry link that will be drawn. (you might want to have other keywords for other geometry's). As i think of it, it may not be a problem to have multiple geometry's if they have the same material. i don't think that a one geometry limitation will be very helpful to any one. Cheers E From verse-dev@blender.org Wed Aug 18 22:07:13 2004 From: verse-dev@blender.org (Thorsten Jordan) Date: Wed, 18 Aug 2004 23:07:13 +0200 Subject: [Verse-dev] New results about the missing triangles, nodeid reminder In-Reply-To: <41228194.2010205@obsession.se> References: <41210B2C.90201@gmx.de> <4121699F.1030708@obsession.se> <41225659.7000208@gmx.de> <41228194.2010205@obsession.se> Message-ID: <4123C501.4030301@gmx.de> Hi! This may be interesting for Eskil: i have adapted and tested my old and my new geometry pusher, so that they use nodeids as suggested. Now all models seem complete, no triangles are missing. I don't know why i once saw missing triangles with the new server code (the patch that Eskil sent me), it works now. The cause of the difference between missing triangles and complete models lies at the patched file (vs_node_geometry.c). The old one causes missing triangles, the new seems to fix the bug. Thanks so far! But i also noticed that when i let the output print to the console instead of sending it to a file and load up a large mesh (70.000 faces), the server will stop to accept data after a while, the client pushing the data hasn't finished the process and is asleep waiting for an answer of the server. The server will react to another client sending another mesh, but also stop before the mesh is completely uploaded. The viewer receives some data, but shows nothing, which indicates that it only receives vertex data, but not indices. I guess that this problem is caused by a network buffer overflow or something similar. Again a question from an older mail that seems to got lost: Eskil proposed using nodeids -1,-2,-3,... for creating layers. Let's say i create a lot of layers, the numbers get smaller. When is it safe to start again at -1? -- Greetings, Thorsten From verse-dev@blender.org Wed Aug 18 21:53:45 2004 From: verse-dev@blender.org (Thorsten Jordan) Date: Wed, 18 Aug 2004 22:53:45 +0200 Subject: [Verse-dev] Material fragments In-Reply-To: <200408181947.i7IJlCP14727@tessla.levonline.com> References: <200408181947.i7IJlCP14727@tessla.levonline.com> Message-ID: <4123C1D9.5070305@gmx.de> Eskil Steenberg wrote: > Hi > >>one geometry link and one material link for each object node, but >>multiple object links. Sounds simple and ok. > There will be more then one material per geometry node. And it is how it is determined which faces use which material then? This relates to Marcus' question about meshes. It would be a lot simpler, if one geometry node would be just one mesh. > likely that there will only be a key word for the one geometry link > that will be drawn. (you might want to have other keywords for other > geometry's). As i think of it, it may not be a problem to have > multiple geometry's if they have the same material. i don't think > that a one geometry limitation will be very helpful to any one. The only disadvantage is that more object nodes would be needed... the advantage is that it is simple and clear which geometry node uses which material. -- Greetings, Thorsten From verse-dev@blender.org Wed Aug 18 22:57:15 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Wed, 18 Aug 2004 23:57:15 +0200 Subject: [Verse-dev] New results about the missing triangles, nodeid reminder In-Reply-To: <4123C501.4030301@gmx.de> References: <41210B2C.90201@gmx.de> <4121699F.1030708@obsession.se> <41225659.7000208@gmx.de> <41228194.2010205@obsession.se> <4123C501.4030301@gmx.de> Message-ID: <4123D0BB.1030704@obsession.se> Hi > > This may be interesting for Eskil: > i have adapted and tested my old and my new geometry pusher, so that > they use nodeids as suggested. Now all models seem complete, no > triangles are missing. I don't know why i once saw missing triangles > with the new server code (the patch that Eskil sent me), it works now. > > The cause of the difference between missing triangles and complete > models lies at the patched file (vs_node_geometry.c). The old one > causes missing triangles, the new seems to fix the bug. Thanks so far! Thats great news! I know the verse source isnt optimal but then it atleast works. > But i also noticed that when i let the output print to the console > instead of sending it to a file and load up a large mesh (70.000 > faces), the server will stop to accept data after a while, the client > pushing the data hasn't finished the process and is asleep waiting for > an answer of the server. The server will react to another client > sending another mesh, but also stop before the mesh is completely > uploaded. The viewer receives some data, but shows nothing, which > indicates that it only receives vertex data, but not indices. I guess > that this problem is caused by a network buffer overflow or something > similar. Interesting, I know that print outs take up a lot of CPU and slowing things down. so it could be something that has to do with timing. I will look in to it. > > Again a question from an older mail that seems to got lost: > > Eskil proposed using nodeids -1,-2,-3,... for creating layers. > Let's say i create a lot of layers, the numbers get smaller. When is > it safe to start again at -1? > when you have reseved the layers back from the server. Again i will look in to how you can use only -1 in the next release. Cheers E From verse-dev@blender.org Thu Aug 19 09:07:39 2004 From: verse-dev@blender.org (Marcus Hoffmann) Date: Thu, 19 Aug 2004 10:07:39 +0200 Subject: [Verse-dev] [Verse-dev]understanding event collapse In-Reply-To: <41237808.2000405@obsession.se> Message-ID: > >So this is another good example where a change command would be a benefit. > >If you send the first create command and after that a change command may > >looking like that: > > > >verse_send_b_init_dimensions(2, 128, 128, 1); > >verse_send_b_change_dimensions(2, 256, 256, 1); > > > >you would have no problems with overwriting something. If the change command > >arrives before the create command nothing will happen! and then the create > >command arrives and will create a layer. > >Yes - the change is lost, but you won't have wrong data. But what you then > >can think of is a stack that holds the change command for a short time. and > >looks for an arriving create command that contains the layer or node that > >you wish to change...... > > > > > You dont seem to have under stood what the event compression does, > because the event compression as it is right now deals with this so that > you do get the right data, and that data arrives securely, with no > look-ups.and you dont always have to wait for re-sends. (anything else > is a bug in the implementation) This was not about event compression and the handling in verse but about the server implementation. Maybe i did use this example in the wrong context. ;) What your event compression does (verse internally) is not in my interest. I don't have to see it and i don't have to care about it, just the result is interesting for me. What i wanted to explain is, that if the server - or a client - would get two different commands for create and for change, it would be much clearer to implement. If you use the creation command for creating and for changing then every one has to decide every time is it creation or change. This decision would get lost if we had two different commands. Thats what all this discussion was about. And to the example above: What i wanted to say with that is: If a change command (with a real verse change command and not a create) would arrive and i don't find anything relating to change, nothing would happen. Thats it. Don't you thing that is much clearer, that a change can only happen if a relating node/layer/element was created before? Anyway... the problem still remains that events can go out from a client and arrive at the server in changed order. But i don't think that is that critical, because a user will rarely send two change commands or a create and a relating change in a short time (i'm talking about milliseconds). greets M From verse-dev@blender.org Thu Aug 19 12:48:25 2004 From: verse-dev@blender.org (Thorsten Jordan) Date: Thu, 19 Aug 2004 13:48:25 +0200 Subject: [Verse-dev] New results about the missing triangles, nodeid reminder In-Reply-To: <4123D0BB.1030704@obsession.se> References: <41210B2C.90201@gmx.de> <4121699F.1030708@obsession.se> <41225659.7000208@gmx.de> <41228194.2010205@obsession.se> <4123C501.4030301@gmx.de> <4123D0BB.1030704@obsession.se> Message-ID: <41249389.6040903@gmx.de> Eskil Steenberg wrote: > Hi > >> But i also noticed that when i let the output print to the console [...] > Interesting, I know that print outs take up a lot of CPU and slowing > things down. so it could be something that has to do with timing. I will > look in to it. yes, i also suppose that waiting for the output (which takes longer for the console) is the reason for this behaviour. >> Eskil proposed using nodeids -1,-2,-3,... for creating layers. >> Let's say i create a lot of layers, the numbers get smaller. When is >> it safe to start again at -1? >> > when you have reseved the layers back from the server. to be a bit more precise: can i use -1 after i have received *the* layer that was created with a send command using ID -1, or after i have received all layers, that i have created in one batch from -1 downwards? > Again i will look in to how you can use only -1 in the next release. that would be a great help. -- Greetings, Thorsten From verse-dev@blender.org Thu Aug 19 17:49:10 2004 From: verse-dev@blender.org (Eskil Steenberg) Date: Thu, 19 Aug 2004 18:49:10 +0200 Subject: [Verse-dev] [Verse-dev]understanding event collapse In-Reply-To: References: Message-ID: <4124DA06.3040003@obsession.se> Hi >This was not about event compression and the handling in verse but about the >server implementation. Maybe i did use this example in the wrong context. ;) >What your event compression does (verse internally) is not in my interest. I >don't have to see it and i don't have to care about it, just the result is >interesting for me. > > obviusly not, since you are trying to change how verse not a specific server works. >What i wanted to explain is, that if the server - or a client - would get >two different commands for create and for change, it would be much clearer >to implement. If you use the creation command for creating and for changing >then every one has to decide every time is it creation or change. >This decision would get lost if we had two different commands. >Thats what all this discussion was about. > > > If you would have read and understood my text about event compression, you would know this is impossible. I dont agree that it would make either server or client implementation any easier even if it would work (something that it wouldent so thats really hypteticaly speaking) If you still dont want to give it up, write me two callbacks for a verse call and show me how it would be easier. >Anyway... the problem still remains that events can go out from a client and >arrive at the server in changed order. But i don't think that is that >critical, because a user will rarely send two change commands or a create >and a relating change in a short time (i'm talking about milliseconds). > > How about dragging a vertex? or a player movement in a game? assuming that millisecond changes doesnt matter is not really what i would call low latency protocol. E From eskil at obsession.se Mon Aug 23 09:11:32 2004 From: eskil at obsession.se (Eskil Steenberg) Date: Mon Aug 23 09:06:11 2004 Subject: [Verse-dev] TEST In-Reply-To: <4124DA06.3040003@obsession.se> References: <4124DA06.3040003@obsession.se> Message-ID: <412998A4.50204@obsession.se> Hi Some people hard problems joining the mailing list so im just sending out a main to see that the list is still alive. E From Thorsten_Jordan at gmx.de Mon Aug 23 12:31:46 2004 From: Thorsten_Jordan at gmx.de (Thorsten Jordan) Date: Mon Aug 23 12:31:25 2004 Subject: [Verse-dev] Problem with links Message-ID: <4129C792.80805@gmx.de> Hi! My pusher app uses links to connect the nodes. The problem is that the print-function of verse shows that all links are send from the pusher, but not all are received by the server! Both are on localhost, so this can't be caused by lost UDP packets... Attached is the output of my pusher, the verse server output, and the pusher code. It seems like using link_ids from 0xfffe rather than 0xffff downwards leads to a different set of links sent - but not all are received by the server. Any hints? Thanks! -- Greetings, Thorsten -------------- next part -------------- A non-text attachment was scrubbed... Name: push_3ds.cpp Type: text/x-c++src Size: 16199 bytes Desc: not available Url : http://projects.blender.org/mailman/private/verse-dev/attachments/20040823/76cc7a00/push_3ds-0001.cpp -------------- next part -------------- [nothing about links here, 2500 lines erased] receive: verse_send_o_link_set(node_id = 6 link_id = 65533 link = 5 name = (sub)object? target_id = 0 ); callback = 0x80525a4 send: verse_send_o_link_set(node_id = 6 link_id = 0 link = 5 name = (sub)object? target_id = 0 ); receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 42 tile_y = 5 z = 0 type = 1 ); callback = 0x804a7f3 send: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 42 tile_y = 5 z = 0 type = 1 tile = 0xbffff130 ); receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 410 v0 = 219 v1 = 240 v2 = 220 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 28 tile_y = 14 z = 0 type = 1 ); callback = 0x804a7f3 send: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 28 tile_y = 14 z = 0 type = 1 tile = 0xbffff130 ); receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 451 v0 = 243 v1 = 313 v2 = 264 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 32 v0 = 5 v1 = 1 v2 = 7 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 492 v0 = 259 v1 = 286 v2 = 260 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 73 v0 = 515 v1 = 45 v2 = 44 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 114 v0 = 80 v1 = 88 v2 = 89 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_o_link_set(node_id = 5 link_id = 65534 link = 3 name = material? target_id = 0 ); callback = 0x80525a4 send: verse_send_o_link_set(node_id = 5 link_id = 0 link = 3 name = material? target_id = 0 ); receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 155 v0 = 85 v1 = 124 v2 = 125 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_m_fragment_create(node_id = 3 frag_id = 65535 type = 12 ); callback = 0x80511eb send: verse_send_m_fragment_create(node_id = 3 frag_id = 10 type = 12 fragment = 0xbfffebb0 ); receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 196 v0 = 109 v1 = 143 v2 = 144 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 237 v0 = 130 v1 = 163 v2 = 131 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 1053 v0 = 528 v1 = 495 v2 = 523 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_vertex_set_real32_xyz(node_id = 4 layer_id = 0 vertex_id = 543 x = 0.412733 y = 58.472328 z = 5.000003 ); callback = 0x804dba4 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 1094 v0 = 32 v1 = 429 v2 = 553 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_vertex_set_real32_xyz(node_id = 4 layer_id = 0 vertex_id = 584 x = -0.050011 y = -74.939079 z = 6.782952 ); callback = 0x804dba4 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 1135 v0 = 564 v1 = 547 v2 = 546 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_vertex_set_real32_xyz(node_id = 4 layer_id = 0 vertex_id = 625 x = -1.055498 y = 59.238373 z = 6.933333 ); callback = 0x804dba4 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 1176 v0 = 578 v1 = 588 v2 = 593 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_vertex_set_real32_xyz(node_id = 4 layer_id = 0 vertex_id = 666 x = 16.500004 y = 27.499998 z = 19.999998 ); callback = 0x804dba4 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 1217 v0 = 619 v1 = 620 v2 = 624 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 798 v0 = 447 v1 = 448 v2 = 395 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 1258 v0 = 634 v1 = 632 v2 = 635 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 839 v0 = 17 v1 = 416 v2 = 415 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 46 tile_y = 3 z = 0 type = 1 ); callback = 0x804a7f3 send: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 46 tile_y = 3 z = 0 type = 1 tile = 0xbffff130 ); receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 880 v0 = 41 v1 = 40 v2 = 436 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 32 tile_y = 12 z = 0 type = 1 ); callback = 0x804a7f3 send: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 32 tile_y = 12 z = 0 type = 1 tile = 0xbffff130 ); receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 921 v0 = 64 v1 = 576 v2 = 575 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 43 tile_y = 5 z = 0 type = 1 ); callback = 0x804a7f3 send: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 43 tile_y = 5 z = 0 type = 1 tile = 0xbffff130 ); receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 962 v0 = 467 v1 = 466 v2 = 76 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 29 tile_y = 14 z = 0 type = 1 ); callback = 0x804a7f3 send: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 29 tile_y = 14 z = 0 type = 1 tile = 0xbffff130 ); receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 543 v0 = 285 v1 = 310 v2 = 311 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 1003 v0 = 520 v1 = 496 v2 = 53 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 40 tile_y = 7 z = 0 type = 1 ); callback = 0x804a7f3 send: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 40 tile_y = 7 z = 0 type = 1 tile = 0xbffff130 ); receive: verse_send_g_vertex_set_real32_xyz(node_id = 4 layer_id = 0 vertex_id = 493 x = -8.999996 y = 27.500002 z = 8.400000 ); callback = 0x804dba4 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 584 v0 = 303 v1 = 326 v2 = 327 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 51 tile_y = 0 z = 0 type = 1 ); callback = 0x804a7f3 send: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 51 tile_y = 0 z = 0 type = 1 tile = 0xbffff130 ); receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 625 v0 = 356 v1 = 378 v2 = 367 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 37 tile_y = 9 z = 0 type = 1 ); callback = 0x804a7f3 send: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 37 tile_y = 9 z = 0 type = 1 tile = 0xbffff130 ); receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 666 v0 = 336 v1 = 371 v2 = 351 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 48 tile_y = 2 z = 0 type = 1 ); callback = 0x804a7f3 send: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 48 tile_y = 2 z = 0 type = 1 tile = 0xbffff130 ); receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 707 v0 = 358 v1 = 398 v2 = 399 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 288 v0 = 156 v1 = 185 v2 = 186 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 748 v0 = 350 v1 = 402 v2 = 403 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 45 tile_y = 4 z = 0 type = 1 ); callback = 0x804a7f3 send: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 45 tile_y = 4 z = 0 type = 1 tile = 0xbffff130 ); receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 329 v0 = 179 v1 = 204 v2 = 180 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 31 tile_y = 13 z = 0 type = 1 ); callback = 0x804a7f3 send: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 31 tile_y = 13 z = 0 type = 1 tile = 0xbffff130 ); receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 370 v0 = 201 v1 = 220 v2 = 202 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 42 tile_y = 6 z = 0 type = 1 ); callback = 0x804a7f3 send: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 42 tile_y = 6 z = 0 type = 1 tile = 0xbffff130 ); receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 411 v0 = 220 v1 = 240 v2 = 221 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 28 tile_y = 15 z = 0 type = 1 ); callback = 0x804a7f3 send: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 28 tile_y = 15 z = 0 type = 1 tile = 0xbffff130 ); receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 452 v0 = 244 v1 = 264 v2 = 265 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 33 v0 = 9 v1 = 79 v2 = 502 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 493 v0 = 262 v1 = 337 v2 = 223 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 74 v0 = 43 v1 = 514 v2 = 44 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 115 v0 = 80 v1 = 89 v2 = 90 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 156 v0 = 85 v1 = 125 v2 = 86 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 197 v0 = 109 v1 = 144 v2 = 110 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 238 v0 = 131 v1 = 163 v2 = 164 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 1054 v0 = 502 v1 = 528 v2 = 503 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_vertex_set_real32_xyz(node_id = 4 layer_id = 0 vertex_id = 544 x = 1.516137 y = 57.546455 z = 5.000003 ); callback = 0x804dba4 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 1095 v0 = 555 v1 = 428 v2 = 556 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_vertex_set_real32_xyz(node_id = 4 layer_id = 0 vertex_id = 585 x = -0.000011 y = -74.924042 z = 6.868239 ); callback = 0x804dba4 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 1136 v0 = 563 v1 = 555 v2 = 556 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_vertex_set_real32_xyz(node_id = 4 layer_id = 0 vertex_id = 626 x = -0.412711 y = 58.472328 z = 5.933333 ); callback = 0x804dba4 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 1177 v0 = 578 v1 = 581 v2 = 588 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_vertex_set_real32_xyz(node_id = 4 layer_id = 0 vertex_id = 667 x = 16.500004 y = 28.499996 z = 14.999999 ); callback = 0x804dba4 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 1218 v0 = 619 v1 = 624 v2 = 623 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 799 v0 = 449 v1 = 450 v2 = 396 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 1259 v0 = 633 v1 = 635 v2 = 632 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 840 v0 = 17 v1 = 19 v2 = 416 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 46 tile_y = 4 z = 0 type = 1 ); callback = 0x804a7f3 send: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 46 tile_y = 4 z = 0 type = 1 tile = 0xbffff130 ); receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 881 v0 = 436 v1 = 435 v2 = 41 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 32 tile_y = 13 z = 0 type = 1 ); callback = 0x804a7f3 send: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 32 tile_y = 13 z = 0 type = 1 tile = 0xbffff130 ); receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 922 v0 = 575 v1 = 63 v2 = 64 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 43 tile_y = 6 z = 0 type = 1 ); callback = 0x804a7f3 send: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 43 tile_y = 6 z = 0 type = 1 tile = 0xbffff130 ); receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 963 v0 = 76 v1 = 466 v2 = 74 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 29 tile_y = 15 z = 0 type = 1 ); callback = 0x804a7f3 send: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 29 tile_y = 15 z = 0 type = 1 tile = 0xbffff130 ); receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 544 v0 = 285 v1 = 311 v2 = 312 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 1004 v0 = 54 v1 = 53 v2 = 496 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 40 tile_y = 8 z = 0 type = 1 ); callback = 0x804a7f3 send: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 40 tile_y = 8 z = 0 type = 1 tile = 0xbffff130 ); receive: verse_send_g_vertex_set_real32_xyz(node_id = 4 layer_id = 0 vertex_id = 494 x = -7.041420 y = 51.002869 z = 8.400000 ); callback = 0x804dba4 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 585 v0 = 303 v1 = 327 v2 = 304 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 51 tile_y = 1 z = 0 type = 1 ); callback = 0x804a7f3 send: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 51 tile_y = 1 z = 0 type = 1 tile = 0xbffff130 ); receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 626 v0 = 345 v1 = 346 v2 = 301 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 37 tile_y = 10 z = 0 type = 1 ); callback = 0x804a7f3 send: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 37 tile_y = 10 z = 0 type = 1 tile = 0xbffff130 ); receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 667 v0 = 380 v1 = 373 v2 = 337 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 48 tile_y = 3 z = 0 type = 1 ); callback = 0x804a7f3 send: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 48 tile_y = 3 z = 0 type = 1 tile = 0xbffff130 ); receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 708 v0 = 358 v1 = 399 v2 = 347 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 34 tile_y = 12 z = 0 type = 1 ); callback = 0x804a7f3 send: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 34 tile_y = 12 z = 0 type = 1 tile = 0xbffff130 ); receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 289 v0 = 156 v1 = 186 v2 = 157 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 749 v0 = 350 v1 = 403 v2 = 369 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 45 tile_y = 5 z = 0 type = 1 ); callback = 0x804a7f3 send: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 45 tile_y = 5 z = 0 type = 1 tile = 0xbffff130 ); receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 330 v0 = 180 v1 = 204 v2 = 181 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 31 tile_y = 14 z = 0 type = 1 ); callback = 0x804a7f3 send: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 31 tile_y = 14 z = 0 type = 1 tile = 0xbffff130 ); receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 371 v0 = 202 v1 = 220 v2 = 203 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 412 v0 = 221 v1 = 240 v2 = 241 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 53 tile_y = 0 z = 0 type = 1 ); callback = 0x804a7f3 send: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 53 tile_y = 0 z = 0 type = 1 tile = 0xbffff130 ); receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 453 v0 = 244 v1 = 265 v2 = 245 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 34 v0 = 502 v1 = 503 v2 = 9 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 494 v0 = 262 v1 = 380 v2 = 337 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 75 v0 = 517 v1 = 47 v2 = 516 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 116 v0 = 80 v1 = 90 v2 = 91 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 157 v0 = 86 v1 = 125 v2 = 126 v3 = 4294967295 ); callback = 0x804ea42 receive: verse_send_g_polygon_set_corner_uint32(node_id = 4 layer_id = 1 polygon_id = 198 v0 = 110 v1 = 144 v2 = 145 v3 = 4294967295 ); callback = 0x804ea42 [cut here, no more link commands follow] -------------- next part -------------- send: verse_send_o_link_set(node_id = 5 link_id = 65535 link = 4 name = geometry? target_id = 0 ); send: verse_send_o_link_set(node_id = 5 link_id = 65534 link = 3 name = material? target_id = 0 ); send: verse_send_o_link_set(node_id = 6 link_id = 65533 link = 5 name = (sub)object? target_id = 0 ); receive: verse_send_g_layer_create(node_id = 4 layer_id = 1 name = polygon type = 128 def_uint = 0 def_real = 0.000000 ); callback = 0x80553aa receive: verse_send_b_layer_create(node_id = 2 layer_id = 2 name = col_r type = 1 ); callback = 0x8055748 send: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 0 tile_y = 0 z = 0 type = 1 tile = 0xbfffef50 ); [...] several thousand lines here, nothing about links receive: verse_send_o_link_set(node_id = 5 link_id = 0 link = 3 name = material? target_id = 0 ); callback = (nil) receive: verse_send_o_link_set(node_id = 6 link_id = 0 link = 5 name = (sub)object? target_id = 0 ); callback = (nil) receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 37 tile_y = 12 z = 0 type = 1 ); callback = (nil) receive: verse_send_b_layer_set_tile(node_id = 2 layer_id = 2 tile_x = 48 tile_y = 5 z = 0 type = 1 ); callback = (nil) [cut here, no more link commands follow] From cwant at ualberta.ca Mon Aug 23 14:24:13 2004 From: cwant at ualberta.ca (Chris Want) Date: Mon Aug 23 14:24:16 2004 Subject: [Verse-dev] TEST In-Reply-To: <412998A4.50204@obsession.se> References: <4124DA06.3040003@obsession.se> <412998A4.50204@obsession.se> Message-ID: <4129E1ED.9030901@ualberta.ca> Hi Eskil, Please note that the main webpage for the list has changed (moved from server www.blender.org to projects.blender.org). The new mailing list URL is below. Regards, Chris Eskil Steenberg wrote: > Hi > > Some people hard problems joining the mailing list so im just sending > out a main to see that the list is still alive. > > E > _______________________________________________ > Verse-dev mailing list > Verse-dev@projects.blender.org > http://projects.blender.org/mailman/listinfo/verse-dev > From ton at blender.org Mon Aug 23 14:38:11 2004 From: ton at blender.org (Ton Roosendaal) Date: Mon Aug 23 14:37:59 2004 Subject: [Verse-dev] TEST In-Reply-To: <4129E1ED.9030901@ualberta.ca> Message-ID: <4B33A201-F501-11D8-A49B-0030654FA84A@blender.org> Hi Chris, Good you note this; I will change links on the uni-verse.org site now. Eskil/Emil; can you take care of the blender.org verse pages? Thanks, -Ton- On Monday, Aug 23, 2004, at 14:24 Europe/Amsterdam, Chris Want wrote: > > Hi Eskil, > > Please note that the main webpage for the list > has changed (moved from server www.blender.org > to projects.blender.org). The new mailing list > URL is below. > > Regards, > Chris > > Eskil Steenberg wrote: >> Hi >> Some people hard problems joining the mailing list so im just sending >> out a main to see that the list is still alive. >> E >> _______________________________________________ >> Verse-dev mailing list >> Verse-dev@projects.blender.org >> http://projects.blender.org/mailman/listinfo/verse-dev > > _______________________________________________ > Verse-dev mailing list > Verse-dev@projects.blender.org > http://projects.blender.org/mailman/listinfo/verse-dev > > ------------------------------------------------------------------------ -- Ton Roosendaal Blender Foundation ton@blender.org http://www.blender.org From emil at obsession.se Mon Aug 23 15:54:46 2004 From: emil at obsession.se (Emil Brink) Date: Mon Aug 23 15:54:39 2004 Subject: [Verse-dev] TEST In-Reply-To: <4B33A201-F501-11D8-A49B-0030654FA84A@blender.org> References: <4129E1ED.9030901@ualberta.ca> <4B33A201-F501-11D8-A49B-0030654FA84A@blender.org> Message-ID: <20040823155446.46cbacd2@treebeard> On Mon, 23 Aug 2004 14:38:11 +0200 Ton Roosendaal wrote: > Hi Chris, > > Good you note this; I will change links on the uni-verse.org site now. > Eskil/Emil; can you take care of the blender.org verse pages? Done, I hope. /Emil From Thorsten_Jordan at gmx.de Mon Aug 23 15:31:23 2004 From: Thorsten_Jordan at gmx.de (Thorsten Jordan) Date: Mon Aug 23 16:41:41 2004 Subject: [Verse-dev] connect terminate kills last sent data? In-Reply-To: <4B33A201-F501-11D8-A49B-0030654FA84A@blender.org> References: <4B33A201-F501-11D8-A49B-0030654FA84A@blender.org> Message-ID: <4129F1AB.4040000@gmx.de> Hi, i noticed the following behaviour: my pusher sends all data to the verse server. I added a function that detects when all data is sent and quits the pusher then, calling a verse_send_connect_terminate before exiting the program. The last data was bitmap tile data. When i quit the pusher BEFORE it received (!) its own set_tile commands, the data is lost, in other words, just sending all data and calling connect_terminate seems to kill parts of the data. There is just one bitmap in the scene and only one of the layers is partly transmitted, the rest of the layer and the other layers are missing. Just waiting for all tiles to be received again and exiting only then helps. Well, this is not really a problem for me, but i'm curious if data transmission should be like that way? -- Greetings, Thorsten From Thorsten_Jordan at gmx.de Mon Aug 23 16:42:58 2004 From: Thorsten_Jordan at gmx.de (Thorsten Jordan) Date: Mon Aug 23 16:41:46 2004 Subject: [Verse-dev] Next mysterious thing In-Reply-To: <4B33A201-F501-11D8-A49B-0030654FA84A@blender.org> References: <4B33A201-F501-11D8-A49B-0030654FA84A@blender.org> Message-ID: <412A0272.2060508@gmx.de> Hi again, more explorations ;-) I send a model to the server that has 700 vertices. When receiving it, the server sends 716 vertices, the last 16 are zero. Another model has 403 vertices, received are 422. Why that? -- Greetings, Thorsten From eskil at obsession.se Mon Aug 23 16:52:28 2004 From: eskil at obsession.se (Eskil Steenberg) Date: Mon Aug 23 16:47:11 2004 Subject: [Verse-dev] Problem with links In-Reply-To: <4129C792.80805@gmx.de> References: <4129C792.80805@gmx.de> Message-ID: <412A04AC.7080909@obsession.se> Hi > My pusher app uses links to connect the nodes. The problem is that the > print-function of verse shows that all links are send from the pusher, > but not all are received by the server! Both are on localhost, so this > can't be caused by lost UDP packets... > Attached is the output of my pusher, the verse server output, and the > pusher code. > It seems like using link_ids from 0xfffe rather than 0xffff downwards > leads to a different set of links sent - but not all are received by > the server. Any hints? Thanks! > I cant find anything wrong immediately, It looks like the problem is mine rather then yours. I will look in to it further. E From eskil at obsession.se Mon Aug 23 16:57:17 2004 From: eskil at obsession.se (Eskil Steenberg) Date: Mon Aug 23 16:51:56 2004 Subject: [Verse-dev] Next mysterious thing In-Reply-To: <412A0272.2060508@gmx.de> References: <4B33A201-F501-11D8-A49B-0030654FA84A@blender.org> <412A0272.2060508@gmx.de> Message-ID: <412A05CD.20501@obsession.se> Hi > more explorations ;-) > I send a model to the server that has 700 vertices. > When receiving it, the server sends 716 vertices, the last 16 are zero. > Another model has 403 vertices, received are 422. > Why that? > Bug. line 413 in vs_node_geometry.c is ((double *)node->layer[i].layer)[j] = 0; but should be ((double *)node->layer[i].layer)[j] = V_REAL64_MAX; E From eskil at obsession.se Tue Aug 24 10:01:10 2004 From: eskil at obsession.se (Eskil Steenberg) Date: Tue Aug 24 09:55:51 2004 Subject: [Verse-dev] Next mysterious thing In-Reply-To: <412A05CD.20501@obsession.se> References: <4B33A201-F501-11D8-A49B-0030654FA84A@blender.org> <412A0272.2060508@gmx.de> <412A05CD.20501@obsession.se> Message-ID: <412AF5C6.9030405@obsession.se> Hi Emil just uploaded my new zip with new versions of my apps. Most notably the UV editor has gotten some attention and should now be very useful. There are still some features that i would like to add but for now this can be considered done. Here is my UV change log for the past week: Main fixes/changes + Added Multiple Undo + Added Multiple Redo + Fixed drag bug + Fixed selection bug + Only auto uv when new UV channels are created + Overlay for poly and edge selects. + Modulated anim speed for different tools. + got Poly, Manip, corner edge, and empty popup menu working. + Added snapping to image corners. + selected Transforms doesnt snap to them selfs. + Hides/ shows manipulator properly. + Supports vertex selection from other apps such as Loq Airou + Fixed Unfold of back facing surfaces. + Fixed alternative front, side and top projection. New tools: + Edge drag + Corner collapse + Cornet select + Rotate polygon to Straighten Edge + Rotate selection to Straighten Edge + Polygon square + Polygon rectangle + Select by normal + Select by plane + poly normal projection + Flip X + Flip Y + Fit selection in image + Split Edge collapse + Strip horizontal + Strip vertical + Edge Select Im now moving over to verse R4. If you find any bugs please mail me. Cheers E From emil at obsession.se Wed Aug 25 10:25:53 2004 From: emil at obsession.se (Emil Brink) Date: Wed Aug 25 10:25:50 2004 Subject: [Verse-dev] Spec updated Message-ID: <20040825102553.04a8f6c7@treebeard> Hello. Just wanted to announce that I uploaded a new slightly improved version of the Verse specification. As usual, the location of the root page is . The changes are mainly due to feedback from Eskil, and include: - Dataset sentence in intro was made into bulleted list, it was more or less unreadable (it came from Eskil's PDF, heh). - Sentence about particles in intro was removed, particles are not yet implemented. - Mention of "matrix" in the object transform context was removed, so as not to confuse people. There is no actual *matrix* there, it's split into components. - Created image for the missing transform equation. - Removed text about "missing" light types. - Added initial text about area lights. - Give the numerical IDs for geometry node base layers (0 and 1). - Explain crease mapping (0: smooth, MAX_UINT32: sharp/hard). - Add missing enum tables for ramp and noise fragments. - Mention that materials are to be evaluated for each surface point. - Added a section about standard material output fragment types. - Explain displacement definition. - Explain bitmap coordinate systems, with new figure showing axis. - Treat bitmaps as basically 3D, with 2D and 1D as exceptions. - Limit how 2D and 1D bitmaps can be created (not yet implemented, but coming soon). - Mention that bitmaps can be filtered. These are not all of the issues I have, but I don't want to get all dogged down with the spec now. I will do further revisions soon, I need to get back to Purple now. Regards, /Emil From eskil at obsession.se Wed Aug 25 11:34:47 2004 From: eskil at obsession.se (Eskil Steenberg) Date: Wed Aug 25 11:29:33 2004 Subject: [Verse-dev] Spec updated In-Reply-To: <20040825102553.04a8f6c7@treebeard> References: <20040825102553.04a8f6c7@treebeard> Message-ID: <412C5D37.4050204@obsession.se> Hi >The changes are mainly due to feedback from Eskil, and include: > > Yes, Several people on this list referred to the spec and it dawned on me that i had not yet read the new and improved spec. As you can see from Emils list I found mostly minor things. But there was one larger issue. Right now the Spec is divided in to three parts, Data, Protocol and API. Although there are good reasons to keep them separate, it brigs us a lot of issues too. Right now there are no links between the data description and the functions that are used to manipulate the data. I also think we need a larger introduction that describes the general concepts of verse more in depth. However both Emil and I concluded that we have too much to do right now so it will have to wait for a while. We are also thinking about revamping the homepage. So why am I so busy? verse R4 I started last night and threw the night i have gotten trough most of the easy stuff. + The VMatFrag union now makes use of enum types rather then uint8 + "type" in the output fragment has been renamed "label" + link name also called "label" (but whats a better name then "target_id"?) + milliseconds are now microseconds (finally....) + bones now have "weight" and "reference". + tag fragment removed + added support for stored data + "create" commands set to -1 no longer collapse (that one took some work) + Users can no longer subscribe to a data set twice. (possible server exploit) + commented out "V_NT_PARTICLE" There are other things that im going to fix like new animation events, timing, a language string for every text buffer, a anim fragment and a sub surface fragment. I want to change the "verse_send_node_create" command to have a "yours" parameter rather then a "owner". But verse doesnt (internaly) have a boolean, i could add it or i could use an enum. Then we could have more flags then just "yours" can any one think of a good use? Are there other things that i might have missed? Right now Im re writing the main code for handling in and out going packets, its a big re write that wont change the api but will hope fully give us better performance in the end (and cleaner code). E Btw, in the spec the text about the refraction parameter notes that this one is very hard to implement, something that isnt true if you are doing a ray tracer. From Thorsten_Jordan at gmx.de Wed Aug 25 18:46:11 2004 From: Thorsten_Jordan at gmx.de (Thorsten Jordan) Date: Wed Aug 25 18:43:19 2004 Subject: [Verse-dev] Spec updated In-Reply-To: <412C5D37.4050204@obsession.se> References: <20040825102553.04a8f6c7@treebeard> <412C5D37.4050204@obsession.se> Message-ID: <412CC253.3090808@gmx.de> Eskil Steenberg wrote: > Hi > > Are there other things that i might have missed? my links-problem ;-) The server seems to lose some link_set commands... and: How many geometry nodes can be linked per object node and how many material nodes and how they are bound? -- Greetings, Thorsten From ingiebee at hotmail.com Wed Aug 25 23:35:08 2004 From: ingiebee at hotmail.com (Ingie Bee) Date: Wed Aug 25 23:39:40 2004 Subject: [Verse-dev] Blender as a client Message-ID: An HTML attachment was scrubbed... URL: http://projects.blender.org/mailman/private/verse-dev/attachments/20040825/1bb3432e/attachment.html From eskil at obsession.se Fri Aug 27 04:54:37 2004 From: eskil at obsession.se (Eskil Steenberg) Date: Fri Aug 27 04:49:22 2004 Subject: [Verse-dev] Blender as a client In-Reply-To: References: Message-ID: <412EA26D.1040903@obsession.se> Hi > How difficult would it be to retain the look and feel of Blender while > giving it the ability to communicate with other similar/different > clients through Verse? It should be fairly easy, Ton has indicated that he would puch for such a development but i dont know when. Cheers E From Marcus.Hoffmann at igd.fhg.de Fri Aug 27 11:03:07 2004 From: Marcus.Hoffmann at igd.fhg.de (Marcus Hoffmann) Date: Fri Aug 27 11:03:12 2004 Subject: [Verse-dev] Connector Message-ID: Hi Eskil, A little problem with the create/change thing... I use the connector to test my server. If i connect first time i start with ID 0 for the avatar object node, build it and return it. So now i integrated the case, that the create command could be a change command. Everytime a create command arrives i test if the given id from verse is existing in my id list. If so i realize it must be a change, if not its a true create. So the problem i've run into is, that connector EVERY TIME sends id 0 with create. But ID 0 is given to the first object node when the first client connects meaning this ID is in already use and so the server decides this must be a change command! For other node types i could make a lookup if the node type is the same etc. but for the object node connector everytime sends ID 0 - with the same owner and the same nodetype. So what to do? greets M Marcus Hoffmann Dipl. Ing. f?r Medientechnologie Fraunhofer Institut f?r Graphische Datenverarbeitung (IGD) Abt. Animation und Bildkommunikation (A3) Fraunhoferstr. 5 D-64283 Darmstadt Fon: +49 (0)6151 / 155-639 Mail: marcus.hoffmann@igd.fhg.de From eskil at obsession.se Fri Aug 27 14:06:03 2004 From: eskil at obsession.se (Eskil Steenberg) Date: Fri Aug 27 14:00:52 2004 Subject: [Verse-dev] Connector In-Reply-To: References: Message-ID: <412F23AB.6000402@obsession.se> Hi >A little problem with the create/change thing... >I use the connector to test my server. If i connect first time i start with >ID 0 for the avatar object node, build it and return it. >So now i integrated the case, that the create command could be a change >command. Everytime a create command arrives i test if the given id from >verse is existing in my id list. If so i realize it must be a change, if not >its a true create. >So the problem i've run into is, that connector EVERY TIME sends id 0 with >create. But ID 0 is given to the first object node when the first client >connects meaning this ID is in already use and so the server decides this >must be a change command! For other node types i could make a lookup if the >node type is the same etc. but for the object node connector everytime sends >ID 0 - with the same owner and the same nodetype. So what to do? > > The problem is that the Connector you are using was written for Release 3 and in release 3 node id zero is reserved. In release 4 it will change and node id 0 will no longer be reserved. But then again R4 is not yet final. So either you change your server to reserve id 0 for now, or you you port Connector a bit closer to R4 by changing line 495 in co_vn_handle.c from verse_send_node_create(0, type, 0); to: verse_send_node_create(-1, type, 0); Obviously i will port Connector and all my other apps for R4 by the time it is out. Cheers E From Marcus.Hoffmann at igd.fhg.de Fri Aug 27 14:37:44 2004 From: Marcus.Hoffmann at igd.fhg.de (Marcus Hoffmann) Date: Fri Aug 27 14:37:50 2004 Subject: [Verse-dev] Connector In-Reply-To: <412F23AB.6000402@obsession.se> Message-ID: Ok i will change connector for now... thats easier than the change that all arrays start with 1 instead 0... greets M > -----Original Message----- > From: verse-dev-bounces@projects.blender.org > [mailto:verse-dev-bounces@projects.blender.org]On Behalf Of Eskil > Steenberg > Sent: Friday, August 27, 2004 2:06 PM > To: verse-dev@projects.blender.org > Subject: Re: [Verse-dev] Connector > > > Hi > > >A little problem with the create/change thing... > >I use the connector to test my server. If i connect first time i > start with > >ID 0 for the avatar object node, build it and return it. > >So now i integrated the case, that the create command could be a change > >command. Everytime a create command arrives i test if the given id from > >verse is existing in my id list. If so i realize it must be a > change, if not > >its a true create. > >So the problem i've run into is, that connector EVERY TIME sends > id 0 with > >create. But ID 0 is given to the first object node when the first client > >connects meaning this ID is in already use and so the server decides this > >must be a change command! For other node types i could make a > lookup if the > >node type is the same etc. but for the object node connector > everytime sends > >ID 0 - with the same owner and the same nodetype. So what to do? > > > > > The problem is that the Connector you are using was written for Release > 3 and in release 3 node id zero is reserved. In release 4 it will change > and node id 0 will no longer be reserved. But then again R4 is not yet > final. > > So either you change your server to reserve id 0 for now, or you you > port Connector a bit closer to R4 by changing line 495 in co_vn_handle.c > from > verse_send_node_create(0, type, 0); > to: > verse_send_node_create(-1, type, 0); > > Obviously i will port Connector and all my other apps for R4 by the time > it is out. > > Cheers > > E > > _______________________________________________ > Verse-dev mailing list > Verse-dev@projects.blender.org > http://projects.blender.org/mailman/listinfo/verse-dev > From ingiebee at hotmail.com Fri Aug 27 16:52:37 2004 From: ingiebee at hotmail.com (Ingie Bee) Date: Fri Aug 27 16:52:45 2004 Subject: [Verse-dev] Blender as a client Message-ID: An HTML attachment was scrubbed... URL: http://projects.blender.org/mailman/private/verse-dev/attachments/20040827/03699310/attachment.htm