Re: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable?

[Celierra Darling]

I don't see why mesh editing needs to be considered "basic"?  I would
consider building through prims to be the most basic, to learn how
objects/prims/links work and what features are available and what texturing
is and the such.  New users also have all the free tools and those existing
tutorials available to start working with meshes, so new users should
hopefully still feel like they have an advancement path.  Even if prim
objects became totally non-competitive on the market, people probably still
start out just experimenting for their own use, so prims should still be a
good stepping stone while learning for their quick results and feedback.
 What would a mesh editor in the viewer add?  (Well, one likely feature of
an in-world tool would be to enable people to work concurrently with others
and see others' changes as they are made, but I doubt you're referring to
that aspect.)

Ironically, what I would think of as the most basic conceptual transitions
going from prims to meshes are probably the most difficult to program.  To
ease the transition to meshes when the time comes for a new content creator,
what I could imagine is the introduction of some tools and concepts from a
mesh's content creation process - hierarchical links to allow stacking
transformations? a way to palletize the textures applied to an object? - but
while still working with prims in-world.  Maybe it can even go as far as a
full conversion tool if someone were ambitious enough to code such a thing
(to convert and tinker).  But I wouldn't go as far as controlling
subdivisions or twiddling edge normals or nudging vertices -- a list that is
in increasing order of usability difficulty, but decreasing order of
programming complexity, and thus the irony of a "basic" mesh editor.

Celi


On Tue, Oct 5, 2010 at 2:21 AM, Science Fiction Computer - SCi-Fi PC <
partn...@scifipc.com> wrote:

> LL Snowstorm/Opensource-Dev,
>
> To stimulate SL growth and accessibility to the mainstream, one or the
> collective SL Viewer developers and/or decision makers ought to think &
> design universally.
>
> If mesh becomes a standard in SL, a basic mesh editor ought to be included
> by default.
>
> The ability to plugin with existing professional tools such as Photoshop,
> Gimp, Blender, Max, etc. is essential for high-end content production and
> advanced SL users.
>
> However, to deny a new users who are discovering either 3D Second Life or
> the 3D Web for the first time a complete basic set of content creation
> tools
> for the 3D world they are introduced to (of which would include a mesh
> editor), may seriously discourage them; along with potential opportunity
> for
> regular influx of new & emerging content creators within our community from
> Low, Medium, and High End.
>
> SL Viewer Mesh Editor doesn't need to be Maya, it just needs to be 'there'
> and 'basic' to encourage new content creators to create and feel that they
> begin to learn and participate without significant barriers.
>
> We must try and avoid any situation where a New User in SL feels
> disadvantaged or unable to create before they start.
>
> Regards,
>
> DMC Zsigmond-Jurassic
> Science Fiction.
>
>
>
> -Original Message-
> From: opensource-dev-boun...@lists.secondlife.com
> [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Stickman
> Sent: Tuesday, October 05, 2010 2:48 PM
> To: Frans
> Cc: opensource-dev@lists.secondlife.com
> Subject: Re: [opensource-dev] Unity 3D as possible base / 2.x Codebase
> plugin capable?
>
> On Mon, Oct 4, 2010 at 1:38 PM, Frans  wrote:
> > I really hope LL is not going to add a Mesh Editor in the client. That's
> > just going to be so bloated.
>
> I think it's a terrible idea for LL to try to recreate tools that
> teams of professionals have already been working on for years.
> Photoshop, Gimp, Blender, Max, Maya -- there are specialty tools out
> there, many of them free, that already do a much, much better job than
> LL ever could, simply because that is their only job and they have
> years of a head start.
>
> What I would like to see is a better connection with existing tools.
> Being able to have SL work with other programs easier, better
> conversion and import support, to cut steps out of the design
> workflow. For example, texture work often involves modifying a
> texture, test it out, modifying it again, and repeat forever. Having
> SL "watch" a texture, model, or other file for a change and
> automatically update it in SL so you can see exactly what it will look
> like would cut out a lot of steps. Even if it was only a local view.
> Heck, even if I had to pay for every single time I hit the save button
> in Photoshop or Blender. Though I'd prefer it be integrated in a way
> that all people could see what I was working on, then I hit "finalize"
> and it does the final upload.
>
> Having said that, very simple editors that are not designed to have
> fancy features but be as basic as possible would allow people to
> create 

Re: [opensource-dev] WebP, a new image format for the Web

[Philippe (Merov) Bossut]

Hi,

I was puzzled by this "yet another image format" from Google and did some
quick research tonight. Not much turned up in the data provided by Google
and, as always, the best starting point is Wikipedia:
http://en.wikipedia.org/wiki/WebP . Short but to the point.

The critical part is the Math: WebP is based on block prediction and
encoding, something that works well for compressing frame to frame videos
but one has to wonder about still images. Why would blocks be predictable
spatially? Similar textures? May be but loss of precision would be
horrendous, something that I don't thing the JPEG (a group of Pro
Photographers) would swallow. Besides, it reminds me a lot about fractal
compression of the mid 90's and we all know how this ended... Then, if
prediction fails, WebP falls back to DCT so no better than classical JPEG
and the blocking artifacts are  as "good" as what JPEG gives us... a problem
that, precisely, wavelet compression (used in jpeg2000) solved. It seems to
me that, as far as encoding differences from levels to levels, wavelets do
that uniformly on the whole image much better already and its mathematical
underpinning is much stronger (see Stéphane Mallat papers' on Optimal Image
Compression). Not to mention that wavelet gives us LOD (Level of Details ==
discard level == subres access) that we *do* use in SL and random spatial
access that, unfortunately, we do not use in SL (though we ought to).
Anyway, WebP gives us neither one not the other.

