Re: [opensource-dev] Convexdecomposition for open source devs

[Dahlia Trimble]

There is an implementation of bullet in OpenSimulator but it's not as well
tested as ODE, which is the dominant engine in use. Both engines are
currently using trimesh colliders for complex prims, sculpties, and meshes
and the version of ODE included with OpenSimulator does not support convex
hull colliders.
On Dec 30, 2010 8:10 AM, "Dave Booth"  wrote:
> On 12/30/2010 08:03, WolfPup Lowenhar wrote:
>>
>> I have recently had a conversation with someone @ LL that has said
>> they would be willing to help develop and OS version of
>> llconvexdecompisition. I even I even discussed which ones they thought
>> was good but they have not had the time to look at the open source
>> version in a technical way. So what I thought of is start a thread
>> here that would allow the OS community both vote and comment on the OS
>> versions with the one most generally liked being used and converted to
>> be compatible to the LL mesh viewer.
>>
>> Versions that I have found(to place your vote on this put an x next it.):
>>
>> Bullet Physics Library(just the convexdecomp section):
>>
>> Web site : http://code.google.com/p/bullet/
>>
>> Votes>
>>
>>
>> John Ratcliff's :
>>
>>
>> Web Site :
>>
http://codesuppository.blogspot.com/2009/11/convex-decomposition-library-now.html
>>
>>
>> Votes>
>>
>>
>> Comments for either system:
>>
>>
>
> I cant exactly speak to the quality of either but the fact that Bullet
> is the physics implementation used by opensim should IMHO give that
> choice a bit of a leg up. The fact that the library is already in use as
> the phys engine on the most prevalent opensource server makes its use
> for decomp in an opensource viewer rational, just as the use of havok
> decomp in the LL-compiled viewer made sense since that physics library
> was already present in-house.
> ___
> 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] Very Strange occurrence...

[Dahlia Trimble]

I've seen evidence that the Improved Instant Message packet still contains a
good user name while the group chat window displays ???(???) for the same
message.

On Wed, Dec 29, 2010 at 5:33 PM, Nicky D. wrote:

> > phenomenon's been occurring at least once a day.  Sometimes they're ???
> at
> > login, sometimes they show properly at first and then flip to ??? on
> their
> > own.  Sometimes the ???'s remain throughout the session, and sometimes
> they
> > flip back to show the correct names.  It happens regardless of whether
> the
> > user has a Display Name set or not.
>
> What irks me the most, is that changing from a good name(!) to ??? all
> of sudden.
>
> And whoever thought using ??? was a good idea should really take a few
> considerations
> what this means for logs, IMs and so on if suddenly everyone is ???
>
> I can understand that it is a problem if the name cannot be resolved.
> But why not at
> least take the safe route and use the old one (if there was already
> one) and try again
> instead of overwriting a good cache entry with ???.
>
> There should be a few fallback strategies like:
> a) Try to keep the old cache entry.
> b) Use the normal user name.
> c) Maybe even use the UUID.
>
> But just showing everyone (in the worst case) as ??? really screws
> things up IMO.
>
> Cheers,
>Nicky
> ___
> 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] Where is MXP implementation ?

[Dahlia Trimble]

I'm not sure about RealXtend, but there is a MXP implementation in
IdealistViewer. You should be able to see the code here:
http://forge.opensimulator.org/gf/project/idealistviewer/scmsvn/?action=browse&path=%2Ftrunk%2FIdealistViewer%2FNetwork%2F


On Thu, Jan 20, 2011 at 12:34 AM, Rustam Rakhimov wrote:

> Where is MXP implementation ?
>
> hi everybody,
>
> RealXtend uses MXP but where exactly, i mean which part and where its used
> or implemented
>
> please let me know. if possible file name and function name
>
> thank you in advance !!
>
> ___
> 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] Review Request: Allow objects to have 99.99% max hollow for default hollow shape.

[Dahlia Trimble]

One thing I noticed while coding collision geometry for OpenSimulator is as
hollow is increased and prims are twisted or otherwise manipulated such that
the hollow shape doesnt exactly follow the outer shape, the probability
increases that the surfaces formed by the triangles that make up the hollow
shape may actually protrude beyond those that make up the outer surface. I'm
not sure what SL sims do under these conditions but what ODE (Open Dynamics
Engine - most commonly used physics engine in OpenSimulator) is create a
condition where physical objects may become trapped between the resulting
surfaces. ODE uses trimesh colliders and surface normals for determining
collision surfaces and if prim hollow surfaces protrude outside of prim
outer surfaces, the surface normals for these surfaces point in the wrong
direction. This can be alleviated by increasing prim vertex count, but for
some of these prims vertex count may already be even greater than 4000
vertices. Increasing it further would use excessive memory and likely
increase the cost of computing collisions dramatically. I've found that a
limit of 95% maximum hollow is a good compromise between prim complexity and
usability.


On Mon, Jul 11, 2011 at 7:34 PM, Wolfpup Lowenhar
wrote:

>This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/388/
>   Review request for Viewer.
> By Wolfpup Lowenhar.
> Description
>
> As a Builder, I want to be able to create prims that are more than 95 % 
> hollow which will allow me to create more realistic paper sheets, flags, 
> fabric bits, ribbons, etc.
>
>   Testing
>
> Built viewer locally and testes Viewer Phase of Acceptance Criteria.
>
>   *Bugs: * STORM-58 
> Diffs
>
>- doc/contributions.txt (d4cd5f0f33d2)
>- indra/llmath/llvolume.cpp (d4cd5f0f33d2)
>- indra/newview/llpanelobject.cpp (d4cd5f0f33d2)
>- indra/newview/skins/default/xui/en/floater_tools.xml (d4cd5f0f33d2)
>
> View Diff 
>
> ___
> 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] Review Request: Allow objects to have 99.99% max hollow for default hollow shape.

[Dahlia Trimble]

Unfortunately it does happen, especially when prims are twisted or otherwise
skewed. 99.99 is too close. You may mot see it in a viewer but physics will
not work with it. I believe the current 95% limits are there for a reason
and the original designers may not be around to defend it or have documented
it.

On Tue, Jul 12, 2011 at 9:13 AM, Vadim ProductEngine <
vsavc...@productengine.com> wrote:

>This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/388/
>
> Ship it!
>
> No objections.
>
>
> - Vadim
>
> On July 11th, 2011, 7:34 p.m., Wolfpup Lowenhar wrote:
>   Review request for Viewer.
> By Wolfpup Lowenhar.
>
> *Updated July 11, 2011, 7:34 p.m.*
> Description
>
> As a Builder, I want to be able to create prims that are more than 95 % 
> hollow which will allow me to create more realistic paper sheets, flags, 
> fabric bits, ribbons, etc.
>
>   Testing
>
> Built viewer locally and testes Viewer Phase of Acceptance Criteria.
>
>   *Bugs: * STORM-58 
> Diffs
>
>- doc/contributions.txt (d4cd5f0f33d2)
>- indra/llmath/llvolume.cpp (d4cd5f0f33d2)
>- indra/newview/llpanelobject.cpp (d4cd5f0f33d2)
>- indra/newview/skins/default/xui/en/floater_tools.xml (d4cd5f0f33d2)
>
> View Diff 
>
> ___
> 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] Review Request: Allow objects to have 99.99% max hollow for default hollow shape.

[Dahlia Trimble]

Unfortunately the official reply mechanism has the following restrictions:

"*In order to post reviews or comment on them in this system, you must
either: *

   * *
   - *be an employee of or contractor for Linden Lab*
   - *have executed a Contribution
Agreement<http://secondlifegrid.net.s3.amazonaws.com/docs/SLVcontribution_agmt.pdf>
   ***

"

I'll IM Oz and refer him to this discussion.


On Tue, Jul 12, 2011 at 11:54 AM, Vadim Savchuk
wrote:

> Dahlia, please comment in the ticket for the Product Owner to notice.
>
>
> On 07/12/2011 09:16 PM, Dahlia Trimble wrote:
>
>> Unfortunately it does happen, especially when prims are twisted or
>> otherwise skewed. 99.99 is too close. You may mot see it in a viewer but
>> physics will not work with it. I believe the current 95% limits are there
>> for a reason and the original designers may not be around to defend it or
>> have documented it.
>>
>
> --
> Vadim
>
>
___
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] An Idea

[Dahlia Trimble]

1) open map
2) zoom out all the way
3) double click somewhere

works for me :)

On Sat, Oct 22, 2011 at 4:51 PM,  wrote:

> Hey Everybody,
>
> i had an idea.  My dad used to tell me that when i had one of those i
> should treat it kindly, 'cause it was in a strange place.  "Ha-ha," huh?
>
> Anyways, what if there was a "Random TP" button or keypress or whatever?
> i mean, just to make things interesting?*  i don't know what kind of
> controls or whatever might make it more (or less) practical, but i think
> it would be a pretty cool thing.  i know i'd try it lots.  Well, as soon
> as i get my computer fixed, anyway.
>
> Y'all rock!
>
> - AK
>
> * Some things i can think of might be:  1) to a place with more (less)
> than X avis there,  2) from the list of Linden Prize winners,  3) with
> maturity rating (not) Y,  4) dance clubs or concerts,  5) language(s)
> being spoken Z,  ...and like that.  Maybe people could sign up to be on a
> list of destinations, or maybe some of it could just be parsed out of info
> we could otherwise collect ourselves if we wanted to spend a lot of time
> doing it.  Or maybe it could just be made out of all the places that
> aren't trying to keep people out?
>
> ___
> 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] "Standard Human Mesh Avatar"???

