ALM Proposal / Work

[animats]

1 hour ago, Fluffy Sharkfin said:

However since we don't live in a world where hardware resources are unlimited and some residents are struggling with the requirements of SL already it makes sense to limit the available texture size to something less excessive. 

Overly large textures are becoming a non-problem. My experimental viewer only loads textures up to one texture pixel (texel) per screen pixel. If you have a giant texture on an object you're not right on top of,  the high-detail version of the texture will never be loaded. LL is putting that in their viewer. This is a huge win.

Creator User Group has been very encouraging lately. LL has hired some people from game graphics development, and they're gradually bringing the LL viewer into the current decade. Coming soon, per the last meeting:

• Loading textures based on how much space they occupy on screen, as above.
• PBR,  per the gLTF 2.0 spec.
• Avatar impostors as Z-sprites, so they depth sort properly.
• Better environmental reflections.
• All deferred rendering, which means the GPU does more of the work.
• Maybe even mirrors.

This should be interesting.

 

[Fluffy Sharkfin]

1 hour ago, animats said:

Overly large textures are becoming a non-problem. My experimental viewer only loads textures up to one texture pixel (texel) per screen pixel. If you have a giant texture on an object you're not right on top of,  the high-detail version of the texture will never be loaded. LL is putting that in their viewer. This is a huge win.

While I'm definitely in favor of LL updating the viewer and making some much needed changes in order to improve performance there will always be benefit to be had from encouraging creators to use common sense when determining what resolution their textures need to be.

In fact it's not just creators that would benefit from learning a little more about texel density.  Whether you're decorating your living room, putting together a new outfit or building an entire region paying attention to the comparative texel density of the assets you're using can substantially improve the end result.  As this quote (from the article Texel Density – What is it and why is it so important?) puts it

Quote

Maintaining a consistent texel density might seem like an unimportant technical detail in the grand scheme of making art, but it is essential for not only creating a great-looking asset but for keeping the quality of art consistent throughout the entire game. Having objects with wildly different texel densities sitting next to each other shines a light on quality issues of the assets and can be emersion-breaking as the player is no longer looking at a consistent world.

 

1 hour ago, animats said:

Creator User Group has been very encouraging lately. LL has hired some people from game graphics development, and they're gradually bringing the LL viewer into the current decade. Coming soon, per the last meeting:

• Loading textures based on how much space they occupy on screen, as above.
• PBR,  per the gLTF 2.0 spec.
• Avatar impostors as Z-sprites, so they depth sort properly.
• Better environmental reflections.
• All deferred rendering, which means the GPU does more of the work.
• Maybe even mirrors.

This should be interesting.

I'm definitely looking forward to the new features and improvements!

One new feature that was mentioned briefly but hasn't been discussed much is the ability to flag meshes (and hopefully individual faces) as being double-sided.  This may seem a little trivial at first but I'm guessing it will make a big difference to creators of landscaping items like trees and other items that make use of "leaf cards" since it could substantially lower the number of polygons required.  Another area in which double-sided faces could have a huge impact is in the creation of "billboard" LOD models since it will essentially halve the number of triangles required to make the low/lowest LOD models, perhaps it will even allow some creators to make mesh that utilizes proper LOD models and yet rivals the low land impact of mesh that doesn't.

[ChinRey]

5 hours ago, animats said:

Overly large textures are becoming a non-problem. My experimental viewer only loads textures up to one texture pixel (texel) per screen pixel. If you have a giant texture on an object you're not right on top of,  the high-detail version of the texture will never be loaded. LL is putting that in their viewer. This is a huge win.

I have to disagree with you there, Animats - unless I misunderstand you that is.

No system is stronger than its weakest link and when it comes to textrue handling that is not the gpu. Bandwidth/cache retrieval time and/or VRAM capacity are usually the factors that limit how well SL can handle textures.

[EliseAnne85]

6 hours ago, Fluffy Sharkfin said:

I'd argue that almost every object looks "better" with 1024x1024 textures, but it's nothing compared to how amazing objects look when you use PBR materials with 4k textures.  However since we don't live in a world where hardware resources are unlimited and some residents are struggling with the requirements of SL already it makes sense to limit the available texture size to something less excessive. 

For tinies and Dinkies, since we are very small animal avatars, 1024's aren't always needed but, for the most part, most everything does look better in a 1024, except maybe scripted grommets on shoes.

I don't know how to do multi quotes so I will just address some of the things you said.

Yes, I know each region has limited scripts they can run but I find most lag occurs with heavily scripted things, especially Halloween with all it's "effects" and Christmas, too, with all the snow, twinkling lights, etc.  So, I'd say scripts have difficulties even if as you say they are "server side". 

As far as missing the original Lindens, SL was just better then  I can't believe the original Lindens who sold LL to this new company would recommend their viewer be set lower than FS's recommended 2.  The LL viewer recommends one set their LOD at what 1.175?!   This low load thing kills about half the objects in SL.  @ the Devs, this low viewer LOD isn't a good idea.  And, the new company is responsible for this horrible EEP, which is a hassle.  Granted, EEP is a bit better now than when the first viewer arrived but it's still a hassle.  Brights are too blown out or it's too dark or it's fiddle, fiddle, fiddle.  We just need a lighting that is easy to work and pretty.  Plus, ALM and EEP cause fan issues.  The fan issues are listed throughout this thread.  

