Subject: Re: [mmox] RealExtend Teleporting Between Worlds

From: "[email-masked]" <[email-masked]>
Date: Wed, 25 Feb 2009 23:22:22 GMT

>Actually, this is not true with the 'standard tres' on the
SecondLifeGrid ( name taken from http://secondlifegrid.net/ ).   The
protocol specifies that each 'Primitive' has a type identifier called,
'PCode'.   There is a PCode for 'Primitive', there is a 'PCode' for an
Avatar, there is a PCode for a Tree, there is a 'PCode' for Grass.
(Ref: http://wiki.secondlife.com/wiki/PCode )  Additionally, the
protocol has an identifier for type specific information called
'State'.   Each of the 'standard tree types' have a specific value in
this 'State' identifier.   There is absolutely no user created content
sent to the client for 'standard trees and grass' beyond the fact that
it's a tree and the type of tree based on a previously specified
limited group of trees that are in the client, which I'll list below;

Pine1 = 0,
Oak = 1,
TropicalBush1 = 2,

Anyone looking at those trees can tell they aren't Linden trees of the standard issue, but look more like Lilith Heart trees.

And precisely because they don't look like Linden trees, I asked who is the author/creator and where were they created.

Yes, I realize Linden tree generation is a totally different thingie than the usual prim-making, and works on a different principle of virtuality, which I guess you've outlined.

BTW, did the Lindens let you copy their tree-generating program, and do they mind if you port that capacity into other worlds? Because Linden trees are special, in that they can blow in the wind and such the way home-made trees can't.

Some of the Linden trees are nice, but I have to wonder, if you were going to make another world, even a clone-world reverse-engineered, why on earth would you copy that dying cocoanut tree and the weird eel grass?! Couldn't you make something different over there?

____________________________________________________________
Become a Medical Transcriptionist. Click here to find schedules designed to fit your life.
http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTJjHaxNmAyItCqkAlDcdx5EnBR4D8iAtzWiJgUYAtcOSIPDHYyfh2/

---

From: Dan Olivares <[email-masked]>
Date: Wed, 25 Feb 2009 18:30:23 -0500

"Anyone looking at those trees can tell they aren't Linden trees of
the standard issue, but look more like Lilith Heart trees"

To discover the actual identity of those trees, parhaps you should
contact Jani.   To me, they looked like 'standard linden trees', to
you they look like 'Lillith Heart' trees.

"BTW, did the Lindens let you copy their tree-generating program, and
do they mind if you port that capacity into other worlds? Because
Linden trees are special, in that they can blow in the wind and such
the way home-made trees can't."

The lindens license their client under the GPL, they licence the
multimedia content under the Creative Commons Sharealike license.  The
'algorithm' for rendering the trees is in the client.  The multimedia
used in the trees are in the client.  Therefore, the onus here is on
realXtend to comply with the GPL and CC Sharealike licenses regarding
displaying 'standard Linden' trees.

"Some of the Linden trees are nice, but I have to wonder, if you were
going to make another world, even a clone-world reverse-engineered,
why on earth would you copy that dying cocoanut tree and the weird eel
grass?! Couldn't you make something different over there?"

LOL, indeed, indeed :D

Sincerely

Daniel Olivares

On Wed, Feb 25, 2009 at 6:22 PM, [email-masked]
<[email-masked]> wrote:
> Love Graphic Design? Find a school near you. Click Now.
> http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTOroy2KGhDyIhzpw9bFepA2hBUEDYIvudCrEqYNkA7fFsx81qBsw4/
>

---

From: "Hurliman, John" <[email-masked]>
Date: Wed, 25 Feb 2009 16:55:39 -0700

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>[email-masked]
>Sent: Wednesday, February 25, 2009 3:22 PM
>To: [email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: Re: [mmox] RealExtend Teleporting Between Worlds
>
>Anyone looking at those trees can tell they aren't Linden trees of the
>standard issue, but look more like Lilith Heart trees.
>
>And precisely because they don't look like Linden trees, I asked who is
>the author/creator and where were they created.
>
>Yes, I realize Linden tree generation is a totally different thingie
>than the usual prim-making, and works on a different principle of
>virtuality, which I guess you've outlined.
>
>BTW, did the Lindens let you copy their tree-generating program, and do
>they mind if you port that capacity into other worlds? Because Linden
>trees are special, in that they can blow in the wind and such the way
>home-made trees can't.
>
>Some of the Linden trees are nice, but I have to wonder, if you were
>going to make another world, even a clone-world reverse-engineered, why
>on earth would you copy that dying cocoanut tree and the weird eel
>grass?! Couldn't you make something different over there?
>

The Second Life simulators and OpenSim are only sending a single number to say what type of tree the viewer should render. All of the fancy code for drawing the tree and making it blow in the wind is in the Second Life viewer. I agree that it would be very nice if someone improved the default trees in the Second Life viewer.

This brings up an important topic to consider in interoperability. Most (if not all) virtual platforms use shortcuts like this to offload processing on to the client. But saying "draw tree type 7" doesn't mean the same thing (or anything) to Forterra, VastPark, etc. Would you create interop versions of the trees (mesh and texture representations), or just not allow that content to move across boundaries?

John

---

From: Christian Scholz <[email-masked]>
Date: Thu, 26 Feb 2009 10:14:58 +0100

> This brings up an important topic to consider in interoperability.
> Most (if not all) virtual platforms use shortcuts like this to
> offload processing on to the client. But saying "draw tree type 7"
> doesn't mean the same thing (or anything) to Forterra, VastPark, etc.
> Would you create interop versions of the trees (mesh and texture
> representations), or just not allow that content to move across
> boundaries?

I think requiring having some data in the client will not scale. Why not 
give it an URL as well and just tell the client to cache it long enough? 
Should be easy with a REST approach. For SL it might be trees for a game 
it might in fact be everything if no user generated content is allowed.
A specialized game client could even be so clever as to download it in 
advance and have some proprietary way of checking whether it's still 
uptodate or not.
Or it might be a list of things to preload with a caching header on that 
list and a must-revalidate. Then only if the list changes you have to 
download it again.

-- Christian

-- 
Christian Scholz
Blog: http://mrtopf.de/blog
Company: http://comlounge.net
Podcasts: http://datawithoutborders.net, http://openweb-podcast.de

---

From: Lawson English <[email-masked]>
Date: Thu, 26 Feb 2009 02:54:53 -0700

Christian Scholz wrote:
> I think requiring having some data in the client will not scale. Why 
> not give it an URL as well and just tell the client to cache it long 
> enough? Should be easy with a REST approach. For SL it might be trees 
> for a game it might in fact be everything if no user generated content 
> is allowed.
> Or it might be a list of things to preload with a caching header on 
> that list and a must-revalidate. Then only if the list changes you 
> have to download it again.
>
Seems to me that some default content might be distributable as 
libraries/plugins. Any world that wants to allow the display of SL-like 
trees could toss out "SL tree-type 7" in the appropriate message. 
Likewise with some other standardized content found in other worlds. 
Would LL or any other world-provider want to do this? If it facilitates 
interop, perhaps... Just as there eventually will be universal avatar 
formats, there might be universal generic trees, etc. Hmmm... prims, anyone?

L

---

From: "Frisby, Adam" <[email-masked]>
Date: Thu, 26 Feb 2009 04:57:05 -0500

If this is to be done, my suggestion would be to not pick LL-style trees, and standardise on something which more resembles a L-System description. (or perhaps build a standard interface which resembles something like speedtree)

Adam

> Lawson English
> Sent: Thursday, 26 February 2009 1:55 AM
> To: Christian Scholz
> Cc: [email-masked]
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox

---

From: Jon Watte <[email-masked]>
Date: Thu, 26 Feb 2009 10:45:09 -0800

Christian Scholz wrote:
> for a game it might in fact be everything if no 

I agree. In interop terms, it will say "the visual presentation of this 
object uses mesh http://www.whatever.com/some-url-here" and you can 
cache that just like you cache other web data.

> advance and have some proprietary way of checking whether it's still 

HTTP already has a versioning mechanism. However, for a game with 50,000 
assets, doing 50,000 "HEAD" or "if-modified-since" requests might not 
scale so well ;-)

Sincerely,

jw

---

From: Jon Watte <[email-masked]>
Date: Thu, 26 Feb 2009 10:47:29 -0800

Lawson English wrote:
> libraries/plugins.

So, if I'm running FreeBSD on a MIPS processor, where do I get the 
appropriate plug-in?
What if I'm using Java on a Blackberry?
Or C++ on Win64?

I think that transporting any kind of behavior isn't really feasible, 
unless you want to specify a common language, runtime and execution 
environment. There are two of those that could be used: Java JRE or 
Microsoft .NET. I think you'll have trouble getting everyone in the 
world to agree on any one of those.

Sincerely,

jw

---

From: Lawson English <[email-masked]>
Date: Thu, 26 Feb 2009 12:04:41 -0700

> world to agree on any one of those.

How many languages will we be using? There's only a handful of graphics 
engines to worry about, regardless of language. Seems to me that SL uses 
OpenGL while others use DirecctX. I'm not advocating OpenGL and DirectX 
compatibility, so we're left with describing things in terms of one 
graphics engine. Are you suggesting that Linden Lab standard trees are 
too complex to bother with implementing algorithms for in your favorite 
language + OpenGL?

Lawson

---

From: Jon Watte <[email-masked]>
Date: Thu, 26 Feb 2009 11:56:53 -0800

Lawson English wrote:
> How many languages will we be using? There's only a handful of 
> graphics engines to worry about, regardless of language. Seems to me 
> that SL uses OpenGL while others use DirecctX. I'm not advocating 
> OpenGL and DirectX compatibility, so we're left with describing things 
> in terms of one graphics engine. Are you suggesting that Linden Lab 
> standard trees are too complex to bother with implementing algorithms 
> for in your favorite language + OpenGL?

I am suggesting that the problem is a lot wider than just trees.
There.com describes terrain as a guided fractal system. Are you saying 
everyone should implement that system to be able to display There.com 
terrain?
OLIVE describes objects in the form of composition of baser types using 
XML schema. Are you saying everyone should implement that system to be 
able to display OLIVE objects?

Or are trees somehow special, when all other kinds of geometry or 
objects (buildings, water, ships, humans, weapons, telephones, cars, 
...) are somehow less special? Who decides what kinds of geometry are 
special, and what the "canonical form" of those kinds of geometry are?
I believe that trying to go that line of reasoning will end up in very 
much effort, and very much bickering, for very little actual benefit. 
It's much easier to say "entity at point 3,4,5 uses mesh 
http://www.second-life.com/models/tree-oak2.dae."

Sincerely,

jw

---

From: Lawson English <[email-masked]>
Date: Thu, 26 Feb 2009 13:05:57 -0700

Jon Watte wrote:
>> OpenGL and DirectX compatibility, so we're left with describing 
>> things in terms of one graphics engine. Are you suggesting that 
>> Linden Lab standard trees are too complex to bother with implementing 
>> algorithms for in your favorite language + OpenGL?
>
> OLIVE describes objects in the form of composition of baser types 
> using XML schema. Are you saying everyone should implement that system 
> to be able to display OLIVE objects?
>

Ah, OK, though,  it seems to me that SOME things should be built into 
the client in some ways, while others can be downloadable as separate 
meshes... perhaps some way of compromising...

a profile might say "uses SL trees, available as this plugin and 
connection or from server xyz as generic meshes and OLIVE objects, 
available via this plugin and connection or from server uvw as generic 
meshes"

etc.

L

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 26 Feb 2009 16:00:29 -0500

This may be a simplistic (i.e., dumb) question, but I work in  
Telepresence, and can certainly
see mixed Virtual World / Real World telepresence sessions (and, even,  
Telepresence between
incompatible virtual worlds as a means of connecting the unconnectable).

Are there any special issues with this, or is this just a subset of  
the multiple virtual worlds connection problem.

Regards
Marshall

On Feb 26, 2009, at 2:56 PM, Jon Watte wrote:

>> graphics engines to worry about, regardless of language. Seems to  
>> me that SL uses OpenGL while others use DirecctX. I'm not  
>> advocating OpenGL and DirectX compatibility, so we're left with  
>> describing things in terms of one graphics engine. Are you  
>> suggesting that Linden Lab standard trees are too complex to bother  
>> with implementing algorithms for in your favorite language + OpenGL?
>
> There.com describes terrain as a guided fractal system. Are you  
> saying everyone should implement that system to be able to display  
> There.com terrain?
> using XML schema. Are you saying everyone should implement that  
> system to be able to display OLIVE objects?
>
> objects (buildings, water, ships, humans, weapons, telephones,  
> cars, ...) are somehow less special? Who decides what kinds of  
> geometry are special, and what the "canonical form" of those kinds  
> of geometry are?
> I believe that trying to go that line of reasoning will end up in  
> very much effort, and very much bickering, for very little actual  
> benefit. It's much easier to say "entity at point 3,4,5 uses mesh http://www.second-life.com/models/tree-oak2.dae 
> ."
>
> Sincerely,
>
> jw
>

---

From: Gareth Nelson <[email-masked]>
Date: Thu, 26 Feb 2009 21:12:05 +0000

The solution here is for the clients that want to use standard content
to use content packs. Look at something like the modern iD software
FPS games for example. Each game has the engine (under the GPL) and
lots of .pak files  which contain the levels, models, sounds, scripts
etc. If each .pak has a URL from which the latest version can be
fetched, then if-modified-since requests make more sense for
auto-updates on those particular clients that need it.

I could imagine something being sent to the client such as "Get the #7
tree model from http://secondlife.com/content/trees.pak" and the
client caching trees.pak.

On Thu, Feb 26, 2009 at 6:45 PM, Jon Watte <[email-masked]> wrote:
>> Should be easy with a REST approach. For SL it might be trees for a game it
>> might in fact be everything if no
>
> object uses mesh http://www.whatever.com/some-url-here" and you can cache
> that just like you cache other web data.
>
> assets, doing 50,000 "HEAD" or "if-modified-since" requests might not scale
> so well ;-)
>
> Sincerely,
>
> jw
>

---

From: Lawson English <[email-masked]>
Date: Thu, 26 Feb 2009 17:01:47 -0700

> the multiple virtual worlds connection problem.

Actually its hopefully a soon-to-be a [partially] solved subset. We had 
a meeting in-world (in Second LIfe) last Friday to try to explore the 
relevant issues for a jointly shared virtual telepresence at the BOF 
meeting in march. The transcript is found here:

http://wiki.secondlife.com/wiki/MMOX/Chat_Logs/2009-2-19

Lawson

---

From: Jon Watte <[email-masked]>
Date: Thu, 26 Feb 2009 16:26:57 -0800

Lawson English wrote:
> Actually its hopefully a soon-to-be a [partially] solved subset. We 
> had a meeting in-world (in Second LIfe) last Friday to try to explore 
> the relevant issues for a jointly shared virtual telepresence at the 
> BOF meeting in march. The transcript is found here:

Does anyone have the actual details for that BOF meeting?
Time, place, registration details?

Sincerely,

jw