No subject
Sat Apr 19 02:14:48 UTC 2014
evolution of virtual worlds. It is no surprise that most Opensim developers
wish to go beyond that first step, learning from past mistakes and finding
better models for the future.
I mentioned earlier our work at the IETF on new VW protocols, in which LL
are a leading party --- see https://www.ietf.org/mailman/listinfo/ogpx ,
the mailing list of the VWRAP working group. What may surprise you is that
even Lindens know that the current SL is not a good model for the future,
which is why the protocols being discussed go far beyond their legacy ones.
Indeed, Lindens will be facing a huge rewrite if this work bears fruit.
When even Lindens don't wish their future to be constrained by the current
SL design because they know its many problems, this really highlights how
bad it would be for the Opensim team to do so. :-)
I hope that one or more of these issues resonates with you, and makes it a
bit clearer why Opensim really cannot afford to align itself with SL. There
is no future in looking backwards.
Morgaine.
=======================================
On Mon, Nov 23, 2009 at 1:06 PM, Len Brown <lenwbrown at gmail.com> wrote:
Rock,
I sympathize with you on many levels. I've also had my doubts
regarding the future of OpenSim, but I have also maintained some degree of
faith that things will pull through in the end.
For me the shock came when I was abruptly informed that "OpenSim is not
Second Life, is not intended to be like Second Life, nor ever will." I
still haven't the foggiest idea what this developer had smoked for them to
so strongly assert that incredibly false statement.
For me, the enjoyment of OpenSim has come from my intense devotion to
building and skinning. In fact, for the last few months I've been working
on a full region that has many hundreds of skins, clothes, hair, furniture,
etc, etc, that I'd like to package up as an OAR and give out freely, since
repeatedly I've been told that instead of giving money to help further
OpenSim I'd do more proactively by giving content. So I plan to do just
that and give my money to other open source initiatives that matter to me.
I have a passion for writing, and have thought many times that one of
the greatest powers OpenSim would gain is having simple, straightforward,
step-by-step instructions on how to download, compile, install, administer
and overall just plain operate the core applications. What kills me is that
everyone who does a search for OpenSim inevitably hits the opensimulator.org
site and that is where the massive roadblock presents itself. It's useless
for most and irrelevant to the few who consider themselves OpenSim experts.
Heck, even now on the configuration page it still displays info for
0.6.6 including (months old) known bugs in setting up region xml files. If
there was appointed a volunteer whose sole job was to keep information on
opensimulator.org relevant that one task would resolve a mountain of
negativity right there. I sit here in front of my computers a good 10 to 12
hours a day.
I would sincerely love to contribute to the OpenSim project, especially
in documentation support. But the thing holding me back is communication.
If I cannot get a straight answer on who to GIVE money to in order to help,
then I stand little chance of getting clear, straight answers from
developers when asking about issues I need to consider and incorporate in
documentation.
If communication is a hurdle we can all overcome, with a genuine and
heart-felt effort to relay information, motives, and plans with one another,
then I'd sincerely appreciate having the opportunity to personally
contribute. I'm not a programmer today, but have a degree in programming
fro the 90's (so much has changed my degree is practically useless in that
regard). But I do know how to explain things and relay information in
simple terms. But only if my own questions will be answered with more than
"look it up or figure it out yourself" as my answer.
If any of you would appreciate my help, feel free to let me know at any
time and I'll do what I can.
- Len W. Brown
lenwbrown at gmail.com
On Mon, Nov 23, 2009 at 6:23 AM, Colin B. Withers
<Colin.Withers at eumetsat.int> wrote:
Hi guys,
I have decided to leave the Opensim project. You will probably not even
notice if I leave, as not being a programmer my only inputs were the writing
of the step-by-step tutorials ( http://chapter-and-metaverse.blogspot.com/
), the drafts of the OpenSim User Manual on the Forge, and helping out in
the IRC channels, for newcomers.
You may find my reasons for leaving Opensim interesting though (and please
do not construe any of my reasons as an attack on anyone).
1. The Platform
I raised this several times in the past in IRC, and made posts on my blog
about the product lifecycle of the platform (
http://rock-vacirca.blogspot.com/2009/02/direction-of-virtual-worlds.html ).
I believe that the platforms underpinning both Second Life and Opensim are
quite long in the tooth now, and I questioned how much product lifecycle
there was left, particularly given that Opensim is now nearing 3 years of
development, is still in Alpha, and if the current release of 0.6.7 is any
indicator, then still only around two thirds into the development cycle.
With the (inevitable) coming of much superior platforms, such as Blue Mars
and (as a virtual world); Unity, for browser-based Virtual Wolrds; and now
UDK (for creating sandboxes, standalones, and open grids), then I fear that
Opensim has missed the boat as far as the remaining lifecycle of the
platform is concerned. When you show people what is possible with these
engines (for example this avatar editor for the forthcom
ing APB (using the Unreal Engine):
http://www.youtube.com/watch?v=icR3LtEMvZI or this city:
http://www.youtube.com/watch?v=hmLzNbPXMDg (using the CryEngine), then
neither SL not Opensim stands comparison.
2. Lack of Support for Currency in Opensim
I felt the impact of this when I first made the switch from SL to Opensim. I
had a thriving RP sim in SL (over 50 people, mainly female) and they all
agreed to follow me over to my Opensim and the OSGrid. However, within a
month they had all left, citing the same reason, the lack of places to shop,
to buy the quality stuff they wanted (skins, hair, clothes etc), as a
quality appearance, and the fun of shopping is what all the females placed
high on their requirements from a Virtual World. They drifted back to Second
Life, and the guys followed them. I have always believed that the lack of
support for currency in the core was a mistake, but that is just my opinion.
3. Marketing
I have also raised this issue several times, and blogged about it. It is far
from clear just who an eventually released Opensim is actually aimed at. I
think that any company that is interested in a firewalled corporate solution
to collaboration and prototyping will already be looking at the Enterprise
solution that is currently available from Second Life; that any indie group
that is thinking of running a themed grid will need an economy to stay
viable; and any individual who is looking for a private sandbox solution for
their SL work will need full compatibility (which is not the case with the
OS version of LSL diverging from the SL LSL). So, just who is the platform
aimed at? I was also very disappointed in the view of one of the core devs
who said that 'marketing is a null concept for us'.
I am currently designing and creating cities for Blue Mars, and involved in
a team for proving the UDK as a platform for the design and creation of
Virtual Worlds (as opposed to purely games), and with so much documentation
available for these mature engines (particularly for the UDK, Blue Mars lags
behind somewhat in that department, but have hired extra staff to put that
right), I am achieving the productivity I want, building the worlds that I
want, with stable crash-free platforms.
However, I do wish the Opensim team the very best in their endeavours, and I
sincerely hope their goals are eventually achieved.
If anyone would like to take over the Opensim Tutorials pages at
http://chapter-and-metaverse.blogspot.com/ and
http://chapter-and-metaverse2.blogspot.com/ (they will need some updating
following several changes) then I am more than willing to pass the posts
over, and of course the Opensim User Manual is there in the Forge for anyone
to develop further.
Best Regards and Good Luck
Rock
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.709 / Virus Database: 270.14.78/2521 - Release Date: 11/23/09
14:45:00
------=_NextPart_000_002A_01CA6C68.7723E480
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:60176912;
mso-list-template-ids:1803813700;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1
{mso-list-id:351880975;
mso-list-template-ids:2030614596;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2
{mso-list-id:734399464;
mso-list-template-ids:127453844;}
@list l2:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3
{mso-list-id:925723409;
mso-list-template-ids:-1893857844;}
@list l3:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l4
{mso-list-id:1021054588;
mso-list-template-ids:-1628144608;}
@list l4:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l5
{mso-list-id:1075669648;
mso-list-template-ids:-1088278992;}
@list l5:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l6
{mso-list-id:1497458081;
mso-list-template-ids:1316783458;}
@list l6:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l7
{mso-list-id:1514765998;
mso-list-template-ids:2016588378;}
@list l7:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l8
{mso-list-id:1591042131;
mso-list-template-ids:315242460;}
@list l8:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3DEN-US link=3Dblue vlink=3Dpurple>
<div class=3DSection1>
<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>What she said! Thank you Morgaine for clarifying this for =
all of
us. In my opinion this discussion was appropriate here to =
understand roadmap
and documentation efforts. Thanks for caring to let the rest of =
the community
hear about your very smart opinions. More talk like this will =
bring the
community together wherever it occurs.<o:p></o:p></span></p>
<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>
<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
opensim-dev-bounces at lists.berlios.de
[mailto:opensim-dev-bounces at lists.berlios.de] <b>On Behalf Of =
</b>Morgaine<br>
<b>Sent:</b> Monday, November 23, 2009 6:04 PM<br>
<b>To:</b> opensim-dev at lists.berlios.de<br>
<b>Subject:</b> Re: [Opensim-dev] Leaving Project<o:p></o:p></span></p>
</div>
<p class=3DMsoNormal><o:p> </o:p></p>
<p class=3DMsoNormal>On Mon, Nov 23, 2009 at 1:06 PM, Len Brown <<a
href=3D"mailto:lenwbrown at gmail.com">lenwbrown at gmail.com</a>> =
wrote:<o:p></o:p></p>
<p class=3DMsoNormal><o:p> </o:p></p>
<div style=3D'margin-left:30.0pt'>
<p class=3DMsoNormal>For me the shock came when I was abruptly informed =
that <b>"OpenSim
is not Second Life, is not intended to be like Second Life, nor ever
will."</b> I still haven't the foggiest idea what this =
developer had
smoked for them to so strongly assert that incredibly false =
statement.<o:p></o:p></p>
</div>
<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><br>
<br>
Len, let me give you an alternative perspective on that quote to help =
you see
the reasons for it. I'm not on the Opensim team, but after five =
years in
SL, two years in AWG, and a year of working on future VW protocols in =
our IETF
group, I have some background to know why Opensim needs to distance =
itself from
SL:<o:p></o:p></p>
<ul type=3Ddisc>
<li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l1 level1 lfo1'>SL's statically tiled resource =
architecture is
badly <b>non-scalable</b>, because most resource usage in VWs =
cannot be
statically mapped (demand moves around). The inability to =
assign
resources dynamically in SL results in huge overload in busy places =
and
gross wastage in idle areas. It also limits the number of
participants in events and the bandwidth of their interaction, as =
well as
the size and complexity of everything in a region. This =
architecture
is fundamental to SL, yet it is a recipe for failure. As long =
as
Opensim adheres to the SL model, Opensim will be similarly =
non-scalable.<o:p></o:p></li>
</ul>
<p class=3DMsoNormal><o:p> </o:p></p>
<ul type=3Ddisc>
<li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l4 level1 lfo2'>The LSL scripting language is =
linguistically
weak, semantically obscure, and lacking in the glue that could =
allow
components to cooperate effectively. As a result, individual =
scripts
are quite underpowered and inefficient, and multi-script =
constructions do
not scale well in complexity because the overheads of cooperation =
are so
large. That's a bad restriction on progress which Opensim =
needs to
leave behind.<o:p></o:p></li>
</ul>
<p class=3DMsoNormal><o:p> </o:p></p>
<ul type=3Ddisc>
<li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l2 level1 lfo3'>LSL scripts are not scalable in power or =
size,
and this will continue to be true even after SL allows C# and other =
CLR
languages to be used. There is no possibility of using more =
CPU
power for scripting than is available in one single simulator in =
SL.
That is not a good foundation upon which to build an ambitious =
future of
clever components.<o:p></o:p></li>
</ul>
<p class=3DMsoNormal><o:p> </o:p></p>
<ul type=3Ddisc>
<li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l0 level1 lfo4'>SL's simulation environment is =
non-portable,
having evolved over time into a plethora of special cases that will =
not be
accurately replicable anywhere else. In effect this means =
that there
will never be effective interop with SL's scripted objects. =
It would
not be a useful goal to seek compatibility with what could =
realistically
be described as an "ill-defined mess".<o:p></o:p></li>
</ul>
<p class=3DMsoNormal><o:p> </o:p></p>
<ul type=3Ddisc>
<li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l6 level1 lfo5'>SL's object and type systems are =
<b>non-extensible</b>,
so compatibility with SL means living in the past, and worse, =
living in a
past defined entirely by one slow-moving company. Tying the
capabilities of Opensim to that millstone would be a disaster --- =
it would
ensure the death of Opensim versus any extensible alternative that =
may
appear. Developing new extensible forms of world data beyond =
SL's
original set is a must for Opensim's survival as a modern VW =
platform.<o:p></o:p></li>
</ul>
<p class=3DMsoNormal><o:p> </o:p></p>
<ul type=3Ddisc>
<li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l3 level1 lfo6'>SL's viewer has deep knowledge of SL =
semantics
because the client and server were designed for each other rather =
than
designed as endpoints of a standard protocol. This has the =
very bad
consequence that future VW viewers would need to know about SL =
specifics
in order to interoperate with SL, which is a poor approach that =
doesn't
scale to metaverse-wide diversity. Opensim needs to leave
world-specific kludges behind if it has ambitions to underpin a =
highly
diverse metaverse of worlds, and this means leaving the SL viewer =
behind.<o:p></o:p></li>
</ul>
<p class=3DMsoNormal><o:p> </o:p></p>
<ul type=3Ddisc>
<li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l7 level1 lfo7'>SL's constructed objects are =
<b>non-hierarchical</b>,
which means that creators cannot use objects created by others as
subcomponents. This restriction completely blocks the =
hierarchical
engineering process that is the basis of progress in RL. In =
SL you
always have to build from "raw materials", so it is not =
possible
to ride on the shoulders of giants, nor harness a huge pyramid of =
people
skills. Even Philip and Cory Linden admitted that this was a =
mistake
-- see <a
=
href=3D"https://wiki.secondlife.com/wiki/Prim_and_Object_Hierarchy">https=
://wiki.secondlife.com/wiki/Prim_and_Object_Hierarchy</a>
. We don't want to live with their mistake.<o:p></o:p></li>
</ul>
<p class=3DMsoNormal><o:p> </o:p></p>
<ul type=3Ddisc>
<li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l8 level1 lfo8'>SL is based on highly <b>centralized</b> =
concepts
of <i>identity, storage and control</i>, which come together to =
create
either a walled garden or a prison planet, depending on one's
perspective. Whatever one's worldview, the end result is =
badly
non-scalable in those three areas. SL suffers hugely from =
that
non-scalability despite the relatively small size of the service at =
this
early stage. Opensim needs decentralized / distributed =
mechanisms for
<i>identity, storage and control</i> if it is to scale for =
Internet-wide
adoption.<o:p></o:p></li>
</ul>
<p class=3DMsoNormal><o:p> </o:p></p>
<ul type=3Ddisc>
<li class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;
mso-list:l5 level1 lfo9'>From a futurist angle, Second Life has =
very
narrow horizons and barely pays lip service to the =
<b><i>virtual</i></b>
aspect of "virtual worlds". Nobody could claim that =
a
Flatland of square land tiles all featuring the same Earth-like =
look and
physics pushes the envelope of the imagination. To boldly go =
where
Lindens did not go before (topologically and geographically or =
spatially)
will be one of the most appreciated developments in Opensim. =
SL's
obsession with RL is an unwanted constraint in VWs, and we need to =
go
beyond it.<o:p></o:p></li>
</ul>
<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><br>
<br>
That is not the full list of problems with SL, but hopefully it serves =
to
illustrate some of the concerns that VW developers have to consider in =
the
light of the SL legacy. While Linden Lab deserves much applause =
for their
vision and for their work in creating Second Life, many years have now =
passed,
and lessons have been learned. Compatibility with SL must not be =
the end
goal of Opensim because of issues like those highlighted above.<br>
<br>
More information about the Opensim-dev
mailing list