Why beginners don't learn the basics first?

[OptimoMaximo]

10 hours ago, entity0x said:

yep, was just throwing out a number.  I have a simple avatar in use that only has 4000k

OH yes I know, I wasn't saying you do. But the point still persists, like a famous female body everyone uses, that has around 60k triangles per layer and an abomination of topology. 

[Wulfie Reanimator]

14 hours ago, entity0x said:

I have a simple avatar in use that only has 4000k

[Penny Patton]

On 12/10/2019 at 3:51 PM, entity0x said:

but being smug is all you will get for it.

Well, if you build your own environments in SL (whether it be your own small skybox, or a full RP sim) you also get to enjoy a relatively lag-less SL.

I've been building sims for years and they all rez faster, have little or no texture thrashing, and don't freeze up my computer every time I move my camera. And I'm constantly getting messages from visitors gushing because they enjoy those benefits as well.That right there is more than enough incentive for me to keep doing what I do.

 Seriously, I enjoy better framerates and less lag in my own sims on a ten year old computer than most people with brand new computers are likely to ever experience in SL.

Edited December 16, 2019 by Penny Patton

[ChinRey]

5 hours ago, Penny Patton said:

And I'm constantly getting messages from visitors gushing because they enjoy those benefits as well.That right there is more than enough incentive for me to keep doing what I do.

I have similar experiences. I once had a visit from a friend who complained about how laggy mesh was. So I reminded him we were standing in the middle of a whole town made from mesh and asked if he noticed much lag. He had to admit he didn't.

(What he actually said was "No, but you know how to make mesh" but I'm too modest to post that at the forums of course )

 

 

[OptimoMaximo]

On 12/16/2019 at 11:57 AM, ChinRey said:

I have similar experiences. I once had a visit from a friend who complained about how laggy mesh was

See the other thread from 2012 "how do I increase the detail of an object before upload", where someone suggested to use "subserf" modifier. The abomination though is that the most common trend still is "the object itself has to have all details like in RL" and the texture is seen as a secondary issue worth nothing more than mere color and baked in shading. This obviously leads to loads of unique full res textures (God forbid to reuse textures on similar components!) and together with a bloated list of vertices to display per object, any game from the same era and technology SL comes from would choke.

[ChinRey]

1 hour ago, OptimoMaximo said:

The abomination though is that the most common trend still is "the object itself has to have all details like in RL" and the texture is seen as a secondary issue worth nothing more than mere color and baked in shading.

Or as often as not, you have both escessive tris and pixels at the same time.

Personally I tend to prefer to add details to the mesh and use/reuse tilable textures as much as possible since texture overload tends to be a bigger problem than geometry overload. Usually you don't have to add many subdivisions though.

This is not a very good example for a number reasons but hopefully it still illustrates what I mean. The triangle counts for the LoD models of this canopy is 316, 45, 14 and 9, vertice counts 306, 58, 26 and 19. The physics model has 18 triangles. The three textures are all standard LL issued ones; two from the Nautilus content package and one from the Library. Resolutions: 128x128, 256x512 and 256x256. LI is of course well below 1, the LoD changes are barely noticeable with LoD factor set to 1 and the render weight is 1015.

If I ever upload it to SL (this is on the beta grid) I'll use better textures and I'll also redo the main model with more triangles for the canopy itself to get rid of that obvious edge in the middle and fewer for the framework. But those changes won't increase the load figures much and may actually reduce them slightly.

It's all about three very simple rules:

1. Use your brain and your eyes
2. Make the most of what you have
3. Don't fight your materials, work with them

 

Edited December 22, 2019 by ChinRey

[Wulfie Reanimator]

6 minutes ago, ChinRey said:

The physics model has 18 triangles.

Out of pure curiosity, what does the physics model look like? It's the one thing you didn't show!

Edited December 22, 2019 by Wulfie Reanimator

[ChinRey]

1 minute ago, Wulfie Reanimator said:

Out of pure curiosity, what does the physics model look like? It's the one thing you didn't show!

You'll notice that there isn't any physics for the canopy itself, only for the posts. That's deliberate, if people try to stand on a fabric canopy, they are suppsoed to fall through.

Come to think of it, maybe I should add canopy physics with normals facing downwards so you'd get some resistance but still fall through. The physics weight at the moment is only 0.7 so I can add that and more without increasing the LI.

[Profaitchikenz Haiku]

24 minutes ago, ChinRey said:

Come to think of it, maybe I should add canopy physics with normals facing downwards so you'd get some resistance but still fall through.

Better still, add a trampoline script and lob them halfway into orbit.

I was interested in your earlier statement about preferring to add details to the mesh rather than the textures because of the difference between geometry and texture loads, with the growing trend of using displacement and specular maps as well as a diffuse one it's becoming obvious just where the viewer weaknesses are for us poor mortals without SSDs and high-Ram PCs, the cache-to-grahics-card transfer is the biggest hit.

[ChinRey]

1 hour ago, Profaitchikenz Haiku said:

I was interested in your earlier statement about preferring to add details to the mesh rather than the textures because of the difference between geometry and texture loads, with the growing trend of using displacement and specular maps as well as a diffuse one it's becoming obvious just where the viewer weaknesses are for us poor mortals without SSDs and high-Ram PCs, the cache-to-grahics-card transfer is the biggest hit.

We don't have PBR (Physical Based Rendering) in SL, only some very basic implementations of normal and specular maps, so it's not really that relevant here. The one great thing about our nomral and specular map system is that it is optional so a good creator can make models that look good without and then add them as an extra bonus for those who have computer power and bandwidth to spare.

In general I don't think PBR is the solution for complex open online virtual environments as SL because all those surface maps add a lot of load on the bandwidth and VRAM, two of the narrowest bottlenecks in the rendering pipeline. It's different for more focused game enviroments with far fewer assets and for environment that aren't streamed but even for those, I have a feeling there's more than a little bit of PBR for PBR's sake going on.

[OptimoMaximo]

12 hours ago, ChinRey said:

We don't have PBR (Physical Based Rendering) in SL, only some very basic implementations of normal and specular maps

I'll repeat myself for the untempth time about this misconception: 

1) normal and specular maps aren't basic implementation level: their alpha channels contain data that should not dismissed or overlooked as useless or of lesser importance. First, because their alpha values are being read and used regardless of their presence, if no alpha was embedded, it's assumed to be of value 1 (opaque) anyway. Secondly, an object surface look can really vary only using those alphas values, giving the ability to embed multiple and different materials in one set of maps, opening the way to save on texture memory instead of increasing it. But this is meaningful only when glossiness and environment maps are actually there in the alpha channels, otherwise those empty channels don't contribute anything of value and yes, that's more of a resource waste. 

