Volumes of Reading


Here’s an interesting chain of progression from yesterday.

I read yet another TechCrunch article on virtual worlds (dying a little inside, given the wacky coverage). In this instance, Erick Schonfeld interviews Philip Rosedale at a conference of smart people over the coming age of "browser-based" virtual worlds, which PR says are not a threat to Second Life, and to which Schonfeld asks/implies (off-camera) that Rosedale is in denial.

For the record, I agree with Philip on this one — as long as "browser-based" worlds don’t offer the deep user-created-content that SL life does, SL will have that niche all to itself. How big that is is another question. And how soon it will be until one of the "3D chat" clients pushes into that territory is yet another.

But here’s the reason for the apparent disconnect between Rosedale and Schonfeld: "Browser-based" is a term of art that Schonfeld repeatedly mis-uses, IMO. Philip knows that the term implies that an app is hosted in the browser. Schonfeld seems to think it means that an app’s window simply appears in a web page. There’s a big difference.

Second Life could, today (i.e., without too much work), be set up to run in a small window inside any web page. It’s mainly a matter of where the output window is housed. The compiled code, including all OpenGL rednering, would essentially be the same, and a new ActiveX shell would be the main difference.

This is why Google Earth can run in a browser window today* but still use Intrinsic Alchemy under the hood for its 3D rendering, as it did since 2000. Running in the browser, on the other hand, fundamentally means using the browser’s own resources, Javascript, 3D canvases, AJAX fetch, etc.. in a cross-platform and zero-download way to do all the work.

"Browser-based" in Schonfeld’s usage confuses these two concepts — And if there was no end-user difference, I wouldn’t complain. But there is.

As to whether those PC apps like Lively and Vivaty that appear in a browser window are a threat to SL — well, it will be a function of their features over time. They still require platform-native plugins and therefore downloads, small as they may be, which limits adoption as a full PC app does. And they still suffer from other in-browser-window issues, like what happens if I hit the back button or refresh the page, or simply scroll the window down so I don’t see my nice virtual world anymore. Or worse yet, what happens to my mouse wheel, for which, for example, the GE plugin steals control. Philip is right that it’s simply not as immersive as a full-screen stand-alone client, and web integration of 3D worlds is a much more complex issue than just placing windows on pages.

Anyway, slogging through the comments (most of them quite intelligent this time), I found Adam Frisby’s blog. He’s doing some interesting work that would let a SL/Lively client run right in the browser, using an obscure Microsoft API called XBAP, which I’m going to need to learn more about…

Sliverlight is, IMPO, a direct analog to Flash for making rich media browser-based apps. XBAP is more of a sandbox that allows you to run a general PC app in a browser window, but in a way that’s more acceptable, perhaps, (certainly more secure) than ActiveX. It is cross-browser at least, but would require more Mono support than exists on the Mac and Linux right now. Silverlight might be preferable in some ways, but its 3D support, as with Flash to date, is lacking. XBAP might have more potential.

Clicking through Adam’s blog, I then found this page, in which the other people working on a more open version of Second Life lament the terms of use for LLVolume.cpp, which I coincidentally wrote back in 2001. It’s open source lately, but apparently not open enough for their needs.

Now, LLVolume is interesting because it’s the code that creates all 3D objects (excluding avatars and terrain). Philip wanted spheres, cones, cubes, torii, etc.. to be his virtual legos, simple and small. They originally expected to write some code for each kind of prim. I felt it was much simpler to write a common block code to create all primitives at all levels of detail, including the newer flex prims that they added after I left. And indeed, it only took about two weeks and 200 lines of code to alpha-test all the prims they wanted. [The only one that’s unique, in fact, is the sculpty-prim, which is basically a texture-lookup (height map) deformation on a sphere, and I’d argue that this should be a surface feature of all prims, just as bump-mapping would be.]

