Jump to content
cykarushb

Firestorm vs the LL Viewer

Recommended Posts

On 10/10/2018 at 10:50 AM, Phil Deakins said:

TPVs were developed from LL's viewer by modifying it. They weren't written by the TPV developers.

That is not completely true. Sections of the LL Viewer come from third-parties. Materials is the latest BIG example where it was primarily a third-party collaborating with the Lab being in more of a support position for integration than an author.

Another example is the Bento feature where third-parties primarily worked out the Appearance Slider features for the new bones.

The POSER feature and Snapshot interface of Black Dragon are being adopted for use in the LL Viewer.

While it may be technically 'precise' to say all these are modifications to the SL viewer... it is not respectfully accurate. A number of people have contributed original ideas and code to an open source project. They were not just tweaks to existing code. I suspect Oz Linden, the Linden in charge of and fan of the open source aspect of SL Viewer development, would disagree with you too. Your opinion isn't wrong, but it also is not accurately reflective of the reality.

On 10/10/2018 at 3:08 PM, Drake1 Nightfire said:

It's more likely the word i highlighted that is the cause.. SL is a system hog. Even a gaming laptop has issues with it, you just cant pack the power of a PC into a laptop.

There are Alienware laptops that would not even spin up a fan to run SL... OK, I'm exaggerating, but not a lot. But, my desktop is good, built 10/2016, yet I have a friend with same era laptop that smokes it.

You are right SL uses a ton of resources. But, what other virtual world 'game' do you know of that runs with well over 200 petabytes of data? That asset DB in like 2010/2012 was being cleaned to get it down to 200+ petabytes. I haven't heard for some time how big the DB is now. The 200PB was before mesh... 

So, if you are implying SL is a hog from inefficiency, I disagree.

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites
24 minutes ago, Nalates Urriah said:

Materials is the latest BIG example where it was primarily a third-party collaborating with the Lab being in more of a support position for integration than an author.

I used to see someone on a telegram chat who said they created materials.

Thanks for respectfully and carefully explaining all that in your response:

26 minutes ago, Nalates Urriah said:

While it may be technically 'precise' to say all these are modifications to the SL viewer... it is not respectfully accurate.

 

26 minutes ago, Nalates Urriah said:

Your opinion isn't wrong, but it also is not accurately reflective of the reality.

My gut tells me that this can’t be the end of the discussion, but your explanation is awesome!

  • Thanks 1

Share this post


Link to post
Share on other sites
6 hours ago, Nalates Urriah said:

You are right SL uses a ton of resources. But, what other virtual world 'game' do you know of that runs with well over 200 petabytes of data? That asset DB in like 2010/2012 was being cleaned to get it down to 200+ petabytes. I haven't heard for some time how big the DB is now. The 200PB was before mesh...

You have 200PB of data on your computer? Streamed via the Internet? Respect! 😉

SL is a lag hog and slow as hell because nobody cared updating the rendering pipeline after 2006, offloading all the complex calculations involved with avatars to the GPU that has hundreds of shaders that could do that, instead of letting the CPU do all that - and that in many cases even without using SSE2 (or newer). But if they did, a small but loud group of people trying to run SL on 10 year old hardware are going to complain...

Edited by Ansariel Hiller
  • Like 1
  • Thanks 3
  • Haha 2

Share this post


Link to post
Share on other sites

@Nalates Urriah

I didn't say that TPVs haven't contributed some additions to the viewer. I know that they have. I said that they didn't write the viewer, which they didn't, and you agreed.

Edited by Phil Deakins

Share this post


Link to post
Share on other sites
6 hours ago, Ansariel Hiller said:

You have 200PB of data on your computer? Streamed via the Internet? Respect! 😉

SL is a lag hog and slow as hell because nobody cared updating the rendering pipeline after 2006, offloading all the complex calculations involved with avatars to the GPU that has hundreds of shaders that could do that, instead of letting the CPU do all that - and that in many cases even without using SSE2 (or newer). But if they did, a small but loud group of people trying to run SL on 10 year old hardware are going to complain...