2) if it's true that SL doesn't use PBR for rendering, the material system appears to be thought to mimic a PBS shader, when taking in consideration those overlooked "useless" channels mentioned at point 1. There are basically 2 issues with the average user base of SL in this regard: the total lack of lighting in the scenes/Sims and the idea that the reflection has to be modulated via the specular map color intensity. The former flattens any attempt to use materials, the latter makes everything look like plastic. 

Following these guidelines and doing proper observations, I can convert PBR materials into correspondent SL materials using substance designer and a couple math nodes to reproduce the values conversions needed.  This is completely undocumented by LL and I had to go through a LOT of testing over the course of two years, when I had time. Substance Painter had a preset for SL but it was completely lacking (it sucked big time) , most likely because of the feature requester(s) lack of understanding in such regard, again completely missing the alpha channels maps. 

12 hours ago, ChinRey said:

In general I don't think PBR is the solution for complex open online virtual environments as SL

I disagree and agree at the same time on this point. As the current state of shader implementation in SL, I agree because the lack of a proper environmental skydome renders materials quite flat and don't allow them to shine in their full potential. The point on which I have to disagree is that the industry has turned over shaders to accomplish most of the otherwise very expensive features that modern games show off. The most common and easy to understand example is the parallax occlusion, the "fake" (and rather inexpensive) displacement. That allows to avoid insanely bloated vertex counts while giving a surface the look of a highly tessellated geometry. This is why I was so adamantly against BoM and advocating for development of the materials system: not only this would have allowed for a similar feature as BoM, just extended to any type of objects and not limited to avatar replacements, this would have opened the way to further development in the direction of optimizing the rendering pipeline and further development in the texturing field, removing the need for bloated polycounts and opening the way to more effects. It's a major project and requires high competence, which translates into a corresponding salary, and for these reasons I don't see this line of reasoning ever setting foot in to LL. 

12 hours ago, ChinRey said:

I have a feeling there's more than a little bit of PBR for PBR's sake going on.