[Dahlia Trimble]

The MakeHuman mesh is probably far too complex (vertex count) to allow
reasonable real-time  performance for many users with less than the best
graphics cards. There's probably other meshes available on other 3d content
sites which are better designed for real-time animation.

On Sat, Dec 10, 2011 at 9:57 AM, Robert Martin  wrote:

> Does anybody have (and would like to share) a Normal Human Mesh Avatar??
>
> As part of playing with MakeHuman i would like to be able to use it to
> make Mesh Avatars but i need to sort out the right workflow.
>
> things that are currently NOT DOCUMENTED
> 1 what should be the maximum number of vertexes in the model for it to work
> 2 how do i go about rigging the avatar??
> 3 will the normal 1024X textures work or can they be bigger??
>
> Bu naq v unir gevrq gb Tbbtyr Vg fb WSTV vf abg na nafjre gur jvxv vf
> svpgvbany (be qbrf abg nafjre gur dhrfgvba) fb EGSZ vf nyfb n
> abanafjre (fvapr gur xnzn fhgen qbrf abg pbire guvf) {rot13}
>
> --
> Robert L Martin
> ___
> 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] allowing client side AO's to swtich with outfits

[Dahlia Trimble]

3) allow an outfit to include notecards in the outfit folder

On Sun, Apr 15, 2012 at 10:13 AM, Erin Mallory  wrote:

>  I see two really "easy" ways to do this.
> 1) Allow outfit folders and AO sets to be able to share a "hotkey" so that
> pressing that hotkey will both equip the outfit and activate the AO
> 2) Script in a right click menu option at the outfit folder level that
> asks if you want to link an AO config to activate the ao when equipping the
> outfit.  IE: you right click the outfit folder and when the menu pops up it
> has something like "Set outfit AO."
>
> ___
> 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] allowing client side AO's to swtich with outfits

[Dahlia Trimble]

The AO could be coded such that it looks at the name of the currently worn
outfit and selects the appropriate animation list for that name. I believe
the name of the currently worn outfit is sent to the viewer as it's used to
highlight it in the appearance selector menu.

I suggested the notecard approach as an alternative that could also allow
notecards in outfits for other uses besides AO animation lists. However
given that it would likely require a server side change, it's probably much
less likely to happen than just re-coding the client-side AO. Personally I
would prefer anything that is associated with my avatar to not be client
dependant as I switch computers and clients a lot.

On Sun, Apr 15, 2012 at 10:50 PM, Erin Mallory  wrote:

>  Why would it need to be in the inventory taking up space when it would
> ONLY do the same thing that either of these options do?  If you can link a
> client ao to activate when the outfit is equipped that would satisfy the
> need for it to automatically turn on when you equip a new outfit AND keep
> the inventory MUCH less cluttered.
> The entire reason I use Firestorm's ao is so that I could get rid of as
> many copies of aos as I could and swap between ao sets almost instantly
> even in high lag areas.  Right now they do not have a way to equip
> automatically when I set an outfit, however it is two extra clicks to
> select the one I want from a dropdown.  If I could have a menu option on
> the outfit folder to allow me to associate each outfit with an AO so that
> it automatically swapped when I changed outfits that would be neat and do
> the same thing you wanted it to do.  If I wanted to change the association
> or dissociate it I could do so from the same command.
> What I envision would simply be another option with a menu item such as
> "Set AO" and contain a drop nearly identical to the list in the AO drop
> down menu except it would also have a "none" option. for example if I had
> an outfit folder named "feral neko" with several attachments and clothes in
> it and wanted to associate my Puli Neko AO with it then all I would need to
> do is right click the folder for "feral neko" select "set ao" and click
> "Neko Puli AO" and then until i changed the associated ao every time I
> equipped the outfit "feral neko" it would automatically switch the ao to
> the Neko Puli AO set.  That way i would not need any box or notecard or
> other object to clutter my already overwhelming inventory.
> Please explain what such a system would lack that either type of object
> you are talking about could provide because I simply do not see the
> benifits or requirements to have any object in the inventory other than a
> single notecard for each ao set and a copy of each animation that is
> included in any set.
>
>
>
> > CC: opensource-dev@lists.secondlife.com
> > From: secret.arg...@gmail.com
> > Subject: Re: [opensource-dev] allowing client side AO's to swtich with
> outfits
> > Date: Sun, 15 Apr 2012 21:34:30 -0500
> > To: angel_of_crim...@hotmail.com
>
> >
> > On 2012-04-15, at 12:13, Erin Mallory wrote:
> > > 1) Allow outfit folders and AO sets to be able to share a "hotkey" so
> that pressing that hotkey will both equip the outfit and activate the AO
> >
> > > 2) Script in a right click menu option at the outfit folder level that
> asks if you want to link an AO config to activate the ao when equipping the
> outfit. IE: you right click the outfit folder and when the menu pops up it
> has something like "Set outfit AO."
> >
> > Neither of these are acceptable, it _has to_ be something in the
> inventory that is managed with the inventory tools. Otherwise there's no
> reason not to keep using the existing scripted AOs.
> >
> > Ideally, it's just a box, like an existing AO, except instead of having
> a script in it it's attached to an "AO" attachment point or has a name like
> "#AO".
> >
> > Alternatively, a scripted object could run and llOwnerSay a series of
> magic strings containing the animation name and animation type, in on_rez()
> or attach().
>
> ___
> 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] New HTTP Library & Project Viewer

[Dahlia Trimble]

I can't help but think something is wrong here.  A single TCP/IP link is
more than capable of saturating available network bandwidth with efficient
transfers of large volumes of data provided the end-points can produce and
consume quickly enough.

It seems part of the problem may in the request/response nature of HTTP.
The viewer needs to make a request for each asset it needs as it discovers
it needs it. It sends a request for each asset, and the provider endpoint
then has to do whatever it does to make the asset available before
beginning to send it back to the client. This may occur relatively
instantly in the case of assets in a server memory cache, or a lot longer
depending on where it needs to be pulled from or how it may need to be
prepared. Assuming this is the case, having multiple overlapping requests
can improve the overall download rate of multiple assets by allowing some
downloads to occur while others are prepared, albeit at the expense of
additional connections. Having a persistent connection reduces some of the
delays introduced by re-establishing a connection for each asset, but it
does nothing to reduce the time that the server endpoint needs to acquire
and prepare the asset to send.

Now (assuming this isn't the case already) if the producer endpoint could
be made aware of future requests, it could fetch and prepare the asset for
transfer prior to the actual request being received, thereby reducing or
eliminating the time delays inherent in the request-response paradigm. This
*may* be as simple as adding additional optional UUIDs and parameters to
the asset request for assets that the viewer would likely be requesting
next. If this were the case, a single connection could have a higher
effective throughput by ensuring minimal delays between request and
response, and reduce the need for more simultaneous connections.

Such a solution may or may not be practical or easily implemented in
existing infrastructure, or may not be as efficient as other designs. My
point is more or less meant to bring more perspectives into the discussion
by considering other bottlenecks that may exist, which if mitigated, could
reduce the need for excessive connections.

Thoughts?
-dahlia

On Wed, Aug 1, 2012 at 7:22 AM, Monty Brandenberg wrote:

> On 7/31/2012 10:03 PM, Kadah wrote:
>
> > Its 8 again with the fallow comment. I tired to track down the rev,
> > but apparently Mecurial 2.2 can't properly annotate that file for some
> > reason, and the new UI for it in TortoiseHg2 is horrid. All of the
> > referenced jiras around its changes are not public.
>
> One of the major reasons around that has to do with the
> behavior of low-end routers.  It really is a problem for
> them.
>
>
> ___
> 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] New HTTP Library & Project Viewer

[Dahlia Trimble]

Don't worry Carlo, I know better than to try to tell an engineer how to do
her/his job ;)

So, if pipelining is implemented and it works, what other bottlenecks are
there that make multiple connections work so well?


On Thu, Aug 2, 2012 at 10:14 AM, Carlo Wood  wrote:

> On Thu, 2 Aug 2012 02:01:45 -0700
> Dahlia Trimble  wrote:
>
> > I can't help but think something is wrong here.  A single TCP/IP link
> > is more than capable of saturating available network bandwidth with
> > efficient transfers of large volumes of data provided the end-points
> > can produce and consume quickly enough.
> >
> > It seems part of the problem may in the request/response nature of
> > HTTP. The viewer needs to make a request for each asset it needs as
> > it discovers it needs it. It sends a request for each asset, and the
> > provider endpoint then has to do whatever it does to make the asset
> > available before beginning to send it back to the client. This may
> > occur relatively instantly in the case of assets in a server memory
> > cache, or a lot longer depending on where it needs to be pulled from
> > or how it may need to be prepared. Assuming this is the case, having
> > multiple overlapping requests can improve the overall download rate
> > of multiple assets by allowing some downloads to occur while others
> > are prepared, albeit at the expense of additional connections. Having
> > a persistent connection reduces some of the delays introduced by
> > re-establishing a connection for each asset, but it does nothing to
> > reduce the time that the server endpoint needs to acquire and prepare
> > the asset to send.
> >
> > Now (assuming this isn't the case already) if the producer endpoint
> > could be made aware of future requests, it could fetch and prepare
> > the asset for transfer prior to the actual request being received,
> > thereby reducing or eliminating the time delays inherent in the
> > request-response paradigm. This *may* be as simple as adding
> > additional optional UUIDs and parameters to the asset request for
> > assets that the viewer would likely be requesting next. If this were
> > the case, a single connection could have a higher effective
> > throughput by ensuring minimal delays between request and response,
> > and reduce the need for more simultaneous connections.
> >
> > Such a solution may or may not be practical or easily implemented in
> > existing infrastructure, or may not be as efficient as other designs.
> > My point is more or less meant to bring more perspectives into the
> > discussion by considering other bottlenecks that may exist, which if
> > mitigated, could reduce the need for excessive connections.
> >
> > Thoughts?
> > -dahlia
>
> Dahlia, an overwhelming amount of past experience has taught us that
> Linden Lab is not interested if you "think along" with them about the
> server, or the viewer-server protocol,either with suggestions, designs
> or anything. This list is set up to get feedback about viewer bugs, and
> to announce things they came up with (in most cases someone else came up
> with than the ones that we're allowed to talk with). So, it's a complete
> waste of your time to do anything else than to just sit back and read
> what Linden Lab is going to push through (no matter what arguments you
> come with, or what flaws you point out).
>
> [ That being said, they came up with "pipelining" as the solution for
> the problem you mention. That allows a viewer to send new requests over
> the same connection, without having to wait for a reply for former
> requests. This isn't the most efficient solution, but a lot better
> (still depending on the closed source server implementation though)
> than how it works so far. ]
>
> --
> Carlo Wood 
> ___
> 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] feature suggestion: make "doubleclick navigation" more "immersive"

[Dahlia Trimble]

If you want to request a server mod, perhaps a mod to the autopilot
functionality to be able to use pathfinding. A potential problem with using
a waypoint list is the path may become obstructed or otherwise modified
while traversing the path.

-d

On Fri, Sep 21, 2012 at 12:17 AM, Lance Corrimal
wrote:

> Hi all!
>
> Here's a feature idea that I just had, and I thought I'd float it past here
> before I post a feature request on the jira.
>
> As a user I would like to see a third option for doubleclick navigation
> inworld: "pathfinding - immersive"
>
> With that option turned on, the viewer would determine if the point the
> user
> clicked on is within draw distance, and if so, use pathfinding "navigate
> to"
> to walk there. If the point was outside of drawdistance, the viewer would
> use
> whatever else the user had configured for normal doubleclick navigation
> (i.e.
> teleporting or "go here").
>
> any thoughts?
>
> I'd believe that would need some server code, so that the viewer could ask
> the
> server for a list of waypoints to walk from A to B, the user being a
> character
> type A.
>
>
> bye,
> LC
>
> ___
> 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] feature suggestion: make "doubleclick navigation" more "immersive"

[Dahlia Trimble]

I was *not* suggesting using the autopilot as it currently exists. I was
suggesting a newer autopilot-like function provided by the simulator that
can use live pathfinding to move the agent. I was suggesting it because a
waypoint list can become obsolete between the time it's generated and the
time the path is traversed. A *pathfinding capable* autopilot function
could update the waypoint list while in route in case the original path
becomes obstructed.

-d

On Fri, Sep 21, 2012 at 9:32 AM, Lance Corrimal
wrote:

> Am Freitag 21 September 2012, 01:24:30 schrieb Dahlia Trimble:
> > If you want to request a server mod, perhaps a mod to the autopilot
> > functionality to be able to use pathfinding. A potential problem with
> using
> > a waypoint list is the path may become obstructed or otherwise modified
> > while traversing the path.
>
>
> and walking a straight line from A to B withoiut even paying attention to
> obstacles is better?
>
> That is what the viewer does now when you do a "go here" by clicking on the
> ground twice.
>
>
> bye,
> LC
>
> >
> > -d
> >
> > On Fri, Sep 21, 2012 at 12:17 AM, Lance Corrimal
> >
> > wrote:
> > > Hi all!
> > >
> > > Here's a feature idea that I just had, and I thought I'd float it past
> > > here
> > > before I post a feature request on the jira.
> > >
> > > As a user I would like to see a third option for doubleclick navigation
> > > inworld: "pathfinding - immersive"
> > >
> > > With that option turned on, the viewer would determine if the point the
> > > user
> > > clicked on is within draw distance, and if so, use pathfinding
> "navigate
> > > to"
> > > to walk there. If the point was outside of drawdistance, the viewer
> would
> > > use
> > > whatever else the user had configured for normal doubleclick navigation
> > > (i.e.
> > > teleporting or "go here").
> > >
> > > any thoughts?
> > >
> > > I'd believe that would need some server code, so that the viewer could
> ask
> > > the
> > > server for a list of waypoints to walk from A to B, the user being a
> > > character
> > > type A.
> > >
> > >
> > > bye,
> > > LC
> > >
> > > ___
> > > 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] feature suggestion: make "doubleclick navigation" more "immersive"

[Dahlia Trimble]

I guess it could be prototyped  by using
http://wiki.secondlife.com/wiki/LlGetStaticPath  in an attachment that the
viewer can communicate with, but (assuming the wiki is accurate) it looks
like it doesn't deal with the obstructed path problem so requesting a new
path upon reaching a waypoint probably wouldn't do much good.


On Fri, Sep 21, 2012 at 1:58 PM, Lance Corrimal
wrote:

> Am Freitag 21 September 2012, 12:43:29 schrieb Dahlia Trimble:
> A *pathfinding capable* autopilot function
> > could update the waypoint list while in route in case the original path
> > becomes obstructed.
>
> basically, after reaching a waypoint it would request the list of remaining
> waypoints again? that sounds like a good plan.
>
>
> bye,
> LC
>
> ___
> 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] New HTTP Library & Project Viewer

[Dahlia Trimble]

Would this excerpt from RFC2616 (section 8.2) be relevent?  Perhaps some
routers and other infrastructure assume this as design criteria:

"
   Clients that use persistent connections SHOULD limit the number of
   simultaneous connections that they maintain to a given server. A
   single-user client SHOULD NOT maintain more than 2 connections with
   any server or proxy. A proxy SHOULD use up to 2*N connections to
   another server or proxy, where N is the number of simultaneously
   active users. These guidelines are intended to improve HTTP response
   times and avoid congestion. "



On Tue, Oct 23, 2012 at 7:28 AM, Monty Brandenberg wrote:

> On 10/23/2012 6:10 AM, Henri Beauchamp wrote:
>
> > And in fact, llappcorehttp.cpp only touches CP_CONNECTION_LIMIT, so
> > CP_PER_HOST_CONNECTION_LIMIT is kept at its default (8) whatever the
> > TextureFetchConcurrency debug setting value, meaning the viewer never
> > opens more than 8 simultaneous connections per HTTP server.
> >
> > I therefore think that, as it is used right now TextureFetchConcurrency
> > is not really useful (there's already a hard-coded limit of 40 in
> > lltexturefetch.cpp for the max number of simultaenously queued texture
> > fetching requests: perhaps this number should be affected by
> > TextureFetchConcurrency instead ?), and in fact, the CP_CONNECTION_LIMIT
> > will need to be much greater than 8 or 12, once the new HTTP core is used
> > for connecting to other servers than just texture servers (mesh,
> > capabilities, etc).
> > On the other hand, I agree that CP_PER_HOST_CONNECTION_LIMIT should be
> > kept below a reasonnable maximum value (8 sounds good for pipelining
> > requests, but non-pipelining ones could probably allow up to 32 which
> > is the default for per-host connections in most HTTP servers).
>
> Actually, GP_CONNECTION_LIMIT (global) and CP_PER_HOST_CONNECTION_LIMIT
> (per-class, per-host) aren't implemented yet so only CP_CONNECTION_LIMIT
> (and TextureFetchConcurrency) have effect.  _httpinternal.h has the
> general to-do list for next phases.  This is one area that should get
> some attention but a single control is all that's necessary for this
> release.
>
> As for the 40 request high water mark.  That's part of a trade-off
> between several competing factors:
> 1.  Deep pipelining to keep work available to low-level code (favors
> large numbers).
> 2.  Responsiveness to changes in prioritization without having to
> serialize and pass new priority values down to lowest layers (favors
> small numbers).
> 3.  Eventual balancing with other users of the same class to guarantee
> fairness and liveness.  For textures, this will almost certainly include
> meshes and possibly other caps-based requests that don't use SSL.
>
> > Unless the router is buggy, it shouldn't be impacted by the number of
> > open sockets (at least not under 60K sockets)... Some protocols, such
> > as torrent can use hundreds or even thousands of sockets at once.
>
> As Oz points out, routers are all affected by this and other factors.
> And I'd go so far to say that any router that implements NAT is
> guaranteed to be broken by design.  But they're all broken in unique
> and interesting ways.  Some are sensitive to connection concurrency.
> Others to connections created over a time interval.  To counts of
> dest_addr:src_addr pairs, to counts of (dst_addr:dst_port:src_addr:
> src_port:ident) tuples.  To DNS activity interspersed with handshakes.
> And then the failure modes are many.  I once tried to build a simple
> control system to respond to failures but one family of routers
> takes five minutes to respond to a change in environment.  Can't build
> a universally valid feedback system for this purpose with that kind
> of delay in the response.
>
> To quote Roy Batty:  I've seen things you people wouldn't believe.
>
> Here's a chart I keep forwarding:
> http://www.smallnetbuilder.com/lanwan/router-charts/bar/77-max-simul-conn
> Not officially endorsed by Linden, etc., but a useful measure of
> one metric that is likely to predict problems.  At the bottom of
> that chart you'll find members of router families that are both
> very common and very often a source of problems in SL.
>
> > The true limit is server side.
>
> No, not really.  It is *a* limit and one I'm deeply involved with.
> But there are people who are having difficulty getting to the
> servers and haven't even been able to enjoy its limits.
>
>
> ___
> 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] New HTTP Library & Project Viewer

