[vos-d] How databases hurt scalability
http://www.pbs.org/cringely/pulpit/2008/pulpit_20081003_005424.html ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Sorry, need another test message
Just want to make sure the list still works after changing something... Reed -- http://interreality.org/~reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Rough graphs of #vos channel activity
Oops, just noticed that the days of the week are out of order. Should fix that I guess. But there's an interesting upward trend toward the middle of the week, then it goes down to drop off on Saturday. ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] babies
Interesting coincidence! Congratulations to you too! Reed Braden McDaniel wrote: On Wed, 2008-07-30 at 11:51 -0400, Reed Hedges wrote: I have a new top priority project that must compete with VOS -- Zephan Isaac was born on Friday at 7:30 PM! Though so far he's been great and we're well rested (so far) and on top of the world. More photos and news will be on my web site and on flickr in the upcoming weeks. Congratulations, Reed! My own competing project--Dylan Jesse--started a couple of weeks ago. Here's a picture from Day 2. Some more recent ones (and some previous ones) are here: http://www.kodakgallery.com/I.jsp?c=40tmq9nh.6uo36zg5x=0h=1y=bnzfdnlocaleid=en_US We're well into sleep deprivation at this point; but enjoying him immensely. ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d -- http://interreality.org/~reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Web Site
Am thinking of switching over to the new website I was working on earlier (http://interreality.org:4088), but without the half-assed background image. Would be nice to create a nicer one but don't have time. I'll also do an editing and clarity pass to try to improve whatever wording I can, and fix up the layout and Javascript issues. I do think I'm just going to dump everything to a Wiki, either the current Moin, or migrate to MediaWiki or something else. It was great to eat our own dogfood by using VOS for the website, and it triggered some useful features and fixies, but that S4 dogfood is pretty stale by now! If we get further along in S5 and reimplement hypervos or something hypervos-like using it we can move the site back into that (and having available what the wiki gives us will be a good features goal). I'll include the current wiki pages but not really link them to the main site except selectively, to avoid linking in too much confusing info... maybe have an s4 category that collects all the potentially out of date info, and seperate out ideas from current info. Reed -- http://interreality.org/~reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Web Site
On Mon, Jun 30, 2008 at 01:47:35PM -0400, Reed Hedges wrote: Am thinking of switching over to the new website I was working on earlier (http://interreality.org:4088), but without the half-assed Go to http://interreality.org:4088/home to see it ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 properties proposal
We talked a bit on IRC but wanted to respond here too. I think it can be summarized briefly like this, I think: In S4, Vobjects had an ordered list of named child links to other Vobjects, one type of which was a Property. In the proposal, Vobjects have an unordered set of named properties, one type of which is a link to another Vobject. (And properties can be lists or structured records, which could include Vobject links.) I like the benefits of embedded properties, as long as we can still retain or mimic some of the important aspects of Vobjects as well, in order not to limit the usefulness of properties, and also to facilitate transmogrifying a property into a new seperate vobject (using for example the 'overrides' part of your proposal). I think having ordered vobjects is useful. But could live with having ordered property data instead I guess. Properties should still have some kind of type/tagging associated with them (optionally) that could, for example, let programs use extensible API to access them (like Vobjects). For example, could you do the following using the new embedded properties: A property of a certain type has subproperties beneath it that contain the original value translated into other languages or locales. (or are generally speaking alternative versions) You can ignore the translations if you want, but if the property is tagged with has-translations or whatever, and the user has a preferred language, then use the subproperty for that language rather than the default. You could think of various things like this where you want to have the ability to add facets or special meaning onto a property in the same way as you can a Vobject using a Component (metaobject). Or, of course you might just want to have a tag on a property that might have some meaning but which does not imply that any subproperties exist etc. ... Can you walk through how overrides work or how one would replace an embedded property with an override that points to a seperate vobject? Would the new seperated property need to be a subproperty of a vobject? Or could we have a Property type Vobject (like the old kind), with the same or almost the same API as embedded properties? (And then you can link to it directly as a child link.) ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Speed Racer movie - interviews with the VFX directors
http://www.vrmag.org/speedracer/ When they say VR, at least in the John Gaeta interview, I think they are really referring to panoramic images projected on the inside of a sphere, and you view it from the center and rotate to view different parts of the image. The interview starts down a ways on the page. More images are further along towards the bottom showing how they constructed some scenes. Another interview, in video, includes some examples: http://tv.boingboing.net/2008/05/05/speed-racer-is-popti.html ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 vobject properties
I'm worried about introducing yet more complexity into S5. You know that this is a big concern of mine. What is the exact overhead for having entries in the child list for embedded properties? You need a contextual name, and you need the object. The list itself stores the position value. The EmbeddedProperty object stored in the Component could implement the child list entry interface and store its own contextual name (which would be constant for each kind of embedded property), so the only overhead would be the pointer to the EmbeddedProperty object in the list. This is greater than zero, so it wouldn't be zero overhead, but it would let you treat properties and children in the nice and flexible way, and it's only a pointer's worth of overhead. Or it could be an index into something else instead of a native pointer and we could cap it at 32 bits or whatever if you're really trying to shave bits off there. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 vobject properties
In other words, I sort of imagined it like this: class Entity { handleMessage(); setEntity* parents; string url; } class Link { string cname; int pos; Entity *child; Entity *parent; } class Vobject : Entity { listLink children; vectorEmbeddedProperty embeddedProperties; listComponent* components; etc. } class PropertyCore { read(); write(); dataBuffer; etc. } class EmbeddedProperty : Entity, PropertyCore { Vobject *owner; } class PropertyVobject : Component, PropertyCore { } class Site { setEntity* entities; } So if a host or site has entities foo, bar, baz, you can send messages to vip://site/foo, vip://site/bar, vip://site/baz, and they could be vobjects or embedded properties. An Entity is basically something that can be linked to and can receive messages, so it includes both embedded and non-embedded objects. I know this is simplified but does this make sense? Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] More on the web site
I've started putting together a new website in (s4) hypervos at http://interreality.org:4088/home. It's simplified from the current site, and has less info. As we update things like documentation for S5 and make releases, we can expand the site. I make a wiki page (DraftDocs) that links to some of the random notes and drafts that are in the wiki, and also links to the old Creating Interreality manual for people that want more info. Any comments? I still have to: * Improve the screenshots, either make new ones from the first S5 app prototype, or get some old ones * Improve the colors a bit * Make a new background image * Tweak and improve the layout and whitespace. It looks ok on my screen but will try a few others. * Make some compatibity pages from the old site that get some google referrers * Add a few more icons and illustrative figures. Reed -- http://interreality.org/~reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] More new S5 classes/concepts
I was under the impression that, for the most part, you are always going to be working through Wrapper objects. Is this true? I still think it would be easier for people to use VOS if the wrapper classes had plain names, and the thing being wrapped had the funny name. E.g. DataType is the wrapper for DataTypeCore or DataTypeImp or DataTypeBase. The same reason I stated before, I want to avoid confusion between having a reference to an object and having an actual copy of the object. We could call them Handles instead of Wrappers (so you would access objects through DataTypeHandle or VobjectHandle) which might be clearer. Changing the name would be a hassle, though (search and replace across dozens of files). This is something of an artifact of how the C++ binding is implemented (due to the limits of C++) and can be done more cleanly in languages with better reflection facilities or dynamic typing. I.e. it seems to me that at the most basic, and starting/newbie use level users just need to work with wrappers. Through the vobject wrappers they find children, access component wrappers, etc. So this use level should be the simplest and hide some of the complexity that's going on. Well, the hope is that eventually newbies won't be using C++, they'll be using Python or C# or some other more civilized language. ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 hypervos (mod_vos)
Lalo Martins wrote: Also spracht Reed Hedges (Thu, 14 Feb 2008 14:23:53 -0500): On Thu, Feb 14, 2008 at 07:13:14PM +, Lalo Martins wrote: hypervos is already alive and kicking in the form of an Apache mod_vos; Is the src/app/mod_vos directory in bzr current? Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 hypervos (mod_vos)
Reed Hedges wrote: Lalo Martins wrote: Also spracht Reed Hedges (Thu, 14 Feb 2008 14:23:53 -0500): On Thu, Feb 14, 2008 at 07:13:14PM +, Lalo Martins wrote: hypervos is already alive and kicking in the form of an Apache mod_vos; Is the src/app/mod_vos directory in bzr current? I'd like to work on hypervos a bit in s5 and start bringing in some of the features I was working on in s4. I don't want to deal with Apache at the moment though. Can I split mod_vos.cc to seperate the Apache specific stuff out? (Or can you?) If so, it would help to have some comments explaining some of the stuff it's doing (especially the Apache stuff, since I only know a little bit about Apache modules...) Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] More new S5 classes/concepts
What is the Extension Manager? (WHat's an ExtensionManagerWrapper?) What is a Service Manager (site.getServiceManager)? ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Fwd: C++0x developments
Original Message Subject:[liblf-dev] C++0x developments Date: Fri, 22 Feb 2008 12:47:36 -0500 From: Bjorn Roche [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hey all, I just wanted to update everyone on the latest developments in C++0x (hopefully that will be C++08!). Lawrence Crowl, one of the members of the committee gave a talk to google back in may about the developments: http://video.google.com/videoplay?docid=3528799355371049884 http://video.google.com/videoplay?docid=3528799355371049884 One of the most important things is that C++ will have built-in support for threads, including a memory model, synchronization and atomics. Since he gave his talk, the committee has decided to add limited support for fences as well. Note that GCC currently has intrinsic support for atomic operations (http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Atomic-Builtins.html http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Atomic-Builtins.html ) and even fences, so it's possible to build such types now that's at least compatible with gcc. I'm going to write a prototype for and atomic int for GCC if anyone is interested -- should be pretty simple with those intrinsics, but who knows. Lawrence sent me this. The papers are a bit hard to find, but knowing which ones to look for helps a lot: You can keep up at the C++ standards committee web site: http://www.open-std.org/JTC1/SC22/WG21/ http://www.open-std.org/JTC1/SC22/WG21/ Under the link 'papers' you can find the latest papers in each area of threading: 2007 N2427 C++ Atomic Types and Operations 2007 N2429 Concurrency memory model (final revision) 2007 N2440 Abandoning a Process 2007 N2459 Allow atomics use in signal handlers 2007 N2480 A Less Formal Explanation of the Proposed C++ Concurrency Memory Model 2008 N2492 C++ Data-Dependency Ordering: Atomics and Memory Model 2008 N2493 C++ Data-Dependency Ordering: Function Annotation 2008 N2497 Multi-threading Library for Standard C++ (Revision 1) 2008 N2513 Dynamic Initialization and Destruction with Concurrency 2008 N2514 Implicit Conversion Operators for Atomics 2008 N2516 Threads API Review Committee Report 2008 N2519 Library thread-safety from a user's point of view, with wording 2008 N2528 Timed_mutex in C++0x ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Website design ideas
Reed Hedges wrote: Here are two ideas I had for a new website design. Both are rough sketches. \ 2. http://interreality.org/~reed/tmp/iro/index2.html I made a few small changes to this one, trying a different background image (the branches one is just to show the concept, it's a terrible render). Put some little controls in the lower right to try different stuff out. It does seem that having viewport-fixed objects, including background, really slow down firefox (when you scroll). Reed -- http://interreality.org/~reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Updated Road Map on Wiki
reed wrote: I updated the Road Map page on the Wiki to reflect S5 plans. Pete, please correct it if it's a bit off. This is just a general guideline, we don't really know yet when the first S5 release will be, or whether it will be a 1.0 release or a beta or testing prerelease that is less easy to use. http://interreality.org/wiki/VosRoadMap I decided that in addition to a Blender export script, import from Google Sketchup (or export from it to COD or XOD) would be really good. It's very easy to learn, and some people interested in VOS might already know how to use it (it's the main app for creating objects to drop into Google Earth). Is this a good idea? I added it to the road map. This would be an easy contribution from anyone in the community who already knows ruby. I'll also make the changes you mentioned Lalo. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Website design ideas
Lalo Martins wrote: I like #1. When I did a mockup a long long time ago, I went with a similar idea, and I think it's still valid; the metaphor being that you're looking at a few flat widgets floating in a 3d space. The main thing I don't like is it's too dark and black, which might scare some people off a bit :) (Even if just subconciously). Maybe I'll make a different render that has more of a twilight or sunrise gradient to it, and I want to find better background images for the boxes. Also, in my own mockup, I used partial opacity in the boxes. Maybe mine were too transparent, but something like 90%, 95% would look good? (The problem with a lower value being, of course, that the Celestia background was black with white stars, which would clash with the text...) I tried some transparency, but it does slow down rendering, and with such sparse stars it doesn't add much. If there were more or better stars or more planets or other scenery in the BG that might be cool. Maybe a PNG with alpha transparency wouldn't slow it down as much, and it could provide better borders. I did want the background to look very CGI, could even turn it into flat unsmothed polygons or put a wireframe on it. -- http://interreality.org/~reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Website design ideas
I made the divs a bit transparent in #1. I think they're too boring though, maybe need a bit more bubbliness? (Or is that too Web 2.0? :) Or more of a border? I just threw together the background images in blender, but I do like having them look more polygonated and emphasising that they are 3d graphics. With the second design, my idea is also that there would be a set of similar background images, but with a different one for each page. (or randomly selected when loaded). The background in #1 and the menu in #2 are fixed to the viewport, but I haven't decided if that's a good idea yet. And I'm just having fun experimneting with the javascript mouseover effects. Let me know if you think they would work. Reed On Mon, Feb 18, 2008 at 05:24:32AM +, Lalo Martins wrote: I like #1. When I did a mockup a long long time ago, I went with a similar idea, and I think it's still valid; the metaphor being that you're looking at a few flat widgets floating in a 3d space. I have a nice background image I generated from Celestia :-) Also, in my own mockup, I used partial opacity in the boxes. Maybe mine were too transparent, but something like 90%, 95% would look good? (The problem with a lower value being, of course, that the Celestia background was black with white stars, which would clash with the text...) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - http://lalomartins.info/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d -- http://interreality.org/~reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Future of the Blender UI
Here's Ton talking about some changes to the Blender UI code: http://www.blendernation.com/2008/02/18/the-future-of-blender/ Our UI client ideas are somewhat similar to the kind of things Blender does. If they make the code reusable and general enough, it's possible that we could even use it to make our UI client. Ton seems to want to get the changes done pretty soon. The internal code changes are to use a more general event system for UI and tool actions, and make all the UI infrastructure accessible and customizable from Python. Reed -- http://interreality.org/~reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Future of the Blender UI
The internal code changes are to use a more general event system for UI and tool actions, and make all the UI infrastructure accessible and customizable from Python. Here's more http://wiki.blender.org/index.php/BlenderDev/SundayMeetingAgenda/December_23rd_2007 http://wiki.blender.org/index.php/BlenderDev/Blender2.5/Status Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] More new S5 classes/concepts
Croquet is very cool. I know Pete and I have been following it and reading about it since we started VOS. I don't know if its details have influenced our design much, but some the end goals and features are similar. A lot about it is not documented, as far as I can tell. It's all is Squeak, which can be an obstacle (both because of the language and because of the way some things must be done within the framework.) And it doesn't really come with much out of the box (though at this point, neither does Interreality). With networking, it was designed to support a few particular features, which are sort of unusual (originally meant for a LAN only, no internet; in a sense it's really a number of seperate single-user worlds, that can optionally synchronize). We've taken a more practical and direct approach I think. There is a commercial product based on it that appears to be fairly complete and work well (quaq.com). Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Updated Road Map on Wiki
On Thu, Feb 14, 2008 at 07:13:14PM +, Lalo Martins wrote: hypervos is already alive and kicking in the form of an Apache mod_vos; Ack! Why didn't you email the list! I've been adding stuff to S4 hypervos (and intend to port them to S5!) And I have many plans for further development (see HyperVosIdeas on the wiki) Tell me more about mod_vos. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 site ids
Lalo Martins wrote: AIUI from IRC conversations, the site IDs won't actually be visible to the application programmer later on; we'll deal only with IDs like /vos/ core/StringProperty. (I'm not sure about the code namespaces, but I hope some simplification is intended there too ;-) ) Peter has actually told me a few days ago that side IDs being required for the type attribute in XOD is a bug. For now, we cope; the IDs are extra work, but not really a killer. Aha, that's nicer then, and sounds similar to how I was hoping it would work (with the name (e.g. StringProperty) as the actual name used by humans). I will miss the foo:bar type syntax, but that's OK I guess if in the new syntax things are equally expressive but terse. Curious what the bug is; what's missing from s5 that will fix this? (Curious so I can understand S5 a bit more.) All C++ files except for main.cc (and in my branch, plugin.cc) are generated. Here's how I observed it works: Thanks! Does one just run voscodegen with the xod file as input to generate the code? Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] s5 build errors
Can this be fixed, or is there a way to disable sitetest, or have scons skip it or something? g++ -o debug/build/src/test/sitetest.o -c -g -Wall -Idebug/thirdparty/stage/include -Idebug/stage/include src/test/sitetest.cc src/test/sitetest.cc: In function 'void sitetest_verify_signature()': src/test/sitetest.cc:8: error: 'vos' has not been declared src/test/sitetest.cc:8: error: expected `;' before 's' ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 site ids
The new type IDs are still bothering me a bit too (among other things, like the code namespaces). A huge advantage of the old user-invented type names is that they were natural to understand and easy to remember. We're going to have to do a lot of cutting and pasting, and when we get one digit wrong, will be tearing our hair out over it. (Or the only option will be to use the GUI tool.) Why not have a type/class have separate secure (crypto) ID, and name. When you use a human-readable name in the UI client or in a XOD or whatever, VOS could just look up the OTD/record of the type/class and gets its crypto ID, and throw an error or ignore it if there are name conflicts or not found. In the actual internal inter-object references/links it would use the crypto ID. Also, what in the HelloWorld example is autogenerated and what isn't? Reed Lalo Martins wrote: Is there any rhyme or reason to site ids? If all libraries will ship a separate site (as XOD or something) with their OTDs, won't that pollute the site id space? And aren't them bound to clash at some point? Maybe set up a registry of library site ids somewhere in the website? Or is this (library OTD) going to be substantially different later on? best, Lalo Martins -- http://interreality.org/~reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] More new S5 classes/concepts
Started listing S5 changes at: http://interreality.org/wiki/S5 http://interreality.org/wiki/ChangesToA3dl Will fill them in a bit as I go through the vos-d archives and talk to Pete more. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] More new S5 classes/concepts
I'm going through S5 a bit more deeply now. Pete, can you give a summary explanation of these new classes/concepts, and how you use them, what they do, etc. What are: ComponentWrapper Promise Status (used with a Promise it seems?) IVobject VobjectImpl ImplementationWrapper ImplementationComponent ConstructorFunctionWrapper ConstructonFunctionFunctor ConstructorFunctionComponent The host's factory (i.e. from Host::getFactory()) ParentChildLinkWrapper the SITE_...blahblah..._NAMESPACE namespace DataType DataTypeWrapper Class ClassWrapper the vos:abcdefg12345...[1]/foo/bar strings that appear various places What is something's owner (i.e. the getOwner() virtual methods that lots of classes have) What kinds of things are generated by the code generator, and from what bits of information? Can you explain 'MVC' a bit more (it seems to now be part of the library?) In interreality3D, how does it use MVC? What is, for example, an object like wxMultiframeContextWrapper and wxMultiframeContextComponent? What is the wxgui namespace. What does it mean to append children to the local host? I am guessing this is so the object doesn't get destroyed (by reference count/garbage collection), and so you can also obtain it by name later? Do all objects need to be added to the local host (like they were all children of the local site in s4)? And if so, why not do that automatically when created? Can you explain more these changes to A3DL? What is a scene, what is a render layer, clock, node, etc.? I'll start a NewStuffInS5 wiki page or something, including some of the previous discussion on vos-d. Reed -- http://interreality.org/~reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] More new S5 classes/concepts
And just a general impression... S5 is becoming really complex and daunting (and sophisticated, and hopefully very powerful) piece of software. But this means that we're going to need to put a *lot* of work in documenting, tutorials, as well as just polishing and refining the API itself, to make it easier for newbies to understand, or at least get started with the most common operations (like creating new types/components, etc.) Just something to keep in mind as it's being developed and designed... if you think of a way to make it make more sense or be more natural, at least post it somewhere for future consideration Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 progress and design - OTD XML
On Fri, Dec 07, 2007 at 06:01:30PM +, Lalo Martins wrote: Also spracht Reed Hedges (Fri, 07 Dec 2007 10:57:10 -0500): Oh, ok, then my sketch is not really SOD, just a similar thing. Sorry for apropriating the name. I didn't know that you implemented your format (or forgot). Why wasn't it merged into the main S4 repository? Hmm... ehn... that's a good question :-P didn't even think about it. Guess s5 came around before I could finish it? I couldn't access your bzr repository, can you maybe post an example SOD file just so those of us getting nervous about editing all that XML can relax a bit :) Ah yes, the repository was in a temporary location... I now pushed it to http://interreality.org/~lalo/bzr/sod (or for those who can, bzr+ssh:// interreality.org/home/lalo/bzr/sod). I also checked it out there, so you can actually see the source by going to the same URL; the example is at http://interreality.org/~lalo/bzr/sod/doc/examples/3dworld-blocks.sod Looks nice. My only comments are that the ...end syntax is a bit unexpected (would have used braces, and/or allow a block to be on one line with some seperator other than newline, like ;), and was initially confused as to what with: meant. Also, to give a property a value and a type you must use with:...end, right, you can't have a one-line property with a type? But anyway, it's nice and minimal and would be a good addition to VOS, I'll add it to xplanner or something. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 progress and design
I don't know about Karsten, but the reason I have a knee-jerk reaction against suffixes like Wrapper is that it just feels like cruft, based on other systems where the word had no consistent meaning, at least from a user's perspective, it just seemed a hack to extend an API or facilitate its use without changing the deeper classes, or it was in fact an implementation detail that just happened to be exposed to the user. It's another naming issue I guess. Call it a Handle and use an H suffix. Or an Accessor. Call it a Lever, I don't know :) Wrapper just has bad connotations to some of us :) (Maybe like Component) In the end it will just be something that a C++ user has to learn what it means, but at first glance they have to have trust that it's actually very useful and that there's a good reason they have to do that extra typing. Reed Peter Amstutz wrote: On Thu, Dec 06, 2007 at 05:50:04PM +0100, Karsten Otto wrote: My concern is that if the wrapper class is named with just the name stem, the following situation is very confusing: { Vobject* foo = getFoo(); delete foo; // Oops. I think I deleted foo, but all I did was delete // the wrapper. The underlying object is actually still there. } { VobjectWrapper* foo; delete foo; // I know it is a wrapper, so I know I'm just deleting the wrapper // and that the underlying object is untouched. } This is a little contrived, since wrappers are usually stack-allocated (although the confusion is still there, just not as obvious), but similar cases can be made for other common operations such as assignment and comparison. It's ugly, but it should be considered an artifact of the implementation. Languages with better metaprogramming facilities (meta object protocols, in the traditional academic sense) and hopefully script language bindings should not require this technique. ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 progress and design - sites, hosts, and URLs oh my
Karsten Otto wrote: Ok, I see. But this implies there could be more servers than just one, each hosting a replica. Which one do I contact for updates? With VOP/VIP URLs this was straightforward, but please remind me again, how do I contact a vos:0011223344... key-based site? Is there a name server somewhere? There are two layers, host and site, where before there was just a site. Peter, does the following sound more or less like the way it's going to work or could work, roughly speaking? -- First, you contact a host, then you find the site and its vobjects. You either already have a connection, or you have a URL like vip://interreality.org:4231/MyCoolWorld/thing. You could say that interreality.org:4231 is the name of the host. Then you go looking for the /MyCoolWorld/thing vobject, which is part of some site hosted on this host. You could just send the host the name of your vobject (/MyCoolWorld/thing), and the remote host looks up which of its sites (if it has more than one) that vobject is part of [vobjects on different sites would have to be children of different root vobjects, like /site1, /site2, /MyCoolWorld], and returns a message informing you of your requested vobject's site identity information, you do key authentication, etc. The site doesn't really have a name, but it has its key, and on any given host it has a unique root vobject that all its other vobjects are underneath (though that root could have different names on different hosts).This is not too dissimilar from the site handshaking/negotiation in S4, I think, it just has the extra part where you need to tell the remote site what vobject you want so it can figure out which site to use for that vobject, and tell you. Yes, nobody should really have to every care about the actual site ID/key strings, unless they're debugging something or it happens to be useful in some code to have a unique value that identifies the site (i.e. in S4 you would have used the site's URL for that) or are developing something more advanced involving site replication or distribution or whatever. Or they are suspicious about a site's identity and want to manually verify whether it matches some record . End users (surfers) would still have URLs. Though one thing I do want to get into the client application etc. more quickly than we would have in S4, is reimplementing the service directory we had in S3. It incorporated both online directories of services (e.g. a 3D world), and LAN discovery. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 progress and design
We should also include at this point a reminder of why there's a code generator. If I understand things correctly, the goal is to use the code generator to (a) generate code for different programming languages (b) make it easier for users to generate MetaObject (now called Component) wrapper classes corresponding to different type interfaces (and in different programming languages). The fact that Peter happened to use the code generator to generate VOS itself is, again if I understand it correctly, partly for (a), and partly to make sure it works well. Correct me if I'm wrong Pete. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s/MetaObject/Component
Component is generic, and also recalls COM etc. How about: Part Facet Role Type Fragment Trait What exactly *is* a metaobject? It's a constituent Vobject that's part of a real Vobject, and which implements a facet or part of that Vobject, probably corresponding to a type. It implements part of the Vobject's interface. It provides an interface to the programmer (e.g. in C++ or whatever) for that facet or part or type. It handles a set or group of messages within that Vobject. I kind of like Part. Could even be inside Vobject's namespace I guess (Vobject::Part). I don't know how much this might have changed in s5 but generally a programmer only needs to know about MetaObjects when he is implementing one, if you're just using VOS you deal either with objects as generic Vobjects or with their type interface classes (e.g. Property, Object3D, etc.) Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] S5 and ordering listeners
Can you comment on this Peter? Let's say I want a set of listeners attached to an object to be invoked in order. Let's say that both listeners live on the same local site (process) and maybe are both associated with the same vobject. Will there be a way to do this in S5? What if the listeners are associated with metaobject types (e.g. a vobject L is linked to another vobject Source. Applying type X to L causes listener x to be created, and applying type Y casues listener y to be created, each listening to vobject Source (they find Source because it's linked to L). I always want x to be notified before y of any changes to Source. Does this make sense? -- http://interreality.org/~reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] thinking about a new web site
Here are some ideas I had on revamping the web site. Graphic Design -- * Change the background to white or another light color. Maybe change the main content area to a different shade too, rather than current grey. * A set of background/side illustrations, that convey some of the more general themes of VOS and Interreality -- interconected things; multifaceted stuff; distributed structures -- but also look cool and have a computer graphics style to them. Pages - It's great that the site runs on hypervos. Maybe we want to keep it, or maybe we want to switch to something else then go back to it. It would be great to have text in Vobjects that can be reused on multiple pages. One possability is to use a wiki for all the pages, and then transition back to hypervos once S5 is ready for it. We could have some pages consist of more free form brainstorming and draft documentation like the current wiki, and some pages be the more public facing webpages, but those pages could be smaller but interlinked. More detail below. If we use a wiki for the main pages, we'd need to hide all the meta wiki stuff. I'm also planning on figuring out how to set up a somewhat customized drupal site for a different project, so if that works out maybe we could use that. Sections I don't think we really need a hierarchy [with the exception of About, see below], at least for the public facing aspect. These links can be listen in a little table or grid at the top of the page, like they are now (but set in a grid so they line up nicely, perhaps with logical groping/separation). * About [See below] * Screenshots * News [redirects to forum announcements] * Download * Docs * Forums * Mailing Lists * IRC * Servers [not at first, but eventually link to running servers] * Bugz * Contact About Section - This is where we explain what the heck Interreality is, and sell it. One thing we could do is have a set of short descriptions, each aimed at a different kind of person who might be interested, or describe in general terms how you might approach solving particular problem or implementing a type of idea using VOS. Docs Here we have short articles that explain how to do specific programming tasks with VOS (howto's), as well as the reference manuals. We should probably take S5 as an opportunity to split up the reference manuals, to have one for each library. I don't know if we should just update the Creating Interreality manual, or split it up into smaller documents. I'm inclined to split it up a bit, or at least separate the VOS Design document from the more practical program/how-to manuals. ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] notes from IRC
On Fri, Oct 19, 2007 at 05:16:27PM -0400, Peter Amstutz wrote: Notes from some initial discussion of the interreality 3d interface. Participants: winterk, zaharazod, tetron - Should be more like stuff people expect - Splitting and merging panels is likely to confuse casual users - Casual users should not have to mess around with the interface (splitting, creating new panels, changing modes, etc) - Suggested having a basic layout and an advanced layout to help casual users - Discussed implementing different layouts as UI skins which set up a particular panel/mode configuration for a particular task (browsing, editing, programming, etc). Skins could hide customization buttons like splitting. I agree, this is something I suggested to Pete earlier. Do people want this feature added to the prototype, or wait for the real app? Other things that can go into saved GUI configurations are shortcut commands for the particular application. Esp shortcuts to creating objects of a certain type. So if you are in 3D mode and are going to create a new object, the menu gives you all the a3dl types (at the top of the list.) It should also remember your last UI configuration and could also ship with a default configuration in a file. Having the UI configurations in files lets people set up configs for different purposes or users and share and redistribute them. - Suggested initial 3D panel after login should include chat panel (good idea). This could be part of the default UI configuration. (I actually am not a fan of having login be a full panel, it should be a temporary panel or dialog box shown by other view modes as needed.) - Discussed that the goal is for UI controls to be per-world configurable This is something that will make it really useful and work well, but is pretty novel AFAIK. I don't really know of any other application that does this, except that Javascript has a key handler so web pages can get keystrokes (except control keys). VRML does it similarly I guess. But those are all used by the content, neither of those is customizing the shape of the meta-UI. So we need to think through how it works. E.g. should it automatically reconfigure, then show a message at the top notifying you that it did? Or should it ask first? Should it only allow configuration within the one pane that is viewing the Vobject that wants to reconfigure? Should it open a new window frame with the new configuration, leaving your old configuration alone? Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Forums integrated with mailing lists
Here's an RSS feed for the vos-announce form/mailing list: http://interreality.org/announce.rss (actually, it's an alias for the RSS feed that the forum software generates, but this abstracts that in case we change forum software or whatever. vos-d also has an rss feed, just go to its forum page to get it.) Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Forums integrated with mailing lists
I think it would be ok to just black it out (e.g. [EMAIL PROTECTED]). It's not that useful to have email addresses visible, this is just an artifact of how some email clients do replies. On Fri, Oct 19, 2007 at 11:07:22AM -0400, Peter Amstutz wrote: Posted at: http://interreality.org/phorum/read.php?2,88,96#msg-96 Peter Amstutz wrote: After a quick scan of the phorum modules listed on their site, I didn't find anything that specifically obscures email addresses. It probably wouldn't be too hard to do, and I have already had to do a bunch of modifications to the email modules used to tie the forum to the mailing list (and I've never written php before!) I do wonder how effective email obscuring is, these days. It's not hard to write a bot that would use a regular expression like (.*) at (.*) dot (.*) in addition to the usual (.*)@(.*) ... ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d -- http://interreality.org/~reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] notes from IRC
Just thought of this: One thing that a remote app. might want to customize about the UI is how some things are labeled, or it might want to add special informational labels/text blocks/tooltips/bubbles/whatever. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Forums integrated with mailing lists
Nope. You can see here: http://interreality.org/phorum/read.php?2,88 Reed On Fri, Oct 19, 2007 at 02:43:08PM +0200, [EMAIL PROTECTED] wrote: Hi Peter, I hope the mail addresses are not open readable in forum then, or we might get a lot of spam here soon? -- http://interreality.org/~reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 version control and persistence
On Wed, Oct 17, 2007 at 02:53:49AM +, Lalo Martins wrote: Also spracht Reed Hedges (Tue, 16 Oct 2007 10:24:27 -0400): - type list - child list - payload, if any (eg properties) - security capabilities - parent list? That would be problematic. Since the PCRs are already represented on the parent side, having them repeated on the child would open a potential spot for corruption. Also, it kind of breaks the idea that an object only commits itself; if it adds a new child, then the child would have to update its parent list. Most of all, I don't think it's necessary. Yes, it's redundant and could be problematic. But what if you have some objects in storage, and you want to revive them, and have them insert themselves as children of another object? They need to remember what their parents were. I.e. any situation in which some version gets disconnected from its parents needs to remember what its parents were. This could just be a special case, where you keep track of them but normally you don't need to use them about them, except in situations where you're recovering from a network problem or change which broke the link, or moving objects out of persistant storage,etc. Version control: how it's stored Hmm, it seems the only thing that you need to reason about merging is textual property data. I don't think so. I think the most common type of merging we'll have is on child lists. True, their ordering could conflict. Maybe in that case you just do the best you can, that's pretty easy for a user to fix in applications where order matters. (Or e.g. some code triggered by a listener has to resort them or whatever.) In text, if things get too messed up, it can be a real pain to fix manually, since information tends to span multiple lines. I think we should really never have any situation in which there's a conflict, unless you as a user specifically command it to merge two divergent branches, then of course you are there to resolve conflicts. Right. In all other cases, I suppose the newer revision overrides the older one, when there is conflict. What would the downsides be to treating payload (e.g. property data) as atomic? We can do diffs in a version history UI to present it in a nicer way. We could. Horizons Off the top of my head, I think we'd like to be able to set a horizon per host, per type, and per vobject, in that order of precedence (vobject overrides type). What if a vobject has two different types that specify a horizon? Respect the first? The last? What is a horizon?? A preference of how many historical revisions to keep. You may set your host globally to a horizon of, say, 10, to save space; or set some less important object to a small number, because you don't care... Part of this might be archiving old revisions to disk, either in a known place where they can be called up again, or archive and forget. Reed -- http://interreality.org/~reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 version control and persistence
This sounds really good. Having replication and clustering will be really important as we move forward. It will let us do all kinds of scaling and load distribution, and even manage things like internal, in-development or draft datasets that get published to a public site when ready... lots of great possabilities. What we're thinking is to take this one level further, and implement persistence itself as a host; so even in a single-host setup, persistence would be a discrete thing, This makes a lot of sense. Replication also indicates one path to bridging different networks or different network transport mechanisms. I.e. you can have two sitehosts that mirror each other, one which is accessible over VIP, and one which is accessible over some obscure shared memory or other communications system. A version control branch corresponds to a concrete site, by which I mean the information about one site as seen by one host (as opposed to the full site, which is the most up-to-date version as seen by the whole We should probably come up with some specific names for these things. Like: Site = A collection of vobjects that live together in one conceptual set, and may all be accessed in the same way (e.g. over VIP talking to one internet host). Host or Server = A server program (E.g. omnivos) that holds some vobjects in a site (maybe the whole site) or one replication/mirror within a site that has several replications. Or repository? Site version? = A copy of a particular version from a site's vobjects' revision histories. This could be said to be a version 'derived' from the 'ancestor' site. [should avoid calling them parents/children, to avoid confusion with vobject structure.] Or is this what you mean by branch? ... etc. - type list - child list - payload, if any (eg properties) - security capabilities - parent list? Version control: how it's stored Hmm, it seems the only thing that you need to reason about merging is textual property data. I think we should really never have any situation in which there's a conflict, unless you as a user specifically command it to merge two divergent branches, then of course you are there to resolve conflicts. What would the downsides be to treating payload (e.g. property data) as atomic? We can do diffs in a version history UI to present it in a nicer way. Revisions and transactions Sounds pretty good, not sure I understand all the issues with local objects doing commits. Any particular call chain would be building up a list of commits, that would be executed by the initial vobject that got the message before it returns from handling the message and sends any reply? Regarding transactions, is this something that could be saved for later, after the basic revision control is implemented,or does it have to be integrated now? Horizons Off the top of my head, I think we'd like to be able to set a horizon per host, per type, and per vobject, in that order of precedence (vobject overrides type). What if a vobject has two different types that specify a horizon? Respect the first? The last? What is a horizon?? Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Douglas Englebart and some Google folks talk about knowlege tools and organizational improvement
Brief oververview of Englebarts vision and ideas, talking to folks at Google. http://youtube.com/w/?v=xQx-tuW9A4Q ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] issue building on OS X
Pete has a Mac so maybe he can help. I guess you have neither readline nor termios, so it's trying to use getch() from curses. Can you post the 'config.log' file that should have been created in the main build directory? Can you grep for the getch() function somewhere, it should be in curses.h in the standard includes directory (is it /usr/include on OSX or something else?) Reed Jake Franklin wrote: Thanks Reed, I'm running automake 1.6.3 The build got much further this time, but seemed to die when building mesh: g++ -DHAVE_CONFIG_H -I. -I. -I../../libs/vos -I../../libs -I../../inplace/include -I../../inplace/include/crystalspace -DINSTALL_PREFIX=\/usr/local\ -DVOS_EXPORTS -D_REENTRANT -D_PTHREADS -I/Users/jake/vos/vos/inplace/include -D_REENTRANT -O1 -D_REENTRANT -D_PTHREADS -fvisibility=hidden -g -Wall -I/Users/jake/vos/vos/inplace/include -c -o util.o `test -f 'util.cc' || echo './'`util.cc util.cc: In function 'std::string mesh_read_input(const char*)': util.cc:634: error: 'getch' was not declared in this scope make[3]: *** [util.o] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] development plan
5) Come up with some milestones and prioritize development. The strategy will probably be to code enough of the VOS framework to support concurrent development of higher level pieces like A3DL, and to start putting some meat on the bones of the UI prototype. This may be something like scripting + A3DL + application frontend (which could be a useful tool in its own right) without the networking, distributed computing and persistance pieces necessarily being ready yet. Hmm... I kind of want to begin porting S4 libraries and apps (mesh, omnivos, hypervos, the metaobject libraries, etc.) over to S5. Should I just wait on that? Networking is probably needed (though maybe not). Metaobject/type API is needed. Message handling would be needed. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] What do we want in the 0.24 release?
I thought of another thing: fix up the blender export script. At this point it's a crucial key to making 3D worlds that you can use in Interreality, and probably will be in the future as well. (Though, anyone tried out the ASE converter recently?) Some things it needs to be update for are: * Get meshes' properties (part of the game engine logic stuff) and make them into vos properties * Maybe output vobjects for Empty Blender objects (and follow their parent-child relations) * Needs an actual UI where you can select options, rather than just the menu subitems Anyone tried this script recently? Have any problems that need to be fixed or missing features added? In a little while I'll consolidate possible tasks for 0.24 and we can prioritize them (we probably won't be able to do all of them, we ought to release 0.24 pretty soon). Reed Reed Hedges wrote: Are there any bugs or real defects in Ter'Angreal or VOS? I know of two, don't know if we should fix them: * Avatar settings (model/skin) aren't saved (really just an unimplemented feature) * Objects aren't always removed from the world Something to test is whether all A3DL property/object changes are properly reflected in Ter'Angreal. May not be worth fixing all of them, but maybe some of them if people think they need to use that feature. Others? What is the state of the Python interface? Other things we could do are * Update the manual with VIP documentation. * Make some new worlds. I'm working on a little demo of objects flying around. * Is the IRC bridge working properly now? * Do all the Visual C projects work? * What else? Then we need to do some test release builds and make sure they work. During and after the release I might write some short tutorials that focus on how to do specific things, probably starting with going through how to make something in blender, export it, and load it into a server. Other ideas are at http://interreality.org/wiki/HowTos Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Interpolation in TerAngreal
I've been writing some code that makes some objects fly around and Ken's interpolation code makes it look nice and smooth. However, in doing so I experimented a bit with position update frequency, wondering what the slowest rate I could use is, especially when the velocity I was trying to show was constant. There's effectively a maximum speed that the interpolation achieves, so that if you update less than several times a second (e.g. once or twice a second), the object has a really jerky start-stop motion. Is there a quick fix for this? Or should we just let that issue be, and later add concepts of velocity and acceleration to A3DL? Would it be possible to add position-interpolation-speed and orientation-interpolation-speed properties to Object3D? Or position-update-freq-hint and orientation-update-freq-hint? These would be advisory parameters for the interpolation code, that would let it choose object velocity in the interpolation. I like the idea of update-freq-hint, because it's not implying anything other than what the server side is doing (updating the property periodically). However, the client side would always be one step behind, so it might make things look pretty glitchy. Thoughts? Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] State of S4 Scripting (Lalo!)
It doesn't have to be in depth about how it works, just shows what it does and doesn't do (i.e. it just wraps the core vobject and property api, right, not all the metaobjects [yet]?) and how to go about trying to use it, maybe give some examples. How do you build it? (run setup.py?) Reed Do you have any documentation or notes you can add like the great docs in s4-scripting? Why thanks, that's a great idea of something to do until s5 materializes. I haven't written the docs first as I usually do (referred to as design by science fiction in Zope circles), because I was learning s5 as I go, so I wasn't too sure what it was going to look like :-) but I think I know enough to at least write the gist of the docs now. It may even be possible to recycle the s4-scripting doc structure to some extent. ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] State of S4 Scripting (Lalo!)
Lalo Martins wrote: Yes. There is already a prototype s5-scripting branch somewhere to match Peter's prototype s5 branch, and it looks absolutely beautiful, although Is it sftp://interreality.org/home/bzroot/s5-scripting/libs/vos/python? Do you have any documentation or notes you can add like the great docs in s4-scripting? Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] State of S4 Scripting (Lalo!)
OK, cool. Maybe we can tar up the Python stuff as a separate download in case people want to try it out? Though lack of message handling might be a problem for some people? So, you plan on moving forward with S5 scripting some time in the future, and not really continuoing to work on S4 scripting? (which would be basically a dead end.) Reed Lalo Martins wrote: Also spracht Reed Hedges (Wed, 27 Jun 2007 12:58:40 -0400): What is the state of the S4 scripting branch (http://interreality.org/home/bzroot/s4-scripting)? Does the Python interface work? disclaimer: I haven't touched it in months. I'm answering half from memory, half from a quick look in the last two hours. The whole scripting extension idea suffers from one conceptual bug, as explained to me by Peter: in-process messaging isn't guaranteed to work in s4, and scripts communicate with c++ entirely by messages. However, in my tests, it has worked flawlessly; my tests aren't very extensive, though, so it's possible I didn't cover whatever corner case it is that breaks them. The Python interface mostly works. You can build script objects from a string or file, and you can execute it. Missing is the idea of script properties we discussed before. Binding a script to respond to a message requires a hack. Also, it should probably be doable from Python as well, and it isn't. The JavaScript interface segfaults like there's no tomorrow, due to my poor understanding of SpiderMonkey's weird garbage collection. And the whole thing isn't hooked into the vos build system. All in all, I'm not sure it's worth fixing; it value would be, at best, a technology preview of the kind of script you'll get (much more safely) in s5, and at that, it won't even be api-compatible. If anyone really wants it, they can compile from the branch; then again, if you think you want it, you probably actually want s5 :-) best, Lalo Martins ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] What do we want in the 0.24 release?
Are there any bugs or real defects in Ter'Angreal or VOS? I know of two, don't know if we should fix them: * Avatar settings (model/skin) aren't saved (really just an unimplemented feature) * Objects aren't always removed from the world Something to test is whether all A3DL property/object changes are properly reflected in Ter'Angreal. May not be worth fixing all of them, but maybe some of them if people think they need to use that feature. Others? What is the state of the Python interface? Other things we could do are * Update the manual with VIP documentation. * Make some new worlds. I'm working on a little demo of objects flying around. * Is the IRC bridge working properly now? * Do all the Visual C projects work? * What else? Then we need to do some test release builds and make sure they work. During and after the release I might write some short tutorials that focus on how to do specific things, probably starting with going through how to make something in blender, export it, and load it into a server. Other ideas are at http://interreality.org/wiki/HowTos Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] thoughts and plans
On Wed, Jun 27, 2007 at 12:29:43PM +0200, Karsten Otto wrote: This sounds like a radical redesign... so far we had a single local vobject acting as a sequencer for multiple remote vobjects. Obviously, you have something new in mind. Please tell us more :-) My feeling is that this would be like an optional add-on to a vobject. We would still have the single master local object with remote proxies (that's still one logical option; it's the libvos API that calls the remote objects as objects not proxies and gives them the same interface). Replication means making copies of local objects and moving them to different sites, but keeping them in sync behind the scenes, so a change to one copy gets reflected in the other copy. This requires the locking mechanism during that synchronization; locking would be generally useful as well, even if you're just talking to one object as a client, not a replicator IS this kind of thing what you are thinking of Pete? I've put together a mockup screenshot here: http://interreality.org/~tetron/terangreal%20mockup.png Looks like Safari! :-) I thought you wanted something different than a web browser? In Yes, I would skip the back and forward buttons, and the big bookmark buttons. particular, what use are Tabs here? After all, interacting with a 3D world is about immersion, i.e. you interact with only one virtual reality. Well, we could do what some web browsers do, which is hide the tabs UI if there's only one tab. You might want to be working in multiple worlds. SOmetimes immersion can be a pain because it forces the world metaphor on you. LEt's say your lurking in one world waitingc for people to arrive, but also participating in the other. Or you are moving objects back and forth between worlds. Maybe one of your tabs is the local world within terangreal (i.e. the one that terangreal starts up in that has some instructions in it) that you're using as a scratch space to create objects, then moving them to the other when done. Apart from that, it looks like you intend the interface to be purely 2D. Why restrict ourselves to that? Why not a separate 3D overlay, driven by a VOS graph in the same manner as the main 3D world? We I agree, having the ability for the client to display local 3D stuff for UI purposes might be neat, but there's some stuff that just gets hard in 3D. I think it's a good idea to start off with typical WIMP graphics (using wxWidgets) so that we can make something useful at something faster than our current glacial pace. If GUI elements are somewhat modular as Pete seems to be suggesting (I.e. action/mode X means load GUI panes Z and Y) then we can eventually replace 3D versions if we want, down the road. Well, URLs were originally never intended to be visible in the original browser concepts. True, but they turned out to be useful :) IN our case, you will only see the top level world URL (unless you specifically ask for a particular Vobject's URL). IMO the entire top half including bookmark buttons sould be the display part of a tool plugin, just like everything else, and should only show up if you select this particular tool. I agree (though we might want to keep some stuff just built in to terangreal if it doesn't really need to be a plugin). If so, I am not sure what the mode stack in your mockup is for. Yeah, nont sure about this either. Is it a history of modes you used to be in? Sounds fine, the only problem I see is how to determine that the user is done with the current tool/minor mode. There sould be a consistent and obvious way for the user to signal that. The current mode should only be effective in the main part of the browser, with an unobtrusive reserved mode selection area that is always available and re-grabs mouse/keyboard bindings if you move the mouse over to it or hit ESC or something. Well, is this what the mode stack window is for? I think various tools could trigger mode transitions (bound to keys, mouse buttons, other input devices). Anyway, we can just put them all in a menu too so you can always have access to any of them as well. ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] What do we want in the 0.24 release?
On Fri, Jun 29, 2007 at 08:05:37AM -0600, S Mattison wrote: I can fall through the map. =P Well maybe you need a floor! :) Well, it's not difficult when there are no invisible bounding boxes holding me on. Actually it's several things 1. Bounds in the world that terangreal can check, plus maybe an option to turn bounds checking off 2. Option to turn gravity off/on 3. Option to turn collision detection off/on 4. A fly mode that is initiated by fly keys that turn off gravity while you're flying, then a key that turns it back on. 1. is pretty trivial, 2 and 3 are trivial, 4 is not too hard but would take a bit of work. ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] State of S4 Scripting (Lalo!)
What is the state of the S4 scripting branch (http://interreality.org/home/bzroot/s4-scripting)? Does the Python interface work? Thinking about what we should try to include in 0.24 (codename s4 swan song). Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] development status
Chris is referring here to a proposal for the X3D format/language (new version of VRML) to add the sensor nodes mentioned, by the way. Reed chris wrote: Hi, just a few comments on other status that may interest. I have been testing tcp/ip networking with an implementation of the network sensor nodes in Flux. I have been able to get the basic test examples to work with two linux servers. An example of the nodes is given below. For the mass avatar event at siggraph I will be working on modifying the communications for UDP. This raises the possibility of testing vos server with these nodes if ur inteterested. A description of the test examples and MM server is at http://www.mediamachines.com/hydra/ my experience with installing / running the server is at: http://planet-earth.org/smam/fluxServerInstallRun.html tho u would be wanting to run your own vos server. I am also running a 2 hr multisuer virtual world BOF at siggraph (August) so if you want me to demo vos let me know. I would want something that would not require old browser versions, old java etc if possible because I need to be able to demo other stuff with current tech as well. ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Listener notifications in S5
On Thu, Jun 07, 2007 at 10:02:03PM -0400, Peter Amstutz wrote: On Thu, Jun 07, 2007 at 07:31:42PM -0400, Reed Hedges wrote: How do listener notifications fit in with the S5 vobject-as-logical-thread idea? I'm thinking specifically about impact on ability to scale number of objects that one listener is listening to. Well, my primary concern with the listener system is that if you are interested in a large number of vobjects, the s4 model of adding a listener to each vobject individually has a lot of overhead and redundancy. However, because we want to be able to support multiple worlds hosted in the same process (or a world segmented over multiple sectors) it's not desirable to broadcast every update to every potentially interested party. The general strategy I have in mind is to have updates sent to some intermediate vobject that represents a group of vobjects. Then becoming a listener to that intermediate vobject would be sufficient to be able to listen to the entire group. Seems that this kind of relay or chaining can easily be created just by creating vobjects to do the relaying. Then you can structure it however you want. In doing some hypervos stuff I am creatingsome general purpose listener tools. Most of them will also be MetaObjects so thy cane be created remotely. I wonder if we want to enrich the core listener types in S5 a bit, by adding conditions that can be checked before sending a notification for example. The main challenge with conditions is you either have to define a fixed set of predefined conditions, or create a minilanguage in which you write your arbitrary conditional expression. Easier said than done, in other words. I think it would be a very useful feature. But we should postpone it until we have more real world examples of what kinds of conditions would be required. It's really just an optimization; but I've noticed two things: commonly the very first thing that a listener does (or ought to do) is doa check on a new object's cname or type, or on a property's data type; and that if you really want to have dynamic response to vobject changes in an applications, you need to use a couple layers of the current listeners (e.g. listen for children, then add a type listener to new children with certain names, then add new listeners such as property listeners in response to a type change), and it would be easier to make very dynamic, event driven stuff if some of those more complex conditions were available out of the box, and done efficiently. But yeah, wait on this as a future refinement, need more data to determine how to go about it. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Listener notifications in S5
How do listener notifications fit in with the S5 vobject-as-logical-thread idea? I'm thinking specifically about impact on ability to scale number of objects that one listener is listening to. I'm guessing listener notifications are processed same as any other messages in the vobject's message queue/thread, right? How would you set up parallel notification processing? Create a little listening vobject to recieve the notification on the main vobject's behalf, perhaps? I wonder if we want to enrich the core listener types in S5 a bit, by adding conditions that can be checked before sending a notification for example. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Errors building crystalspace
Was the crystalspace snapshot updated or changed recently? I'm getting these errors now trying to build it. Is anyone else or is something strange going on with my checkout? C++ ./out/linuxx86/debug/libs/csutil/csstring.o ./include/csutil/formatter.h:992: error: non-template 'IEEEFloatMantissa' used as template ./include/csutil/formatter.h:992: note: use 'csPrintfFormatterTwriter, Treader::template IEEEFloatMantissa' to indicate that it is a template ./include/csutil/formatter.h: In constructor 'csPrintfFormatterTwriter, Treader::IEEEFloatSplitterT, Tbase::IEEEFloatSplitter(const T, int, int)': ./include/csutil/formatter.h:1024: error: 'mantissa' was not declared in this scope ./include/csutil/formatter.h: At global scope: ./include/csutil/formatter.h: In instantiation of 'csPrintfFormattercsStringFmtWriter, csFmtDefaultReaderunsigned char ::IEEEFloatSplitterlong double, unsigned int': ./include/csutil/formatter.h:1043: instantiated from 'void csPrintfFormatterTwriter, Treader::OutputFloatHex(Twriter, const csPrintfFormatterTwriter, Treader::FormatSpec, const T, int, int, int) [with T = long double, Twriter = csStringFmtWriter, Treader = csFmtDefaultReaderunsigned char]' ./include/csutil/formatter.h:1407: instantiated from 'void csPrintfFormatterTwriter, Treader::Format(Twriter) [with Twriter = csStringFmtWriter, Treader = csFmtDefaultReaderunsigned char]' libs/csutil/csstring.cpp:117: instantiated from here ./include/csutil/formatter.h:992: error: type 'csPrintfFormattercsStringFmtWriter, csFmtDefaultReaderunsigned char ' is not a base type for type 'csPrintfFormattercsStringFmtWriter, csFmtDefaultReaderunsigned char ::IEEEFloatSplitterlong double, unsigned int' ./include/csutil/formatter.h: In member function 'void csPrintfFormatterTwriter, Treader::OutputFloatHex(Twriter, const csPrintfFormatterTwriter, Treader::FormatSpec, const T, int, int, int) [with T = long double, Twriter = csStringFmtWriter, Treader = csFmtDefaultReaderunsigned char]': ./include/csutil/formatter.h:1407: instantiated from 'void csPrintfFormatterTwriter, Treader::Format(Twriter) [with Twriter = csStringFmtWriter, Treader = csFmtDefaultReaderunsigned char]' libs/csutil/csstring.cpp:117: instantiated from here ./include/csutil/formatter.h:1046: error: 'struct csPrintfFormattercsStringFmtWriter, csFmtDefaultReaderunsigned char ::IEEEFloatSplitterlong double, unsigned int' has no member named 'mantissa' ./include/csutil/formatter.h:1067: error: 'struct csPrintfFormattercsStringFmtWriter, csFmtDefaultReaderunsigned char ::IEEEFloatSplitterlong double, unsigned int' has no member named 'mantissa' ./include/csutil/formatter.h:1108: error: 'struct csPrintfFormattercsStringFmtWriter, csFmtDefaultReaderunsigned char ::IEEEFloatSplitterlong double, unsigned int' has no member named 'mantissa' ./include/csutil/formatter.h:1110: error: 'struct csPrintfFormattercsStringFmtWriter, csFmtDefaultReaderunsigned char ::IEEEFloatSplitterlong double, unsigned int' has no member named 'mantissa' ./include/csutil/formatter.h:1112: error: 'struct csPrintfFormattercsStringFmtWriter, csFmtDefaultReaderunsigned char ::IEEEFloatSplitterlong double, unsigned int' has no member named 'mantissa' ./include/csutil/formatter.h:1407: instantiated from 'void csPrintfFormatterTwriter, Treader::Format(Twriter) [with Twriter = csStringFmtWriter, Treader = csFmtDefaultReaderunsigned char]' libs/csutil/csstring.cpp:117: instantiated from here ./include/csutil/formatter.h:1116: error: 'struct csPrintfFormattercsStringFmtWriter, csFmtDefaultReaderunsigned char ::IEEEFloatSplitterlong double, unsigned int' has no member named 'mantissa' ./include/csutil/formatter.h:1407: instantiated from 'void csPrintfFormatterTwriter, Treader::Format(Twriter) [with Twriter = csStringFmtWriter, Treader = csFmtDefaultReaderunsigned char]' libs/csutil/csstring.cpp:117: instantiated from here ./include/csutil/formatter.h:1136: error: 'struct csPrintfFormattercsStringFmtWriter, csFmtDefaultReaderunsigned char ::IEEEFloatSplitterlong double, unsigned int' has no member named 'mantissa' ./include/csutil/formatter.h: At global scope: ./include/csutil/formatter.h: In instantiation of 'csPrintfFormattercsStringFmtWriter, csFmtDefaultReaderunsigned char ::IEEEFloatSplitterdouble, unsigned int': ./include/csutil/formatter.h:1043: instantiated from 'void csPrintfFormatterTwriter, Treader::OutputFloatHex(Twriter, const csPrintfFormatterTwriter, Treader::FormatSpec, const T, int, int, int) [with T = double, Twriter = csStringFmtWriter, Treader = csFmtDefaultReaderunsigned char]' ./include/csutil/formatter.h:1411: instantiated from 'void csPrintfFormatterTwriter, Treader::Format(Twriter) [with Twriter = csStringFmtWriter, Treader = csFmtDefaultReaderunsigned char]' libs/csutil/csstring.cpp:117: instantiated from here ./include/csutil/formatter.h:992: error: type 'csPrintfFormattercsStringFmtWriter,
Re: [vos-d] Errors building crystalspace
OK, it turns out this is just G++ 4.1.3 being stricter than older G++'s. Our CS branch actually had a partial fix for this problem but - bizarrely - it was conditional on the compiler being MSVC 7.1!! I looked at current CS svn and it just declares csPrintFormatter and IEEEwhatever::mantissa correctly to begin with. I'll commit this to our crystalspace branch. How do I regenerate the .tar.gz? Incidentally, crystalspace.tar.gz is humongous. To redownload it in less than a few hours on my dialup connection I went in and deleted a bunch of stuff from the scripts/msvc* directories, the entire data directory, and some of the plugin code we don't use. Maybe we should do the same for our branch (at least delete the data directory). I might also change vos/m4/cs.m4 to only compile some of the CS plugins instead of all of them (many of which terangreal does not and will probably never use). Reed Reed Hedges wrote: Was the crystalspace snapshot updated or changed recently? I'm getting these errors now trying to build it. Is anyone else or is something strange going on with my checkout? ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Embedded properties, string pooling, and search
The planned S5 features of embedded properties and string pooling ought to make it efficient to search for objects on a site by type or name (due to string pooling), if the shared strings have pointers back to their vobjects, right? Have you implemented string pooling yet, or what are your plans (have seperate pools for name and type?) What about searching property values? It would also be nice if they could be very efficiently searched. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Scaling and Origins -- 0.23 vs 0.24
On Wed, May 16, 2007 at 10:18:34AM -0400, Peter Amstutz wrote: The bigger problem was I was doing something dumb in 0.23, which was the code that loads the md2 models for avatars recenters it to make the origin the center of the avatar bounding box rather than at the avatar's feet. So now it uses the bottom extent of the md2 model as the origin for the vobject's polygons? Shouldn't it use the same origin as in the md2 model, and if the origin is wrong there you just have to fix the model? (Or I guess we could have a flag in a3dl:model that decides this, since it's possible that people won't want to have to go back and change the source models, especially if you have a nontrivial workflow involving several artists and programmers). Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Wanna help the Mass Avatar Mash?
We don't have specific plans for H-anim and VOS. We haven't designed how jointed, animateable geometry will work in VOS yet. Chris is just keeping us informed about possible things to do (thanks Chris) I think. At this point, we plan on having a general VRML server for VOS that exposes a running VRML scene in VOS, but I've been lazy and distracted by web stuff and haven't worked on it for a while. :) If anyone is interested in talking about how jointed, animated geometry will work (for both humanoid avatars and other stuff) will work, go ahead :) Reed On Sat, May 12, 2007 at 12:18:32PM -0700, dan miller wrote: can someone sum up what's going on with this project? Is there going to be some sort of H-anim importer to VOS? Or some other X3D compatibility strategy? -dan ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Van Jacobson: named data
Yeah, so his ideas cut accross all kinds of layers and aspects of networking. so I don't think VOS can be THE solution to the problems he explains, but it can provide a few key tools. Namely it can be a data storage system, both for originals, and replicated copies, and for store-and-forward, If we include stuff like hash fingerprints, and signing/encrypting data objects, versions, and caching and distributing copies in a clever way. Maybe it could be used for routing search/query/response messages, but maybe not. For discovering resources in a particular local communications environment (e.g. local wireless network) it's probably best for something like zeroconf or other broadcast queries. Not sure how VOS could fit in with multicast. Not sure if that's something we should worry about here, since multicast has turned out to be something of a dead end on the internet, and most local networks as well that haven't been set up with the possability of multicast in mind. Reed On Mon, May 07, 2007 at 05:51:45AM +, Lalo Martins wrote: Aaron Bentley posted to the bzr list about a Van Jacobson talk: I was watching this talk by Van Jacobson about a new networking paradigm, and I started going hey, I know this stuff. http://video.google.com/videoplay?docid=-6972678839686672840hl=en Around 37:31, he starts talking about a new dissemination mechanism in which you look for named data, rather than having conversations with servers. I can't actually *watch* the talk, though, as stupid google video doesn't work in China. If anyone is interested, can you please watch, and post a summary? In particular, how much it's relevant to the way we're already doing things (named data sounds a lot like vobject from my chair). best, Lalo Martins ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Van Jacobson: named data
I downloaded a copy of this video if anyone wants it. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Van Jacobson: named data -- revision control
This means that if that version object is mutable, i.e. a not read-only property, we need to also have branches in the version history, and any reference to a past version of a vobjcet is really a reference to the most recent version in the branch rooted on this object, which if there is only one version in the branch, is the same as the root object [if that makes any sense]. I don't understand. The example I was thinking of is this: Property P has versions P.1, P.2, P.3. If you have a normal reference to P, you get P.3, though you know it just as P. If you write to P, it creates a new version, P.4, but P (being the current version) is transparently changed to P.4. But if you have a reference to P.2, and you write to it, resulting in a new version P.2.2, it appears to you that the write didn't work, since you're still looking at P.2. So P.2 needs to be an alias for most recent version of P.2 in the same way that P was. P.3 is then also an alias for most recent version of P.3, but P.3 doesn't have any derivative versions, so it's just P.3 (or call it P.3.0 or something). Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Van Jacobson: named data
I guess each copy, whether changed or not, should have a pointer to its original. I wonder if any vobject version should not have it's versions inside it, but simply have a pointer to it's predecessor (or the other way around, an object has links to all its derivatives). Then you can have different sites for different versions. Then, while you can't cryptographically verify the derivative, you can verify its original, and compare them to see if they are the same data or diferent. Reed On Tue, May 08, 2007 at 03:48:38PM -0500, Len Bullard wrote: Understood completely and I know how SSL, checksums, asymmetric keys, etc work but without the understanding that content drifting away from its original sources corrupts means the buyer doesn't understand the technical solution is not the whole solution. In effect, regardless of the wrapper, unless you have the original 1959 first episode of Rocky and Bullwinkle, you probably can't answer those trivia question correctly. If you don't have the authentication and authorization, you don't have access to the original source. If you don't have the digital signature and checksum technology, I can't trust your answers without the original sources. This is the real problem of named data sharing. Otherwise, URIs with registries make the name sharing easy, and the rest is authentication, authorization, signatures, etc. I don't think the problem of discoverability is as big as the speaker believes it is. It isn't just trust. It's verification. For that, you must have an authentic copy of the original source or access which amounts to the same thing but if access, you have to prove that. Names alone won't make that happen. len ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Movement interpolation update
Karsten Otto wrote: You cannot really fix this with a don't-interpolate flag, as there is no good place to put one. You could extend the property- update notification, but a lot of properties do not use interpolation That's ok. Nothing stops you from adding whatever fields you want to the message, and for Terangreal to check for the field for the position property. This is why fields have names. Pete's idea of having extensible method types is interesting though, might be useful. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] build system reviews (long)
On Wed, Apr 25, 2007 at 11:07:11PM -0400, Peter Amstutz wrote: It's actually make distcheck that's interesting in this case. In automake it gives you a single command that will build a source tarball, unpack it to another directory, runs configure and does a build. It's a very useful automated sanity check on your source distribution. Also make dist is distinguished from simply dumping your repository to a tar file by the fact that it includes certain generated scripts like configure that don't, strictly speaking, belong in your version control branch (since they're automatically generated from other files.) In another project I've basically implemented this in a set of common Makefile rules. It is a bit annoying to debug complex make rules like this but it's not that hard my main problem is working in various odd policies and methods still around from a previous version of this stuff, and some of the nonstandard stuff we did there, VOS follows more normal conventions. [1] Although there is a case to be made that such files should be included in your repository anyway, since there are people who might want to check out the latest source for something but still don't want to be required to have every last little build tool. Thoughts? The problem with this is you can end up with these files being regerenerated all the time and end up with a zillion revisions, each with no significant change from the previous. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] VOS on Solaris?
Lars O. Grobe wrote: Do you have libtool installed? That is a separate package from autoconf and automake. I compiled the most recent one from GNU. As I am not root, I installed it in my home and added it to my PATH. Does the build make any assumption where to find libtool (e.g. under /usr)? You may have seen Peter's recent message about changing the build system. Pete, if we're not using automake, then we wouldn't have to use libtool either, right? Also, is jam is available on various systems like Solaris? Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Patches for 0.24 in MSVC
Wow, thanks Ken! The only thing I haven't really tracked down is that avatar movement seems a bit jerky in the MSVC build. If I get more time I might look into it... Try it in a release build. (both VOS and Crystalspace in release mode). MSVC puts a lot of extra code in when in debug mode; CS also has a lot of extra debug utilities that might have been enabled in debug mode. ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] VOS on Solaris?
Hi Lars, thanks for giving it a try. We have not tried the current version of vos on Solaris yet but would like to make it work there (the libraries and server at least). Are you using 0.23, or the development version (source control repository snapshot or checkout)? What version of autoconf is being used, and what version of automake? Reed Lars O. Grobe wrote: Hi, did anyone manage to build VOS on Solaris? Here it ends: libs/vos/vip/Makefile.am:1: Libtool library used but `LIBTOOL' is undefined. libs/vos/vip/Makefile.am:1: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' libs/vos/vip/Makefile.am:1: to `configure.ac' and run `aclocal' and `autoconf' again. So I would be curious if anyone managed to build and install VOS on Solaris. ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] S5 and single-thread option
Pete, in your description of S5 so far it seems like it is defining a threading model that is not neccesarily coupled to a particular thread implementation. That is, conceptually vobjects are threads or proceses but I am guessing that you won't be implementing it by simply creating a pthread for each vobject :) Does this mean that it will use a thread pool of some kind? If so, would it be possible to have a thread pool of size 1, thereby making it possible to run VOS on an OS that effectively has no threads (I'm thinking of stuff like handheld devices, phones, embedded systems, whatever). Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] server requirements
In a different forum, Hellekin Wolf asked: The server issue mentioned above makes me think of the requirements for running a VOS world. Do I need hardware graphics or is it only for the client side? A server does not need any graphics hardware. Many servers in fact are just providing data so you don't even need a fast processor, though things tend to run is many threads so the more processors the better. The current design does use a lot of memory if you have lots of objects, though changing that is a big priority for the next big version (S5) -- a really good threading model is also of course planned as Pete has been telling us about. For reference, interreality.org is an AMD 64 X2 dual core, 2GB RAM and it runs with less than 1% load; we anticipate being able to run several (5-10) small worlds on it as well as the website. It replaced a 300 Mhz Pentium II with less than 512 MB memory!! It ran pretty well, though memory was tight. I have a 1.5 GHz AMD at home and it also runs fine. In the future we may have server modules that do dynamics and physics simulation for everyone, that will require a fast processor, or possibly a coprocessor. Also, servers that need to do more computation will obviously require faster processors. The client requires some kind of 3D graphics hardware to run well. Crystal Space does have a software-only renderer though it is not very actively maintained. Supporting that software-only renderer is something that we'd like to do in Terangreal (the client) eventually. Of course, it's also technically possible to create Vobjects within Terangreal (by modifying terangreal's code) that can be a server to other clients, due to the flexibility of VOS :) (You can also just create objects in the mesh tool, this is a good way of experimenting with stuff.) The server framework is called omnivos. If you look at (vos/apps/omnivos) you'll see that it's like 15 lines of code :) It mainly just loads plugins. Run it with one of the example configuration files like this: omnivos -c example.xod -nofork -o -. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Thinking about Javascript
On Tue, Apr 17, 2007 at 07:27:21AM +, Lalo Martins wrote: One problem I have with the pure-js version is the nature of HTTP; either the browser would need to keep a persistent connection to the server, like some web chat rooms do -- which is error prone (hard to recover from a disconnect) and makes the deserialisation a bit more complicated -- or it would have to poll, which sucks for a number of other reasons. Yeah, this is why I was looking for libraries out there that address these things (so we wouldn't have to). So far I'm only aware of comet and dojo (dojotoolkit.com) (the client side). Probably the best thing is to focus on just updating HTML in the browser. So if the browser opens that persistent, listening channel, then Hypervos can listen to the Vobjcets on its behalf, and if it e.g. sees a child-inserted and the new object is HTML/XML, and it also has an open connection to a listening web browser, to serialize the new objects into an HTML fragment and push that to the browser. Similar for anything changing in the objects or something removed. stick the new or changed HTML into the DOM (set innerHTML or something). Anyway, I'm just trying to gather ideas for future web applications, I probably can't work on this right away-- but if you want to that would be great, let me know and we can coordinate. I've been gathering these ideas at http://interreality.org/wiki/HyperVosIdeas . Part of my motivation has been searching for a good web application focused on Question and Answer customer support, as well as general forum discussion. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Integration of VOS and IRC
This would be great for people who primarily want to just chat or be present in the world while doing other work, so they don't want the full 3D world. It would also make it possible for blind people to interact in the 3D world. Reed On Tue, Apr 17, 2007 at 01:54:23PM -0400, Peter Amstutz wrote: Also something I've wanted to explore is the possibility of creating a semantic representation of a space that is meaningful enough to be navigated from both a MUD-style text interface, while still being able to enter it as a fully 3D immersive world. You could lay down a node network of positions where the text-user could go, add descriptions to all the objects in the space, and then at each node it would print out the descriptions for things that were nearby. For example (thinking of the current demo black sun world: --- You are standing on a hill of brown dirt. To the north is a large white pyramid with an entraceway. To the east the hill continues. To the west the hill continues. To the south is black nothingness. $ Go north You are at the entrace to the Pyramid. To the north is a hallway with a tiled floor. At the end of the hallway are ramps leading up and to the east and west. To west is a doorway. ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Integration of VOS and IRC
scenery part). Unfortunately, viewpoints usually have no navigation links between them. So for what you want to do, you need a combination of both. This requires some work, but VOS is flexible enough to support all this. Yeah, you would just have the waypoint object type have child links to other waypoints. You would then combine it with the viewpoint type which provides the 3D position, orientation, and other spatial info. Or those two aspects could just be contained in one object type. Having a set of exits from a viewpoint might be useful in 3D as well, as a way to help people navigate 3D spaces. You need exit lables on the navigation edges for this. This is what the contextual names on child links are for :) Gonzo(3d) goes south to the entrace to the Pyramid. In contrast, this is terribly complicated. Deriving the intention/ activity of a user (thats what you have here) from its raw movements We can explicitly represent it by giving the waypoint object type a child that's a container for avatars who are at that waypoint. A few other text-user commands that may be handy: follow user - move the text-user's avatar to wherever another avatar (text or 3d!) is moving to. face user - turn the text-user's avatar to face another one. You can also do this automatically if you detect a corresponding speech pattern like kao: are you there? approach user - like face, but also move the avatar close to the target. These behaviors would also be useful in 3D too. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Thinking about Javascript
Is anyone here familiar with Javascript much? I'm wondering what kind of networking tools are available from Javascript. I've been reading about a thing some people call Comet, (http://alex.dojotoolkit.org/?p=545) which basically a publish/push model for the server to update pages live. It looks like it uses a JSON protocol called Bayeux (http://svn.xantus.org/shortbus/trunk/bayeux/protocol.txt). I've been thinking about how we can push VOS events out to the web browser, and I'm wondering whether Javascript running in the browser could use a VOS runtime (running in a plugin??) with JS bindings, or if it makes more sense for the server to translate the events into a more web-specific protocol that would be interpreted entirely by Javascript code shipped along with the page (even perhaps including all the object-to-XML logic in the server as well, like Hypervos). Thanks Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] terangreal changes
On Thu, Apr 12, 2007 at 10:29:35PM -0400, Peter Amstutz wrote: On Thu, Apr 12, 2007 at 09:26:09PM -0400, Reed Hedges wrote: * Change mouse cursor to reflect what clicking will do (i.e. differentiate between mouselook/move modes; change when over a hypercard or clickable) Yea, that would be useful. * If you click some mouse button on an object it becomes selected * In the future, could show a panel to edit properties of selected object, or create new objects attached to it in scenegraph fashion, or whatever How do you differentiate between I'm clicking on this to activate it and I'm clicking on this to edit its properties? What do you mean by activate? You mean if the objcet has the clickable type? Different mouse clicks probably. Or have modes. * If a selected object has the ui:actions type that I added recently, then display those in a side panel as buttons I'll have to take a look at it -- sounds like a generalization of misc:clickable perhaps? So instead of I can accept click messages you say I can accept messages X, Y and Z and specify that X is the default message for clicking. Yes but there's no default currently. A ui:action is like a macro for sending a message to an object that describes the message in a user friendly way. It's implemented in mesh, it prints a list of actions for the current object, and if there's ann action called foo you just say do foo and it sends whatever message is behind foo to the object. * Some way to show/hide sets of objects in the world, or change their properties together as a group (e.g. alhpa to make them fade in and out). These groups could be called layers or groups. This would be one This sounds kind of complicated, although I agree it could be useful. ... Let me also point out that you probably shouldn't kill yourself with crazy new ter'angreal features; the only reason I'm working on it is to I don't think it would be too hard. It's just something I thought of that would be unique and interestincg to show off to people. I was actually thinking of making the layers be metaobjects so others would share your layer selection, useful for collaborative work. Do you think that most of the Terangreal GUI (wx) will be easily transferred to s5, even if the A3DL CS plugin guts are torn out and redone? (Will you post a comprehensive description of A3DL changes in s5 later, like you have been doing for VOS in s5?) When we do demos we actually should have two laptops so people can see what in the scene is shared (and what's not). Reed ___ vos-d mailing list [EMAIL PROTECTED] http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 concurrency (design part 2)
Peter Amstutz wrote: On Fri, Apr 06, 2007 at 05:16:16PM -0400, Reed Hedges wrote: There's also something called Flow-Based Programming that is similar. In some ways it's closer to VOS since Actors are, I think, more like method handlers (in VOS terminology). I don't agree. Flow-based programming is very data-centric, in the sense that it views the system as a connected chain of inputs and outputs and black boxes doing transformations. OK. (You could use VOS easily to do flow based programming, I think there's a brief note about this in the wiki somewhere.) I was under the impression that an Actor was a function that did just one thing? Or are there variations on the model? Well, not important I guess. Reed ___ vos-d mailing list [EMAIL PROTECTED] http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 concurrency (design part 2)
So messages between local objects will be serialized and passed like remote messages, rather than being method calls? Is that overhead a concern? If so, maybe an optimization would be to have a message format that just packs native machine format arguments into the message in the same order as the method handler arguments (omitting the field labels)? Reed ___ vos-d mailing list [EMAIL PROTECTED] http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 concurrency (design part 2)
Peter Amstutz wrote: On Thu, Apr 12, 2007 at 08:16:59AM -0400, Reed Hedges wrote: So messages between local objects will be serialized and passed like remote messages, rather than being method calls? Is that overhead a concern? It is a concern, although I'm don't think I would call it serialization since there is no data conversion happening, it is just copying the method parameters into a temporary message structure, possibly copying the message if it needs to be queued, and then copying those parameters out of the message structure onto the stack when we get around to actually calling the method. If so, maybe an optimization would be to have a message format that just packs native machine format arguments into the message in the same order as the method handler arguments (omitting the field labels)? At the moment it does still include the field labels, but the labels are just pointers into the string table, so they are cheap to copy as well. Will messages be like they are now, essentially a map? Or could we have a Message subclass generated from the OTD, with pointers into the message data for each field, so we don't have to look up fields by name each time? I think it is important to retain the field labels and data types, because once the message is constructed we don't know if it is going to stay in process, be passed to a scripting VM or be sent out over a socket. Yeah, it would be nice not to have to do too much processing on the Message object to send it out over the network-- just grab a data buffer out of the object and byteswap it (or not). Actually sticking to always having named fields is a good thing. They tend to come in handy a lot. (It's one slightly annoying part of XML-RPC in my opinion.) One thing that would be nice in s5 is to be able to very easily nest message structures, either through just embedding a second message inside another as a field, or by a struct definition in the OTD and putting struct type data in the message. On that note, one of the things I want to do is come up with a set of rules for what to do when an incoming message has slightly different parameters from the method signature of the target Good idea. (Other things that are also possible are to have hooks to filter and reform messages, or relay through a Vobject which does that. This kind of thing will be pretty easy to do and will make it possible to hook together different applications.) The rules I'm thinking of would be along the lines of: - If the message has an unrecognized field tag, but all other fields can be matched, ignore the unrecognized field Yes, important. - If the message fields are in a different order than the method expects, reorder the message fields to match the method fields. Yes, very very important. We shouldn't rely on the order at all really. And so on (these are just examples off the top of my head). same for int-float conversions. Basically, we should expand what the Message class can do. Here's a rough outline of how it might look: class Message { size_t len; char *data; // suitable for sending over the network as is? string method; string getField(string fieldName); int getIntField(string fieldName); ///...etc... } Completely made up this: otd structdef name=struct1 field required name=a type=int / field required name=b type=int / field required name=c type=array(float) / /structdef structdef name=point field required name=x type=float / field required name=y type=float / /structdef message method=example-message field required name=foo type=string / field optional name=bar type=array(int)/field field optional name=complex type=struct1 / field optional name=points type=array(point) / /message /otd class ExampleMessage : Message { typedef struct { int a; int b; int c; } struct1; typedef point { double x; double y; } point; char *foo; // pointer into Message::data int *bar;// pointer into Message::data. Easy to access, but need to use a function to insert: void insertIntoBar(int v); size_t *bar_size; // pointer into Message::data struct1 *complex; point *points; size_t *points_size; void insertIntoPoints(ExampleMessage::point v); }; ___ vos-d mailing list [EMAIL PROTECTED] http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] misc:search questions
Ken Taylor wrote: the fact that you guys seem to be allergic to comments doesn't help either ;) (i jest! i jest ... sorta) Just Pete. But he wrote most of the code. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] bakefiles
Peter Amstutz wrote: Whenever I try to set up a VOS build environment on Windows, I get a sharp, throbbing headache and a strong urge to throw my chair out the window. It's difficult to understate just how big of a maintainance hassle the current build system is on Windows (whether Cygwin, Mingw or Visual Studio). It's so bad that I've seriously considered creating a tarfile of the entire mingw tree on interreality.org as the recommend way of setting up a VOS build environment. It takes me personally several days of fiddling to get ter'angreal to build and work on Windows on a new system. Automake is lovely on Unix, but it is an awful cross-platform build system where the platform is not a unix variant. Well, automake works fine for me in general on MinGW whenever I've used it there, but never tried it with Visual Studio or Cygwin. Of course there's always the incompatible-versions problem with the autotools. And maintaining a ton of visual C files sucks, I have to do that all the time :) tools you list. If you do switch to bakefile, let's keep some Makefiles in the bzr tree. And keep bakefile inside the bzr tree so that you don't have to have it installed if you want to modify the makefiles. The primary advantage of bakefile vs. jam or scons is that it generates actual project files for various compilers, so users don't have to drop down to the command line to build VOS when everything else they are doing is in the IDE. That's good. If we can keep those project/make files in the tree without too much trouble then that would be an ok way to go. Let's also keep the bakefile source in the tree and in the source release too, especially if eventually we want vos to be buildable on all kinds of server operating systems (and where admins want to just run make and not have to install extra tools). Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] keyboard vs. wimp interface for 3d
Karsten Otto wrote: Interestingly, while it has buttons that trigger actions, I mainly used them as a quick way to arrange keyboard shortcuts during normal gameplay. The only time I ever used the interface in a traditional way was for complex actions like trading items. Actually this is quite similar to my Blender experience - it drove me crazy when I had to use the menus, but was a breeze once I knew the keyboard shortcuts. Not sure if there is a lesson there... We need these keyboards-- http://www.artlebedev.com/everything/optimus/ (and affordable!) Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Flux Worlds Server Announcement
Tony says more details about their system and protocol will be available later in April (after they present it at the Web3D Symposium). With s5 we've talked about tweaking the A3DL object model a bit for various reasons. One thing we can do is make A3DL line up with X3D/VRML a bit better, which would help with loading VRML into a VOS server. Another possability I'd be interested in looking at is if SWMP is suitable for plugging in as an alternative transport protocol -- I don't think the documentation talks much about it, and we've never really done to much with the idea, but we've always had the idea that VOS objects could communicate in different ways other than just over the network using a protocol like VIP. E.g. different sites in a cluster of computers could communicate much faster through shared memory or something like that. Sites could also talk to each other using different protocols. Not sure yet how to bridge to completely different multiuser 3D systems but at some point we might see if it's possible. Reed Reed Hedges wrote: Subject: [www-vrml] Flux Worlds Server Announcement From: Tony Parisi [EMAIL PROTECTED] Date: Fri, 30 Mar 2007 14:08:27 -0700 To: 'x3d-public list' [EMAIL PROTECTED], 'www-vrml' [EMAIL PROTECTED] To: 'x3d-public list' [EMAIL PROTECTED], 'www-vrml' [EMAIL PROTECTED] Return-path: [EMAIL PROTECTED] Envelope-to: [EMAIL PROTECTED] Delivery-date: Fri, 30 Mar 2007 17:23:26 -0400 Received: from server5.outofcontrol.ca ([67.15.54.3] helo=web3d.org) by interreality.org with esmtp (Exim 4.63) (envelope-from [EMAIL PROTECTED]) id 1HXOZC-0004hj-49 for [EMAIL PROTECTED]; Fri, 30 Mar 2007 17:23:26 -0400 Received: (from [EMAIL PROTECTED]) by web3d.org (8.13.1/8.13.1) id l2UL8b5q002738 for www-vrml-outgoing; Fri, 30 Mar 2007 17:08:37 -0400 X-ClientAddr: 68.142.198.206 Message-ID: [EMAIL PROTECTED] X-YMail-OSG: YdctFGYVM1n.8kk5AKF_NK_BHTa6B4bhKOAcp60Dh6ruxknPqKH_FaSL8MKh.mRJL3H472LKdmQMt_3gT73yu_cgkQ-- MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdzD3XDRb6swz8uR6SHIti2zgRz2w== X-OutofControl-MailScanner-Information: Please contact the ISP for more information X-OutofControl-MailScanner: Found to be clean X-MailScanner-From: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Precedence: bulk X-SA-Exim-Connect-IP: 67.15.54.3 X-SA-Exim-Mail-From: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on interreality.org X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.7-deb X-SA-Exim-Version: 4.2.1 (built Tue, 09 Jan 2007 17:51:29 +) X-SA-Exim-Scanned: Yes (on interreality.org) Folks, We've been up to something over here - thought I would tell you about it before you heard it on the street. Media Machines has been developing a multi-user server based on a new protocol that we intend to put out into the open. We have dubbed it Simple Wide Area Multi-User Protocol, or SWMP (pronounced swamp). The intent is to work with Web3D and potentially other organizations to standardize SWMP. We will also supply a basic open source implementation. Our overriding goal-- one that we are pursuing with total passion and vigor-- is to create an open infrastructure for the Metaverse. We have wrapped SWMP into a server product called Flux Worlds. Flux Worlds is currently in alpha test. While the product is still several weeks away from beta test, we announced it yesterday with the goal of attracting early signups for the beta. We are also integrating a prototype of the new X3D networking nodes being developing by the Networking Working Group, right into Flux Player. The results look promising. Anyway, here is the announcement. We would love to have you be part of the beta when it's ready! http://www.mediamachines.com/press/pressrelease-03292007.php Remember, the Metaverse needs open protocols. Without them... everything else is Just a World. Yours virtually, Tony - Tony Parisi 415-902-8002 President/CEO [EMAIL PROTECTED] Media Machines, Inc.www.mediamachines.com Add 3D content to your web page with the Flux Player. Go to www.mediamachines.com to upload and share your 3D content. - - for list subscription/unsubscription, go to http://www.web3d.org/cgi-bin/public_list_signup/lwgate/listsavail.html
Re: [vos-d] s5 design overview
Ken Taylor wrote: Peter Amstutz wrote: 1. Memory footprint The current s4 design has a lot of per-vobject overhead, leading to a significant memory footprint. The development version improves on this a bit, but the honest truth is that the implementation was not written with memory efficiency in mind. The s5 design will attempt to address in various ways, including attempting to directly minimize the byte count of crucial classes and data structures, and by using the flyweight pattern to collapse identical classes into a single shared instance. In particular, symbols (method names, message fields, types, etc) will be stored in a single global symbol table. This will ensure that such strings (which are expected to be used a lot in the system) are not duplicated, and has the convient effect of also making string comparison a constant-time pointer comparison instead of a linear time compare. This seems like a very good optimization, given how string-heavy the system is. Could string tables also be used to compress COD files more? How about network optimization by having two sites share a string table (or have a static standard string table of commonly used strings in the core protocol?). Also ... are properties stored as strings at the moment or as native bytes (I actually don't know this)? If they're stored as strings, compressing them to native data structures would probably be a big win too (same thing goes for properties with storing them in COD and sending them over the network). [I also had another idea related to network optimization -- which is unrelated to memory footprint. The idea is particularly for large worlds with lots of objects to listen to: instead of listening update messages sending the whole message string and object identification, etc, have an optimized listen protocol, where a chosen-at-runtime tag is used to identify a certain kind of update message coming from a specific object, and that's all you need to have in the network traffic (other than the actual updated values, of course). This could even be done transparently at the network interface level] Another method for making the most out of the memory will be the ability to load vobjects from persistant storage on demand, and swap out rarely used vobjects. This will allow a site to contain many more vobjects than would otherwise fit in RAM. This Could this also be extended to support persistant transparent caching of remote sites that have been visited? Perhaps paired with a new method to query certain information about vobjects, such as is-cacheable and last-updated/version? To reduce the footprint of vobjects themselves, I am introduce a concept called embedded children. These are objects that appear in protocol terms to be independently addressable vobjects that can send and receive messages, but are actually stored as a field of another vobject. This emerged from the observation that while it was extremely powerful from a design pattern standpoint for properties to be first-class vobjects, in s4 this often led to situations where it hundreds of bytes of overhead to store even a single four byte integer (for example). As an embedded child, the child vobject is simply a normal data field in the parent class, and it falls upon the parent sends and receives messages on behalf of the child. Sounds reasonable... What reasons (other than asthetics/symmetry) are there for properties to be first-class? Will a property object ever have children? Will one ever be at site root with no other parent? Will one ever be a meta-object other than property? I guess you could have two parents sharing the same property if it's a big one ... Heh, well actually we tried that :) In s2 properties were indelible components of their parent objects. But it made everything more complicated and made the properties themselves much less useful. Being able to share properties is a critical feature of VOS that has emerged. And all the usefulness that comes from metaobjects/vobjects too-- Pete mentioned FileProperty and ExtrapolatedProperty (which no longer exist), but the new vostoolbox library I've been working on recently has several property subclasses; since they're metabobjects you can instantiate them remotely (e.g. in mesh, create foo property:property.foo With s5's new embedded children, you will still be able to optionally override an embedded child with a full Vobject. Yes. I've run into this ls at site root problem and it's a bit annoying :) And orphaned vobjects just seem like a lose. Related to this, I added a new setting and command to mesh, cache. The setting does an initial request for all objects when you enter a new object to cache them. This doesn't actually solve the problem (since you still have to wait for the initial cache) but it makes the actual ls command operate at a reasonable speed. Set settings in mesh with the set command (and you can
[vos-d] Flux Worlds Server Announcement
---BeginMessage--- Folks, We've been up to something over here - thought I would tell you about it before you heard it on the street. Media Machines has been developing a multi-user server based on a new protocol that we intend to put out into the open. We have dubbed it Simple Wide Area Multi-User Protocol, or SWMP (pronounced swamp). The intent is to work with Web3D and potentially other organizations to standardize SWMP. We will also supply a basic open source implementation. Our overriding goal-- one that we are pursuing with total passion and vigor-- is to create an open infrastructure for the Metaverse. We have wrapped SWMP into a server product called Flux Worlds. Flux Worlds is currently in alpha test. While the product is still several weeks away from beta test, we announced it yesterday with the goal of attracting early signups for the beta. We are also integrating a prototype of the new X3D networking nodes being developing by the Networking Working Group, right into Flux Player. The results look promising. Anyway, here is the announcement. We would love to have you be part of the beta when it's ready! http://www.mediamachines.com/press/pressrelease-03292007.php Remember, the Metaverse needs open protocols. Without them... everything else is Just a World. Yours virtually, Tony - Tony Parisi 415-902-8002 President/CEO [EMAIL PROTECTED] Media Machines, Inc.www.mediamachines.com Add 3D content to your web page with the Flux Player. Go to www.mediamachines.com to upload and share your 3D content. - - for list subscription/unsubscription, go to http://www.web3d.org/cgi-bin/public_list_signup/lwgate/listsavail.html ---End Message--- ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] How to host a product design dinner party
We don't know what our niche is yet. We have one main domain (3D) and a secondary domain (Web) but there might even be others. Actually when we first began this several years ago, we knew someone who knew someone intersted in building factory tracking systems, though we ended up not really considering that at the time. At one point I wanted to do wireless self-organizing sensor networks-- I still think that will be an emerging realm of innovation but I know that VOS is not a good fit for its requirements. I think we have some vague ideas on what we want our specific niches within 3D to be-- Peter and I may not even be able to explain it well yet. So, we're just trying to implement what we can, so we can show it to people and eventually find a niche. Reed On Thu, Mar 22, 2007 at 11:22:10AM -0500, Len Bullard wrote: The urge to focus on one single application is normal, but if you are building a toolkit such as VOS, it would be deadly. You're doing the right thing, but it violates two of the web myths: easy and simple. Simplistic analogies will sell it perhaps, but don't get trapped by your own press. VOS won't be a tool everyone can use. The niche that can can do a lot with it. I think that is Reed's point, yes? len ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Upcoming changes: factory, actions.
Ken Taylor wrote: Cool! I was actually thinking the other day that being able to select and inspect objects in Ter'Angreal would be useful and not super-difficult to implement on the current architecture. I like the ui:actions object as a sort of scripting approximation, though i'm assuming it will probably be supplanted by a more general user-scriptable-actions mechanism in future versions. Yes. It's meant to also complement server-side scripts. E.g. you make a script that can be triggered by some random message you invent. Then you can add an action that will let the user send that message with a button click. What also would be neat is an advanced mode which allows you to edit the properties on objects directly (assuming you have permission) -- including adding new child objects. Allow this to be done on the sector (or a sub-space of the sector, once that is added to a3dl), and you have basic real-time geometry building. Yes, we need that. I've been thinking about that a lot. We had a simple one back in the day, just did a few 3D properties. I think what we'll try to do is have a little editing pane/dialog in TerAngreal, but it will be provided by a library, so we will also have a more complex standalone editor too. This is another place that OTDs could be useful: if the object editor knows what types of properties to expect, then it can create useful GUI controls for them in a generic manner. Of course, before allowing all users the ability to add objects, it would be good to hack in some quotas/limits and auto-destruction of old objects, lest your server grind to a halt from a malicious user. But perhaps I'm thinking too far ahead at the moment ;) Yeah, I think we'll worry about that later. I'm pretty sure we'll be able to implement all kinds of quota or throttling access control behaviors in server plugins in the future, when they become neccesary, as long as we keep Identities in use, and also perhaps more robust/certain remote-site identification that might be coming in s5 IIRC?? Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Message handler problem
Another thought: does your derived class *have* to inherit Base virtually? Yes, basically. Well, in one case it doesn't and calling the method in the base class to register the handler works. In another case it has to be virtual. Maybe I can find a way to reorganize things to avoid it. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] XOD questions
Peter Amstutz wrote: On Thu, Mar 15, 2007 at 06:15:39PM -0400, Reed Hedges wrote: The reason I ask is that I want to load some 3D objects from a COD file, but then insert some non-3d children into one of those objects, and extend its types. This is the kind of thing that VOS is all about :) Practically speaking, I want to be able to re-export the 3D COD from Blender and clobber it while keeping my non-3d extensions seperate. So, it sounds to me like you want to append file A and file B to produce file C, and that some of those pieces in file B are intended to modify pieces of file A. I see why you might want to do that. Sort of. Here's an example of what I was thinking of: load file=3dworld.cod/xod/whatever / vobject parent=/obj-from-file type=ex:extra ... /vobject extend ref=/obj-from-file type=ex:weird-type / Well, I feel like it should be more purely declarative and reflected by the DOM structure, and not require that you have to in effect execute a stream of commands 1, 2, 3, 4, 5, 6 in a specific order scattered around the file to reconstruct the vobject structure. This being what COD is, sort of, right? Anyway, eventually when we have OTDs we could use those OTDs to generate DTDs or Schemas and be able to say a3dl:sector name=world a3dl:object3d_sphere name=foo property name=a3dl:position0 0 0/property a3dl:material name=a3dl:material ... /a3dl:material /a3dl:object3D_sphere /a3dl:sector Which would really be using XML to the fullest. Except for when you want a Vobject to have two types, then we need some other way to do that, like multitype-vobject name=foo a3dl:object3d_sphere ...object3d-related children... /a3dl:object3d_sphere misc:metadata ... metadata ... /misc:metadata /multitype-vobject or some other way of using seperate XML elements for different types. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] XOD questions
Peter Amstutz wrote: Well, the idea was more to support the ability to import other file formats (X3D comes to mind, although it's maybe not a good example since it's really an example of how not to design an XML schema) using a straightforward XSLT transform. Of course, we haven't yet tried writing any transforms so I don't know if it's actually feasable. I wrote a transform that goes from Doxygen's XML output to XOD. It was just an excersise to finally learn XSLT, which turns out to be really easy. I haven't tried it yet, I want to figure out how to be smart about inventing positions for 3d objects automatically. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] X3D
Len Bullard wrote: I will move on to X3D because eventually I will need some of the new features like Inlines with interfaces and bits like the Keyboard Sensor, the upcoming Network Sensor and the physics engine, or the Nice-to-Haves like the Boolean Sequencer that I can replicate in script but a node is easier. For now, I am building in VRML97 where the weather suits my clothes. Fortunately, it sounds like some good GUI editors are coming out (like Flux studio).I never did manage to find a really good GUI tool for building VRML97 that was really focused on VRML and supported all of it, though I was only looking at the free ones. (Back when I was able to actually do 3D for a job I ended up exporting VRML from a simple modeler called AC3D and then mucking about in it by hand slightly.) Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] [www-vrml] RE: [x3d-public] X3D Game Engine?
chris wrote: Lauren, you were clear enough - I was just reinterpreting a bit because I don't think I have seen such a thing for x3d. But there are some potential candidates as a starting point, such as vos, vrspace or deepmatrix, to perhaps link with an X3D browser. I just don't know enough about them to comment on their specific strengths/weaknesses. One of our plans for VOS is VRML and X3D support. Unfortunately I haven't made any progress on it recently. The VRML/X3D engine will run on one or more servers. Users will view the world in a client that is connected to those servers using the VOS network protocol and object models. Let me know if you want more info or want to help implement this. http://interreality.org for more about VOS. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Message handler problem
For one thing, apparently you can't do this: class Base { public: virtual void pure() = 0; templateclass T register() { VobjectBase::registerHandlerT(message, handler); } void handler(Message *m) { ... } }; class VirtualDerived : public virtual Base { public: VirtualDerived() { Base::registerVirtualDerived(); } virtual void pure() { ... }; }; ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] XOD questions
Peter Amstutz wrote: No, and it shouldn't do that -- the goal is to have the XML DOM structure reflect the VOS structure in a meaningful way. If you spread essential information for a single vobject all over the document such that it requires that you must process the entire document before being able to do anything, you're not really working with XML, you're working with XML-flavored tag soup. Of course, the internal cross-references we do have (mostly confined to the link tag, I think, which *is* a special case) use VOS paths instead of XML identifiers and anchors, but that's another discussion... The reason I ask is that I want to load some 3D objects from a COD file, but then insert some non-3d children into one of those objects, and extend its types. This is the kind of thing that VOS is all about :) Practically speaking, I want to be able to re-export the 3D COD from Blender and clobber it while keeping my non-3d extensions seperate. I don't see why the XOD format should prevent stuff like that-- which are important abilities we have in VOS. If we have link why not parent (or the parent attribute)? parent would just be the inverse of link. XML is too restrictive here. XOD is already very specific to VOS in its element names; if you want to reuse a XOD along with some other XML you're going to be applying a trasformation to it anyway, and I'm pretty sure XSLT and XPATH are powerful enough to gather objects declared in different places in the file that have parent child relationships. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Metaobject Doc
Reed Hedges wrote: OK, cool. We have needed that kind of thing for a long time. We had a simple way of doing this called OTD (object type definition) a while ago, but then all the code change and all the OTDs went out of date :) http://interreality.org/wiki/ObjectTypeDefinitions http://interreality.org/wiki/ArchaicOtdFormat ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] VOS apps...
Lalo Martins wrote: But that's more or less what we're talking about, at least for some of those cases if not all. A properly 3d IM app using libgaim wouldn't be too hard, for example. This is basically what the IRC bridge does, except it doesn't create any graphical object to represent people. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d