As for the 39% better compression touted by Google, I fail to see that as a
big selling point, especially when taking the huge compression time they
apparently experience into account. You also get much better compression
rate with jpeg2000 than with jpeg any day. But, even with good old jpeg, if
you take the time to compute adapted quantization tables for each image, you
would get much better compression rates. Now, no one does this because it
takes too long at compress time (which is typically done on cameras...) so
everyone uses the same set of "standard" (read "ought to work for all run of
the mill picture taking situations") quantization tables. So, if you were to
really compare apple to apple, I'm not even sure that WebP is that much
better than standard jpeg.

More: 8 bits per channel only? That must be a typo... I won't even go down
the "raw" and high dynamic range debate familiar to folks with an interest
in photography. Well, I don't see why the method can't be extended to 16
bits though.

Then this: comparing "visually" differences between JPEG images pulled from
the web and reencoded with WebP to judge quality? No seriously, I almost
cried... I thought Google had better standards for quality of engineering.
What a disappointment.

My take: keep on the radar (because it's Google...) but I don't see the
urgency to jettison JPEG2000 for static images yet.

Cheers,
- Merov


On Fri, Oct 1, 2010 at 10:45 AM, Tateru Nino  wrote:

>  Hmm. Only supports a single image data chunk and no alpha channels in this
> release. True, you could break compatibility and extend it, but I'm not sure
> that's really the way to go. Not close to a drop-in replacement yet, even
> after banging it on some rocks.
>
>
> On 2/10/2010 3:15 AM, SuezanneC Baskerville wrote:
>
> Google is putting out a new open source image format, said to offer higher
> compression rates than JPEG2000.
>
> I just thought someone with the appropriate technical knowledge ought to
> take a look at in case it might be useful for use in Second Life.
>
>  http://blog.chromium.org/2010/09/webp-new-image-format-for-web.html
>
>  *To improve on the compression that JPEG provides, we used an image
>> compressor based on the VP8 codec that Google 
>> open-sourcedin
>>  May 2010. We applied the techniques from VP8 video intra frame coding to
>> push the envelope in still image coding. We also adapted a very lightweight
>> container based on 
>> RIFF.
>> While this container format contributes a minimal overhead of only 20 bytes
>> per image, it is extensible to allow authors to save meta-data they would
>> like to store.
>>
>> While the benefits of a VP8 based image format were clear in theory, we
>> needed to test them in the real world. In order to gauge the effectiveness
>> of our efforts, we randomly picked about 1,000,000 images from the web
>> (mostly JPEGs and some PNGs and GIFs) and re-encoded them to WebP without
>> perceptibly compromising visual quality. This resulted in an average 39%
>> reduction in file size. We expect that developers will achieve in practice
>> even better file size reduction with WebP when starting from an uncompressed
>> image.
>> *
>
>
> http://code.google.com/speed/webp/
> --
> v i r t u a l   w o r l d   e n t h u s i a s t
> -- http://www.google.com/profiles/s u e z a n n e --
>
>
> _

[opensource-dev] Problem with displaying Arabic menu text in SL client

[izze euler]

Hi,

I have been looking to get Arabic text working on the SL client, but so far 
with no luck. I am only looking to display Arabic for menus and text on the 
client.

What I have found is that the Arabic text is being displayed left-to-right, 
rather than right-to-left. I have added a language to SL, so I have the Arabic 
translations in UTF8 format in XML files, as with the other languages such as 
Chinese.

I used Notepad++ to copy the translations to the XML files, and they are 
displayed right-to-left correctly. However, when loaded into the SL client, the 
text is being reversed so that it reads left-to-right.

I have tried reversing the text, so that it displays left-to-right in the XML 
file, in the hope that it will then be reversed and display right-to-left in 
the client. I cannot read or write Arabic, but I have been told that the 
characters are displayed disjoint, most likely due to the wrong ordering of the 
characters breaking associations between them in the XML file.

Has anyone looked into this problem, or have any ideas to what I could try? 
Does anyone have this working?

Kind Regards,
Izze

  ___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Problem with displaying Arabic menu text in SL client

[Boroondas Gupte]

 Hi Izze

On 10/05/2010 10:31 AM, izze euler wrote:
> I have been looking to get Arabic text working on the SL client, but
> so far with no luck. I am only looking to display Arabic for menus and
> text on the client.
>
> What I have found is that the Arabic text is being displayed
> left-to-right, rather than right-to-left. I have added a language to
> SL, so I have the Arabic translations in UTF8 format in XML files, as
> with the other languages such as Chinese.
>
> I used Notepad++ to copy the translations to the XML files, and they
> are displayed right-to-left correctly. However, when loaded into the
> SL client, the text is being reversed so that it reads left-to-right.
Unicode has special control characters to switch between left-to-right
and right-to-left in mixed language documents. Additionally, I think
some programs switch direction automatically when they encounter
characters they know belong to a right-to-left written script. So if the
translations are displayed correctly, Notepad++ is capable of at least
one of those, probably the former (interpreting the control characters).

> I have tried reversing the text, so that it displays left-to-right in
> the XML file, in the hope that it will then be reversed and display
> right-to-left in the client. I cannot read or write Arabic, but I have
> been told that the characters are displayed disjoint, most likely due
> to the wrong ordering of the characters breaking associations between
> them in the XML file.
Arabic script relies heavily on ligatures. Ligatures are glyphs that
represent multiple characters. Other than the ligatures used for latin
script (fl, fi ffi, etc.) which merely make the rendered text look
"nicer", ligatures in scripts like Arabic, Devanagari (a script used for
Sanskrit, Hindi and other Indian languages), Bengali (another Indian
language and script) and probably many others look very distinct from
the characters they represent
and aren't
"optional". (Typographs and typesetters might argue that Latin ligatures
aren't optional either. But omitting ligatures in these other scripts
will not only look typographically wrong but, well, just wrong. (I don't
know whether it'd be considered an orthographic error in the respective
cultures.))

> Has anyone looked into this problem, or have any ideas to what I could
> try?
We've discussed the problem this summer, see here:
http://wiki.secondlife.com/wiki/Open_Source_Meeting/2010-07-13

The issue is that while the SL client has support for displaying Unicode
characters, it lacks the ability to use Unicode's script direction
markers and the feature of converting specific character sequences to
the matching ligatures. For pre-set strings (e.g. your UI translation),
the first problem can be worked around by writing stuff backwards, as
you already tried. To work around the second problem, you'd have to
directly write the ligature "characters" (so you have only one character
per wanted glyph). I don't know Unicode well enough to tell whether
"characters" for all possible glyphs exist. It might well be that some
ligatures always have to be created on-the-fly from a sequence of
single-character "characters".

Of course, both of these workarounds aren't feasible for chat and other
run-time user input, because users will be used to write sequences of
single characters in reading order rather than ligature "characters" in
left-to-right order. Also, entering these ligature "characters" (if they
even exist) might be complicated and time consuming, because their usual
keyboard layout might not give direct access to them.

> Does anyone have this working?
Adding these features to Linden Lab's homebrewn text rendering system
would be a major effort that probably none of us is capable of.

Alissa Sabre once adapted the Viewer to use Pango for text rendering. (
See
http://wiki.secondlife.com/wiki/User:Alissa_Sabre/Pango_adaptation_in_SL_viewer)
Pango can handle bidirectional text and ligatures just fine, so this
solved the problems. However, these changes haven't been integrated in
the official viewer and her patches are now out of date.

For chat, using Dzonatas' Icesphere (allows for IM and chat in separate
GTK+ windows, thus also using Pango) has been recommended to some Arabic
users, and that seems to work alright. Both, the sender and receiver,
will have to use it to be able to chat in Arabic script.

Cheers,
Boroondas
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Problem with displaying Arabic menu text in SL client

[Francesco Rabbi]

U+200F

Reverse direction

Notes:
- Microsoft have a bug, this char don't work sometimes (msoffice 2011 for
Mac affected too)
- parser work left2right put the char on left side of each entry in all XML
files


-- 
Sent by iPhone

Il giorno 05/ott/2010, alle ore 12:19, Boroondas Gupte <
slli...@boroon.dasgupta.ch> ha scritto:

Hi Izze

On 10/05/2010 10:31 AM, izze euler wrote:

I have been looking to get Arabic text working on the SL client, but so far
with no luck. I am only looking to display Arabic for menus and text on the
client.

What I have found is that the Arabic text is being displayed left-to-right,
rather than right-to-left. I have added a language to SL, so I have the
Arabic translations in UTF8 format in XML files, as with the other languages
such as Chinese.

I used Notepad++ to copy the translations to the XML files, and they are
displayed right-to-left correctly. However, when loaded into the SL client,
the text is being reversed so that it reads left-to-right.

Unicode has special control characters to switch between left-to-right and
right-to-left in mixed language documents. Additionally, I think some
programs switch direction automatically when they encounter characters they
know belong to a right-to-left written script. So if the translations are
displayed correctly, Notepad++ is capable of at least one of those, probably
the former (interpreting the control characters).

I have tried reversing the text, so that it displays left-to-right in the
XML file, in the hope that it will then be reversed and display
right-to-left in the client. I cannot read or write Arabic, but I have been
told that the characters are displayed disjoint, most likely due to the
wrong ordering of the characters breaking associations between them in the
XML file.

Arabic script relies heavily on ligatures. Ligatures are glyphs that
represent multiple characters. Other than the ligatures used for latin
script (fl, fi ffi, etc.) which merely make the rendered text look "nicer",
ligatures in scripts like Arabic, Devanagari (a script used for Sanskrit,
Hindi and other Indian languages), Bengali (another Indian language and
script) and probably many others look very distinct from the characters they
represent and aren't
"optional". (Typographs and typesetters might argue that Latin ligatures
aren't optional either. But omitting ligatures in these other scripts will
not only look typographically wrong but, well, just wrong. (I don't know
whether it'd be considered an orthographic error in the respective
cultures.))

Has anyone looked into this problem, or have any ideas to what I could try?

We've discussed the problem this summer, see here:
http://wiki.secondlife.com/wiki/Open_Source_Meeting/2010-07-13

The issue is that while the SL client has support for displaying Unicode
characters, it lacks the ability to use Unicode's script direction markers
and the feature of converting specific character sequences to the matching
ligatures. For pre-set strings (e.g. your UI translation), the first problem
can be worked around by writing stuff backwards, as you already tried. To
work around the second problem, you'd have to directly write the ligature
"characters" (so you have only one character per wanted glyph). I don't know
Unicode well enough to tell whether "characters" for all possible glyphs
exist. It might well be that some ligatures always have to be created
on-the-fly from a sequence of single-character "characters".

Of course, both of these workarounds aren't feasible for chat and other
run-time user input, because users will be used to write sequences of single
characters in reading order rather than ligature "characters" in
left-to-right order. Also, entering these ligature "characters" (if they
even exist) might be complicated and time consuming, because their usual
keyboard layout might not give direct access to them.

 Does anyone have this working?

Adding these features to Linden Lab's homebrewn text rendering system would
be a major effort that probably none of us is capable of.

Alissa Sabre once adapted the Viewer to use Pango for text rendering. ( See
http://wiki.secondlife.com/wiki/User:Alissa_Sabre/Pango_adaptation_in_SL_viewer)
Pango can handle bidirectional text and ligatures just fine, so this solved
the problems. However, these changes haven't been integrated in the official
viewer and her patches are now out of date.

For chat, using Dzonatas' Icesphere (allows for IM and chat in separate GTK+
windows, thus also using Pango) has been recommended to some Arabic users,
and that seems to work alright. Both, the sender and receiver, will have to
use it to be able to chat in Arabic script.

Cheers,
Boroondas

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting
privileges
__

Re: [opensource-dev] Problem with displaying Arabic menu text in SL client

[izze euler]

Are you able to give an example on how to use this character within an XML file?

Izze

From: syt...@gmail.com
Date: Tue, 5 Oct 2010 12:38:44 +0200
Subject: Re: [opensource-dev] Problem with displaying Arabic menu text in SL 
client
To: slli...@boroon.dasgupta.ch
CC: iz...@hotmail.co.uk; opensource-dev@lists.secondlife.com

U+200F
Reverse direction
Notes:- Microsoft have a bug, this char don't work sometimes (msoffice 2011 for 
Mac affected too)