[Dahlia Trimble]

I believe the 2 persistent HTTP connections/server recommendation is just
that: a maximum of 2 *persistent* connections *per server*. Torrent
downloads are more likely 1 connection per server with many servers.
Torrent clients also have the ability for users to specify maximum outbound
transfer rates and trying to overcome them by opening more connections to a
particular server will likely not be fruitful.

Also, networked system designers may have control of how endpoints are
implemented but if the public internet is used as a transfer medium then
they have little (if any) control over what happens between those
endpoints. ISPs can (and often do) control traffic via whatever criteria
they deem fit. Choke points likely exist in many places and end users may
be powerless to understand and/or resolve issues caused by over-zealous
connection hoarding.


On Tue, Oct 23, 2012 at 5:21 PM, Henri Beauchamp  wrote:

> On Tue, 23 Oct 2012 10:28:37 -0400, Monty Brandenberg wrote:
>
> > Here's a chart I keep forwarding:
> >
> http://www.smallnetbuilder.com/lanwan/router-charts/bar/77-max-simul-conn
> > Not officially endorsed by Linden, etc., but a useful measure of
> > one metric that is likely to predict problems.  At the bottom of
> > that chart you'll find members of router families that are both
> > very common and very often a source of problems in SL.
>
> Very interesting chart... And quite frigthening too, seeing all the
> so-called "routers" that can't even handle 1K connections !
>
> This said, such routers would also stall on torrent downloads.
>
> Henri.
> ___
> 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] Materials

[Dahlia Trimble]

Are the protocol changes documented anywhere? Who might be able to provide
any information about them?

On Fri, Nov 9, 2012 at 12:36 PM, Oz Linden (Scott Lawrence) <
o...@lindenlab.com> wrote:

>  On 2012-11-08 18:50 , Martin Fürholz wrote:
>
> Hello,
> Maestro Linden just announced that the materials project is live on Aditi,
> is there a link for a project viewer to test the changes?
>
>  Large parts of the server side support for storing and retrieving the
> material data are running on a couple of Aditi regions, but we don't have a
> Project viewer yet.
>
> Don't worry - when we do, we won't keep it a secret.
>
>
> ___
> 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] Mac viewer and Apple maintained opensource libraries

[Dahlia Trimble]

It's probably considered bad practice for code to use an ARB extension
without first checking to see if it's available.

On Wed, Feb 1, 2017 at 12:24 PM, Geir Nøklebye 
wrote:

> Cinder said
>
> >For what it?s worth, Apple did warn developers to stop using it and
> switch to Cocoa?s crypto frameworks or ship their own.
>
> …and that is the core of the state of the macOS version of the viewer(s).
> Deprecated code all over.
>
> When will be see the crash in the occlusion code being fixed due to the
> fact that GL_ARB_occlusion_query2 is not available in the OpenGL Legacy
> Profile the renderer currently is forced to when the viewer is running on
> macOS 10.11 or higher?
>
> Event:   GPU Reset
> Date/Time:   Wed Feb  1 21:17:26 2017
>
> Tailspin:/Library/Logs/DiagnosticReports/
> gpuRestart2017-02-01-211726.tailspin
> GPUSubmission Trace ID: 0
> OS Version:  Mac OS X Version 10.12.3 (Build 16D32)
> Graphics Hardware:   NVIDIA GeForce GTX 660M
>
>
> NVDA(Graphics): Channel exception! Exception type = 0x1f Access Violation
> Error (MMU Error 2)
> Channel Info: [44, 0x14, 0x12, 0x136555]
> Version Info: [com.apple.GeForce, 10.1.4, 0x7d780b0a, 18894120,
> 355.10.05.15f03, 1]
> MMU Error: FAULT_PTE at 0x5063c
>
>
> This crash happens in Cool VL Viewer, Singularity, Alchemy, Firestorm,
> Kokua, SecondLife release and all dev versions including Second Life
> Project Alex Ivy
> You probably never get it reported because the  Google Breakpad reports
> don’t catch 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] macOS 10.14 deprecation of OpenGL, what does this mean for SL?

[Dahlia Trimble]

I've been hearing of this coming for a couple years. The quoted article
seems to suggest that OpenGL will be around for a while and I can't believe
that Apple will remove an API that so many applications use. They seem to
want people to port to Metal but that may not be possible for a lot of
legacy applications. Regardless, they don't want anyone developing new
applications that use OpenGL.

Perhaps the MoltenGL people might see an opportunity here and extend their
products to include desktop versions of OpenGL.

But seriously, perhaps LL should consider writing a new viewer with a
modern, API-agnostic rendering layer. OpenGL is stagnant on just about
every platform now.

On Mon, Jun 4, 2018 at 7:23 PM, Cinder Roxley 
wrote:

> Apple deprecated AGL in 2009 and yet programs linking to it still run
> nearly ten years later. The sky Isn’t falling any time soon.
>
>
> On June 4, 2018 at 5:26:00 PM, Kadah Coba (kadah.c...@gmail.com) wrote:
>
> So just heard about this, not sure if this was known about before this.
> https://developer.apple.com/macos/whats-new/
>
> "Apps built using OpenGL and OpenCL will continue to run in macOS 10.14,
> but these legacy technologies are deprecated in macOS 10.14. Games and
> graphics-intensive apps that use OpenGL should now adopt Metal."
>
> There's doing the same on iOS too, not that it effects us.
>
> Knowing Apple's way, could likely assume 10.15 or 10.16 may not support
> OpenGL at all, or at worse, a later update of 10.14.x.
>
> So what does this mean for us since its the thing we breath
> ? Blue alert or do we change
> the bulb to red ?
> May 31, 2018 at 11:22:38 AM ___
> 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
>
___
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] macOS 10.14 deprecation of OpenGL, what does this mean for SL?

[Dahlia Trimble]

But Vulkan bears virtually no resemblance to OpenGL. Some might consider it
next generation OpenGL but it's really a whole new API, based on "Mantle"
from AMD. It's also much more difficult to use than OpenGL and requires
more systems programming expertise than typical graphics oriented APIs.
It's also not supported by Apple either, but I've heard some good things
about MoltenVK (a Vulkan abstraction on top of Metal).

On Tue, Jun 5, 2018 at 1:27 AM, Henri Beauchamp  wrote:

> On Mon, 4 Jun 2018 22:41:48 -0700, Dahlia Trimble wrote:
>
> > But seriously, perhaps LL should consider writing a new viewer with a
> > modern, API-agnostic rendering layer. OpenGL is stagnant on just about
> > every platform now.
>
> OpenGL is not stagnant (v4.6 dates only from July 2017): it is simply
> mature.
>
> However, next generation OpenGL is not v5.0 but rather Vulkan (the latter
> allowing to take a much larger benefit from multi-core CPUs, at the cost of
> a lower level API and thus more work and complexity for the 3D application
> programmers).
>
> As for SL viewers, I'd love to see a Vulkan renderer developed, but I doubt
> it will happen any time soon...
>
> Henri.
> ___
> 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] Client-side scripting in Snowglobe

[Dahlia Trimble]

I haven't been following this topic in any office hours so I hope my
comments aren't too off base.

Personally I'd prefer to be able to run extensions as sandboxed, and maybe
have the option of running them unprotected on a per-extension basis. To me,
an environment such as SL or the web in general tend to attract a few
malicious developers, or more so, companies and individuals who are
interested in collecting personal data and usage patterns. I'd prefer some
level of control over what they can access without needing to understand the
source code of any scripted extensions (if indeed source was available).

Concerning Morgaine's list: while I may not fully agree with reasons 1-4,
they appear to reflect valid concerns and are presented in a agreeable
manner. Reasons 5 and 6 seem to imply political overtones to me, and I
suspect any platform choice will carry some political burden with it.
Personally I believe mono to be a reasonable choice for a scripting
environment, especially given LL's experience with it in their servers.

And now since I don't contribute to the LL viewer source, I'll shut up :)

-d


On Thu, Feb 18, 2010 at 4:57 AM, Morgaine wrote:

> A line got lost from my post owing to finger trouble.  Item 6 about Mono
> should have read:
>
>
> 6. Some parties identify other reasons for avoiding Mono in general.
>  Without getting into that subject at all, requiring Mono for client-side
> scripting would make scripting unavailable to that portion of the user
> base.  Since client-side scripting without Mono is perfectly feasible, Mono
> should not be made mandatory for scripting, so that the widest user base can
> be supported.
>
>
> Morgaine.
>
>
>
>
>
> 
>
>
> On Thu, Feb 18, 2010 at 12:42 PM, Morgaine  > wrote:
>
>> I referred recently to Linden's internal project "Firefly" to add
>> client-side scripting to SL viewers.  This has been the topic of open
>> discussion at several Office Hours with Lindens in SL, but that openness has
>> not extended to many design details --- the Firefly design process is not
>> open to the community.  The only technical details that are being disclosed
>> about Firefly appear to be:
>>
>>
>>- "Scripts" are actually *Mono assemblies*, so that only languages
>>that compile to Mono will be allowed.
>>- The programs run in a *sandbox*, which means that most platform
>>resources are not accessible to them.
>>
>>
>> Please note that I quite like C# as a language, but the following remarks
>> are about Mono use *in the SL viewer*, only, where its tradeoffs are
>> poor.
>>
>> The first known detail about Firefly (mandatory Mono) is problematic on
>> several fronts:
>>
>>1. Only a tiny fraction of the world's applications, libraries and
>>languages work on Mono, so client-side scripting will be unable to benefit
>>from the huge mountain of resources available on the Internet.  This is an
>>extremely severe limitation, and an unnecessary restriction in the context
>>of client-side viewer scripting.  If I want to use a locally-installed
>>package X from within my client-side script, I should be able to.  What 
>> runs
>>client-side should always be our individual choice, not someone else's.
>>2. Programmers want to write client-side scripts in the language that
>>they know best, because that always yields the fastest progress and 
>> highest
>>quality results.  There was a good technical reason for forcing everyone 
>> to
>>use LSL server-side, but there is no technical reason to impose this
>>requirement on all client-side scripting.  It is counter-productive to 
>> force
>>CLR compatibility on client-side script developers when there is a simple
>>alternative:  define a *socket-based viewer API* for client-side
>>scripts instead, hence usable from any language.
>>3. Mono runs poorly on Linux, so from being rock-solid on Linux now,
>>the LL-derived viewers will become second-rate on this platform.
>>4. The viewer is already extremely bloated and a memory hog.  Adding a
>>Mono dependency will compound that horribly.
>>5. There is only one effective supplier of Mono:  Novell.  That is a
>>very bad situation to encourage and to support in the viewer.
>>6. Some parties identify other reasons for avoiding Mono in general.
>> Without getting into that subject at all,
>>
>>
>> The second known detail about Firefly (mandatory sandbox) is problematic
>> on two related fronts:
>>
>>1. Sandboxes by design do not allow most platform resources to be
>>accessed, as a security measure.  This is fine and important when scripts
>>are being downloaded from unknown places (like Javascript in web pages), 
>> but
>>that same protection also means that client-side scripts would be 
>> powerless
>>to do useful things for us in concert with local applications, files,
>>devices, etc.  Sandboxing client-side scripts effectively hardwires in
>>  

Re: [opensource-dev] Third party viewer policy

[Dahlia Trimble]

C'est la vie



On Wed, Feb 24, 2010 at 12:43 AM, Lawson English  wrote:

> Marine Kelley wrote:
> > You gotta be kiddin me !! I call that a stab in the back. You guys
> > disgust me.
> >
> >1. Your Third-Party Viewer name must not be confusingly similar to
> >   or use any part of a Linden Lab trademark, including “Second,”
> >   “Life,” “SL,” or “Linden.” For example:
> >  1. You must not have a Third-Party Viewer name that is
> > “ Life” where “” is a term or series of terms
> >
>
> I wonder if 二回♀will violate this
>
>
> Lawson
>
>
>
>
> ___
> 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] Third party viewer policy

[Dahlia Trimble]

Wasn't meant to torment anyone. Actually I was considering it for a viewer
name ;)


On Wed, Feb 24, 2010 at 1:00 AM, Marine Kelley wrote:

> Laugh, while I work at finding a name that will not infringe LL's new
> policy, update countless pages of documentation, download websites and
> blogs, update all my scripts and manuals, and explain to scripters why they
> have to update theirs.
>
>
>
> On 24 févr. 2010, at 09:48, Dahlia Trimble 
> wrote:
>
> C'est la vie
>
>
>
> On Wed, Feb 24, 2010 at 12:43 AM, Lawson English < 
> lengli...@cox.net> wrote:
>
>> Marine Kelley wrote:
>> > You gotta be kiddin me !! I call that a stab in the back. You guys
>> > disgust me.
>> >
>> >1. Your Third-Party Viewer name must not be confusingly similar to
>> >   or use any part of a Linden Lab trademark, including “Second,”
>> >   “Life,” “SL,” or “Linden.” For example:
>> >  1. You must not have a Third-Party Viewer name that is
>> > “ Life” where “” is a term or series of
>> terms
>> >
>>
>> I wonder if 二回♀will violate this
>>
>>
>> Lawson
>>
>>
>>
>>
>> ___
>> Policies and (un)subscribe information available here:
>>  <http://wiki.secondlife.com/wiki/OpenSource-Dev>
>> 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
>
>
___
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] TPV & opensim

[Dahlia Trimble]

I have been experimenting with combining and/or offloading physics
simulations on physics capable clients (not LL based) with OpenSim, but
nothing has been released as open source as of yet. It's not clear to me how
a new TLD would affect this though, or why it might be required.

-Dahlia
(Core)

On Thu, Feb 25, 2010 at 11:05 AM, Dzonatas Sol  wrote:

> I thought this was quite of interest for viewer developers that might ever
> be interested to attach a simulator to their viewer in order to dispel
> latency.
>
> --- snip ---
>
> If one opensim box connects to another opensim box, that is, technically,
> peer to peer.
>
> So, are you saying an opensim box cannot run a client at the same time?
>
> >Melanie wrote:
> >Hi,
>
> >peer to peer simulation is not practical for many different reasons.
> >Latency being the chief one.
> >
> >OpenSim is not going to be a peer to peer system, therefore your
> >suggestion is off topic. Opensim doesn't need another TLD, and it is
> >not what you are envisioning. OpenSim firmly embraces the concept of
> >SERVER SIDE simulation, therefore every sim will always have a
> >central server.
> >
> >I believe this has gone as far as it will go and if there is any
> >more name calling, well, we'll just have to moderate some people,
> >won't we?
> >
> >Melanie
> >(Core)
>
> If one opensim box connects to another opensim box, that is, technically,
> peer to peer.
>
> So, are you saying an opensim box cannot run a client at the same time?
>
> Melanie wrote:
>
>> Hi,
>>
>> peer to peer simulation is not practical for many different reasons.
>> Latency being the chief one.
>>
>> OpenSim is not going to be a peer to peer system, therefore your
>> suggestion is off topic. Opensim doesn't need another TLD, and it is
>> not what you are envisioning. OpenSim firmly embraces the concept of
>> SERVER SIDE simulation, therefore every sim will always have a
>> central server.
>>
>> I believe this has gone as far as it will go and if there is any
>> more name calling, well, we'll just have to moderate some people,
>> won't we?
>>
>> Melanie
>> (Core)
>>
>>
>>
>>
>
>
>
> ___
> 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] Script memory limit vs server CPU utilization as a key metric

[Dahlia Trimble]

Or at least the ability to disable them if the object is no-mod.

On Thu, Mar 11, 2010 at 5:41 AM, Lear Cale  wrote:

> On Thu, Mar 11, 2010 at 7:18 AM, Carlo Wood  wrote:
> > On Wed, Mar 10, 2010 at 03:51:31AM -0800, Ann Otoole wrote:
> >> If you guys want to really help then give us the ability to disable
> scripts by
> >> attachment creator name. There are certain products that cause problems.
> Made
> >> by people LL props up as shining examples of how creators should be BTW
> lmao.
>
> This would be a really bad idea, because there are plenty of full-perm
> freebies from reputable, sensible content creators that anyone could
> easily turn into a resource hogs, sullying those creators' names.
> This would be an easy way to torpedo a competitor.  I vote a
> resounding "no".
>
> Instead, we need the ability to delete scripts from objects even if
> they're no-mod, as we used to have.
> ___
> 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] oh give me a break

[Dahlia Trimble]

troll :P

On Wed, Mar 17, 2010 at 12:51 PM, John Hurliman wrote:

> 100th post
>
>
> On Wed, Mar 17, 2010 at 3:21 AM, Gareth Nelson wrote:
>
>> Not under the DMCA - perhaps outside of the US it might be
>>
>> On Tue, Mar 16, 2010 at 10:43 PM, Tigro Spottystripes
>>  wrote:
>> > -BEGIN PGP SIGNED MESSAGE-
>> > Hash: SHA1
>> >
>> > isn't that actually fair use?
>> >
>> > On 16/3/2010 09:04, Gareth Nelson wrote:
>> >> The answer to that pic is to buy the movie and then rip it - still
>> >> technically copyright infringement, yet you're supporting the makers
>> >> without getting all the extra crap
>> >>
>> >> In other news, this thread has been massively derailed..
>> >>
>> >> On Tue, Mar 16, 2010 at 11:35 AM, Rob Nelson
>> >>  wrote:
>> >>> On Tue, 2010-03-16 at 09:48 +0100, Anders Arnholm wrote:
>> 
>>  There been a nice illustration floating arounf the internet, showing
>> the
>>  problems with DRM protections today, mostly on video media.
>> 
>>  http://www.techxav.com/wp-content/uploads/2010/02/piratelegal.jpg
>> >>>
>> >>> I love the subtle :trollface: in the background.  I don't know why
>> it's
>> >>> there, but it's still great.
>> >>>
>> >>> ___
>> >>> 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
>> >>>
>> >>
>> >>
>> >>
>> > -BEGIN PGP SIGNATURE-
>> > Version: GnuPG v2.0.12 (MingW32)
>> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>> >
>> > iEYEARECAAYFAkugCWkACgkQ8ZFfSrFHsmW4AACfTedwiStaEa37XemDFLMz7Bj3
>> > JTUAnAil0sr0rkYMpk5HDnVtTHDZGMN/
>> > =FbdH
>> > -END PGP SIGNATURE-
>> > ___
>> > 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
>> >
>>
>>
>>
>> --
>> “Lanie, I’m going to print more printers. Lots more printers. One for
>> everyone. That’s worth going to jail for. That’s worth anything.” -
>> Printcrime by Cory Doctrow
>>
>> Please avoid sending me Word or PowerPoint attachments.
>> See http://www.gnu.org/philosophy/no-word-attachments.html
>> ___
>> 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
>
___
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] Snowglobe 1.4 trunk build

[Dahlia Trimble]

Is this version supposed to have the viewer 2.0 user interface? I installed
the linux viewer from the link in the message and it had the old UI.

On Tue, Mar 16, 2010 at 10:46 AM, Philippe (Merov) Bossut <
me...@lindenlab.com> wrote:

> Hi,
>
> There were a couple of parabuild (build farm machinery) issues that tripped
> me for a while. Those have been fixed now and we were able to build
> Snowglobe 1.4 trunk for the 3 platforms. Remember that 1.4 is the "1.x"
> based trunk that we keep building as long as we don't have a perfectly
> stable and complete 2.0.
>
> The most significant fix in that build is :
>SNOW-551: Don't lowercase the loginuri command line argument
>
> Downloads:
>
> Windows:
> http://secondlife.com/developers/opensource/downloads/2010/trunk/3229/Snowglobe_1-4-0-3229_Setup.exe
> Darwin:
> http://secondlife.com/developers/opensource/downloads/2010/trunk/3229/Snowglobe_1_4_0_3229_SNOWGLOBETESTBUILD.dmg
> Linux:
> http://secondlife.com/developers/opensource/downloads/2010/trunk/3229/Snowglobe-i686-1.4.0.3229.tar.bz2
>
> Cheers,
> - Merov
>
> ___
> 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] Third party viewer policy: commencement date

[Dahlia Trimble]

I have developed a BSD licensed viewer that is not derived from LL source
code. It is designed and intended for use with OpenSimulator, however since
it uses Linden Lab protocols it is capable of connecting to the Secondlife
grid, although functionality is impaired. I have no intention of making it
compliant with the TPV as *I never intended it to be used with SL*. However,
upon reading the TPV, it looks as though a possible interpretation may be
that my SL membership status may be at risk if someone (outside of my
control) uses the viewer to connect to SL and subsequently causes some
misfortune to another party, and that LL may wish to pursue legal remedies
against me as the developer of this viewer. As the viewer has been published
under a BSD style license long before the TPV came into existence. and I
have no control over already distributed copies and derivatives, and I have
no intention of stopping distribution, could my SL account be at risk, and
should I assume LL may attempt legal remedies against me for any unintended
use of this viewer?


On Tue, Mar 23, 2010 at 5:34 AM, Boy Lane  wrote:

>  I've put my summary about TVP on my blog
> http://my.opera.com/boylane/blog/linden-labs-final-3rd-party-viewer-policy-tpv
>
>
>  Linden Lab's final 3rd Party Viewer Policy (TPV)
> TUESDAY, 23. MARCH 2010, 19:15:03
>
> A lot of things are changing, I've voiced my opinion several times, and I
> want to summarize here what I think about Linden Lab's 3rd Party Viewer
> Policy (TVP) that can be found here: Policy on Third-Party Viewers |
> Second Life 
>
> Under assumption of common sense LL produced guidelines that should
> regulate and control the way people can connect to their service, that is
> the SecondLife grid. Guidelines which would be correct under the aspect of
> common sense and I believe LL came from that perspective by initially
> creating that guidelines in form of the 3rd Party Viewer Policy.
>
> What went wrong? They gave it in the hands of JohnDoe Linden lawyers who
> obviously missed the subject completley and overstepped ridiculously. But
> let's get down to the roots.
>
> Basically there are 2 core things very wrong with it. Initially LL requires
> everyone to comply to the GPL licensing. Which is fine as that sets the
> context. The GPL clearly states a developer has no warranty or liability for
> the code whatsover, even if that means ones viewer starts a nuclear war
> against former Soviet Russia or China or both. That clause is included in
> every single file of sourcecode (not the part about the Russians or Chinese
> ). LL explicitely disclaims any liability themselves for the resulting world
> war but then puts exactly that liability back on the shoulders of anyone
> developing a viewer.
>
> Not only that, by complying to their TPV a developer would also accept
> universal responsibility for all and everything "viewer". To be exact, as a
> developer "You assume all risks, expenses, and defects of any Third-Party
> Viewers that you use, develop, or distribute." A viewer does not even need
> to be able or connect to SL for that.
>
> In this regard it does not matter if a JohnDoe Linden comments on a mailing
> list or if a legally not binding FAQ tells us that this would be only for
> usage by connecting to the SL grid. It is not. TPV in it's current form
> says "I'm responsible (read: guilty) for using, developing or distributing
> any 3rd party viewer".
>
> Already by simply developing I'm assuming full responsibility for
> everything. I could take the official LL sources and compile and distribute
> a sourcewise identical "official" viewer, without changing a single line of
> code; but with all the bugs and vulnerabilities *made by LL*. Guilty by TPV.
> It's really ridiculous.
>
> This is a clear violation of the in the first place by LL required GPL
> licensing. It puts further restrictions on developers GPL explicitly
> prohibits.
>
> Another point of concern, putting up the RL details (which is pointless as
> LL has them already and require them by ToS) is required for a listing in
> the viewer directory. The details of the two guinea pigs who registered
> (Kirsten's, Metabolt) were promptly published for a day before someone in LL
> pressed the emergency button. But that was not the first time that LL
> distributed private details.
>
> In summary, the policy is legal-technical flawed and not acceptable by any
> dev in their right mind. What it will achieve is the destruction of any
> *legal* 3rd party viewer; which probably is the (by some welcomed) goal of
> LL to close-source the viewer. It will not do anything to stop malicious
> clients to flourish, the Neils give a shit on policies or licenses.
>
> The consequence is that no 3rd party developer that uses LL's GPLed sources
> (including already registered KLee or famed Emerald) can produce a
> legitimate viewer that is either compliant to GPL and/or violates TPV (which
> says it must be 

Re: [opensource-dev] Requesting Linden Response: Please move TPVPTopics to a different mailing list

[Dahlia Trimble]

I also would be interested in seeing those freely offering their legal
advice on this list also describing their qualifications to do so and in
which jurisdictions they are licensed to practice law. If not, then please
add a "IANAL" or other suitable disclaimer, or mention to what level you
would be willing to be responsible for the misfortunes that may happen from
others who may take your advice.

On Thu, Apr 15, 2010 at 4:04 PM, Joel Foner  wrote:

> I wonder if anyone has an easy way to calculate the actual signal (os-dev
> posts) to noise (legal posts) ratio on this list over, let's say the last 30
> days. It's getting hard to recall when the last actual os-dev discussion
> happened. Maybe I'm just missing it.
>
> Back to my regularly scheduled programming, as it were.
>
> Joel
>
> ___
> 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] --loginuri command line option disabled in viewer2 final?

[Dahlia Trimble]

Works for me on "Second Life 2.0.0 (203055) Mar 30 2010 08:11:18 (Second
Life Developer)", but with a single dash. I also remember having trouble
with localhost and I had to specify 127.0.0.1 instead


On Sat, Apr 17, 2010 at 2:33 AM, Latif Khalifa wrote:

> Hello,
>
> I'm having problems specifying alternative login url with  --loginuri
> command line option. It work up to "final" viewer2 release, through
> all the betas, but it seem to be not working in the final release, and
> in the later snowglobe builds.
>
> Latif
> ___
> 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] SL on ARM platform

[Dahlia Trimble]

Naali has at one time been ported to N900 but I'm not sure if it's a serious
project or not. I'm also not sure if Naali is planned to support SL.
http://www.youtube.com/watch?v=IP7zty5Kg7g