This, this is the point I always have to bring up when someone is concerned about performance. This game relies entirely off of old school legacy code that really likes the way old hardware worked, but with a modern demand.

This game really doesn't care what your GPU is, it wants single threaded performance and a bit of ram. Even if you have a terrible quantity of video memory it just starts using drive cache instead.

I have tested this game on literally dozens of different graphics cards and processors and ram quantities, every windows OS post XP, there's a huge problem where I get nearly the same performance out of a dual core Pentium e series and a GTX 275 that I get with any other gpu I cram in there. The only big performance jumps come with the CPU, but even that peaks eventually where my i5 4570 is performing just a tad bit below a 7700k...

 

Ive thrown everything from a GeForce4 Ti 4600 to a GTX 970 at SL and it doesn't really care as long as it has 3gb of ram to eat and a decent processor.

Side note, why did this get necrobumped so hard lel

IMG_2467.JPG

Share this post


Link to post
Share on other sites
On 10/12/2018 at 1:52 PM, Nalates Urriah said:

So, if you are implying SL is a hog from inefficiency, I disagree.

Sl IS a hog from inefficiency, but not on the part of LL, sort of... Its due to merchants and people using 1024 x 1024 textures fro things like, buttons, doorknobs, jewelry, nails and eyes.. There is no need for it. If its so small you have to cam in tight to see it, use a 256.. or even a 128

  • Like 2

Share this post


Link to post
Share on other sites
9 hours ago, Drake1 Nightfire said:

Sl IS a hog from inefficiency, but not on the part of LL, sort of... Its due to merchants and people using 1024 x 1024 textures fro things like, buttons, doorknobs, jewelry, nails and eyes.. There is no need for it. If its so small you have to cam in tight to see it, use a 256.. or even a 128

this has absolutely nothing to do with the framerate of SL, you would just see these massive textures load slowly, and uncompressed gradient 1024x1024 texture is 4mb. And you will never see uncompressed textures, nor are they all rainbow gradients (to create max file size). Most are going to be 100-300kb in size each.

So even if you have literally 10,000 of these textures visible its only 3gb of memory used for textures. The regular viewer caps at 512mb of texture memory because you're rarely gonna see more than 1gb of textures in one place anyway. Even if it was all stored in gpu vram (which it isnt) nobody should be using less than a 1gb video card in 2018 anyway.

tl;dr no, large textures do not affect performance in SL

This is a massive misconception by people who dont know what theyre talking about trying to find something to blame for SL's terrible performance. It is plain and simple that the game is not utilizing the hardware of modern PC's well, if at all. High end GPU's sit in this game at sub 30-50% usage and people go "huh, i wonder why that could be". Its because the majority of mesh object rendering is still handled by the CPU, almost entirely. Pretty much everything but textures. Shadows, the framing, lighting as a whole, bump mapping and shiny/specular effects, its all CPU bound and to top it all off SL's engine doesnt like to use multiple cores/threads very much. The GPU is really just handling textures and some of the more finnicky math related bits to object placement and alignment.

 

  • Confused 2

Share this post


Link to post
Share on other sites
On 15 October 2018 at 1:07 AM, cykarushb said:

and uncompressed gradient 1024x1024 texture is 4mb. And you will never see uncompressed textures, nor are they all rainbow gradients (to create max file size). Most are going to be 100-300kb in size each.

So even if you have literally 10,000 of these textures visible its only 3gb of memory used for textures

File formats for images (compressed or un-compressed) are ONLY relevant for STORAGE of images, say on a hard disk, or for transmission of images.

When textures are loaded into memory for display in an image viewing app, or used in a render engine, they get UNCOMPRESSED into BITMAPS, so a 1024 x 1024 rgba image would be 4 mb, REGARDLESS of what the image actually is or how complicated it might be.

On 15 October 2018 at 1:07 AM, cykarushb said:

people who dont know what theyre talking about

