Physically based rendering, and all that

[Nicky Dasmijn]

More of the "all that" ....

@animatsI am curious if your client is open source/you are willing to share the source?

[Fluffy Sharkfin]

9 hours ago, Coffee Pancake said:

Maya, which is $1700

Not to drag this thread off-topic with a discussion of the pros and cons of various software (which is a pointless endeavour since we all know it's the results that matter not the tools used) but Autodesk now provide an indie license which allows access to the fully featured application for around $260 a year (as long as your annual earnings are below $50,000).

That being said it doesn't detract from the fact that Blender is by far the most obvious choice (and I say this as someone who doesn't use Blender beyond opening .blend files and converting them for use in other applications), it's versatility, focus on community-driven development and the fact it's already been so widely adopted by SL content creators make it pretty much the only option if LL were looking for an application to "endorse" by providing documentation, tutorials or even possibly plugins to help aid in the creation of content for SL.

[animats]

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

Video of Port Babbage with the Animats experimental viewer. Same system which produced the stills above.

[Mollymews]

6 hours ago, Beq Janus said:

The external toolkit is not entirely alien as a concept, consider Robolox Studio. I don't think it is a viable product for SL as the effort needed to maintain it barely justifies it. We struggle enough to find viewer developers, let alone people willing to throw their spare time into a toolkit. Roblox has the advantage of having very deep pockets.

 

i think that Linden should make this

all of the technical platforms that can host virtual worlds have content editors (in whole or part). Unity, Unreal, Roblox, etc. As you have shown

no doubt when the new wave metaverse offerings (Meta Facebook etc) arrive then so will they have content editors. If Linden can't afford to do this now, then how will they be able to afford it later when the competition really ramps up ?  If the answer is never then  is all pretty much oh! well

in the oh! well case then a path forward is third party development. A way to fund this path on an ongoing basis is already available - LGPL 2.1 license. The content editor can be designed to use plugins. As such the plugins are proprietary to the plugin developer, they can, if they choose, sell their plugin and they don't have to release their plugin code

example plugins

Make a dress for Maitreya. Make a pair of pants for Jake Belleza. Make hair for Lel Evox. Make a Tree. Make a Waterfall. etc

[Extrude Ragu]

Bit of a bump but Inara Prey was talking about PBR development in LL viewer the other day

