Raytracing

[Arduenn Schwartzman]

Raytracing can look good in dark wet/metallic environments with lots of light sources all around, like Cyberpunk 2077. In dry rocky and leafy places (say nature/forest/deserts, but also dry urban places during daytime, the environment with RTX on does not differ noticably from that with RTX off.

[Finite]

On 9/6/2023 at 12:52 AM, Gopi Passiflora said:

This may be a stupid question, but can Second Life support raytracing? Just wondering.

The reason why I ask is because I'm getting a new graphics card (RTX 4070, which is capable of raytracing). Even if RT is not possible in SL, I want to see how the graphics card improves the graphics in SL over my current GTX 1660 Super.

My understanding is that SL doesn't currently utilize video card memory as much other games. It mostly uses CPU and RAM. So that 4070 might only be a slight difference (at least for SL. It'll be a huge difference for actual games). This will change in a good way once PBR is implemented however as the resources will then be diverted mostly to CPU and VRam. I'd probably wait to see how that 1660 performs with PBR unless you are hellbent on upgrading regardless or were able to snipe one in the meantime for a good price. I think anyone who isn't using an on-board vid card will see a bump in performance once PBR is out.

Edited September 7, 2023 by Finite

[Luna Bliss]

4 hours ago, Arduenn Schwartzman said:

Raytracing can look good in dark wet/metallic environments with lots of light sources all around, like Cyberpunk 2077. In dry rocky and leafy places (say nature/forest/deserts, but also dry urban places during daytime, the environment with RTX on does not differ noticably from that with RTX off.

What about in a forest where it just rained and there were puddles on the ground?

[AmeliaJ08]

20 hours ago, Finite said:

My understanding is that SL doesn't currently utilize video card memory as much other games. It mostly uses CPU and RAM. So that 4070 might only be a slight difference (at least for SL. It'll be a huge difference for actual games). This will change in a good way once PBR is implemented however as the resources will then be diverted mostly to CPU and VRam. I'd probably wait to see how that 1660 performs with PBR unless you are hellbent on upgrading regardless or were able to snipe one in the meantime for a good price. I think anyone who isn't using an on-board vid card will see a bump in performance once PBR is out.

With the correct viewer and settings SL will absolutely consume as much VRAM as you allow it to. It doesn't utilise the GPU or CPU very well though.

SL's largely completely unoptimized content means it will swallow up gigabytes of VRAM with no issue and even run into problems due to its appetite for this, the caching and moving textures in and out of VRAM is very broken and results in that texture blurring issue we all encounter even with many gigabytes of VRAM and RAM for it to use effectively.

 

 

 

Edited September 8, 2023 by AmeliaJ08

[Zalificent Corvinus]

1 hour ago, AmeliaJ08 said:

the caching and moving textures in and out of VRAM is very broken and results in that texture blurring issue we all encounter even with many gigabytes of VRAM

It's called "Texture Thrashing", and part of the cause i that more than 20 years  ago, some diingbat decided that SL's default texture file format would be JPEG2000, instead of some sensible "game-friendly" format like png or tga or dds, or een bmp.

 

Every JPEG2000 is actually several images. There i a standard jpg image at the official resolution using standard jpg lossy compression, probably with the old default quality/compression ratio of 80/20, then several more versions with less quality and more compression,  hence blur. storing images like this typically increases  memory usage, while doing absolutely nothing for render quality. On the official Fail-Viewer, with its 512 mb vram cap, this means every time it has to swap out a texture to make room for a new one, it d*cks about, wasting CPU cycles reading all those damn ever-lower-quality copies FIRST, and throwing them at the GPU for display, starting with the worst quality version first.

By the time it's finished extracting all the versions from worst to sort-of-best, odds are another texture has to be swapped out and another swapped in, possibly the same ones, over and over. THAT is "Texture Thrashing", Having more RAM available helps reduce this. So does not having a STUPID high Draw Distance, and trying to load every texture on  9/23/41 regions depending if your DD is 512/768/1024 m.

