Re: [opensource-dev] What is with the cycling port connections on SLv2.4?

[Zabb65]

This is one of the most confusing posts I've seen in ages. Would you
like to provide some technical detail of what you see happening, and
what you EXPECT to happen?

On Thu, Dec 23, 2010 at 00:47, Ann Otoole  wrote:
> connect disconnect connect 4 times at once disconnect 4 bang bang hammer
> hammer
>
> Dear Oz and Esbee: Run a port monitor and look at what your client is doing.
>
> Please. No don't just do it from the office LAN. Hire someone to travel
> around to different areas of the country to monitor what your client really
> does. Seriously. Crashiest client ever.
>
>
> ___
> 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] Debugging Snowstorm under Linux x64 with GDB locks the whole X session

[Zabb65]

Reading through the documentation on this. It may be easier to just
add "GDK_DEBUG=nograbs" to the shell script launcher when it uses GDB,
and have it work on all distros, up to date or not?

On Wed, Dec 29, 2010 at 15:30, Monty Brandenberg  wrote:
> On 12/29/2010 1:19 PM, Aleric Inglewood wrote:
>
>> yes, this is a "known" problem: the viewer sometimes locks the X display,
>> if then you halt it in the debugger you're toast.
>
> I only have creaky old Debians at hand but wondered if those with
> more modern distros with updated GTKs can work around it by
> changing the 'gtk_debug_flags'.  There's now a GTK_DEBUG_NOGRABS
> flag (1 << 12, I think).  Set that and play a bit.  No guarantees,
> you'll need very recent libs and I don't know at what point in
> execution you'll need to set that flag.  (The --gtk-debug and
> --gdk-debug cmd options also drive this.)  But there it is...
>
> --
> Monty Brandenberg                                         617.401.2384
> mo...@lindenlab.com
> ___
> 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] Does writing to llerrs make the viewer crash ?

[Zabb65]

Yes, llerrs purposefully dereferences a null pointer to cause a crash,
and if that fails it infinitely loops. This is so "errors" get fixed
instead of being ignored.

On Fri, Dec 31, 2010 at 05:42, Marine Kelley  wrote:
> Hello all,
>
> I have just filed a JIRA (VWR-23459) about a random crash that would
> occur in the rendering pipeline, when suddenly it struck me : I
> remember that years ago the viewer would crash when writing to llerrs,
> and that it was voluntary (don't ask me why).
>
> Is it still the case ? In this JIRA, the fix I provide merely removes
> the write to llerrs, and returns without going any further into the
> method. I did not have time to give it more attention, it was more of
> a dirty hack to be able to keep from crashing every 15 minutes while
> my friends were waiting for me.
>
> Thanks and happy new year to all of you !
> Marine
> ___
> 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] s3-proxy.lindenlab.com points to a private IP address?

[Zabb65]

Linden Lab should not be distributing either of these libraries, as
they do not have a license that permits them to do so(from what I have
heard from them in other dialogs). So this violates and possibly voids
their license for Kakadu, as well as all of their careful planning to
keep it out of every developers hands except for their own.

I hope that they will take these down, and it is not an error that you
should NOT be able to download them. The error here is that they are
trying to be downloaded at all.

On Wed, Apr 6, 2011 at 23:34, Glimmering Sands
 wrote:
> Well, I have discovered, through the wonders of Mr. Google, that there
> is an older copy autobuild.xml out there at:
>
> https://bitbucket.org/merov_linden/viewer-autobuild2010/src/44f214103cff/autobuild.xml
>
> and I was able to simply use the
>
> http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/...
>
> lines for both fmod and kdu (would it be considered a bug that Linden
> Labs is distributing an autobuild.xml that uses internal only paths
> rather than using the external paths (that I guessed the used to
> have?)
>
> One can also wonder why you would let internal DNS records be allowed
> to external sites as well...
>
> Sometime later I will discover if this solves my grey goo box problem or not 
> :-)
>
> Hugs,
>
> Glimmering
>
> On Tue, Apr 5, 2011 at 8:14 PM, Glimmering Sands
>  wrote:
>> Sorry to bother you kind folks again.  I am attempting to follow the
>> suggestion of building from scratch from a new account.  Given that
>> the instructions for how to install fmod are now missing from the wiki
>> I decided I should just follow the autobuild instructions.  Maybe they
>> will work better?  But alas, fate would have it that this has a
>> failure for me as well:
>>
>>
>> downloading fmod archive from
>> http://s3-proxy.lindenlab.com/private-builds-secondlife-com/hg/repo/3p-fmod-private/rev/221852/arch/Darwin/installer/fmod-3.75-darwin-20110222.tar.bz2
>> unable to download file: 
>>
>> So why does this download timeout?
>>
>> $ nslookup s3-proxy.lindenlab.com
>> Non-authoritative answer:
>> s3-proxy.lindenlab.com  canonical name = int.excod.lindenlab.com.
>> Name:   int.excod.lindenlab.com
>> Address: 10.6.3.104
>>
>> No, even in the fantastical world I might live in, I am quite certain
>> I am not able to reach linden lab's private servers, nor do I think
>> setting up my own 10.6/16 network would be of any assistance.  Perhaps
>> this is an error by the DNS administrators at Linden Labs?
>>
>> Kind Regards,
>>
>> Glimmering
>>
> ___
> 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: STORM-58 Allow objects to have 99.99% max hollow for default hollow shape.