Like the people who assume that gfx cards GPUs are hardwired to understand the thousands of different image file formats out there, instead of leaving that to software to decode and dump on them in a bitmapped format?
 

  • Haha 1

Share this post


Link to post
Share on other sites
2 hours ago, Klytyna said:

File formats for images (compressed or un-compressed) are ONLY relevant for STORAGE of images, say on a hard disk, or for transmission of images.

When textures are loaded into memory for display in an image viewing app, or used in a render engine, they get UNCOMPRESSED into BITMAPS, so a 1024 x 1024 rgba image would be 4 mb, REGARDLESS of what the image actually is or how complicated it might be.
 

That's just not how any of that works. You could've done a literal 10 second google search and read even a single sentence to get more accurate information than this.

Before I explain the rest of that, this kinda posting, big words, bold font, argumentative demeanor and the confused reaction, this is why I state "people who don't know what they're talking about". Its seriously harmful to these forums for people who pretend to know what they're saying to try and answer the questions of those who genuinely need help. Like the time a certain someone pulled up a jira report from 2007 about a mobile ATI graphics chipset having problems when someone said their newer laptop was showing graphical artifacting...

Anyway, textures remain compressed in SL, in fact I can't really think of many things that would use uncompressed textures. Outside of some specific professional programs and well I guess any 3D modeling software. There isn't any reason to uncompressed them. Compressed images don't show a drastic reduction in quality and they're much easier to manage by a game that stores a lot of them for use. They also don't become bitmap files, they're not converted and the texture you see remains the texture the file originated as. The GPU in this game doesn't do much, but it's definitely not spending it's time ucompressing textured which is a hugely CPU bound task, not in designation but in pure efficiency. The GPU is terrible at compression tasks. You can actually test this yourself with 7zips benchmarking tool if you don't believe me. Compression methods rely on CPU clock speed, lots of weaker cores running at a lower speed don't make for very good compression/decompression (a gpu).

And just because a file is uncompressed does not mean it's always going to be the same file size regardless of the content in it. The more complicated the image, as in the more colors that are different from one another and are not next to each other the more complex the data of the image, the larger the images file size. The most complicated image is a 24 bit rgb gradient, so every pixel would be a different color. In regular old png format that gives you your 4mb image. Hell, make it a tiff if you want to be certain of it being a pita to compress.

The less complex the image the smaller the file size. An entirely black, entirely white image is going to be exponentially smaller, with image metadata in png format, under 50kb. Less if you can strip the metadata.

Remove all pixels and all metadata and you can have a 1024x1024 image that's under 1kb. I have demonstrations for these images if you would like, though I cannot post an entirely blank png with no metadata because it causes most web browsers to crash out.

 

Share this post


Link to post
Share on other sites

Demonstration here with compressed images, a PNG of a 1024x1024 section of the SRGB hued colorspace. This a 214kb image. Note that i cant really make it any more than 750x750, so im not spamming up the place its going to be 300x300. The image is here: https://stuff.mit.edu/~kenta/one/color-lab/dwvcvceg/manylab.png

manylab.thumb.png.4e0a6fe46435571739e566daae372f0a.png

This image cannot be compressed without losing any image quality, because every pixel is a different color. Even the spots that show entirely white or entirely black to the naked eye are actually different colors. The only places with continuation in pixels are the very top and very bottom single rows of pixels which are entirely black and entirely white.

If we lost some image quality, basic compression brings it down to 164kb, but its noticeable with a gradient like this. Leaving this one at 750x750 to show that.

manylab.thumb.png.becb4155c1675f7e640a26d5e6188b35.png

This is entirely black 1024x1024 png. It is 14kb.

black.thumb.png.cfbff7656e4584dfc8e44cc4c417f3d4.png

This is the same black png compressed down to 250 bytes.

black-min.thumb.png.486ccb407088fec921c9901dff471850.png

Chances are you are never going to see an uncompressed image ever used for anything in SL or most games for that matter. Since most of the time the textures you see arent color gradients. For a more realistic scenario, heres a 1024 texture of some wood.