What interests me the most is proper environment reflections, which means metals will be able to look metallic without baking on fake metallic effects and mirrors will look somewhat more mirrory - (although it remains to be seen if the viewer will reflect the avatar since it's using a map baked by the viewer).

The image posted in the blog shows the propeller of a plane - But that makes me wonder, since this is using so-called probes with automatically generated environment maps within the viewer, how will the new viewer handle moving metallic objects such as a plane? Would it be generating a new environment map every single frame? Seems like a lot of new CPU load for the viewer.

With that said, I find it somewhat confusing - There is talk of adding 'PBR support' to the viewer, but my understanding is that we already have a form of PBR support, specifically the Specular/Gloss workflow. We're able to modulate specularity using the RGB channels of the Specular image and Gloss using the Alpha channel of the Normal Map.
 

From SecondLife Wiki - Material Data

So I wonder therefor what they really mean when they say they are adding PBR support.

Perhaps they just mean supporting the Roughness/Metallic Workflow?

It would be interesting to see how they implement that. In theory, that would reduce the number of texture channels needed from 4 (Specular RGB Channels + Gloss Channel) to 2 (Roughness Channel/Metallic Channel). Implemented right, you could actually reduce the texture memory usage in the viewer, for example you could channel pack the Roughness into Diffuse Alpha and Metallic into Normal Alpha, and forfeit using a Specular map completely, achieving almost the same quality of materials in SecondLife, using only 2 textures instead of 3. It would mean that objects that use alpha have to use the old Specular workflow though, which I think is a good tradeoff honestly.

[arton Rotaru]

3 hours ago, Extrude Ragu said:

Bit of a bump but Inara Prey was talking about PBR development in LL viewer the other day

What interests me the most is proper environment reflections, which means metals will be able to look metallic without baking on fake metallic effects and mirrors will look somewhat more mirrory - (although it remains to be seen if the viewer will reflect the avatar since it's using a map baked by the viewer).

The image posted in the blog shows the propeller of a plane - But that makes me wonder, since this is using so-called probes with automatically generated environment maps within the viewer, how will the new viewer handle moving metallic objects such as a plane? Would it be generating a new environment map every single frame? Seems like a lot of new CPU load for the viewer.

With that said, I find it somewhat confusing - There is talk of adding 'PBR support' to the viewer, but my understanding is that we already have a form of PBR support, specifically the Specular/Gloss workflow. We're able to modulate specularity using the RGB channels of the Specular image and Gloss using the Alpha channel of the Normal Map.
 

From SecondLife Wiki - Material Data

So I wonder therefor what they really mean when they say they are adding PBR support.

Perhaps they just mean supporting the Roughness/Metallic Workflow?

It would be interesting to see how they implement that. In theory, that would reduce the number of texture channels needed from 4 (Specular RGB Channels + Gloss Channel) to 2 (Roughness Channel/Metallic Channel). Implemented right, you could actually reduce the texture memory usage in the viewer, for example you could channel pack the Roughness into Diffuse Alpha and Metallic into Normal Alpha, and forfeit using a Specular map completely, achieving almost the same quality of materials in SecondLife, using only 2 textures instead of 3. It would mean that objects that use alpha have to use the old Specular workflow though, which I think is a good tradeoff honestly.

Nope, the current shader is a so called legacy specular-gloss shader (well, at the time LL implemented it, it was the standard workflow in game design. Since PBR has taken over, it's called legacy). Despite the similar terminology, PBR is something completely different, even for the Specular/Gloss PBR workflow.
The LL plan is to import PBR materials via glTF. They will end up as a single inventory asset that can be applied to prim faces.
Which specific maps will be supported is TBD. For sure there will be Albedo(Diffuse), Normal, and RGB channel packed Ambient Occlusion/Roughness/Metalness. So that's 3 maps. Just the same as with our current legacy material workflow.

Edited May 7, 2022 by arton Rotaru

[Extrude Ragu]

35 minutes ago, arton Rotaru said:

The LL plan is to import PBR materials via glTF. They will end up as a single inventory asset that can be applied to prim faces.

Just looked up the specification for glTF 2.0. 199 pages long 😨

[arton Rotaru]

3 minutes ago, Extrude Ragu said:

Just looked up the specification for glTF 2.0. 199 pages long 😨

🤪

For now maybe this might be of some interrest:
https://www.khronos.org/blog/art-pipeline-for-gltf

However, since there hasn't been any work started yet, I won't hold my breath untill this gets relevant for SL.

[Dahlia Bloodrose]

@animats  Do you have a Patreon or other way we can support your work?  Are you planning to open source it at any point?  

[animats]

13 minutes ago, Dahlia Bloodrose said:

@animats  Do you have a Patreon or other way we can support your work?  Are you planning to open source it at any point?  

Don't need money. Too early to say how this develops. I'm working towards a demo version, with login, move, view, and local text chat, but not much else.

[Dahlia Bloodrose]

3 hours ago, animats said:

Don't need money. Too early to say how this develops. I'm working towards a demo version, with login, move, view, and local text chat, but not much else.

My apologies, for real.  I made the offer without doing any research and now that I have, I hope I didn't insult you.  

[bigmoe Whitfield]

5 hours ago, animats said:

Don't need money. Too early to say how this develops. I'm working towards a demo version, with login, move, view, and local text chat, but not much else.

need a tester

[animats]

6 hours ago, bigmoe Whitfield said:

need a tester

Probably in the fall.

[Love Zhaoying]

On 4/25/2022 at 6:21 PM, Mollymews said:

i think that Linden should make this

all of the technical platforms that can host virtual worlds have content editors (in whole or part). Unity, Unreal, Roblox, etc. As you have shown

no doubt when the new wave metaverse offerings (Meta Facebook etc) arrive then so will they have content editors. If Linden can't afford to do this now, then how will they be able to afford it later when the competition really ramps up ?  If the answer is never then  is all pretty much oh! well

in the oh! well case then a path forward is third party development. A way to fund this path on an ongoing basis is already available - LGPL 2.1 license. The content editor can be designed to use plugins. As such the plugins are proprietary to the plugin developer, they can, if they choose, sell their plugin and they don't have to release their plugin code

example plugins

Make a dress for Maitreya. Make a pair of pants for Jake Belleza. Make hair for Lel Evox. Make a Tree. Make a Waterfall. etc

Wouldn't a content editor negatively impact and alienate creators, who drive the SL economy?

[Wulfie Reanimator]

On 4/26/2022 at 1:21 AM, Mollymews said:

On 4/25/2022 at 6:20 PM, Beq Janus said:

The external toolkit is not entirely alien as a concept, consider Robolox Studio. I don't think it is a viable product for SL as the effort needed to maintain it barely justifies it. We struggle enough to find viewer developers, let alone people willing to throw their spare time into a toolkit. Roblox has the advantage of having very deep pockets.

 

i think that Linden should make this

all of the technical platforms that can host virtual worlds have content editors (in whole or part). Unity, Unreal, Roblox, etc. As you have shown

The existence of those editors Unity and Unreal have (along with Roblox and Sansar) is because the world will eventually get "compiled" into its own static-ish environment. SL doesn't have this step, so an external editor like those is unnecessary.

If we still were to separate the build tools from the current viewer, what would be the benefit? Would the viewer performance increase significantly? Could we have more advanced tools that we couldn't otherwise?

What about the cost? How much time would it take to create and maintain these separate viewer releases? Would we no longer be able to do something as simple as tint an object without relogging to this "build viewer" or "builder?" (Without scripts anyway.. would those be written in the builder too?)

It should also be noted that those external editors don't replace programs like Blender and Photoshop. The majority of developers still create most assets elsewhere and then import them to these external editors. SL has one step less.

Edited May 30, 2022 by Wulfie Reanimator

[Mollymews]

3 hours ago, Wulfie Reanimator said:

If we still were to separate the build tools from the current viewer, what would be the benefit? Would the viewer performance increase significantly? Could we have more advanced tools that we couldn't otherwise?

What about the cost? How much time would it take to create and maintain these separate viewer releases? Would we no longer be able to do something as simple as tint an object without relogging to this "build viewer" or "builder?" (Without scripts anyway.. would those be written in the builder too?)

It should also be noted that those external editors don't replace programs like Blender and Photoshop. The majority of developers still create most assets elsewhere and then import them to these external editors. SL has one step less.

 

is not suggested to do away with the existing viewer build tools. They are perfectly fine as they are, for what they do.  This is about meshes

channelling my inner Stimpy. Maybe or maybe not do it

if the answer is maybe then why ?

SL avatar assets have to be rigged in a way peculiar to SL

LOD models are also done in a way peculiar to SL

a third one is making models SL physics compatible

then additional things like UVs, PBR when it comes, etc. All done in the SL way

i think the underlying why is that SL assets to perform well, have to conform technically to the ways in which the region server and viewer best function. And I think such a program is a way for Linden to standardise creative technical conformity that best suit the region server and the viewer

the program renders the asset in the exact same way as the viewer does. Can flip the view between Build mode and Display mode. What you see is what you will get inworld when upload

any deficiencies or suggestions for improvement to assets can then be done formally thru the JIRA. Instead of how it is now, done informally thru various other channels that Linden staff frequent on topics that are not formal JIRA material

i also think such a program needs a plugin interface, so that 3rd parties (residents) can monetarise their plugins (or not as they choose)

 

[Mollymews]

7 hours ago, Love Zhaoying said:

Wouldn't a content editor negatively impact and alienate creators, who drive the SL economy?

am not sure that making it easier to make stuff is a negative.  Is not so much about the technicals, is about the art of making

like I can make a way better vehicle that many other people from a technical perspective. it will outperform and out run anything else on the grid, and crash a whole lot less on region crossings than any other competing vehicle

only issue I have with my mighty grid crushing, destroy all challengers vehicle, is that is a box with the sandpaper texture removed. brmmm !! Which doesn't have a whole lot of commercial appeal to people who like bling. Yanno bling! like wheels and wings and stuff 😺

[Coffee Pancake]

A this point, building a SL Preview plugin for blender is far simpler than building blender in the SL client, even if that client doesn't log in or have social tools (which due to the way the viewer works, would actually be a huge amount of work - the viewer is a 3d dumb terminal, no more).

[Sammy Huntsman]

Not gonna lie, I wish the lab would hold creators accountable for not optimizing their items. I mean video game companies don't even use overly high poly items in their games. 

[Coffee Pancake]

8 minutes ago, Sammy Huntsman said:

Not gonna lie, I wish the lab would hold creators accountable for not optimizing their items. I mean video game companies don't even use overly high poly items in their games. 

Being able to use over poly hyper detailed items is literally the whole point of UE5. 

Triple A PC gaming has a very high poly budget, SL stuff, on the whole, isn't bad. It's just bad for SL.

Go play some current games they are way more detailed than SL most of the time, object density and clutter is though the roof, lighting is breathtaking and it all runs with a smoothness and stability we can only dream of.

[Sammy Huntsman]

2 minutes ago, Coffee Pancake said:

Triple A PC gaming has a very high poly budget, SL stuff, on the whole, isn't bad. It's just bad for SL.

That is what I meant, High Poly and SL don't mix. So when you have creators who don't optimize their mesh, it can get kinda annoying and laggy. 

[Coffee Pancake]

3 minutes ago, Sammy Huntsman said:

That is what I meant, High Poly and SL don't mix. So when you have creators who don't optimize their mesh, it can get kinda annoying and laggy. 

That's the problem though, it's not the mesh itself. It's the systems required to deliver the mesh and get it on screen. The time cost of rendering the actual mesh in the grand scheme of things is pretty insignificant.

At thins point punishing creators is neither appropriate or conducive to LL's goals.

[Sammy Huntsman]

5 minutes ago, Coffee Pancake said:

That's the problem though, it's not the mesh itself. It's the systems required to deliver the mesh and get it on screen. The time cost of rendering the actual mesh in the grand scheme of things is pretty insignificant.

At thins point punishing creators is neither appropriate or conducive to LL's goals.

Than LL has to overhaul their current rendering system. 

[Wulfie Reanimator]

2 hours ago, Mollymews said:

This is about meshes

Oh okay. Ignore my ramblings. ♥️

[Coffee Pancake]

13 minutes ago, Sammy Huntsman said:

Than LL has to overhaul their current rendering system. 

We've been saying that for a decade, and even louder and with greater urgency since Apple announced they were depreciating OpenGL, but here we are.

We need a complete and fully multithreaded overhaul to the asset fetch render pipeline, and we needed it years ago. This is a huge project and would take a significant amount of time to implement and test, it is well beyond the scope of any unfunded 3rd party viewer project (even the mighty FS).. and now you know why we don't have it.