[Zabb65]

The clamp for primitive parameters was in place long before the
megaprim "debacle", unless you are referring to the one in early 2006,
possibly even earlier than that.

>From what I know, doing this will require that the server be updated
to relax this restriction.
___
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] Mesh viewers and tcmalloc issues

[Zabb65]

It is not desirable to let the default allocation engine run under
Linux, and possibly Mac. glibc has an incredibly slow allocator for
small objects, and tcmalloc was implemented to remedy these
situations(This is what I heard, but have not confirmed.) Inventory
and a few other items create massive numbers of very small heap
objects. Setting a much lower value(1000) that only returns memory
occasionally is much more desirable on this platform. You can do this
without recompiling tcmalloc as well by passing an environment
variable, which is the desired method. Please note that it is listed
as a caveat on the tcmalloc page that it very clearly does not return
memory to the system(I assume this is outdated, or reflects the
default value)

Windows doesn't really have a need for tcmalloc from what I can see.
If LL compiles using visual studio 2010, the C runtime uses the low
fragmentation heap allocator. The low fragmentation allocator is fast
enough to satisfy even large numbers of small objects, and keep heap
fragmentation to very small percentages. Working "against" the heap
manager on windows by rolling your own is generally not advised unless
there are extraordinary needs or requirements, and even then, it is
far easier to cause more problems then you fix.

Is tcmalloc really providing aligned allocations? I only found
documentation that it would enforced specific amounts of space between
items, not that they were guaranteed to be aligned to an X byte
boundary. (Maybe this is what the spacing guarantees, but I am
unsure.)

On Sun, Oct 2, 2011 at 00:23, Mike Chase
 wrote:
> On 10/01/2011 04:24 PM, Henri Beauchamp wrote:
>> Greetings,
>>
>> I noticed that all the viewers using tcmalloc (mesh viewers under Linux
>> and Windows, since those use SSE2 and must gain memory-aligned malloc()
>> and new() calls that their standard library does not provide) suffer
>> from a serious problem: they never release memory back to the system,
>> meaning that after visiting a crowded place and caming around a lot,
>> the viewer can occupy 2.5Gb of memory, and even after you TP out to a
>> skybox with almost no objects/textures and no avatar around, the viewer
>> retains the full amount of alloctaed memory for itself.
>>
>> Worst, should you manage to keep the viewer from crashing during a full
>> hour or so, its allocated memory will get so badly fragmented that it
>> starts crawling down and finally crashes, even in quiet sims.
>>
>> Bao Linden recently worked on private memory pools to work around these
>> issues, but so far and despite his hard work, the result is less than 
>> satisfactory: the memory is still never released to the system, and the
>> viewers using private memory pools crash every few minutes after issuing
>> a warning:
>> "LLPluginProcessParent::poll: apr_pollset_poll failed with status 4
>>
>> Well, be happy since I found an easy work around for these problems
>> while working on the Cool VL Viewer v1.26.1 (the mesh branch).
>>
>> tcmalloc is actually supposed to release back to the system the memory
>> freed by the application using it, but it does so only after a certain
>> number of memory blocks have been freed. There is an environment
>> variable that you can set (TCMALLOC_RELEASE_RATE) to adjust the "rate"
>> at which tcmalloc will release the freed blocks back to the system.
>> In fact, this is not really a rate, but a divisor (the number of freed
>> blocks is divided by the rate number (when != 0: a 0 rate means "never
>> release memory"), and compared to a threshold. If the number is below
>> the threshold, the freed blocks are released.
>> The documentation for tcmalloc says that "Reasonable rates are in the
>> range [0,10]", but even with a rate of 10, you never get the viewer to
>> release more than a couple hundreds megabytes for 2+Gb of allocated
>> memory. It occurred to me that the algorithm tcmalloc uses is simply
>> crippled !
>>
>> The good news, is that if you pass an "unreasonnable" rate, tcmalloc
>> will finally release memory (the more "unreasonnable" and the more
>> memory is released). With a rate of 1 (yes, ten thousands), you
>> get the viewer to release everything when it doesn't need it any more,
>> which matches the behaviour of tcmalloc-less viewers.
>>
>> Since the Windows builds don't use a wrapper script to launch the
>> viewer, it is however best to hardcode this new rate as the default
>> one in tcmalloc istelf. This is what I did for the Cool VL Viewer
>> and it works like a charm. There is only one line to change in
>> tcmalloc source, in src/page_heap.cc:
>> DEFINE_double(tcmalloc_release_rate,
>>      EnvToDouble("TCMALLOC_RELEASE_RATE", 1.0),<--- HERE
>>      "Rate at which we release unused memory to the system.  "
>>      "Zero means we never release memory back to the system.  "
>>      "Increase this flag to return memory faster; decrease it "
>>      "to return memory slower.  Reasonable rates are in the "
>>      "range [0,10]");
>>
>> Now, the view

Re: [opensource-dev] Possible glitch in TPV identification procedure

[Zabb65]

Channel name is a persistent saved setting. Meaning if you log in under a
viewer that sets its channel in the saved settings file, but does not use
one of its own(settings file), the normal viewer will continue to identify
itself as that viewer. Until you remove the entry yourself, by either
clearing your settings files, or by hand, this will always happen.

I've notified LL about this problem once or twice before, but nothing
appears to have been done about it. Marking the channel entry as non
persistent would be enough to mitigate the problem caused here, in the
app_settings/settings.xml file.

The reason this does not occur for the normal viewer, and spread to TPV
clients is because only settings that have been changed from their defaults
are written into the users settings.

On Wed, May 5, 2010 at 18:01, Jay Reynolds Freeman <
jay_reynolds_free...@mac.com> wrote:

> Now this is weird:
>
> I have a TPV that I have developed for my own occasional use --
> not for distribution.  I have identified it according to the
> procedures outlined in
>
>  http://wiki.secondlife.com/wiki/Channel_and_Version_Requirements
>
> and they seem to work.  So far, well and good.
>
> I also have an executable binary of a standard LL viewer -- 1.23.5
> -- that I use most of the time.  This is a straight download of
> the executable, direct from LL, unmodified by me in any way, and
> so verified by inspecting the dates on the actual executable.
>
> Yet when I run my unmodified 1.23.5 and use the menu item
> "Help->About Second Life ..." , what is displayed is the version
> string that I have created for my modified TPV.
>
> Taken at face value, this observation suggests that my unmodified
> 1.23.5 binary is somehow identifying itself as my personal TPV when
> I launch it, and that sounds like a glitch somewhere -- I just don't
> know where.
>
> Further information:
>
>I am running on a Macintosh, under MacOS 10.6.3 ...
>
>I run the two viewers -- 1.23.5 and my personal one -- using
>  the same Macintosh account (Unix account) and also using
>  the same SL accounts (avatar names).
>
>When I create a different Macintosh/Unix account, and run
>  the 1.23.5 binary while logged in as that different account
>  (but using one of my usual SL accounts), the misidentification
>  does NOT occur; that is, it looks like the incorrect
>  identification of 1.23.5 only happens in the Unix account
>  in which I have also used my personal TPV.
>
> I reiterate, all the mods to identify my personal TPV were made in
> the source directory I use to build it, and the version of 1.23.5
> that I am running was compiled by Linden Laboratories -- all I did
> was download it.
>
> My guess is that there is something like a cookie, somewhere
> associated with my everyday Macintosh/Unix account, that is
> not getting cleared when it ought to be.  Does anyone have any idea
> what is going on, or what I ought to do to fix the problem
> systematically?  Remembering to clear cookies every time I log in,
> or something like that, does not sound like a very robust fix.
>
> Unanticipated regular misidentification of viewers could cause
> great confusion.
>
> I will be happy to file a bug report about this, but it might help
> if I knew what was going on ...
>
> --  Jay Reynolds Freeman / CeeJay Tigerpaw
> -
> jay_reynolds_free...@mac.com
> http://web.mac.com/jay_reynolds_freeman (personal web site)
>
>
> ___
> 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] Mesh rendering: What does indicesp provide?

[Zabb65]

>From what I remember...

Indicesp is a pointer to an array of U16s that are offsets to vertexes in
the vertex buffer. Read it as the vertexes normals and all this other stuff
being in static arrays. It then runs through the indice list and runs the
associated glVertex3f commands or whatever on the vertex at the specified
index on the array. This is done for all data types.

vector verts;
vector colors;
vector normals;
U16 indices[3] = {0, 1, 2, 1};

for(U16 i = 0; i < 3; ++i)
{
U16 x = indices[i];

glColor4f(colors[x].mV[0],colors[x].mV[1],colors[x].mV[2],colors[x].mV[3]);
glNormal3f(normals[x].mV[0],normals[x].mV[1],normals[x].mV[2]);
glVertex3f(verts[x].mV[0],verts[x].mV[1],verts[x].mV[2]);
}

Is the most simple example I can think of that would demonstrate how it
works internally.

In the code example you have, the vertexes are drawn one by one in immediate
mode, which is both slow, and undesired. You will have to do some research
into using proper vertex buffers to properly convert the code.

On Wed, Jun 2, 2010 at 19:35, Rob Nelson wrote:

> I am almost to the point of going crazy.  I was going to write a
> notecard to a Linden, but I've been knocked out of SL for reasons
> unknown, so I'll have to ask here.
>
> In my infinite lack of wisdom, I decided to start working on a project
> where I replace the heightmap terrain in Second Life with one based on
> voxels.  To get to the core of the reasoning behind this switch so I
> don't spend too much time on it:
>
>  * Voxel-based land allows creation of overhangs/caves/floating chunks
> of land (not possible with heightmaps)
>  * Also adds the ability to handle up to 255 terrain materials
> (textures, eventually detail shaders) instead of 4, and the materials
> are placed where desired instead of at fractional heights.
>
> I am working on the rendering code in the SL viewer at the moment,
> having completed the server-side code and some of the client-side
> packet-handling classes.  However, I have zero familiarity with OpenGL,
> so bear with me.
>
> My viewer needs to construct a terrain surface (a mesh) for display.  I
> have completed an LLViewerObject to this end, except for:
>
> ::getGeometry(LLStrider &verticesp,
>LLStrider &normalsp,
>LLStrider &colorsp,
>LLStrider &texCoords0p,
>LLStrider &texCoords1p,
>LLStrider &indicesp)
>
> What is confusing me is indicesp.  I think it has something to do with
> connecting vertices, but I'm not sure how.  The example code I am
> working with uses a mess of lookup tables in the following loop for each
> voxel:
>
>//Draw the triangles that were found.  There can be up to five per
> cube
>for(iTriangle = 0; iTriangle < 5; iTriangle++)
>{
>if(a2iTriangleConnectionTable[iFlagIndex][3*iTriangle] < 0)
> break;
>
>for(iCorner = 0; iCorner < 3; iCorner++)
>{
>iVertex =
> a2iTriangleConnectionTable[iFlagIndex][3*iTriangle+iCorner];
>
>vGetColor(sColor, asEdgeVertex[iVertex],
> asEdgeNorm[iVertex]);
>glColor4f(sColor.fX, sColor.fY, sColor.fZ, 0.6);
>glNormal3f(asEdgeNorm[iVertex].fX,
> asEdgeNorm[iVertex].fY,   asEdgeNorm[iVertex].fZ);
>glVertex3f(asEdgeVertex[iVertex].fX,
> asEdgeVertex[iVertex].fY, asEdgeVertex[iVertex].fZ);
>}
>}
>
> Can anyone give me any pointers on getting this converted?
>
> Thanks.
>
> Rob
>
> ___
> 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] Mesh rendering: What does indicesp provide?

[Zabb65]

As for conversion, it looks like you should just convert asEdgeVertex
asEdgeNorm and the results of vGetColor(for each normal in asEdgeNerm) into
arrays, and build the index table from the results of iVertex. It more or
less looks like it was written to use vertex buffers, but was converted to
something else.

That being said, you will need to convert the colors from floats into bytes
to use the LL implementation of vertex buffers, and either tell it you don't
have textures, or provide texture coordinates as well.
___
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] LLUUID::getNodeID() returns (random) software MAC

[Zabb65]

Just to add my 2c on this issue.

I was getting this once in a while as well, when I finally tracked it
down, to the above reason(although it was an older version.) it was
actually pulling a random interface each time my computer rebooted as
being the one chosen.
In the list of random devices, there were 4 that had
random(potentially) mac addresses each time, cisco vpn adapter,
ieee1394(firewire) connector, hamachi adapter, and a loopback
adaptor(I use it for testing things, but it was disabled at the time
it was picked)

I'm aware that there are probably hundreds of potential software
interfaces that all return psuedo random addresses each time, or some
that always return invalid addresses(seem to remember one that
returned 00:00:00:00:00:00 every time), to make matters worse, you can
arbitrarily rename adapters under all versions of windows.

There should likely be a bit of investigation done into determining
the outgoing interface used for a given address(I suspect there is a
way to determine such), and using that interfaces hardware address.

Under mac and *nix variants, once can query the kernel routing table
to determine the outgoing interface for a specific address, so it
should be significantly easier under those two.

As for why the function doesn't already do this, I'd guess it was
simplicity, or the assumption that the operating system would return
the physical/activated/highest priority interface first in the list,
although this doesn't appear to be ALWAYS true under any of the
operating systems supported.

On Fri, Jun 18, 2010 at 08:19, Kitty  wrote:
> I tried to log on this morning and got a "Second Life can not be accessed
> from this computer"... naughty me! :o.
>
> Looking into it only that particular puter was "banned" and even then it was
> restricted to only 2.1 (my own build and the official one).
>
> Delving deeper the problem seems to be that LLUUID::getNodeID() is using
> GetIfTable() table to enumerate over the available interfaces and just
> returns the MAC of the first ethernet one it comes across... which happens
> to be the MAC of the WAN miniport *software* interface which has a different
> MAC generated every time the puter is rebooted.
>
> Just my luck that a randomly generated MAC happens to be a blacklisted one
> :p.
>
> Is there any reason why GetAdaptersInfo() isn't used to get the MAC of the
> *physical* network interface(s)? *confuzzled*
>
> Aside from the issue I ran into where a random MAC turned out to be banned,
> the (official) viewer shouldn't be effectively spoofing the MAC address by
> just sending something "random" either?
>
> Additionally fixing that bug probably means that LLMachineID::init() can be
> reverted to using the MAC address again since it has a comment about the MAC
> address seemingly changing across reboots and has work-around code there to
> use the BIOS serial instead?
>
> Kitty
>
> ___
> 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] viewer-external svn r3448: multi-wearables seriously broken?

[Zabb65]

Needs a 1.40 sim to function as expected. When such rolls out, it will
behave as you want. Until then, it thinks you are placing them on
attachments points it doesn't know about.

On Mon, Jun 28, 2010 at 03:31, Lance Corrimal  wrote:
> Heya,
>
> I just gave the new multi-wearables in viewer-external (svn r3448) a try, and
> i found it to be seriously broken.
> when I logged in, every single attachment, including HUDs, went to some rather
> weird attachment point somewhere near my right knee, and everything was only
> "half attached": huds would complain that "you have dropped ... to the ground"
> if they were scripted to detect that, and none of the stuff showed "worn" in
> my inventory. And what was even more strange, the prims stayed where they were
> when I moved, hanging in the air at the very spot where my avatars right knee
> was when i attached them.
>
> Maybe even more worse was the fact that that attach point then was stored in
> the asset, and the stuff would attach to the same weird point even with an
> older viewer (snowglobe 1.4). Took me about 45 minutes to repair the damage to
> my default outfit 0.o
>
> Anyone else noticed this bug?
> Is there already a jira for it?
>
>
> 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] list for builds from the new snowstorm viewer-development repository?=

[Zabb65]

I'll stop in and say that it would be useful if you used the existing
mailing list address as well. And would appreciate emails on commits.

On Mon, Aug 16, 2010 at 15:32, Lance Corrimal  wrote:
> Am Monday 16 August 2010 schrieb Henri Beauchamp:
>> On Mon, 16 Aug 2010 11:38:44 -0700, Kadah wrote:
>> >> Would it be useful if I set up a one-way mailing list for
>> >> announcements of build results for the new viewer-development
>> >> repository?
>> >
>> > Why not use the existing one, sldev-comm...@lists.secondlife.com?
>>
>> Seconded.
>
> thirded (is there such a word?)
>
> 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] Compiler optimizations on Viewer and LLKDU

[Zabb65]

KDU automatically detects and uses cpu optimization if its available.
The only compiler options I'm aware of are those that enable or
disable threading of decoding, which I suspect won't be of much
benefit for the type of images uses in SL(small and fast to decode).
Compiling the base code with optimizations for CPU instruction
sets(SSE,etc) might help slightly, but the results would be minimal.

In the long ago days of Emerald, compiler optimizations were evil, and
caused obscure bugs that were hard to find, most of them would show up
on linux and mac, but there were some on windows too, related to using
SSE2 instruction sets that would cause the builds to crash at random.
At the time, I think LL has managed to balance optimization flags with
stability, It might be wise to leave what is known to work alone, save
there is enough manpower and time to extensively test the use of new
instruction sets across a great number of machine setups.

In the testing that was done internally for Emerald, results were
rather surprising, using SSE2 either causing a major slowdown and
choppy behavior for the client on some setups, or the results were
between 3 and 8% frame rate increase for a test scene. The major
improvement that I remember was in avatar rendering time, as well the
rebuilding of face geometry, where it could take advantage of doing
multiple things at once. None of the testing done was terribly
organized or reliable though, so I hope somebody else can set up some
tests and compare this a bit more accurately.

Summary: Might want to leave this as is, for stability, because the
gains are either negative, or small enough that its not worth the
possible losses.
___
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] Severe water flicker in recent development build

[Zabb65]

It generally isn't fair to compare other engines results with that of
second life, and I don't think it ever will be fair to compare
results, or how it looks.

The fundamental differences are too large. Most graphics engines deal
with optimized static geometry that has specially designed textures
that can be mapped onto them in clever ways, and an optimized
pre-computed tree is formed to occlusion, so that you can obtain very
high framerates and good looking results, even from very very modest
hardware. This however is not the case with second life, where there
is NO static geometry that can be optimized or merged, the textures
cannot be applied in clever ways or mapped efficiently, and those
using them generally do not know how their use of textures slows
everything now. I hope to see a lot of this change with the
introduction of mesh.

Second life current has a trade off between simplicity of data
transfer and polygon count and complexity, by over generating its
geometry for each primitive, it allows for simple building blocks that
can be used for construction. The trade off is that a great number of
them go unused or are never visible, hidden inside intersections of
other prims. Sadly this case cannot be optimized, as the system is
entirely dynamic, where any given primitive or object can change or
move at any time, leaving little room for clever programming to fill
in holes and optimize away pieces that cannot be seen.

Currently the second life system does a fairly good job of creating a
semi decent performance scene out of all this chaos, but I am sure
there are ways it could be further improved. Suggesting a move to
another graphics engine that is developed and designed for use with
static optimized geometry in a controlled environment would provide
poor performance, likely far worse than what is currently offered by
the tuned system that current exists. This is particularly true for
the number of unique textures that are often visible within a scene at
any time. Sometimes counting in the thousands. In most games you have
maybe 200 textures visible at any given moment, and its careful tuned
to stay as low as possible to achieve the good performance you are
used to.

I hope that we can continue to watch the engine used for second life
change and evolve in ways that increase this performance and lower the
bar of entry, but it will never be something that the programmers
alone can do, it takes the coordination of everyone involved, content
creators and users included.
___
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] Lindens way ahead of us

[Zabb65]

llviewercontrol.h is the header that allows access to saved settings values
within the viewer, and has nothing to do with RLV or any other form of
control over the viewer. They are simply a set of saved control values in
llsd xml format.

On Sun, Sep 26, 2010 at 22:37, miss c  wrote:

> All this talk about adding these plug ins RLV and breast physics plug
> ins were added to viewer 2 already.
>
> They were just going to surprise us I suppose -.-
>
> I found it here
> http://bitbucket.org/oz_linden/test1/changeset/bbecf41db5c8
>
> Quote:
> merge avatar physics up to latest viewer-development
>
> 49 
> 
>
> #include "llbreastmotion.h"
>
>  49 
> 
>
> 50 
> 
>
> #include "llviewercontrol.h"
>
>
>
>
> YAY
>
> 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

Re: [opensource-dev] Fix for "Attachments displayed in mouselook" bug

[Zabb65]

I tend to agree with Argent on this, it should have a comment if there
is a hack in place to make it all function.

I ran it through hg blame and it claims that revision 11977 was when a
big block in pipeline.cpp changed

11977: BOOL LLPipeline::hasRenderType(const U32 type) const
11977: {
11977:  return mRenderTypeEnabled[type];
11977: }

previously this function was in a header and looked like

BOOL hasRenderType(const U32 type) const{ 
return (type &&
(mRenderTypeMask & (1 I don't normally gripe about stuff like this, but somehow this one
> triggered my twitches from 20 years of supporting PhD programmers.
> Brilliant guys, but sometimes it's SO hard to figure out what they're
> trying to do.
>
> This is a case where the trinary "?:" operator is much more readable
> and understandable.
>
> (type == 0) ? FALSE : mRenderTypeEnabled[type];
>
> But even better:
>
> if(type == 0)
>  return FALSE; // explain why here .. eg "in this context we are
> always rendering attached prims on the head when blah blah..."
> else
>  return mRenderTypeEnabled[type];
> ___
> 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] As a content creator, I would like...

[Zabb65]

The local script editing and local texture editing has already been
done before and were implemented in phoenix. Scripting was done by
Katharine and textures were done by Vaalith.

I believe Vaalith is waiting for mesh source code so they can begin
working on the mesh portion of that.

The caveats of this is that there is no way to sync them to existing
inventory items or to update existing assets with the new one. So you
get a local preview of the changes instantly, but you have to decide
to upload a final copy at some point, and then it goes into your
inventory. This also costs money. If there was some method of fast
temporary uploads they could be previewed by all residents within a
sim, but until that is done on the simulator side, there is no way to
provide a cohesive element of live previews for other residents in the
sim. (They see either of a broken prim/mesh/texture or the old copy
that you uploaded.)

Until there is a local disk based prim editor. I would not expect
there to be the final item.

On Mon, Oct 18, 2010 at 14:34, Ponzu  wrote:
> These are some vague and undeveloped ideas I am sure a lot of us have had.
> I wonder if we can make any progress on them?  Some consensus on what
> could/should be done is a place to start.  So..
>
>
> I have some scripts in a folder in my inventory.  I would like to save them
> to my local disk.  If I change either my local version or my inventory
> version, they stay in sync.
>
> I can open my textures from in-world in my external editor of choice, modify
> them, and sync them back to the copies in inventory (or even the copy
> applied to an object).
>
> After I upload my Collada mesh, if I change my local copy, my inventory copy
> changes by magic.
>
> I can save my prim objects and coelesced objects locally, perhaps even
> directly in my local editing tool of choice.  Then modify them, and
> re-upload them.  Local and inventory versions are kept in sync by magic.
>
> Far off, I know.  Now I need to think about "how?"
>
> regards
> ponz
> ___
> 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] As a content creator, I would like...

[Zabb65]

My mistake. Credits to Xotmid then for external script editor.

On Mon, Oct 18, 2010 at 15:17, Brandon Husbands  wrote:
> Actualy I did the external script editor you can use the pre processor to
> link in saved scripts from your hard drive
>
> On Oct 18, 2010 1:43 PM, "Zabb65"  wrote:
>
> The local script editing and local texture editing has already been
> done before and were implemented in phoenix. Scripting was done by
> Katharine and textures were done by Vaalith.
>
> I believe Vaalith is waiting for mesh source code so they can begin
> working on the mesh portion of that.
>
> The caveats of this is that there is no way to sync them to existing
> inventory items or to update existing assets with the new one. So you
> get a local preview of the changes instantly, but you have to decide
> to upload a final copy at some point, and then it goes into your
> inventory. This also costs money. If there was some method of fast
> temporary uploads they could be previewed by all residents within a
> sim, but until that is done on the simulator side, there is no way to
> provide a cohesive element of live previews for other residents in the
> sim. (They see either of a broken prim/mesh/texture or the old copy
> that you uploaded.)
>
> Until there is a local disk based prim editor. I would not expect
> there to be the final item.
>
> On Mon, Oct 18, 2010 at 14:34, Ponzu  wrote:
>> These are some vague and undeve...
>
>> ___
>> 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] As a content creator, I would like...

[Zabb65]

They have been completed to the point of technical limitations of the
platform(AFAIK). I explained the caveats of the technical limitations
currently imposed upon them. If all you want is to locally see it.
Sure its been done. Otherwise, no, but there is progress that can be
built on when the technical limitations are lifted. To do it as you
explain it. It would require major updates to the way SL stores and
uses assets.

On Mon, Oct 18, 2010 at 15:46, Ponzu  wrote:
> On Mon, Oct 18, 2010 at 2:42 PM, Zabb65  wrote:
>>
>> The local script editing and local texture editing has already been
>> done before and were implemented in phoenix. Scripting was done by
>> Katharine and textures were done by Vaalith.
>>
>> I believe Vaalith is waiting for mesh source code so they can begin
>> working on the mesh portion of that.
>>
>> The caveats of this is that there is no way to sync them to existing
>> inventory items or to update existing assets with the new one.
>
>
> I like the way you say it has been done already and then explain that it has
> not yet been done.  Of course there are ways to sync them.  You could
> completely rewrite SL to allow it, for example.  I don't expect that, but it
> is still "a way".
>
> Anyway, I was more thinking of the user story and what the features would
> look like.  A plan to implement it can wait awhile until "it" is defined.
>
>
___
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] Mesh Source Code ETA

[Zabb65]

Last week when Mesh was announced into public beta, it was said the
source code would be put up by the end of the week, checking the blog
post mentions that it would be placed on the snowstorm wiki page, but
I cannot find it there.

After having corresponded with a few people it seems that the build
was broken and that is what is keeping the source from being
published. Later on I heard that pieces of mesh were being removed
from the code because of license restrictions. So my questions are as
follows:

1. Is there any ETA on a release for the source code to the mesh viewer?
2. As things are being removed, what exactly is being pulled, the
entire uploading process? Mesh decomposition support only? Something
else?
3. Is there the possibility of the code being released, even in its
broken state so that the community can review the changes made and
become more accustomed to them for merge purposes. Or so that the
dedicated community could piece together a working build from what is
there somehow?

~Zwagoth
___
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] Mesh Source Code ETA

[Zabb65]

They have only said they would release source, though they do not have
to release it. They are doing so out of their own good will as a
company, not by legal obligation, please remember this. I suspect they
are not trying to hide anything at all in this. Just complications
have likely occurred, so looking for updates or comments from the
official source as to whats going on.

~Zwagoth

On Thu, Oct 21, 2010 at 20:36, malachi  wrote:
> wow. see i missed this somewhere. but i comnpletely agree. if this client is
> OPEN SOURCE. where is the source? why is it being hidden behind walls?
> On Thu, 21 Oct 2010 18:05:32 -0400, Zabb65  wrote:
>
>> Last week when Mesh was announced into public beta, it was said the
>> source code would be put up by the end of the week, checking the blog
>> post mentions that it would be placed on the snowstorm wiki page, but
>> I cannot find it there.
>>
>> After having corresponded with a few people it seems that the build
>> was broken and that is what is keeping the source from being
>> published. Later on I heard that pieces of mesh were being removed
>> from the code because of license restrictions. So my questions are as
>> follows:
>>
>> 1. Is there any ETA on a release for the source code to the mesh viewer?
>> 2. As things are being removed, what exactly is being pulled, the
>> entire uploading process? Mesh decomposition support only? Something
>> else?
>> 3. Is there the possibility of the code being released, even in its
>> broken state so that the community can review the changes made and
>> become more accustomed to them for merge purposes. Or so that the
>> dedicated community could piece together a working build from what is
>> there somehow?
>>
>> ~Zwagoth
>> ___
>> 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
>
>
> --
> 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] Mesh Source Code ETA

[Zabb65]

Looks like this does not need an answer now. Code is up.
http://hg.secondlife.com/mesh-development/
\o/

On Thu, Oct 21, 2010 at 20:56, Zabb65  wrote:
> They have only said they would release source, though they do not have
> to release it. They are doing so out of their own good will as a
> company, not by legal obligation, please remember this. I suspect they
> are not trying to hide anything at all in this. Just complications
> have likely occurred, so looking for updates or comments from the
> official source as to whats going on.
>
> ~Zwagoth
>
> On Thu, Oct 21, 2010 at 20:36, malachi  wrote:
>> wow. see i missed this somewhere. but i comnpletely agree. if this client is
>> OPEN SOURCE. where is the source? why is it being hidden behind walls?
>> On Thu, 21 Oct 2010 18:05:32 -0400, Zabb65  wrote:
>>
>>> Last week when Mesh was announced into public beta, it was said the
>>> source code would be put up by the end of the week, checking the blog
>>> post mentions that it would be placed on the snowstorm wiki page, but
>>> I cannot find it there.
>>>
>>> After having corresponded with a few people it seems that the build
>>> was broken and that is what is keeping the source from being
>>> published. Later on I heard that pieces of mesh were being removed
>>> from the code because of license restrictions. So my questions are as
>>> follows:
>>>
>>> 1. Is there any ETA on a release for the source code to the mesh viewer?
>>> 2. As things are being removed, what exactly is being pulled, the
>>> entire uploading process? Mesh decomposition support only? Something
>>> else?
>>> 3. Is there the possibility of the code being released, even in its
>>> broken state so that the community can review the changes made and
>>> become more accustomed to them for merge purposes. Or so that the
>>> dedicated community could piece together a working build from what is
>>> there somehow?
>>>
>>> ~Zwagoth
>>> ___
>>> 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
>>
>>
>> --
>> 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] Mesh Source Code ETA

[Zabb65]

I think this would be the most obvious way to add proper decomposition
support back into the client, and allow for a full third party
implementation. Bullet has a fairly basic decomposition engine, but it
should work for what is being done, even if the results are not 100%
idea, and possibly can be worked into snowstorm given sufficient time
and testing.

On Fri, Oct 22, 2010 at 05:03, Aidan Thornton  wrote:
> On 10/22/10, Zabb65  wrote:
>> Looks like this does not need an answer now. Code is up.
>> http://hg.secondlife.com/mesh-development/
>> \o/
>
> Looks like convex decomposition support has been pulled.
> "LLConvexDecomposition is a proprietary library based on Havok (TM)
> physics libraries. In its place, Linden Lab shares the code for
> LLConvexDecompositionStub, a stub version of the same library with no
> proprietary components."
>
> I'd suggest porting the convex decomposition code from something like
> (for example) Bullet instead might be a good idea.
>
___
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] Crashing integration tests

[Zabb65]

It looks to be a problem with multiple tests running at the same time.
Looking at the error gives a hint that its a collision with a globally
shared named pipe of some type. Running the tests individually works
just fine for me, running more than one at a time doesn't.

On Mon, Oct 25, 2010 at 17:01, Boroondas Gupte
 wrote:
> On 10/25/2010 10:56 PM, Nicky Perian wrote:
>
> I found the same thing about failed tests on 2d and subsequent builds. The
> build has an error the first time but passes the second. This was on
> VC++Express 2005 build. And, didn't matter about redoing develop.py.
>
> So this isn't GNU make or even Makefile specific. Either it's a CMake bug,
> or we make some mistake at using CMake, probably not declaring all
> dependencies correctly.
>
> 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
>
___
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] Files deleted by uninstaller don't appear in Recycle Bin

[Zabb65]

My only concern with some of this, is that it eliminates the support
teams easy one line answer to everything odd or unexplained. Uninstall
and reinstall the client. The reason this works so well is that it
deletes all of the users settings and preferences, which often become
corrupted or contain invalid or bad values from previous versions, and
cause trouble. Log files should not be placed inside a hidden/system
folder to begin with in my opinion, its like treating user created
content as program preferences.

On Wed, Oct 27, 2010 at 16:18, Da5id Kronfeld  wrote:
>
> On 2010-10-27, at 7:45 AM, Kent Quirk (Q Linden) wrote:
>
>> Au contraire. Some people get very upset when an installer leaves any files 
>> behind that were created by the program automatically, such as log files. 
>> It's simply not true that the uninstaller shouldn't remove anything in the 
>> profile -- I have worked at multiple companies where leaving behind any 
>> breadcrumbs (anything that wasn't created by File Save) after an uninstall 
>> was considered a major bug.
>
> I disagree with this statement. On unix like systems it's standard practice 
> to store user specific settings in a file or directory like ~/.thePackage . 
> Just because someone removes/replaces/updates the software does not mean that 
> *anything* should happen to the contents of that file or directory. It's even 
> worse on systems with more than one user.
>
> I think that it's better to decouple the per-user settings and preferences 
> from the package installation entirely. Just my $L0.02.
> ___
> 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