On Mon, Jul 19, 2010 at 12:34 PM, Tigro Spottystripes <
tigrospottystri...@gmail.com> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Are you gonna make a Maemo/Meegoo SL client? That would be fucking
> awesome! :D
>
> (i'm getting myself a N900 in a couple of weeks, having a SL client to
> run on it would be the perfect icing for the cake)
>
> On 14/7/2010 09:35, DEEPAK JAIN wrote:
> >
> >
> >
> > On Fri, Jul 9, 2010 at 6:58 AM, DEEPAK JAIN  > > wrote:
> >
> > Hi,
> >
> > Is it possible to run second life on any ARM based platform OR
> > anybody tried to compile SL on ARM?
> >
> > If YES, what all diffficulties that came or is it that it is not at
> > all possible?
> >
> >
> > SL has been compiled on quite a few different processors and in most
> > cases while possible to compile, results were disappointing. That said
> > please don't let me put you off.
> >
> >
> > It means that it was tried on a ARM based device. Results disappointing
> > means that SL performance was really poor on ARM devices due to huge
> > library dependencies or what?
> >
> > Thanks,
> > Deepak Jain
> >
> >
> >
> >
> > IMHO the easiest route would be to use a Linux based distribution such
> > as Debian or Ubuntu (personal bias to those distros) and do a
> > --standalone build. This would use the system pre-compiled libraries for
> > all the dependencies. It will be necessary to build a couple of extra
> > dependencies yourself that are not present in default distributions. The
> > way I would tackle this is to install Debian for Arm then use my
> > apt.byteme.org.uk  source repository to pull
> > in all source dependencies and compile the extra packages directly from
> > there.
> >
> > Regards
> >
> > Robin
> >
> >
> >
> >
> >
> > Thanks & Regards,
> >
> > Deepak Jain
> >
> > Sr. Software Engineer - R&D
> >
> >
> >
> >
> >
> >
> > ___
> > 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
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.14 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEAREKAAYFAkxEqJoACgkQ8ZFfSrFHsmWeUACfe+Qa+xX7y0WeFuKA/RCpnChe
> TEUAoIPmUcUcj1mRptXyOA7ccA0K72Fc
> =J2uK
> -END PGP SIGNATURE-
> ___
> 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] display names = the end of 1.x viewers?

[Dahlia Trimble]

Great. Now I can look forward to "Dahlia9993482 Resident"
-dahlia
(case intentional)

On Tue, Aug 17, 2010 at 3:57 PM, Erik Anderson <
eri...@odysseus.anderson.name> wrote:

> I wouldn't say "forever", I suspect a few years down the line it would be
> transitioned to "Andromeda.Quonset Resident" and then permanently drop the
> last name...
>
>
> On Tue, Aug 17, 2010 at 3:54 PM, Brian McGroarty wrote:
>
>> This is correct. Andromeda Quonset will be Andromeda Quonset forever.
>> At some point, new residents won't be able to choose a last name -
>> only these will be "Resident"
>>
>> No existing script function will return different results than it does
>> today. New script functions are added for fetching/referencing Display
>> Names.
>>
>
>
> ___
> 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] Open Viewer Development Announcement

[Dahlia Trimble]

One thing I liked about the pie menu is the area where the mouse click needs
to take place increases in width as you move away from the center, making it
easy to make the desired pick. I often find when navigating nested
rectangular menus that it's difficult to keep the mouse hovered in the
desired area and it tends to open the wrong one unless the cursor is very
precisely placed. This is especially troublesome when navigating
thru several menu levels.


On Wed, Aug 18, 2010 at 12:33 PM, Kadah  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> On 8/18/2010 12:04 PM, Oz Linden (Scott Lawrence) wrote:
> > If I understood him correctly, what Q seemed to think was the right
> > behavior is:
> >
> > * The first mouse-down opens the pie centered on the mouse location,
> >   so no choice is under the mouse
> > * If the choice is a submenu, each new menu is also centered on the
> >   mouse
> >
> > that way, you are never making a choice within the submenu if you
> > accidentally double click, because the center is never a choice.  this
> > does mean that the nested menus 'creep', but that has the effect that
> > each nested choice is a 'gesture-like' unique series of clicks.
>
> I think he thinks that the proper behavior should have been that the
> cursor recenters on the new sub pie menu.
>
> I liked how for something like inspect was down, click, right, and
> delete was down, up-right. As long as the item in the submenu in that
> spot was either blank or nonharmfull, which it mostly was, I'd have
> nearly no problems. Unlike with the context menus used now, I'm always
> hunting for the option and frequently hit the wrong one.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJMbDWkAAoJEIdLfPRu7qE2hRMH/RNLyOFVogQGaMfBnax20dbp
> D+vQ2b6ANu48R4vCZtPDidvlWXde6cGBYpZrCrzzUKK+HeF4+KrW9IcDH+hnOPq7
> YGUz2Q1CuYjuVWz9gVxioFe8zTQHKD92F+Mm3mkB+2PaFjxclejGf8nE54dft8Yc
> 6jEQTJ/bZB17KMIjMMWf+9fjPej6eF0zFjN0+6UpFXvMDiQHpllfY2KlJodd677P
> NhDTVPIOZELC3pJ4ssMGfJUK3CdyYXyEhJiRTV99qs1gn3VKT/Tbc/QuLM4NdcFk
> kchWh03rYVXG41rPEGJjjunayK6Qn2BpAwPbHbZTY7MWJ4P6Te1M1ZccwpfdvSo=
> =C9qT
> -END PGP SIGNATURE-
>  ___
> 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] This is how Linden Lab treats it's customers...

[Dahlia Trimble]

After reading this thread, somehow all my past bad memories from being a
mainland resident no longer seem quite so bad.

On Sat, Aug 28, 2010 at 11:21 AM, Carlo Wood  wrote:

> Sorry, but you are ignorant.
>
> A running sim is being paid for. That money is paid to Linden Lab.
> It doesn't matter if that money was first paid by a grandmother to
> her grandson, then double by gambling in the casino and subsequently
> paid to some random stranger on Xstreet who give L$ for it, which
> then were paid to some untrusty game-landlord who gave the game
> money to yet another random stranger on Xstreet for which he recceived
> real dollars which then finally are paid to Linden Lab.
>
> Namely, if the guy actually using the sim doesn't want to pay for
> it, the sim can't run. The fact that it runs means someone pays
> for it and you can bet on it that that comes from the wallet of the
> person using it (living on it).
>
> So, in this case the sim was running a year aka $100 per month.
> Now the sim isn't running anymore and this income of LL stopped.
>
> The renter then offers to continue renting it for $100 per month,
> by paying *directly* to LL, but that is not accepted.
>
> It is this last thing that is ridiculous. Or at the VERY LEAST it
> should be (or have been) possible to rent an isolated/private homestead
> directly from Linden Lab.
>
> Don't say that 'L$' isn't real money so one has no rights. This is
> not about what a RL lawyer would say, this is about common sense
> and people being pissed off till they vomit and want to run away
> screaming from SL, or at least from Linden Lab.
>
> On Sat, Aug 28, 2010 at 11:51:03AM -0400, Joel Foner wrote:
> > Quick note... if the $100 a month, if this is rent, is not being paid to
> Linden
> > Lab if you're renting. It's paid to another avatar... different
> picture... It
> > seems to me the slap in the face is a landlord who does this to a large
> number
> > of tenants without notice, actually.
> >
> > Joel (also going back to lurking)
> >
> > On Sat, Aug 28, 2010 at 11:42 AM, Darmath  wrote:
> >
> >  On 29/08/2010 1:23 AM, Gareth Nelson wrote:
> > >   and pointing out that LL have no contract with tenants of
> > > rental regions - tenants of such regions are thus not customers.
> > True. But a premium account holder is a customer of LL. "And to say
> well
> > we dont want you $100 a month because your not a full sim owner" is a
> > slap in the face, period. FWIW i'm a premium account holder...whose
> now
> > returning to lurking.
> > ___
> > 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
>
>
> --
> Carlo Wood 
> ___
> 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] J2C fast decoder

[Dahlia Trimble]

Jpeg 2000 discard levels are also used for reducing the resolution of
textures for distant objects which reduces data download requirements. Few
other formats offer comparable compression ratios with the quality that Jpeg
2000 offers. HTTP transfer doesn't magically make data traverse the network
faster; much of the reduced download time is due to offloading the sim from
the task of sending textures as they can come from another server process
(or even another physical server).


On Sun, Sep 12, 2010 at 10:40 PM, Tateru Nino  wrote:

>  If we're using HTTP textures, is there actually any need for the JPEG 2000
> format? Since the transfer time of individual textures is vastly reduced
> (from the first byte to the last byte) the intermediate quality levels
> supported by jpg2k would seem to be redundant. Indeed, you could argue that
> transferring the textures in jpg2k format imposes a now-redundant workload
> on the texture-pipeline, and that providing HTTP textures in a simpler
> format that is more tractable to high-speed, low-cost decoding would save a
> whole lot of problems.
>
> Would it be a huge problem, for example, to transfer HTTP textures as TGA
> or PNG and use one of the rather well-optimized decoder libraries for those
> instead? It seems to me that it would be more efficient both on the network
> and on the system - though at the expense of conversion of all the textures
> at the store.
>
> Just thinking out loud.
>
>
> On 13/09/2010 1:58 PM, Sheet Spotter wrote:
>
>  Some comments on SNOW-361 (Upgrade to OpenJPEG v2) suggested that
> changing to version 2 of OpenJPEG might improve performance, while other
> comments suggested it might not support progressive decoding.
>
> http://jira.secondlife.com/browse/SNOW-361
>
>
>
> Is an upgrade to OpenJPEG v2 under active development?
>
>
>
>
>
> Sheet Spotter
>
>
>  --
>
> *From:* opensource-dev-boun...@lists.secondlife.com [
> mailto:opensource-dev-boun...@lists.secondlife.com]
> *On Behalf Of *Philippe (Merov) Bossut
> *Sent:* September 9, 2010 10:35 PM
> *To:* Nicky Fullton
> *Cc:* opensource-dev@lists.secondlife.com
> *Subject:* Re: [opensource-dev] J2C fast decoder
>
>
>
> Hi Nicky,
>
> As it happens, I've been working on instrumenting the code to add metric
> gathering for image decompression as part of the Snowstorm sprint.
>
> You may want to use my branch (
> https://bitbucket.org/merov_linden/viewer-development-vwr-22761) and
> create a baseline for openjpeg then run a test for Jasper. You'll have to
> sort out the failing cases certainly and just throw them so we compare what
> gets truly decompressed (though, clearly, working in all cases is pretty
> critical if we look at Jasper as an alternative).
>
> Here's what I got comparing KDU and OpenJpeg:
> Label Metric  KDU(B) OJ2C(T)
>  Diff(T-B) Percentage(100*T/B)
> ImageCompressionTester-1
>  TotalBytesInDecompression50486435003370-4527399.1
>  TotalBytesOutDecompression 40415336  465928966177560115.29
>  TimeTimeDecompression3.74   17.04  13.3
> 455.39
> ImageCompressionTester-2
>  TotalBytesInDecompression50007445000144 -600
> 99.99
>  TotalBytesOutDecompression 46440040  44248324   -219171695.28
>  TimeTimeDecompression3.64   15.02   11.37
>  412.02
>
> For that test, I output data every time 5MB of compressed data have been
> processed. It's partial but shows that OpenJpeg is roughly 4 times slower
> than KDU (at least, the version we're using in the official viewer
> currently). Would be nice to have a similar set of numbers for Jasper before
> going too far down the implementation path.
>
> I wrote a short (and still incompleted) wiki to explain a bit how the
> metric gathering system works:
> - https://wiki.secondlife.com/wiki/Performance_Testers
>
> BTW, that's something we should be using more generally for other perf
> sensitive areas, especially when starting a perf improvement project.
>
> See http://jira.secondlife.com/browse/VWR-22761 for details.
>
> Cheers,
> - Merov
>
> On Fri, Sep 3, 2010 at 9:05 AM, Nicky Fullton  wrote:
>
> Hello,
>
> >> i'm testing in RL office (not or a viewer) JasPer decoder for JPG2000
> >> images, after a short test with openjpeg2000 from EPFL we have tested
> >> last 3 days JasPer (only a POC apps to do some bench), we must do a lot
> >> of work too, but this is a lil question... anybody here around never
> >> tried it as alternative to OpenJPEG/KDU in a viewer?
>
> >I'm not aware of anyone publishing results for such a test, but if you
> >have the time it would be interesting reading.
>
> You might be interested in:
> http://bitbucket.org/NickyD/viewer-development/changeset/027bf44c5582
>
> I made a rather quick hack to try Jasper instead of OpenJpeg to decode
> images.
>
> The patch has some very rough edges. In fact is the decoding into th

Re: [opensource-dev] J2C fast decoder

[Dahlia Trimble]

Requesting a discard level means you only get a portion of the entire file,
and if you wanted the highest resolution you would download the entire file
which would include all discard levels. The advantage of being able to
request only what you need can save a lot of network traffic. You don't
really want to download a 1024x1024 texture for a distant object that only
covers a few pixels on the screen.



On Mon, Sep 13, 2010 at 12:24 AM, Tateru Nino  wrote:

>  Wouldn't we be making a network saving by omitting the discard levels
> entirely? Granted, I don't have hard data about that - would the base
> texture encoded in a lighter-weight format end up causing less data to
> traverse for a given texture in the long-run than the more-efficiently
> compressed j2c of the same texture including discard levels? My gut instinct
> says 'probably', but I can't prove that with data.
>
> If it *does* then we would have a double-bonus of also saving on decoding
> time.
>
>
> On 13/09/2010 4:38 PM, Dahlia Trimble wrote:
>
> Jpeg 2000 discard levels are also used for reducing the resolution of
> textures for distant objects which reduces data download requirements. Few
> other formats offer comparable compression ratios with the quality that Jpeg
> 2000 offers. HTTP transfer doesn't magically make data traverse the network
> faster; much of the reduced download time is due to offloading the sim from
> the task of sending textures as they can come from another server process
> (or even another physical server).
>
>
> On Sun, Sep 12, 2010 at 10:40 PM, Tateru Nino wrote:
>
>>  If we're using HTTP textures, is there actually any need for the JPEG
>> 2000 format? Since the transfer time of individual textures is vastly
>> reduced (from the first byte to the last byte) the intermediate quality
>> levels supported by jpg2k would seem to be redundant. Indeed, you could
>> argue that transferring the textures in jpg2k format imposes a now-redundant
>> workload on the texture-pipeline, and that providing HTTP textures in a
>> simpler format that is more tractable to high-speed, low-cost decoding would
>> save a whole lot of problems.
>>
>> Would it be a huge problem, for example, to transfer HTTP textures as TGA
>> or PNG and use one of the rather well-optimized decoder libraries for those
>> instead? It seems to me that it would be more efficient both on the network
>> and on the system - though at the expense of conversion of all the textures
>> at the store.
>>
>> Just thinking out loud.
>>
>>
>> On 13/09/2010 1:58 PM, Sheet Spotter wrote:
>>
>>  Some comments on SNOW-361 (Upgrade to OpenJPEG v2) suggested that
>> changing to version 2 of OpenJPEG might improve performance, while other
>> comments suggested it might not support progressive decoding.
>>
>> http://jira.secondlife.com/browse/SNOW-361
>>
>>
>>
>> Is an upgrade to OpenJPEG v2 under active development?
>>
>>
>>
>>
>>
>> Sheet Spotter
>>
>>
>>  --
>>
>> *From:* opensource-dev-boun...@lists.secondlife.com [
>> mailto:opensource-dev-boun...@lists.secondlife.com]
>> *On Behalf Of *Philippe (Merov) Bossut
>> *Sent:* September 9, 2010 10:35 PM
>> *To:* Nicky Fullton
>> *Cc:* opensource-dev@lists.secondlife.com
>> *Subject:* Re: [opensource-dev] J2C fast decoder
>>
>>
>>
>> Hi Nicky,
>>
>> As it happens, I've been working on instrumenting the code to add metric
>> gathering for image decompression as part of the Snowstorm sprint.
>>
>> You may want to use my branch (
>> https://bitbucket.org/merov_linden/viewer-development-vwr-22761) and
>> create a baseline for openjpeg then run a test for Jasper. You'll have to
>> sort out the failing cases certainly and just throw them so we compare what
>> gets truly decompressed (though, clearly, working in all cases is pretty
>> critical if we look at Jasper as an alternative).
>>
>> Here's what I got comparing KDU and OpenJpeg:
>> Label Metric  KDU(B) OJ2C(T)
>>  Diff(T-B) Percentage(100*T/B)
>> ImageCompressionTester-1
>>  TotalBytesInDecompression50486435003370-4527399.1
>>  TotalBytesOutDecompression 40415336  465928966177560115.29
>>  TimeTimeDecompression3.74   17.04  13.3
>> 455.39
>> ImageCompressionTester-2
>>  TotalBytesInDecompression50007445000144 -600
>> 99.99
>>  TotalBytesOutDecompression 4

Re: [opensource-dev] Broken Rubber Bands

[Dahlia Trimble]

Could checking to see if a user is still pressing a movement key fit into
the algorithm? It seems it could be a useful input to help determine if the
user really wants to continue along a dead-reckoning path.

On Tue, Oct 12, 2010 at 2:51 PM, Dale Innis wrote:

> On Tue, Oct 12, 2010 at 5:38 PM, Simon Linden  wrote:
>
> > Some of my changes should help, however.  The viewer will check the edge
> of
> > the region, and if there is no neighbor region, stops the object motion.
>
> >  Predicted object motion is also pinned to the
> > allowable underground distance and top of the region.
>
> These will be major, and very welcome, changes to the SL experience!
>
> (Not to mention giving us oldbies one more class of "In my day..."
> stories to tell...)
> ___
> 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] Web login

[Dahlia Trimble]

I think the web login code has been bitrotting for probably a couple
years now, if you're referring to the same code I'm thinking of.
Anyway probably better to ask this question in the opensim-dev mailing
list.


On 11/20/10, Olli Aro  wrote:
> Hi all,
>
>
>
> Anyone using the web login with the latest version of OpenSim?
>
>
>
> We are in process of porting our OpenSim management system to the latest
> version and seem to have problems with the web login functionality that
> worked fine previously.
>
>
>
> Any chance that could have got broken when the database was restructured?
>
>
>
> Regards,
>
>
>
> Olli
>
>
>
>
>
>
___
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