It's an unoptimied image file format, with an unoptimised VRAM limit and an unoptimised draw distance. A 20 year plus Dev mistake, a 13 year plus Dev mistake, and constant User Error.

 

Simply screaming "unoptimised content" just hides the awful truth, that SL was built wrong from the ground up, and used by people who pick their viewer settings without any actual rational basis for doing so,.

[gwynchisholm]

On 9/6/2023 at 12:02 AM, Love Zhaoying said:

Interesting to me is, back when I was in college, "ray tracing" required "supercomputers"!

Fast Ray tracing for sure, but technically a graphing calculator can do ray traced lighting, it just takes minutes per frame.

Its pretty amazing how fast computer tech has moved, and then in many ways while it slowed some, specialized technology like dedicated optimized ray tracing cores being a thing suddenly bring a whole new tech into the mix.

On 9/6/2023 at 2:45 AM, Ted McGregor said:

Partially true. Even though SL's engine does not support true ray tracing (that's why you see reflections and physical depth but not the actual beams of light ), the RTX hardware will certainly improve the PBR experience for lighting, reflections and depth.

I agree you shouldn't just invest in RTX hardware, because of SL only.

This is the big point with this. Consumer available Ray tracing hardware, ie nvidia RTX graphics cards, or Intel ARC or AMD’s Radeon equivalents, are specialized solutions that require the game and API used by the game to support it.

Its not like “this hardware is powerful enough for real time Ray tracing”, instead it’s more like “this hardware can do real time Ray tracing, if the software can utilize it”

Not capability, but compatibility. I think a lot of people aren’t super aware of that, and realistically the average consumer has no reason to be, they just want to play games. So it’s worth keeping that information out there so people don’t get their expectations too high when roblox doesn’t suddenly have Ray tracing when they get a 4090, which I have seen at least one person confused by that exact scenario.

Unrelated Fun fact, roblox had Ray tracing, though not rtx compatible, predating the concept of onboard rt cores even. So it was awful and slow and it was scrapped from their beta builds for a few lighting demos in favor of voxel HDR lighting and PBR.

[animats]

3 hours ago, Zalificent Corvinus said:

Texture Thrashing" ... JPEG2000

The main problem with JPEG 2000 is that the decode process is really slow. (JPEG decoders are either slow and buggy, or expensive to license.) And the way to read part of the file and get a lower rez version is badly designed. But that has nothing to do with VRAM utilization or texture thrashing. Those are separate problems.

LL started to address texture loading in "Project Interesting" some years back, and there's an abandoned project viewer where you can see the beginnings of that.

Here's my Sharpview tech demo of that problem, solved. It's a speed run through Port Babbage. There isn't enough VRAM to put the whole region in the GPU. Textures are being frantically loaded and unloaded by background threads. If you look closely, you'll see that, especially where the camera approaches and enters "Savory Street Market". Note the sign being blurry, then snapping into focus. Some of the vendors in the stores are blurry at first, then load at higher resolution. It's not perfect, but it's pretty good. (If that transition was a 3/4 second dissolve, like it is in GTA V, you probably wouldn't notice at all. Blink and you'll miss it.)

There's no reason the mainstream SL viewers should be stalling for 30 seconds to get some textures upgraded to the needed resolution. That's just a bug.

Anyway, no, it's not JPEG 2000. And it's unrelated to ray tracing.

The rendering feature I think SL needs is subsurface scattering for skin. This is the effect where light hits skin, bounces around inside, and a bit of red light comes back out.

Light goes into skin, comes out somewhere else with a color change. And we humans react "It's alive."

Humans are hard-wired to detect this as "alive". Without that, you're stuck where we are now, in the uncanny valley, with a range of choices between "dead" and "plastic". The theory of this is complicated, but it becomes one shader and one more material layer for skins. This layer should have been in the glTF material standard. (It's an extension.) It's in Blender and Unreal Engine.

