Why not look at parts of the code that get used for fancy displays already?
For example the development -> render metadata -> physics(?) dipslay. It
removes all in-world textures and shows physics as colors on the objects.
I am sure you can find something interesting in that code.
--Chalice Yao
I have a copy of viewer-interesting that I patched with code from my
NaCl-release repo. I can upload it to my repo later so you can see examples
of how I converted custom code to the new types.
On Fri, May 9, 2014 at 3:52 PM, Nicky Perian wrote:
> haven't tried, looks like the best choice is it
make that items->at(i) to match your example.
On Fri, May 9, 2014 at 3:53 PM, Ambrosia wrote:
> array->at(i), if 'array' is a pointer to a vector.
>
> --Chalice Yao
>
>
> On Fri, May 9, 2014 at 3:47 PM, Lance Corrimal
> wrote:
>
>> Am
array->at(i), if 'array' is a pointer to a vector.
--Chalice Yao
On Fri, May 9, 2014 at 3:47 PM, Lance Corrimal wrote:
> Am Freitag, 9. Mai 2014, 15:37:15 schrieb Nicky D.:
> > > > I notice "operator[](i)" is used in the interesting,
> > >
> > > With std::vector, you could also use array.at(i),
Additionally to that, the amount of traffic that goes through the actual
sim these days has been highly reduced with bringing textures, mesh and
materials onto the sim-external HTTP pipeline that isn't bound to a single
sim.
Of course there is still people who feverishly set their texture pipeline
*stop
On Wed, Jul 24, 2013 at 2:32 PM, Ambrosia wrote:
> Would you please top spamming this mailing list over and over?
>
> Thank you.
>
>
> On Wed, Jul 24, 2013 at 2:27 PM, Ikram Bououd
> wrote:
>
>>
>> Sorry for multiple receptions
>>
>> Dea
Would you please top spamming this mailing list over and over?
Thank you.
On Wed, Jul 24, 2013 at 2:27 PM, Ikram Bououd wrote:
>
> Sorry for multiple receptions
>
> Dear All,
>
>
>
>
>
> I am Ikram Bououd, Ph.D. candidate in Information Systems at Telecom
> Business School in Paris. Under the s
eps I
used cause the diff
to be based off the sunshine either way.
The clone method of merging repos indeed creates the 2.2MB file.
--Chalice Yao
On Thu, Dec 20, 2012 at 6:12 PM, Ambrosia wrote:
> On Thu, Dec 20, 2012 at 10:56 AM, Henri Beauchamp wrote:
>> On Thu, 20 Dec 2012 00:03:03 -080
On Thu, Dec 20, 2012 at 10:56 AM, Henri Beauchamp wrote:
> On Thu, 20 Dec 2012 00:03:03 -0800 (PST), Nicky Perian wrote:
>
>> I decided to put some walk with my rather cheap talk.
>> Here is a repackaged server side avatar baking repository.
>> https://bitbucket.org/NickyP/viewer-development-sunsh
Oz, as an aside..
Is there a plan to ever support building non-standalone on Linux 64bit
without installing 32bit libraries or workarounds? It can be a
nightmare with some distributions, and being forced to compile it as
32bit in 2012 just feels..wrong.
Pretty much all that blocks it is a lack of
Greetings,
Just a heads up to anybody building any kind of official TPVs:
Do not use the llPhysicsMotion.cpp and .h that are currently in the
repository, nor derivate code off them.
They come with GPL headers and would taint any relased builds into
being GPL licensed, certainly an oversight on t
On Mon, Dec 13, 2010 at 10:28, Ambrosia wrote:
> On Mon, Dec 13, 2010 at 05:27, Mike Chase
> wrote:
>> On 12/12/2010 10:48 PM, Marc Adored wrote:
>>> Yes 32bit SLVoice can run with 64bit viewer because the viewer is not
>>> using it as a lib its a network connect
On Mon, Dec 13, 2010 at 05:27, Mike Chase
wrote:
> On 12/12/2010 10:48 PM, Marc Adored wrote:
>> Yes 32bit SLVoice can run with 64bit viewer because the viewer is not
>> using it as a lib its a network connection between each other so none
>> of that matters.
>>
> Ok, so maybe one thing that might
On Fri, Oct 15, 2010 at 11:23, leliel wrote:
> On Fri, Oct 15, 2010 at 2:04 AM, Lance Corrimal
> wrote:
>> Am Freitag, 15. Oktober 2010, 10:00:44 schrieb Rob Nelson:
>>> So basically, LL decided to go from simply changing the formatting of
>>> their logs to (if what I am hearing is correct), of
Wait, what?
The new chat/IM logs are saved in LLSD of all things?
Why? To make chat/IM history work with the display names or...what?
And there is no option to also store a .txt copy?
On Fri, Oct 15, 2010 at 08:15, Jamey Fletcher wrote:
> WolfPup Lowenhar wrote:
>
>> Actualy the file extension
I hope the point was brought up that Webp only does lossy compression
tho, while Jpeg2k Also does lossless.
In light of sculpts requiring lossless compression, I'd not expect the
need for a jpeg2k decoder
to go away anytime soon for at least that kind of texture, alas,
unless lossless textures'd g
On Thu, Sep 30, 2010 at 08:03, Ambrosia wrote:
> On Thu, Sep 30, 2010 at 01:06, Kelly Linden wrote:
>> * In the end the number of scripts shouldn't be important
>
> 15ms of overhead. Plus -at least- 16mb of memory used if all those
> scripts are mono, which is unlikely.
On Thu, Sep 30, 2010 at 01:06, Kelly Linden wrote:
> * In the end the number of scripts shouldn't be important
It is currently important hover, because due to a lack of script
memory limits per avatar/parcel, you can see lots of people wearing an
excess of over 200 scripts per avatar. Easily. All
On Wed, Sep 29, 2010 at 15:51, Obsidian Kindragon wrote:
> On 9/29/2010 7:34 AM, Opensource Obscure wrote:
>> On Mon, 27 Sep 2010 22:55:57 -0700, Kelly Linden
>> wrote:
>>> There are multiple issues at play here:
>>> What I understand is that the viewer is flogging our servers to brute force
>>>
> There was one small surprise. Only two threads were in use for both the
> OpenJPEG v1.3.0 and KDU tests. I expected KDU to use all eight available
> threads.
>
Remember that LL is still shipping a downright ancient KDU 4.* based
llkdu.dll with the viewer.
If they successfully update to 6.4.* or
It goes even further. JPEG2k is superior in compression ratio compared
to quality to both, JPEG and PNG when it comes to lossy and lossless.
it is actually a quite awesome image format through and through.
The only real problem with JPEG2k are software patents. It's the
reason why free decoders li
Dzontas,
Please do not post to this list intoxicated or on heavy medication,
which you've seemed to be on for the last several days judging by the
rather random and rather confusing (And quite confused sounding)
content of your messages in several OSDEV topics.
Thank you.
On Sun, Aug 8, 2010 at
> and what henri has is the same feature in a different implementation (100%
> viewer internally), so it's not as if you could use emerald and something sold
> or given away for free by henri INSTEAD of this guys script.
> THIS IS NOT WORTH ANY KIND OF MONEY (since its sort of the whole point
> of
On Wed, Apr 14, 2010 at 14:00, Carlo Wood wrote:
> This guy really filed a lawsuit.
>
> Such people exist, ... one of the reasons I REALLY don't want to work
> on a SL viewer when there is a TOS that says I'm responsible and
> liable for any damages done as a result of using that viewer.
>
The la
> So, cool, wouldn't it be nice to only allocate what is actually
> requested?
That -is- in the works, with the Small Scripts and Big Scripts
projects. it will allows you to reserve just as much memory as you
need for mono scripts, less than the 64k..or even more. But alas, yes,
time will have to
25 matches
Mail list logo