"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

s5 properties proposal

Why the current s5 design for "embedde children" doesn't work...

Background.

A key aspect of the design of VOS s3 and s4 is the parent/child list.  
This is an associative array of name/value pairs, where the value is a 
link to another vobject.  This list of outgoing links plays a key role 
in VOS as the primary mechanism of linking vobjects to "properties" 
(other vobjects storing values that describe the first vobject) as well 
as the overall organization of vobjects into a (mostly) hierarchical 
namespace.

Advantages of this scheme (that have gotten us pretty far):
 - A naive implementation is very easy, only need the Vobject class.
 - Serialization/persistance is pretty easy.
 - Introspection of the vobject structure is straightforward.
 - Accomodates lists (order-sensitive) and maps (key/value pairs).
 - Vobjects can share properties and link to remote properties.

Disadvantages of this scheme (that we learned the hard way):
 - An efficient implementation is very difficult.  Since properties are 
standalone vobjects, there is a great deal of overhead associated with 
it: the property vobject has its own child list, access control list, 
listener list, etc.
 - Because of the overhead, scaling up to large numbers of vobjects 
(over 10,000) turned out to be a problem.
 - The child list is always order sensitive, even when not required or 
desiriable.
 - Poorly suited to object/relational mapping.
 - Associative array semantics permits duplicate, redundant or 

s5 properties again

Some ideas for a new design for properties.

Replace the vobject "child list" with a "property map".  A property is a 
slot that holds some value, which can be a basic type (int, string), a 
compound type (struct, array or map) or a reference to another vobject.  
Reflection permits iterating over all entries in the property map.

Unlike links in the child list, the order of properties is not 
significant, and two properties of the same name are not allowed.  Where 
order is important, data can be stored in an array property.

Paths are still available.  For example:

/vos/Namespaces/core/Types/String

Where
"vos" is a vobject
"Namespaces" is a map of names to vobject references
"core" is a reference to a particular vobject
"Classes" is another map, part of "core"
"String" is a reference to another vobject

Another example:

/scene/objects/_2/position/x

Where
"scene" is a vobject
"objects" is a list of vobject references
"_2" is the reference at index 2 in the list

s5 vobject properties

Things have been quiet lately, but I assure you, we are still working!

Anyway, something I've been mulling over --

One of the planned changes in the design of s5 as compared to s4 is the 
integration of plain-old-data properties as part of the vobject class 
definition.  In s3 and s4, property data (simple stuff like integers, 
strings, position vectors, etc) is stored by special vobjects with a 
special "property" type.  This has some nice advantages in that the 
properties describing a vobject are just child links to other vobjects, 
so browsing and editing vobject structures is very straightforward.

The disadvantage of this scheme is that it is very inefficient.  It 
results in vast amounts of overhead for storing what amounts to a field 
in a data structure, and it also introduces coordination issues among 
property vobjects that should otherwise be logically tied closely 
together.  It would be much better (more memory efficient among other 
things) to be able to store simple data as part of the vobject class 
directly.

So, for s5, the idea I originally had was to try and meet these goals 
halfway and have "embedded children".  These would be sort of "virtual 
vobjects" (hah) that would appear to be child vobjects, but be managed 
entirely by the parent vobject they are embedded in.  This would combine 
the benefits of the "everything is a vobject" abstraction with the 
advantages of storing things more efficiently.

As always, though, the devil is in the details:

 * For the "embedded child" concept to work (or even make sense), these 

[[Spam?]] RE: April 70% OFF

_______________________________________________
vos-d mailing list
vos-d@...
http://www.interreality.org/cgi-bin/mailman/listinfo/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

Wiki editing fixed

I fixed the wiki permissions so that anyone who is logged in should be able to
edit pages.  Click the "login" link at the top.  If you don't have a login yet,
follow the instructions, though it's a bit strange. You have to go to
UserPreferences, fill in the form (enter your password twice, ignore the
confusing label). 

Let me know if there are any problems.

There is a seperate group that has permission to delete and revert pages.  If
you need a page deleted or want that permission let me know.

Reed

--

-- 
http://interreality.org/~reed

Fun with the generator

Well.  I spun off the web MVC stuff into a new library (hypervos).  That 
opened a pandora box of generator fun 

I'm a bit exhausted, so I'll go over them briefly; if you need more 
detail, ask, and I'll elaborate tomorrow.  Or check out my branch and 
play around yourself.

Also, I'm not saying these need to be fixed urgently; just that we need 
to know about them for the future.

1: mod_vos.xod (and my other projects) extend a lot of classes from the 
new library.  But since the generator doesn't know about those, it 
reports broken links and generally doesn't know what to do.

The answer to this may be in my plugin loader; I might try my hand at 
solving it later this week.

2: The #define guards use only the file name.  If you have headers with 
the same name in different libraries (eg MVC.hh)... you get my point I 
think.  I manually changed them to eg #define _hypervos_MVC_hh_, might 
make the change in the generator later.

3: Much worse happens if you have namespaces with the same name  the 
generated code has things like MVC::View all over, which of course 
generate "ambiguous namespace reference" errors galore.

4: This is unrelated to the hypervos move, I noticed it earlier.  If my 
class "Foo" extends "vos::core::Bar", then Foo.hh will have
#include "Bar.hh"
which of course won't work so well... should be <vos/Bar.hh> 

5: Just to put in a positive note and because I like the number 5 better 
than 4, I'll say I found great joy in recent s5 work; in particular 
Vobject::clone() saved me hours of toil!

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/

Choosing a GUI toolkit for S5

Posted at: http://interreality.org/phorum/read.php?2,222,222#msg-222
reed wrote:

To help choose a GUI toolkit to use for the S5 user interface app, I made this comparison chart.  wxWidgets and
Qt are the top contenders, though I added a few others to consider.

If you have any corrections or know any of the missing pieces of data ("unk"), please correct it on the wiki or
reply here.

http://interreality.org/wiki/ChoosingAGUIToolkit

Reed

serialization

My current task is working on a serialization framework for structs and Vobjects.  This will 
handle loading and saving state for vobjects, and provide the basis on which to implement 
marshaling and persistance.  Being able to load and save structs will also make it possible to 
start working on some of the upper layers of the VOS stack, such as A3DL (which needs to be able 
to efficiently represent data like vertex arrays.)  I have worked out an efficient template-based 
approach which supports arbitrary serialization/deserialization methods, so we can easily have 
binary, XML, YAML, JSON etc serializers, and message encoding for VOS network protocols will 
probably be built on the serialization framework as well.

--

-- 
[ Peter Amstutz ][ tetron@... ][peter.amstutz@...]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey:  pgpkeys.mit.edu  18C21DF7 ]

_______________________________________________
vos-d mailing list
vos-d@...
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

SIGGRAPH multiuser virtual worlds/applications BOF

_______________________________________________
vos-d mailing list
vos-d@...
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d