- parser work left2right put the char on left side of each entry in all XML 
files

-- Sent by iPhone 
Il giorno 05/ott/2010, alle ore 12:19, Boroondas Gupte 
 ha scritto:




Hi Izze



On 10/05/2010 10:31 AM, izze euler wrote:

  ___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable?

[Ponzu]

On Tue, Oct 5, 2010 at 3:08 AM, Celierra Darling  wrote:

> I don't see why mesh editing needs to be considered "basic"?


One philosophical stance is that all types of building whould include an
easy path for novices to do that sort of building.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Daily Scrum Update - Monday, October 4, 2010

[Sarah (Esbee) Hutchinson]

These emails keep getting corrupted on send (likely due to my extraneous
formatting).
You can also view the daily updates on the wiki, here:
https://wiki.secondlife.com/wiki/Snowstorm_Daily_Scrum_Archive

But here's a far less fancy update for those who prefer email! :)

- Esbee

*Daily Scrum Update - Monday, October 4*
*
*
*General Notes*
* Merge Monkey of the Day: Merov

*Team Status*

*Merov Linden*
*PAST*
* STORM-137: fmod on Windows: fixed fmod.dl not been copied over to
build-vc80/newview/RelWithDebInfo. Modif in viewer_manifest.py and
cmake/CMakeLists.txt. Committed to dev branch.
* STORM-306: water flicker issue: identified the issue as being introduced
mid-July in the viewer code.
* STORM-330 : Crash in texture rendering: got that crash under the debugger
on Windows and logged it immediately.
* HR stuff