Indeed, PBR has become the choice in the industry because, compared to the other shader models, is less expensive in terms of computation, memory use and allows for a greater range of features. The fact that is also more reliable in different lighting setups is an added value to a shader model that was conceived to ease the material creation process with consistency in its maps value ranges while using the smallest memory footprint for such driven attributes. Metallic, roughness / glossiness, ambient occlusion and height maps are assumed to be Grey scale images, meaning 1 channel each, and are more often than not embedded in one single rgba image. And the most modern engines also use the normal maps B channel (which is always full white, basically empty and wasted resource) to embed a specular intensity map to simulate reflectance at normal (a fresnell attribute), reconstructing the normal map afterwards. 

To summarize it all up: with proper development, materials can be the future of SL, LL's will to invest in anything its doom. 

Edited December 23, 2019 by OptimoMaximo

[ChinRey]

4 hours ago, OptimoMaximo said:

1) normal and specular maps aren't basic implementation level

I suppose I have to clarify then. I wasn't saying normal/specular maps were "basic" in themselves, the way they are implemented in SL is. You gave most of the reasons yourself so I won't go into details.

 

4 hours ago, OptimoMaximo said:

To summarize it all up: with proper development, materials can be the future of SL, LL's will to invest in anything its doom. 

With proper development, maybe. But... ummm... No comment

Even so, we have to consider the sheer amount of maps required. That's not a major issue for a game environment optimized on scene level but in an open Sandbox worl like SL it can be very significant. Imagine 2000 different materials, each with five 1024x0124 resolution four channel maps. 20 GB to download, 40 GB of VRAM required, that's tough even for the strongest gamer desktop.

[OptimoMaximo]

1 hour ago, ChinRey said:

. Imagine 2000 different materials, each with five 1024x0124 resolution four channel maps.

Hhmm nope. Even with the max number of maps possible, we would end up with 3 textures per material: environment in the specular = metallic and ambient occlusion in the normal maps blue channel. As I said in another thread, a proper development would start implementing a proper mip mapping system. The one we have now is a joke and it can't be considered proper. 

1 hour ago, ChinRey said:

With proper development, maybe. But... ummm... No comment

OH no, please DO comment! I try here to read your mind (actually it's mine but let's pretend) : LL is not inclined to proper development, they always fold over patchwork as largely demonstrated by BoM, animesh and the only resemblance of proper development from scratch represented by EEP (which is a mess yet and not even remotely near to something releasable). Indeed I stated that LL's will to invest (=proper development) is SL's doom. We all know that such will is equal to or lesser than zero.

When I say proper development for materials, I mean to create a dedicated asset, so to compress textures in binary format, creating a new marketable asset type with much lower streaming cost, instead of leaving the component textures floating as they are, in which case you'd be right estimating such download sizes. With such type of asset, a material weight would be so negligible to allow layering and ease a mip mapping feature implementation. Of those 2000 materials you were talking about, maybe 20 or 30 might be in range to be calculated at full resolution, the others would stay mipped until the viewer gets closer (mipping the previously full resolution ones on display). Ah well, it's just a dream, LL would never apply such workforce and funds. 

Edited December 23, 2019 by OptimoMaximo

[Kurshie Muromachi]

10 minutes ago, OptimoMaximo said:

Hhmm nope. Even with the max number of maps possible, we would end up with 3 textures per material: environment in the specular = metallic and ambient occlusion in the normal maps blue channel. As I said in another thread, a proper development would start implementing a proper mip mapping system. The one we have now is a joke and it can't be considered proper. 

I would be curious to see this laid out in a table. I know where you're going with this and it's exactly what I've been pondering. There's gotta be a way to minimize the number of textures within SL by utilizing the channels and organizing them in a way so that maps that aren't detail critical could be grouped to take advantage of smaller dimensions. Is the JPEG2000 format an ideal format to really be using now that we're years ahead from since then? I believe that's what's being used for mipmapping if I'm not mistaken.

[Kurshie Muromachi]

@OptimoMaximo Nevermind the previous post... somewhat. I'm not a content creator but I've read a "bit" about PBR here and there. I was curious to see your table layout because I thought there may have been some loss in explanation. My lack of knowledge though. I didn't see Roughness mentioned but found from another forum post that the Specular Exponent is more or less the inverse of Roughness in PBR.

Now, my question is why the loss of the Normal Map's blue channel for AO? Is it really not needed? Is there data to prove that it is not needed or is it just that SL doesn't actually use it or use it well? I'm finding little info on this.

Is AO really needed if proper AO post-processing was done in real-time considering the nature of SL's dynamic lighting?

[ChinRey]

35 minutes ago, OptimoMaximo said:

Hhmm nope. Even with the max number of maps possible, we would end up with 3 textures per material: environment in the specular