As far as unlimited hardware, the new hardware or chips being made now are going to be energy efficient.  I don't know if energy efficient equals a "game" to be played on the computer like the new LL seems to want.  And, it does seem also the new LL wants SL to be turned into a game now.  

[animats]

6 hours ago, ChinRey said:

I have to disagree with you there, Animats - unless I misunderstand you that is.

No system is stronger than its weakest link and when it comes to texture handling that is not the gpu. Bandwidth/cache retrieval time and/or VRAM capacity are usually the factors that limit how well SL can handle textures.

OK, here we go with material that's a bit too technical for these forums again.

You don't have to load the entire texture into VRAM to show a lower resolution of it. You don't even have to load it over the network. JPEG 2000 lets you load a lower-rez version, reading only part of the file. The problem is that the LL viewers don't plan their loads very well. The texture detail loaded is based on a fraction of what's available in the source texture, not the actual number of texture pixels needed. What you want is roughly one texture pixel per screen pixel.

So we have too much texture detail loaded on some small objects, and not enough detail on big ones.

So this is one of the problems I worked on cracking in my experimental viewer. All Rust, all Vulkan/Metal, all multi-threaded. What you'd code today if not tied to legacy code.

I've posted this video before, of zipping around Port Babbage at high speed.

https://video.hardlimit.com/w/sFPkECUxRUSxbKXRkCmjJK

Understand what's going on here. All the textures for the whole region are not in VRAM at full resolution. They're being frantically loaded and unloaded from the GPU and memory by five background threads, which are changing the texture resolution loaded as the camera moves. This isn't just mip-mapping; textures are being inserted and removed into memory. Using Vulkan, you can do that from other threads than the main thread.

If you watch closely, you can see this happening. Watch the "Savoury Market" sign appear blurred, then snap into focus. Watch the vendors in the "Everyday clothing" store do the same.

This is from a warm cache - all the textures are already loaded. If the camera does not move, CPU usage is low, because it's all deferred rendering in Vulkan and the GPU is doing most of the work. When the camera starts moving around fast, the CPU load is keeping about 6 hardware threads busy.

This scene is using about 3.8GB of VRAM and 37% of GPU time on an NVidia 3070. I'm targeting gamer PCs here, with the goal of getting AAA title quality from SL on a machine that can get AAA title quality with games. LL has much lower hardware targets. 30% of SL users can't even run Vulkan, which was first supported in Windows 7. I'm targeting machines with an NVidia 1060 with 6GB (the 2016 model) or above. That's what the average Steam user has.

Now, from a empty cache, it's much worse.

https://video.hardlimit.com/w/vZ59tAjjL6kMmTnVC9NgWd

This needs to be sped up. The OpenJPEG JPEG 2000 decoder is too slow, and it's decoding the entire high-resolution image when it doesn't need to. Both of those problems can be fixed. There are additional improvements beyond that I have planned. I've discussed some of them elsewhere. There are ways to get rid of the grey.

For years, people, including some Linden Lab people, have been saying that SL couldn't have the visual quality and frame of an AAA game title. Over the last year, I've demonstrated that it can. This seems to have penetrated to LL management. They've hired more developers who understand modern game technology, and the LL-based viewers are, at last, improving.

[animats]

10 hours ago, Fluffy Sharkfin said:

"billboard" LOD models

I was pushing for billboard impostors a few years ago. I had an "impostor garden", with 3D objects and 2D impostors side by side. From a distance, they looked the same. Since this came up again, I put one of my old impostor demos on display today.

One stone lion has 1100 triangles. One has two triangles. Which is which? Go to my little park at Vallone/120/14/36 and find out. Can you tell without climbing into the fountain?

This impostor has 8 flat images, and it shows whichever one is facing the avatar. This is a proof of concept demo. It looks right only when no more than one avatar is nearby, because it's done with an LSL script which changes which face is displayed based on the nearest avatar.

For many objects, if they're more than 20-30 meters away, you can't tell if it's an impostor.

The images were made by putting the object on a turntable backed by a green screen and taking pictures in 8 orientations. Then the pictures go through a green screen program to cut out the outline, and are combined into one texture atlas.

To be useful, this has to be supported in the viewer.

[Fluffy Sharkfin]

43 minutes ago, animats said:

To be useful, this has to be supported in the viewer.

I'm all in favor of automatically generated billboard style LOD models, as long as they're optional.

There's no single workflow or solution for generating LODs that will produce the ideal models for every type of asset since what works best will rely to some extent on the assets intended use and while automatically generated billboards are obviously more preferable when compared to random floating triangles I'd still rather have the ability to make my own custom LOD models than be limited to auto-generated LODs simply because some people can't be bothered to do likewise.

Edited October 8, 2022 by Fluffy Sharkfin

[blissfulbreeze]

I did not read all the posts. Does SL plan on still making the viewer ALM only? Has Firestorm remarked on it?