*FUTURE*
* New round of SG JIRA scrubbing to prepare sprint planning
* Merge Monkeying
* STORM-137 : FMOD issue: fix upload issue with Brad. Hopefully, the rest
will be easy.
* STORM-105 : Perf decompression: put new data out, check the work done by
opensource-dev community on similar tests.
* STORM-281: integrate?
* STORM-306: back burner: bissect and incremental builds till I pinpoint the
culprit...

*IMPEDIMENTS*
* Kakadu license upgrade


*Oz Linden*
*PAST*
* Caught up on email from my vacation
* Answered questions from a couple of people on Contribution Agreements
* Office Hour
* Put in request for change to the download page for Development builds
* Started running third party viewer crash reports

*FUTURE*
* Clarify wiki documentation on where to get code and download binaries
* Get current on autobuild developments
* Work on proposals for open code review and build systems
* Help with code reviews?

*IMPEDIMENTS*
* none


*Q Linden*
*PAST*
* HR stuff, administration
* Planning Q4
* Documenting release process
* Crashhunting in beta
* Meeting on test automation
* Looking into antialiasing

*FUTURE*
* Answer PE questions on STORM-325 and 295
* HR stuff
* Q4 planning
* Further meetings on test automation
* Writing automation for LLDir

*IMPEDIMENTS*
* paperwork/planning blocking me from coding


*Esbee Linden*
*PAST*
* VWR triage
* Process discussions
* Bug hunting
* Backlog reviews
* Set up new meeting times for Sprint Planning, Retrospective, and Review
meetings
* HR Stuff
* Q4 planning

*FUTURE*
* VWR triage
* Backlog grooming & new feature request review
* Prep for Sprint 5
* Viewer roadmap planning
* Systems requirements research
* HR Stuff
* Q4 planning

*IMPEDIMENTS*
* None


*Paul ProductEngine *
*PAST*
* STORM-263 Cog button in lower-left of sidebar panel does not close popup
menu on second click
** Fixed, tomorrow will test and send for a review

*FUTURE*
* other bugs

*IMPEDIMENTS*
*none


*Andrew ProductEngine*
*PAST*
* Bug STORM-264 (Resize grab areas on detached sidebar panels are tiny and
unmarked)
** Reviewed.
* Bug STORM-325 ("i" button no longer opens profiles).
** Reproduced in viewer-beta, investigated, found changeset with fix in
viewer-development and left comment in ticket.
* Major bug STORM-295 (Mini-inspector fades out if adjust voice volume).
** Reproduced in viewer-beta, investigated, found changeset with fix in
viewer-development and left comment in ticket.
* Major bug STORM-315 (Changes to Environment Editor are not saved and do
not persist across sessions).
** Started investigating. Estimate- 6 hours.

*FUTURE*
* STORM-315 (Changes to Environment Editor are not saved and do not persist
across sessions).

*IMPEDIMENT*S
* STORM-295 and STORM-325 are fixed in viewer-development. What should be
done with these fixes? Should changesets with them be transplanted from one
repository to another, or simply fixed the same way manually, or left
untouched to wait merge with development?


*Vadim ProductEngine*
OOO - Vacation. Will be back to office on Oct, 11th.


*Seth ProductEngine (Sergey)*
*PAST*
* BUG (STORM-316) Debug: Inventory.Folders by Name/Sort by Date/Sort by
Name/System Folders to Top Do not apply and settings changes do not persist
after relogging.
** Investigated. Waiting for Esbee's reply in JIRA.
* BUG (STORM-314) Wear button in My Appearance greyed out
** Investigated. Could not reproduce with reporter's scenario. Probably
misfiled.
* BUG (STORM-310) crash after setting sound preferences
** Could not reproduce.
* BUG (STORM-305) Undocked minimized SP tabs are restored after re-login
** WIP.