That's still three textures per "face". So 12 GB file downlaod and 24 GB VRAM then - it's still a lot. It works now partly because there aren't usually that many surfaces that use normal and specular maps in a scene, partly because they optional so a user can switch them off if their computer and internet connection can't handle the load.

 

52 minutes ago, OptimoMaximo said:

As I said in another thread, a proper development would start implementing a proper mip mapping system.

Server side mip mapping would help a lot. Server side baking to create last resort static textures estimating the effect of the maps would also help. There are also several other things that could be done to make an "SL friendly" PBR but I don't think adopting Unity/UE4 style PBR style directly is good idea. It's important to keep in mind here that PBR is not a fixed set of features. It's a concept that can have different interpretations and implementations. To put it simple, it's about focusing on cause rather than effect: Rather than replicate the color a certain spot on a surface has, we try to replicate the mechanisms that gives it that color. (Incidentally, there are to elements of the common PBR interpretation that should be relatively easy to implement, should be very valuable and won't require additional maps: The Fresnel effect and microsurface scattering.)

 

1 hour ago, OptimoMaximo said:

OH no, please DO comment! I try here to read your mind (actually it's mine but let's pretend) : LL is not inclined to proper development, they always fold over patchwork as largely demonstrated by BoM, animesh and the only resemblance of proper development from scratch represented by EEP (which is a mess yet and not even remotely near to something releasable). Indeed I stated that LL's will to invest (=proper development) is SL's doom. We all know that such will is equal to or lesser than zero.

I don't think it's about willingness, it's about ability. LL has very limited developing resources and spending more in that field isn't likely to increase their revenue enough to cover the extra expenses. The developers also have to be very careful to maximise backwards compatibility to avoid offending estabished users and they are fighting against a horrendously convoluted code crammed full of unintended and undocumented dependencies (or as Ebbe put it: "too much spaghetti in the code"). LL also has a very strong tradition favoring free standing projetcs over concerted strategies and although that has improved a little over the years, it's still very much part of their corporate culture. You see how slowly even those less-than-ideally-implemented projects you mentioned have evolved. It's not because the developer aren't any good, it's because they're working under extreme conditions.

On top of that the idea that anyybody can be a builder is still a very strong element in people's perception of SL and it's a very important (albeit increasingly dubious) sales argument. LL simply can't aford to let go of it, they have to cling on to the sad shattered remains of an idea that once was the core of SL's success. You say it took you two years to figure out how normal and specular maps work in SL. Imagine how it would be for somebody with little or no modelling experience at all to deal with an even more complicated system.

[Wulfie Reanimator]

19 minutes ago, ChinRey said:

That's still three textures per "face". So 12 GB file downlaod and 24 GB VRAM then - it's still a lot. It works now partly because there aren't usually that many surfaces that use normal and specular maps in a scene, partly because they optional so a user can switch them off if their computer and internet connection can't handle the load...

...but mainly because everything is streamed from the hard drive when needed, not constantly loaded into memory. 

[ChinRey]

1 hour ago, Kurshie Muromachi said:

There's gotta be a way to minimize the number of textures within SL by utilizing the channels and organizing them in a way so that maps that aren't detail critical could be grouped to take advantage of smaller dimensions.

You can even merge all the maps into a single file with a dozen channels. It's hard to find software that can handle such files though.

 

1 hour ago, Kurshie Muromachi said:

Is the JPEG2000 format an ideal format to really be using now that we're years ahead from since then?

JPEG2000 is SL's internal image format. No matter what format you upload, it will be converted to JPEG2000. As for its suitability, it's a 22 year old format specially made for photos. I think the reason LL chose it was that it cupports but lossless and lossy compression. These days you hardly ever see textures with lossy compression though so yes, I think it's redunant. Whether this is important enough to justify the considerable work it would take to change to a different format is another question.

 

15 minutes ago, Kurshie Muromachi said:

Now, my question is why the loss of the Normal Map's blue channel for AO? Is it really not needed? Is there data to prove that it is not needed or is it just that SL doesn't actually use it or use it well? I'm finding little info on this.

Keep in mind that normal maps isn't a new invention. The concept dates back to 1976 and the map variant we are familiar with was introduced in 1998. The blue channel is essentially a height map, dark blue pixels are embedded into the surface, light blue above it. These values can of course be calculated from the red and green values of adjacent pixels but back then it was decided to be more efficient to encode them into the map rather than get the viewer software to do all the math.

[OptimoMaximo]

2 hours ago, Kurshie Muromachi said:

didn't see Roughness mentioned but found from another forum post that the Specular Exponent is more or less the inverse of Roughness in PBR.

Specular exponent is another way to call glossiness and glossiness = 1/roughness, in other words the inverse. I found out through experimentation that it actually needs to be squared to work well with the exponent slider in the texture tab. 

2 hours ago, Kurshie Muromachi said:

Now, my question is why the loss of the Normal Map's blue channel for AO? Is it really not needed? Is there data to prove that it is not needed or is it just that SL doesn't actually use it or use it well?

It's not SL itself. A normal map blue channel is always filled with white, as the tangent z axis of a vertex or face should never be bent and the bumping effect is given by distorting the pixels' x and y tangents. This is done in various engines that, for this very reason and to allow the use of the blue channel for other purposes, offer a dedicated node to rebuild a normal map from just r and g channels (see Unity and Unreal normal map reconstruct and Maya bump 2d node). If you just feed a material with a  precomputed AO you save a lot from rendering it realtime, with better control over its spread. Moreover, AO in PBR is used to lower the specular intensity in the darker area, for obvious reasons: the shaded areas receive less light. Looking up materials on the SL wiki will give you a couple of tables for better understanding the channels encoding. 

2 hours ago, ChinRey said:

microsurface scattering

Which is the roughness, so we already have that in firm of its inverse. I can send you a couple of things to show you if you like. Fresnell would be great though and the environment map already is suitable for such a thing. 

 

2 hours ago, ChinRey said:

To put it simple, it's about focusing on cause rather than effect: Rather than replicate the color a certain spot on a surface has, we try to replicate the mechanisms that gives it that color.

It's not really correct, but I'll leave it at that as it would be too long an explanation for my time at hand right now. 

And yes, I know what the problems are at LL with their code and such, but I keep standing by the fact that their net revenue allows them to spend time, funds and work on this side of things. The thing is that they don't want to, SL is their cash cow to fund project idiot-in-goggles and will let SL die as soon as project VRMoron becomes even remotely profitable. 

Edited December 23, 2019 by OptimoMaximo

[ChinRey]

Just now, Wulfie Reanimator said:

...but mainly because everything is streamed from the hard drive when needed, not constantly loaded into memory. 

Yes, as long as you stay in one place and don't mingle with strangers carrying textures in your cache. I'm convinced this is a major reason why there isn't more mobility in Second Life.

[OptimoMaximo]

6 minutes ago, ChinRey said:

The blue channel is essentially a height map,

No, that's the green channel usually and it's a sort-of height map. The blue channel is always pure white, for the reason explained in my previous post

[Kurshie Muromachi]

3 minutes ago, OptimoMaximo said:

If you just feed a material with a  precomputed AO you save a lot from rendering it realtime, with better control over its spread. Moreover, AO in PBR is used to lower the specular intensity in the darker area, for obvious reasons: the shaded areas receive less light.

I see. That seems to make sense for the PBR side of things. But don't you have to account for objects close to one another that are from separate creators? If they precompute their AOs for a single given object, the AO isn't aware of close proximity objects that someone else made. In other words, AO is aware of self cavities, but not objects (from separate creators) touching one another. SSAO handles this sort of scenario but then it conflicts with the baked AOs.

[ChinRey]

17 minutes ago, OptimoMaximo said:

No, that's the green channel usually and it's a sort-of height map. The blue channel is always pure white, for the reason explained in my previous post

I suppose somebody should correct the wikipedia article and Unity's online manual and the other sites on the internet that says otherwise then. They all stubbornly claim red rotates the normals on the x axis (horizontal on the texture plane), green on the y axis (vertical on the texture plane).

But anyways, what's important here is that the blue channel is redunant today and can be reassigned to other purposes.

[ChinRey]

43 minutes ago, OptimoMaximo said:

It's not really correct, but I'll leave it at that as it would be too long an explanation for my time at hand right now.

Yes, I said it was a simple explanation, maybe I oversimplified.

Here's a fairly good introduction to PBR for those who want to learn more: https://marmoset.co/posts/basic-theory-of-physically-based-rendering/

Edited December 23, 2019 by ChinRey

[OptimoMaximo]

40 minutes ago, ChinRey said:

They all stubbornly claim red rotates the normals on the x axis (horizontal on the texture plane), green on the y axis (vertical on the texture plane).

That's what I said. They both bend the x and y tangent space normals, while the blue channel refers to the z axis and can't be bent as its orientation is determined by the modified orientation of the former two and therefore it is pure white. That's why I said the green channel is sort of a height map. It's similar looking, but it's different.