The problem these open source devs found was that LLVolume is not well documented and/or is strange to people used to traditional geometry in OpenGL. So I’ll make this offer: if Adam or his folks need more information on the core LLVolume concepts, I’ll pitch in. I’d be happy to write a "How Second Life Primitives Really Work" post sometime, if there’s sufficient interest, and it’s clearly open source at this point. The main issue is making all of the images to go along with the discussion. But I can swing it in the next month or two, I think. Just let me know.

I do have one big caution though: the thrust of this open sim work seems to be to promote SL as an Open Standard. I certainly hope SL prims don’t become standard in their current form. Even the original code I wrote back in 2001 could do much more than spheres and cubes, and was mainly limited by the SL protcol considerations.

If anything is going to be standardized, I’d much rather see the broader language of procedural geometry become more widely used, rather than SL’s very shallow cross-section of that field.

The benefit would be that complex objects could be represented in a very concise form, and the goals Adam and others have regarding "fingerprinting" and preserving author-credit would become much, much easier to realize. That’s a much longer discussion, but one I hope to take to the streets in the coming months.

 

____________

* in this case, the GE team seems to have done more than just recompile the GE app as an activeX control. They stripped out the UI, added the Javascript hooks for nearly everything, and most importantly, made some core functionality (probably streaming and caching) live outside the plug-in. That makes it possible to run 4 instances and start up very quickly after the first instance is run. And that partly solves the "hitting the back button" problem, though not entirely.

 

  1. #1 by Peter Durkson on August 2, 2008 - 11:33 am

    Aloha,
    We exploring the possible use of Second Life to teach baby boomers the ABCs of aging in place. Can you point us to any SL “learning sites” and/or blogs to help us with our learning curve?
    Thank you,
    peter@mauiagewave.com

  2. #2 by Adam Frisby on August 3, 2008 - 4:10 am

    Oh, that would be fantastic – it’d be something I would verymuch appreciate. Being able to reimplement this from the principles would probably be a good way to go with getting it into the public domain in a way that everyone can use it.

    Many thanks,

    Adam Frisby

  3. #3 by John Hurliman on August 3, 2008 - 3:59 am

    Great post, thank you for this. I wrote the C# port of your llvolume.cpp code, it lives in the libOpenMetaverse (formerly libsecondlife) repository as OpenMetaverse.Rendering.GPL, soon to be moved to an external repository. It exists as an optional rendering plugin that can be loaded at runtime. The issue developers are running into is that most of the code surrounding open source implementations of Second Life (libOpenMetaverse, OpenSim, OpenViewer, etc) have a BSD license and lots of individual contributors. Shipping a simulator or viewer with the C# port of llvolume.cpp, a derivative work of GPL code, would go against the wishes of countless contributors that wrote BSD licensed code.

    An active contributor to the OpenSim project has made a lot of progress on a BSD licensed prim mesher called Meshmerizer, and any more information on how the prim system works would surely be invaluable.

    The idea is not to codify Second Life prims as a gold standard, but without a solid understanding and reference implementation of the current system there is no basis to have a discussion about evolving or extending the system. There are also a lot of interesting possibilities to enhance the current system (offline content creation is one I have been looking at), and a BSD licensed implementation would allow this without breaking the trust of the contributors that have built these projects.

  4. #4 by Dahlia on August 6, 2008 - 8:08 pm

    I have to say I agree with you about the limitations of the “prims” used in SecondLife™. I would much rather see a more flexible and capable system available for new 3D virtual reality applications. Unfortunately there is a lot of momentum in the Opensimulator project with respect to the geometry displayed with the SecondLife™ viewer so it’s difficult to add something new until a more capable viewer becomes available.

    I have had some success creating prims for use as physics proxies in Opensimulator (see the above comment from John Hurliman) and I can duplicate any shape to a high degree of accuracy for all of the prim parameters, but when combined, some minor inaccuracies become evident as prims are resized beyond the normal 10x10x10 meter limits. My prims also use far fewer vertices than the equivalent viewer prims as an attempt to save server memory. There are some fundamental bugs in the profile generation that need to be addressed before all profile cut angles are available, but I’m designing a new profile generator that should fix that.

    I was able to assume many of the properties of prims by carefully noting the changes in size and shape as I varied the parameters in the object editor. I’m not 100% certain that all my assumptions are correct but I believe I am quite close for most of them. I have noticed some interesting inconsistancies such as nonlinearity in some profile cut parameters which I haven’t yet accounted for, but for now I am close enough range for a believable collision mesh for all prim shapes tried to date.

    My code is available under BSD license in the Opensimulator SVN. It is a work in progress and changes should be expected. I would be quite interested in your insights into how prims work if I could use them to implement BSD licensed code. I would also be interested in your thoughts on a more comprehensive definition of procedural geometry. Please contact me at the email address I supplied if you would like to discuss this further.

  5. #5 by avi on August 6, 2008 - 8:20 pm

    Sounds like you folks are pretty far along on prim-generation. But what I’ll do (after I answer some questions from Tish) is write up a general “how prims work” post, for which I will be diligent about sticking to my NDA and only discussing what Linden makes public in the form of the source code.

    After that, I hope to write another post about where I think procedural geometry should go in the future. But I should keep the two topics separate.

  6. #6 by qarl on August 24, 2008 - 7:59 pm

    > which is basically a texture-lookup (height map) deformation on a sphere, and I’d argue that this should be a surface feature of all prims

    actually – they’re not. rather than a height map – they are a position map – which is a subtle but important difference: they allow for arbitrary shapes, not just star-like shapes.

    and once you realize that – you’ll see that it makes no sense to apply them to underlying prims. they ARE their underlying shape.

    K.

  7. #7 by avi on August 24, 2008 - 11:17 pm

    Qarl, thanks for the clarification to my overly-simplistic presentation of the concept. Separating the data into 3 channels instead of a single grayscale heightmap is an improvement over the basic 2D heightmap concept. But I think it’s pretty clear ‘arbitrary’ does not mean ‘all’ — it’s a bit misleading, in fact, considering the limitations on scupty prims.

    A more sophisticated procedural geometry system with basic displacement maps on top would actually be a much more effective way to go. And by leveraging the two together, you can give much easier editing tools to manipulate complex objects once they’re imported.

    All you’re arguing for now is a limited case of geometry import and compression that makes some heavy assumptions about best he distribution of samples.

  8. #8 by qarl on August 25, 2008 - 12:04 am

    sorry – i was just commenting on your statement “and I’d argue that this should be a surface feature of all prims” – which is clearly a misunderstanding of what the sculpt map does.

  9. #9 by avi on August 25, 2008 - 12:27 am

    if you insist — I’d argue that a sculpt map could be applied to prim faces, as I mentioned. The misunderstanding was in the structure/method of displacement, but not in the nature of the result.

    Basically, a sculpt map, like any geometric representation or compression scheme, must exist relative to some coordinate system. For the case of sculpties that are not based on prims (the implemented case), that coordinate system would have position, rotation, and maybe scale. And since there’s no underlying volume, the map must also form a closed surface to define its own volume.

    For the case i’m talking about, the sculpt map would probably inherit the coordinate system normal to its underlying face. In some cases, that could imply a curved space to deal with. But it’s not that hard, given the information known during each prim’s construction.

    What is hard is aligning the sculpt map deformations from adjacent faces and maps to match up without cracks. Still, it’s entirely possible. Some virtual globes, for example, have forms of geometry compression that encode X,Y,Z for terrain, but that information is always stored relative to a coarse elevation per tile. There are indeed solutions to these sots of problems.

    My point is that the assumption that a single map define a single enclosed volume is not necessary, if those other issues are handled properly. And at worse, the normal-to-face+warping method could even be used to warp space for a single prim-wide scuplty map, with interesting results — like working cut and twist, for example.

(will not be published)


  1. Volumes of Reading
  2. Adam Frisby » Blog Archive » Procedural Geometry
  3. New Map Links | geo2web.com
  4. UgoTrade » Blog Archive » Xenki: An “In Your Browser Viewer” for OpenSim and Second life
  5. RealityPrime » Some Definitions