*FUTURE*
* BUG (STORM-305) Undocked minimized SP tabs are restored after re-login
** Estimated: 4 hours.

*IMPEDIMENTS*
* STORM-316 needs answer from Esbee (?)


*Andrey ProductEngine*
*PAST*
* smoke test of 210...@viewer-development
* integrated tickets verification on 210...@viewer-development

*FUTURE*
* regression testing of 210...@viewer-development in scope of changes from
previous development builds

*IMPEDIMENTS*
* none
___
Policies and (un)subscri

Re: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable?

[Dale Mahalko]

An in-world prim-to-mesh converter would both be incredibly powerful
and yet also easy to use. Heck, it could be practically transparent to
the end-user.

Make prims, arrange, and link them
* Prims are merged automagically into a mesh
* Embedded and overlapping internal surfaces are removed
* The original prims disappear from world
* The mesh is now the stand-in for the prims

Unlink the mesh
* The mesh disappears and is discarded.
* Prims are reloaded back into the world for editing as individual objects

This could shed massive amounts of hidden vertexes from linked prim
sculptures, prim vehicles, houses, roads, etc, and significantly
improve frame-rates, all while being mostly transparent to the end
user... perhaps little more than a checkbox option in the editor :
"Make linked prims into a mesh?"


Though I would hope for a way to separately link together prims to
make the physics collision surface for a high-prim object. That way a
beautiful vase with curved handles can have a simple cylinder
collision surface to go with it, and take load off the physics engine.
This could be anti-griefed by making sure that the collision surface
always has fewer vertexes than the visible mesh it is joined to.

- Dale Mahalko / Scalar Tardis


On Tue, Oct 5, 2010 at 2:08 AM, Celierra Darling  wrote:
> I don't see why mesh editing needs to be considered "basic"?  I would
> consider building through prims to be the most basic, to learn how
> objects/prims/links work and what features are available and what texturing
> is and the such.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Vertex Edit Capability

[Daniel]

  I submitted JIRA issue VWR-23202 to provide the simplest in-world 
editing capability, that of moving vertexes on a mesh.

The reasons why include making a clothing item fit better, a large mesh 
object fit within a land parcel, or fit the other objects in a linkset. 
As someone learning to build it would also be more fun and interesting 
to edit shapes.  Even for an advanced builder, while we can load the 
parts of a complex build into our 3D program and get them to fit each 
other, we cannot load all possible avatar shapes, or the surrounding 
land for large items, and see how the mesh will fit the surroundings 
until it is there.

I am not proposing a full blown mesh editor, that is best left to 
specialized software.  What I want to see is a way to adjust items so 
they are more useful once imported/transferred to others, and a learning 
path for new people.  Once they have a taste of modifying a simple 
library mesh, if they want to do more advanced work they can get some 
outside software.  This is similar in my mind to what we do with 
textures.  We can adjust the color tint, tiling ratio, etc on a texture 
(simple mods), but if we want to make a whole new texture you get GIMP 
or Photoshop.

For the UI, I suggest using the same XYZ movement gizmo we use now for 
whole prims, the same numerical input boxes, and the same selection 
highlight.  Just add a radio button to "Edit vertex" like the "Edit 
linked parts" on that's already there.

To simplify asset database and server overhead, it may make sense to do 
the editing local in the client until you leave edit mode.  But I will 
leave technical implementation to those who know more about that side of 
things.

Daniel

>
>
> Date: Mon, 4 Oct 2010 21:47:48 -0700
> From: Stickman
>
>
> Having said that, very simple editors that are not designed to have
> fancy features but be as basic as possible would allow people to
> create things without going to an outside source. But it must be clear
> and planned that they will never evolve beyond a basic level.
>
> Stickman
>
>
> --
>
> From: "Science Fiction Computer - SCi-Fi PC"
> Subject: Re: [opensource-dev] Unity 3D as possible base / 2.x Codebase
>   plugin capable?
>
>
> If mesh becomes a standard in SL, a basic mesh editor ought to be included
> by default.
>
> ...
>
> SL Viewer Mesh Editor doesn't need to be Maya, it just needs to be 'there'
> and 'basic' to encourage new content creators to create and feel that they
> begin to learn and participate without significant barriers.
>
> We must try and avoid any situation where a New User in SL feels
> disadvantaged or unable to create before they start.
>
> Regards,
>
> DMC Zsigmond-Jurassic
> Science Fiction.
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Inventory Organization Feature Request

[miss c]

As a user, I would like to be able to have better  tools to keep my inventory 
neater and put less load on the server when it loads.  I would love a search 
for 
duplicate uuid option so I can easily remove duplicates.  I would also like an 
option to have certain things  received go in designated folders, for instance 
if i open a purchased item and there is a landmark in the box , the landmark 
automatically can go into the landmark folder.  Maybe possibly a warning popup 
saying I already have an item with this uuid in my inventory and asking if they 
can discard the new one.  An option when i do a search to be able to select all 
items returned without selecting the folder its in, for instance if i search 
for 
key phrase floating text or unpackboxscript I can highlight all the returns 
just 
deleting that one item out of every folder.  I would also like a function to 
remove old landmarks where the parcel no longer exists, same with avatar 
calling 
cards. Every single landmark in my inventory loads up when I start my viewer to 
check to see if I have visited that place before, it remembers places I havent  
vistted since 2006, just so it can change the pushpin color, is this really 
needed?

Thank you 

Miss



  ___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Inventory Organization Feature Request

[CG Linden]

