Jenna Huntsman

There isn't a texture by default. The visible sun is actually a bloom effect which is modulated by the cloud layer and environmental fog level.

I do! I'd recommend anyone interested in PBR to give Material Maker a try. It's free, open source and there's plenty of tutorials available on YouTube that can give you some training to get you started.

PBR doesn't affect this. The examples you see online are flat textures for simplicity, as the idea is you'd get that texture and paint it onto a model in (Insert your favorite 3D program here). Here's an example of the UV islands at work in the base colour map (Not a particularly exciting map, but it's the cleanest example I've got) The AO map is, indeed, separate. It is applied at the viewer's discresion, so if the scene lighting makes sense to have a shadow in a given area, the map will be applied. This means that you don't get persistent shadows where they don't make sense.

The background in the mud image is likely an HDRi (A HDR image used in-leiu of an actual scene to get accurate reflections), but the actual surfaces are maps.

I'm not going to post anything from within the SL PBR test, as things are still rolling pretty fast and so things aren't consistent there. But what you want to be looking at is stuff like this: Both of these aren't really possible with the current workflow. Sure, you can make a rusty-looking metal texture, but it'll never interact with light correctly. You can make the metal shine, but then the rust will shine along with it (which is wrong), or you can make the metal matte, which makes the rust look correct, but the metal surface will be wrong. The water / mud example is another good one as it demonstrates scene reflections, which the current SL release version does not have, instead having an extremely bad "environment" map, which contains none of objects or lighting from the scene. A couple of examples from the scene you screenshotted can be: Brick texture is painted on (No normal map), and has baked AO (Will look incorrect at any sky setting other than a midday scene with no nearby light sources) Windowsill texture has no depth or sense of material change (As the paint has flaked off in areas, the base wood underneath will interact with light differently from the paint above it) The window glass has no specular from the scene light sources, and has no reflections. (Glass produces very sharp reflections!)

The alpha channel is contained within the Base Color map (Aka. Albedo), or essentially the PBR version of a traditional Diffuse map (there are differences, but not relevant to this question) Looking at that screenshot, the reason why it looks bland is that there's only an ambient light source, alongside it seems like a lot of the materials are designed to look the same. Bit of a poor example if you ask me. Not so much easy as consistent. The problem with creating content for SL right now is that outside of the diffuse map, it's hard to get any consistency with an external creation tool, meaning material maps go largely unused as it is often too hard to create them (and have them look good across a variety of users / viewers with widely varying graphics settings), so most creators create for the lowest common denominator (Those who disable pretty much every graphical enhancement from the past 10 years), so a lot of the content in SL looks bad. PBR goes a long way to fixing this.

No, because you can use the Occlusion map in PBR to get the shadows instead (Part of what LL are calling the "Metalness-Roughness map", but the industry standard term is "ORM").

Any viewer based on the Linden 6.6.3 + codebase will have the perf. improvements. That includes the latest version of Firestorm. *maybe*, although forward-rendering has been "depreciated" in LL's eyes for a while. It's been getting fixes as-and-when needed, but it was never going to be upgraded with any new features; so any improvement is a happy coincidence.

This is actually incorrect - existing normals can be applied to PBR materials, if wanted - in fact, most will look better as a result of being in the correct tangent space. SL currently uses an older tangent space called Lengyl space, whereas the entire industry moved on to MikkT space mapping near enough a decade ago. SL is now getting support for MikkT space, and this is to be applied to Legacy and PBR content (At least, that is the plan at time of writing)

To add on to this, there are additional performance improvements in the PBR viewer, as well as some that are in-development and should be merged prior to release. From what has been said, I understand that attempting to do PBR in the forward renderer (i.e. non-ALM) would destroy your framerate, especially on lower-spec computers.

The answer is that there isn't an answer. The minimum specs on the SL website have long been out-of-date. If you tried to run SL on a computer built to those exact specs, chances are the viewer wouldn't even run. We're also talking about software that's still in development, so I could say anything, and it could be completely false tomorrow. From what I know, the only "minimum" requirements are (that have any kind of solidity, anyway): Hardware support for OpenGL 4.X Core profiles (On Windows, and presumably Linux) Hardware support for OpenGL 3.X Core profiles (On Mac)

PBR in this sense means the game-engine interpretation of PBR, not PBR in the context of something you might find at a scientific lab or at a university. The latter would be way too slow and too complex for pretty much all users. LL's idea is that SL's PBR will be on par with that of game engines, such as Unreal Engine or Godot. There's a few caveats here and there that creators will need to pay mind to (Some of these will go away in time, as more software adds glTF support), but nothing major.

I can't speak for everything, as the market is huge, but I believe for most major brands (Think LeLutka, Catwa, Maitreya, eBody, etc) all of their content should work properly. I don't have every single body / head to test, but I can say that a LeLutka / Maitreya combo works with zero issues.

Yes* Provided they have been made correctly, no. In fact, they should look better than before. * this is such a broad question, and with so many things that are still not set-in-stone I can't really be more specific.

These won't be supported at launch for PBR, namely because they don't form part of the base glTF spec. Legacy materials will continue to work as they do today, albeit with some fixes and some non-breaking changes. There will be some things where a legacy material is deemed preferable, for example, if you use a specular map to tint the colour of reflected light, as the implementation of PBR at launch cannot do this. (That's not to say it won't ever be able, but the PBR at launch is targetting the base glTF spec, not any of it's extensions, which may be implemented at a later date)

I can actually clarify on this: Materials editor UI is still WIP, so any images you see of it are STC. Channel mapping is correct. Normals no longer have an alpha channel, and we don't use a specular map with PBR materials. Double-sided materials are now supported (So, we no longer need extra geometry to render both sides of a plane) Tangents is an ongoing discussion; but everything is planned to transition to using MikkT space normals (as, this is what most content creation tools have been exporting for years), so existing normals should be more faithful to their source content. Pricing is correct (assuming you're not a premium plus user), however it's unlikely that users need to use all 4 textures often, so the average price of a PBR material is L$ 30. Inventory import is working, ish. There's still some lingering issues. Hopefully these will be solved by the time PBR gets a public test viewer.

Just to build off this, here's an example material which I quickly made for some PBR testing - this is an example of the process of converting a conventional diffuse texture into a PBR material. It's worth noting that this is using photo-based normals - this isn't ideal, as photo-based normals are entirely based on guesswork. Normal maps should be created by baking a high-poly model onto a low-poly one, but for this item photo-based generation works well enough.

Protip: Learn Material Maker It can do the photo-based generation of Normal maps that you're describing, but it can also make PBR materials which will be compatible with Second Life when PBR hits the grid.

*whistles* Things are about to get exciting.

Fancy new-fangled technology that allows objects to reflect the scene around them (see the below example, particularly the windows!)

That operation is going the wrong way - if you want the result to be a list, use llCSV2List

You may want to look at the following LSL functions (If writing yourself): llSetSoundQueueing llPlaySoundSlave llLoopSoundMaster

This is no longer true of recent viewer releases - there's been plenty of JIRAs filed against 6.6.3 < viewers where users' computers were overheating; due to increased usage of resources.

If the device is actively cooled, then you're likely okay. If it's passively cooled, then.. I wouldn't buy it if SL factors in your decision.

In terms of getting an animation to reliably run, you're better off using a looped animation and have the script check the avatar's animation list every now and then to confirm that the animation is still running. You can optimize that script a lot more, but in terms of the issue at fault, the approach is the issue (From reading the script, you're using a non-looped animation and retriggering it every time the animation ends, which is wildly unreliable).