There's realism, and there's "ooh, shiny thing". Both have their uses. People love shiny thing features. Go visit "Materials 1" on the beta grid. So much shiny. Very soon, even shinier, with mirrors! If you saw the '70s disco in test at Rumpus Room 1, you saw how far this can go. Ray tracing is really good for shiny things. But you get a lot more bang for the GPU buck with good normal maps.

Enough rendering for one day.

[Ardy Lay]

1 hour ago, animats said:

Without that, you're stuck where we are now, in the uncanny valley, with a range of choices between "dead" and "plastic".

You forgot "wears too damn much makeup."

[Zalificent Corvinus]

1 hour ago, animats said:

The main problem with JPEG 2000 is that the decode process is really slow. (JPEG decoders are either slow and buggy, or expensive to license.) And the way to read part of the file and get a lower rez version is badly designed. But that has nothing to do with VRAM utilization or texture thrashing. Those are separate problems.

Actually, it DOES have something to do with texture thrashing. Specifically, the crappy multi low quality "stream over a 2400 baud modem" obsolete before it was released file format, is directly responsible for the multi level blurring when a texture is loaded.

Commence loading new texture

Load crapview level 3

*snooze*

Load crapview level 2

*snooze*

Load crapview level 1

*snooze*

Load the ACTUAL texture the user wanted

*snooze*

Unload texture from memory because low VRAM cap means we need the space for another texture.

*multi snooze*

Oh crap, we still need the first texture, redo from start.

 

So the engine goes thru the multi-crap load and display, then unloads, does the multi crap load and display on aa different texture,  then unloads that and does the whole mess over again.

THAT's what "Texture Thrashing IS, the same texture loading a series of blurry versions, loading the sharp version, then reverting to super-duper blurry again.

 

It's a bad texture file choice, coupled with poor VRAM cap settings. TPV's have corrected the VRAM cap issue, something LL are apparently unable to do, but we're stuck with jpeg2k.

 

Moving on.

1 hour ago, animats said:

The rendering feature I think SL needs is subsurface scattering for skin. This is the effect where light hits skin, bounces around inside, and a bit of red light comes back out.

 

 

Humans are hard-wired to detect this as "alive".

NO, humans are NOT "hardwired" to see SSS as "alive".

A fresh human corpse's skin has the same SSS effect as a live human. It does not suddenly become 100% opaque when your heart stops.

As for it's use in rendering, it's been available for a lot longer than PBR. It's also been to blame for some really BAD cgi, people tend to over do the effect, and make the digital skin TOO SSS, so even a dim candle, 15 feet away shines through a so-called "human earlobe" like a 10,000 candle power hand held searchlight.

Seeing how often people in SL have gotten ALM Materials wrong, and projecting how many will get PBR wrong, for example you your self in your hobby viewer, once said that you converted from materials to PBR by greyscalling the ALM specular colour map, and shoving it into the PBR metalness channel, thus making say wet meat on a market stall look like an red-anodised aluminium sculpture of meat, I suspect the introduction of SSS into SL would see a whole epidemic of avatars that look like they are made of translucent wax.

 

Like many people, you mistake "auto checking all the add-photo-realism buttons" with improving overall quality.

 

 

[animats]

25 minutes ago, Zalificent Corvinus said:

thus making say wet meat on a market stall look like an red-anodised aluminium sculpture of meat

Wet meat in market stall, Port Babbage. Sharpview.

Wet meat in market stall, Port Babbage. Firestorm.

Edited September 8, 2023 by animats

[Zalificent Corvinus]

4 hours ago, animats said:

Wet meat in market stall, Port Babbage. Sharpview.

Wet meat in market stall, Port Babbage. Firestorm.

That might have been a better rebuttal if the "meat" had been shiny wet, as in SL materials with a white or pale grey spec map, to greyscale spec "non-metallic" shine, as opposed to diffuse tinted "metallic shine" that you get with PBR if you use a metalness map.

Do feel smug, despite having completely missed the point.

Yet AGAIN.