You might want to split this up into several things:

   - Duplicate avoidance (I believe you may be surprised at how rare true
   duplicates are, since every time you take something scripted back from the
   world into inventory, it will be a new asset with a different script state -
   so even this duplicate detection may involve several user stories)
   - Improved unpacking (How about -not- unpacking and using a delivery to
   folders and subfolders instead? Do you really want things to be auto-sorted
   by class? Many people would disagree there)
   - Improved selection (How about making ctrl-A select all -visible- items
   in the inventory window?)
   - Improve performance by changing the way inventory is loaded and
   accessed (there is work in progress on the server/web service side there).

--
cg

On Tue, Oct 5, 2010 at 8:29 AM, miss c  wrote:

> As a user, I would like to be able to have better  tools to keep my
> inventory neater and put less load on the server when it loads.  I would
> love a search for duplicate uuid option so I can easily remove duplicates.
> I would also like an option to have certain things  received go in
> designated folders, for instance if i open a purchased item and there is a
> landmark in the box , the landmark automatically can go into the landmark
> folder.  Maybe possibly a warning popup saying I already have an item with
> this uuid in my inventory and asking if they can discard the new one.  An
> option when i do a search to be able to select all items returned without
> selecting the folder its in, for instance if i search for key phrase
> floating text or unpackboxscript I can highlight all the returns just
> deleting that one item out of every folder.  I would also like a function to
> remove old landmarks where the parcel no longer exists, same with avatar
> calling cards. Every single landmark in my inventory loads up when I start
> my viewer to check to see if I have visited that place before, it remembers
> places I havent  vistted since 2006, just so it can change the pushpin
> color, is this really needed?
>
> Thank you
>
> Miss
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Access to an object's inventory without rezing (was: Inventory Organization Feature Request)

[Boroondas Gupte]

 On 10/05/2010 05:47 PM, CG Linden wrote:
> # Improved unpacking (How about -not- unpacking and using a delivery to
> folders and subfolders instead? Do you really want things to be
> auto-sorted by class? Many people would disagree there)
Well, that's something the buyer can't choose. It depends on the seller.
But how about not unpacking (in case of in-object delivery) and being
able to access the contained items anyway? See VWR-2427
 (Allow objects containing
other items to be expanded within the Inventory).

Cheers,
Boroondas
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Problem with displaying Arabic menu text in SL client

[Joshua Bell]

On Tue, Oct 5, 2010 at 4:32 AM, izze euler  wrote:

>  Are you able to give an example on how to use this character within an XML
> file?
>