wood1.thumb.jpg.58c8976c574aa3dd7ff0327d7340cb8c.jpg

This is a basic texture, its 284kb.

Compressing that down to 229kb brings us this result.

wood1-min.thumb.jpg.38de49f5bcd95fe651ff1fd599a817ee.jpg

They look identical.

Lets compress it down even more to 189kb.

wood1-min.thumb.jpeg.48ae56cba1550ff2e6eaec9aae1a755b.jpeg

Looks the same.

 

 

Share this post


Link to post
Share on other sites

and for further clarification on how any 1024x1024 image would become 4mb uncompressed and how it has nothing to do with color...

heres this screenshot from SL as both a jpeg and a 24 bit bmp

10241.thumb.jpg.d7ec826b3aac0458cb76be34524e6485.jpg

1.png.7a61b7cfc3571c0cbca1b2039cf7985a.png

 

definitely larger, but definitely not its theoretical max of 4mb because of all the color consistency thats there, and definitely not what your PC is handling hundreds of at a time

  • Confused 1

Share this post


Link to post
Share on other sites
2 hours ago, cykarushb said:

Its seriously harmful to these forums for people who pretend to know what they're saying to try and answer the questions of those who genuinely need help. Like the time a certain someone pulled up a jira report from 2007 about a mobile ATI graphics chipset having problems when someone said their newer laptop was showing graphical artifacting...

Nice attempted "smear" attack there... A certain someone...

Certainly wasn't me...

2 hours ago, cykarushb said:

Anyway, textures remain compressed in SL

they remain in Jpeg2000 format on the asset servers, in the CDN delivery system, and essentially in the disk cache, it's true, but... GPU's don't understand jpeg2000 asa rule, they deal in video-memory dump format, aka, Bitmaps.

Literally, a dump of the memory, with a header to specify the pixel resolution and colour bit depth.

2 hours ago, cykarushb said:

Compressed images don't show a drastic reduction in quality and they're much easier to manage by a game that stores a lot of them for use.

The operative words there being "handle" and "store"...

2 hours ago, cykarushb said:

The GPU in this game doesn't do much, but it's definitely not spending it's time ucompressing textured

We know, in fact that was kind of my point... GPU's do not deal in file formats, they deal in bitmap image data, passed to them by the software running on the CPU...

2 hours ago, cykarushb said:

And just because a file is uncompressed does not mean it's always going to be the same file size regardless of the content in it. The more complicated the image, as in the more colors that are different from one another and are not next to each other the more complex the data of the image, the larger the images file size.

Again the operative word there is "file size" when dealing with non bitmap file formats.

I'd really like you to show us a 1024 x 1024 24-bit RGB BITMAP that wasn't 3mb... Really, See if you can find one...

No cheating and using 8 bit or anything, 24 bit 1024 x 1024 bitmap image.

2 hours ago, cykarushb said:

1.png.7a61b7cfc3571c0cbca1b2039cf7985a.png

Oh and FYI... the "size" there is the actual size, to eof marker, of the image file, compared to the size on disk, which is the theoretical amount of space available in the number of blocks of hard disk capacity used to store the file.

It has NOTHING at all to do , directly with memory size of the image when it's being used or displayed on your screen by your gfx card.

For some self proclaimed "Tech-Guru" you are using some poor image diagnostic tools.

1360472689_Whowaswrong.jpg.deca2bf936a7672145dc136c35ceb3a9.jpg

Note here that the "current memory size" for a png file is the amount of memory it uses when unpacked for display on a screen by your GPU...

3 hours ago, cykarushb said:

this is why I state "people who don't know what they're talking about"

/me coughs...

3 hours ago, cykarushb said:

You could've done a literal 10 second google search and read even a single sentence to get more accurate information than this.

Take your own advice...

...

If we want to know if the $2500 GeekTech 9000 series GFX card is 0.000257 % faster on direct-draw calls than the $2250 CyberFool 8670 series... We'll call you... That's the sort of tech talk you're good at...


 

  • Thanks 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×