Using that character won't have any effect. As Boroondas mentioned, Second
Life's text engine is pretty basic and simply doesn't support:

   - Right-to-Left scripts - typically this functionality is called "BiDi"
   since the  direction actually changes within text strings for numbers,
   foreign words, etc.
   - Contextual shaping (think: ligatures as a mandatory language feature)
   - Combining characters/diacritics* (think: characters merge into single
   glyphs)
   - Complex word breaking (for languages that don't use spaces)

This is a big task, and (as Boroondas also mentioned) is probably best
tackled by a thorough overhaul/replacement of SL's text rendering engine as
Alissa Sabre attempted.

Additionally, if we're talking about a localized version of the UI and not
just rendering text content correctly, you'd also want to flip the X
coordinates for some (but not all) UI layout if the app was running with a
UI language that was RTL, which would require changes to the XUI engine and
some of the controls. (Since, ideally you don't have to touch all of the
control rects in all of the XUI files)

-- Josh

* I look forward to the day when someone writes a text engine that handles
the character combining logic for classical Mayan.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Latest LL viewer beta has inventory count issues?

[Ann Otoole]

Anyone else noticing the inventory counts in the latest LL beta client are 
increasingly less than the count in the production release client and that 
cache 
clear does not correct it?



  ___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Vertex Edit Capability

[Daniel Smith]

On Tue, Oct 5, 2010 at 8:25 AM, Daniel  wrote:

>  I submitted JIRA issue VWR-23202 to provide the simplest in-world
> editing capability, that of moving vertexes on a mesh.
>
>
One of the most likely starting points I see is the terrain editor.  That is
a limited mesh editor in itself.

(one of the other Daniels)


-- 
Daniel Smith - Sonoma County, California
http://daniel.org/resume
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers

[Kent Quirk (Q Linden)]

Agreed (a day late). Teravus' post is great -- very insightful, and it mimics 
our own thinking.

The complexity of what we render, and the fact that it's not professionally 
created content, means that we get all sorts of edge cases that aren't a 
problem in traditional graphics engines. Many systems, including Unity, put 
constraints on the content they'll render to achieve speed or certain effects.

We don't have the same sorts of limitations, and so our engine needs to be 
special. I know we've had people who've evaluated Unity as well as other 
engines, including Ogre, and it's by no means a simple problem to figure out 
how to get our content into those systems without choking them. It may be 
possible, and one of the things I'd like to do is abstract our renderer better 
so that we  have the ability to try a few experiments without re-implementing 
all of the viewer. 

Anyway, I guess that graphics systems are kind of like Tolstoy's unhappy 
families: each one sucks in its own way. It so happens that ours is designed 
for our content (surprise!), and our content is weird, so other engines may not 
be as obviously well suited to displaying it as you might think.

  Q

On Oct 4, 2010, at 8:32 AM, Teravus Ovares wrote:

> When working on IdealistViewer, I noticed that, generally, third party 
> 'general purpose' renderers like Irrlicht and Ogre are not well suited for 
> rendering objects at the quantity that SecondLife prims require.   Rendering 
> prims /can/ be done with them, however, not at the level that can be done 
> with the SecondLife viewer. 
> 
> With Irrlicht, for example, the memory load of a typical 5000 prim scene runs 
> up against the 2GB memory limit.   
> 
> With SecondLife prims, it's more about segmenting the render data so that 
> only the unique things are kept and everything else is a reference to 
> something that was calculated before.   Out of the box, Irrlicht requires 
> per-instance knowledge about texture, mesh buffer, face and lighting settings 
> configurations.   This and reference/const/value type semantics used in the 
> engine causes far more data duplications then are necessary.
> 
> Prims are strange for rendering.  The prim's mesh result is complex in terms 
> of vertex count however, in a given 5000 prim scene there's on average 130 
> 'unique' prim mesh.   Those 130 unique mesh are duplicated with various 
> textures, colors, orientations and associated data to make for the entire 
> prim count in the region.   In theory, you can manage memory reasonably well 
> by using a 'mesh factory' pattern where by the mesh factory keeps track of 
> instance counts and generates a new mesh when required.   In practice, 
> however, the associated data makes this very difficult.   In Irrlicht, the 
> API is such that the texture configuration data is 'stuck in with' the mesh 
> data object.So, to get the variability that the secondlife prim scene 
> requires, you're also duplicating the mesh and making small changes to the 
> object's visual configuration data.   
> 
> Irrlicht, like Ogre, is better optimized for a smaller number of more complex 
> mesh objects then a very large number of highly 'instancable' objects with 
> very small differences.   I'd comment on the opposite of the last 
> statement...   but I don't really know about how the SecondLife viewer works 
> under the hood to do so (OpenSimulator Developer).
> 
> I don't think that this issue is going to 'go away'.   In fact, introducing 
> mesh in the viewer is going to make that memory, speed, and instancing 
> balance even more difficult to maintain.The gap between the viewer and 
> 3rd party 'general purpose' rendering tools will narrow in both directions.. 
> the viewer will get better at managing arbitrary mesh and 3rd party 'general 
> purpose' rendering tools will be able to render secondlife scenes better 
> because there will be less 'prim' to render as a result of there being 
> arbitrary mesh.
> 
> In either case, the future is full of interesting technical challenges.I 
> think in unity, like with Irrlicht, smaller, more specialized scenes will 
> work OK with regards to prim rendering.  And, I don't think 3rd party 
> renderers are going to be able to come close to the capability of the 
> SecondLife viewer when dealing with prim.  They're just not designed for the 
> same type of data.  The object models and API just are not really appropriate 
> for prim.   I'm not saying that it isn't worth pursuing a render plugin 
> architecture.  I am saying, however, that given that 3rd party 'general 
> purpose' renderers are never going to be able to meet the SecondLife viewer's 
> capability in rendering prim, it probably shouldn't be very high on the 
> priority of things to do.
> 
> Regards
> 
> Teravus
> 
> 
> On Mon, Oct 4, 2010 at 12:36 AM, Brandon Husbands  wrote:
> Ive used it, and fount it blehh.  I think we are failing to communicate about 
> our conception of what is possible a

Re: [opensource-dev] Latest LL viewer beta has inventory count issues?

[Ellla McMahon]

Recently reported against Second Life Server
10.9.10.210079SVC-6353Inventory
fails to load fully 

It has been ongoing for well over a year
>

so maybe not the issue you are seeing. Reporter *was* using Second Life
2.2.0 (210127), so maybe this issue is more obvious in the 2.2 Beta.

Older issue SVC-5902  Client
gives up before finishing to load full inventory due to packet loss and
request for a refresh button
VWR-23074Unloading item
on my inventory, cause some useless relog.

Other possibly related (to a slow/incomplete Inventory loading) issues

   - VWR-23308 Can't rename a
   new folder 


   - STORM-314 Wear button in
   My Appearance greyed out 



On 5 October 2010 18:04, Ann Otoole  wrote:

> Anyone else noticing the inventory counts in the latest LL beta client are
> increasingly less than the count in the production release client and that
> cache clear does not correct it?
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Daily Scrum Update - Tuesday, October 5, 2010

[Sarah (Esbee) Hutchinson]

Tuesday, October 5, 2010

*General Notes*
* Merge Monkey of the Day: Merov

*Team Status*

*Merov Linden*
*PAST*
* JIRA triage to prepare sprint planning
* Merge Monkeying: move things in beta, v-d, also pulled beta in v-d so we
have those fixed in v_d as well.
* More HR stuff

*FUTURE*
* Sprint planning!
* STORM-137 : FMOD issue: fix upload issue with Brad. Hopefully, the rest
will be easy.
* STORM-105 : Perf decompression: put new data out, check the work done by
opensource-dev community on similar tests.
* STORM-306: back burner: bissect and incremental builds till I pinpoint the
culprit...

*IMPEDIMENTS*
* Kakadu license upgrade


*Oz Linden*
*PAST*
* Clarified wiki documentation on where to get code and download binaries
** Updated to use new auto-update direct links
** Submitted request to change main download page to match
* TPVP Changes

*FUTURE*
* Worked on proposals for open code review and build systems
* Get current on autobuild developments

*IMPEDIMENTS*
* none


*Q Linden*
*PAST*
* HR stuff
* Q4 planning
* Further meetings on test automation
* Writing automation for LLDir

*FUTURE*
* HR stuff
* Q4 planning
* Answer PE questions on STORM-325 and 295

*IMPEDIMENTS*
* My brain


*Esbee Linden*
*PAST*
* VWR triage
* Sprint 5 planning
* Backlog reviews
* Q4 planning
* Systems requirements research

*FUTURE*
* VWR triage
* Sprint 5 Planning
* Viewer roadmap planning
* Systems requirements research
* Q4 planning
* HR Stuff

*IMPEDIMENTS*
* None


*Paul ProductEngine *
*PAST*
* STORM-263 Cog button in lower-left of sidebar panel does not close popup
menu on second click
** Fixed, tomorrow will test and send for a review

*FUTURE*
* other bugs

*IMPEDIMENTS*
*none


*Andrew ProductEngine*
*PAST*
* Bug STORM-264 (Resize grab areas on detached sidebar panels are tiny and
unmarked)
** Reviewed.
* Bug STORM-325 ("i" button no longer opens profiles).
** Reproduced in viewer-beta, investigated, found changeset with fix in
viewer-development and left comment in ticket.
* Major bug STORM-295 (Mini-inspector fades out if adjust voice volume).
** Reproduced in viewer-beta, investigated, found changeset with fix in
viewer-development and left comment in ticket.
* Major bug STORM-315 (Changes to Environment Editor are not saved and do
not persist across sessions).
** Started investigating. Estimate- 6 hours.

*FUTURE*
* STORM-315 (Changes to Environment Editor are not saved and do not persist
across sessions).

*IMPEDIMENTS*
* STORM-295 and STORM-325 are fixed in viewer-development. What should be
done with these fixes? Should changesets with them be transplanted from one
repository to another, or simply fixed the same way manually, or left
untouched to wait merge with development?


*Vadim ProductEngine*
OOO - Vacation. Will be back to office on Oct, 11th.


*Seth ProductEngine (Sergey)*
*PAST*
* BUG (STORM-316) Debug: Inventory.Folders by Name/Sort by Date/Sort by
Name/System Folders to Top Do not apply and settings changes do not persist
after relogging.
** Investigated. Waiting for Esbee's reply in JIRA.
* BUG (STORM-314) Wear button in My Appearance greyed out
** Investigated. Could not reproduce with reporter's scenario. Probably
misfiled.
* BUG (STORM-310) crash after setting sound preferences
** Could not reproduce.
* BUG (STORM-305) Undocked minimized SP tabs are restored after re-login
** WIP.

*FUTURE*
* BUG (STORM-305) Undocked minimized SP tabs are restored after re-login
** Estimated: 4 hours.

*IMPEDIMENTS*
* STORM-316 needs answer from Esbee (?)
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Where oh where has my rendering gone?

[malachi]

Oh where oh where could it be!

Anyone can point me in the direction of the RGB rendering system in the  
client? Am thinking about making a switch for b&w output to the client.  
just have no idea where to start poking this beast.


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Latest LL viewer beta has inventory count issues?

[Ann Otoole]

Could be related to an existing pjira which is why I asked. However it is 
restricted to code after the LL production release candidate. I observe this in 
the latest Kirstens and the beta viewer. Deleting cache and refreshing in the 
production viewer produces the expected inventory count. Therefore it "appears" 
to be related to the newer code base only.

However I do know asset data is "vanishing". I have a ticket open and never 
looked at in respect to a humble shoe texture I created and uploaded to SL that 
has vanished from the asset system. Easily replacable yes but highly annoying 
to 
know data seemingly vanishes into thin air that way. However the inventory 
record for that texture remains intact. When previewed or rezzed the texture 
just stays gray. No matter who tries to view it. That is an asset issue not an 
inventory issue.






From: Ellla McMahon 
To: Ann Otoole 
Cc: opensource-dev@lists.secondlife.com
Sent: Tue, October 5, 2010 3:41:06 PM
Subject: Re: [opensource-dev] Latest LL viewer beta has inventory count issues?

Recently reported against Second Life Server 10.9.10.210079SVC-6353Inventory 
fails to load fully


It has been ongoing for well over a year
>

so maybe not the issue you are seeing. Reporter was using Second Life 2.2.0 
(210127), so maybe this issue is more obvious in the 2.2 Beta.

Older issue SVC-5902 Client gives up before finishing to load full inventory 
due 
to packet loss and request for a refresh button VWR-23074 Unloading item on my 
inventory, cause some useless relog.

Other possibly related (to a slow/incomplete Inventory loading) issues 

* VWR-23308Can't rename a new folder
* STORM-314Wear button in My Appearance greyed out


On 5 October 2010 18:04, Ann Otoole  wrote:

Anyone else noticing the inventory counts in the latest LL beta client are 
increasingly less than the count in the production release client and that 
cache 
clear does not correct it?
>
>
>___
>Policies and (un)subscribe information available here:
>http://wiki.secondlife.com/wiki/OpenSource-Dev
>Please read the policies before posting to keep unmoderated posting privileges
>



  ___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Daily Scrum Update - Tuesday, October 5, 2010

[Ponzu]

I hope all this HR stuff is OK.  It is making us nervous out here.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Daily Scrum Update - Tuesday, October 5, 2010

[Sarah (Esbee) Hutchinson]

We've all been working on our end-of-year reviews. Nothing to worry about!
:)
(We'll make a point of being more clear about this in future, sorry!)

- Esbee


On Tue, Oct 5, 2010 at 7:49 PM, Ponzu  wrote:

> I hope all this HR stuff is OK.  It is making us nervous out here.
>
>
>
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Where oh where has my rendering gone?

[Kent Quirk (Q Linden)]

Well, it's not quite like that. To pull this off, you'd have to take everywhere 
we set a color, and set it instead to its equivalent black and white value 
(there's a formula that's traditionally used, although there's no "correct" way 
to do it:  Y = 0.3*R + 0.59*G + 0.11*B). You *might* be able to get away with 
modifying the LLColor4 constructor to do this, but it's probably going to have 
some surprising results when you assign a value and don't get the same value 
back.

Next, you'd have to filter all of the textures so that all textures are first 
converted to B&W before being used. That's also a troublesome task, and is 
likely to be slow.

On certain graphics cards, you could try to convert all the pixel shaders to do 
a B&W conversion for each pixel before rendering, but I don't know enough about 
our system to know if that would catch all the useful cases or not. 

I hope that helps, but I'm not particularly optimistic. :/

Q


On Oct 5, 2010, at 5:36 PM, malachi wrote:

> Oh where oh where could it be!
> 
> Anyone can point me in the direction of the RGB rendering system in the  
> client? Am thinking about making a switch for b&w output to the client.  
> just have no idea where to start poking this beast.
> 
> 
> -- 
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges