Lumpy Tapioca

I'd buy that for a L$

// I use this KVP wrapper in every script now. It's surprisingly fast, even at full clock rate for animation, // and all variables are available for easy external debugging, by name. Often, I can eliminate using any native SL variables, // with little to no impact on execution speed. // It's not type safe and you can mess up, but it implements pointers and an easy, persistent cross-script variable pool // makes for much simpler code once you get used to it. // Setting and examining the contents of any and all variables from the command line or other scripts is a godsend. // F_( ) is write, F() is read. _F() is a pointer (returns the value of the value), which I didn't define here for simplicity // add these 8 lines: float F(string name) { return (float)llLinksetDataRead(name); } integer I(string name) { return (integer)llLinksetDataRead(name); } string S(string name) { return llLinksetDataRead(name); } integer B(string name) { if(((float)llLinksetDataRead(name)) != 0.0) return TRUE; return FALSE; } float F_(string name, float value) { llLinksetDataWrite(name,(string)value); return value; } integer I_(string name, float value) { llLinksetDataWrite(name,(string)((integer)value)); return ((integer)value); } string S_(string name, string value) { llLinksetDataWrite(name,value); return value; } integer B_(string name, integer value) { llLinksetDataWrite(name,(string)((integer)value)); return value; } // now you can do S_("name","lumpy"); // assigns "lumpy" to a new variable "name" llOwnerSay(S("name")); // prints lumpy // and S_("query", "name"); llOwnerSay(_S("query")); // also prints lumpy or F_("pi", 3.14159); and F_("two_pi", F("pi") * 2.0); // and llSetText(S("pi")); // prints without having to typecase to (string) (always remember that everything is really a string, watch your precision) - Lots more to this. matrix math, mult/add, lists, delete, search. sort, trig, increment/decrement/double/half... -- That's enough for now.

"Fakery created through stealing others content." Another great description of Second Life.

"Essentially taking a 3d render, passing it into some AI filters" No, and this is key. Not passing a picture, but the actual complete geometry and textures of the scene, then rendered from your camera's point of view. Less to mis-interpret, more cues about shadows and light from things hidden from view. The AI renderer would know something is metal not because it looks metallic, but because it's defined as metal. It would know exactly where the lights are by definition, not inference from how an image looks. Way better. I've not seen this done before.

"however there is also a significant lack of control and hallucinations that can't ever be fully eradicated" A perfect description of Second Life.

Four years. One year for AI still snapshots.

(I know that this is a few years too soon, and saying AI makes people roll their eyes...) The future of SL isn't GLtf or raytracing or $3000 worth of Nvidia on your desk, and most of the world that already exists will never be retrofitted into PBR or whatever follows. This is the only path forward. Use the current SL view, take what the current renderer is fed (geometry and textures and avatars), and feed it as a seed/scene description to a real-time server-based AI renderer, that streams your view back to you, making this largest collection of 3D assets ever created look like the reality we're chasing for over 20 years. It would work magic even with our 20 year old builds, making them look new again. Because you would be feeding it actual geometry, it would work way better than "A castle on a lake, with birds overhead", like we do now with AI image generators. What's the workflow now if you wanted to go out dancing as JKF and Marylyn Monroe? Hunt for avatars, pay for them, make them fit and work correctly, hope that JKF and Marylyn from different vendors look compatible.. Many steps that are difficult at best and nearly impossible for beginners. This vs. "Make us look like JFK and Marylyn. Put JFK in a white tux, Marylyn in a red sequined floor length dress." Done, and better. SL has so much user interface surface area with its sea of buttons and sliders. That's hard for people, especially in the new mobile app. The only way mobile can work today is with a cut down UI that is "less", and turns SL into more of an off-the-rack strip mall Disney hangout than the open creative building environment we have today. We've seen attempts like those fail again and again or just limp along for a year until the users and funding dry up. Sure, an AI will hallucinate, but SL has always been a hallucination anyway. We'll always be chasing reality, but downloading 2K textures and a ton of geometry per frame won't scale much past where we are. - A whole new everything - No more fixed loop walk animations and dancing. Reflections that don't require tricks. Realistic weather with the look and feel of real air and rain and wind (snow that accumulates!!!, water with realistic waves!!!) The best thing will be the element of surprise and discovery in a world that is no longer static and frozen. And sure, it'll all be run up on servers, but it's always been doing that. Lag is an issue with remotely rendered games, but c'mon, it's SL we're talking here. Lag is not a deal breaker for us. We're patient to a point. SL Marketplace vendors may lose some markets, but better builders and better geometry provides a better feed to the real-time AI renderer. There's a boundless new frontier for creators, and all of the old stuff will look new again. It may be some years off, but Linden Lab could start today, taking an SL scene, the actual geometry not a picture, and have an AI imagine/render a still image from the data. Some people think of Ready Player One as the gold standard of what the Metaverse will be. Real-time AI rendering is the only way to make that happen. -- that is all

How are these skies "PBR"? Different from all other skies?

All of this may be totally wrong. - Contrary to rumors, PBR works well and can look fantastic. -- On a new object, you need to take two steps: texture it in old (phong) world first, then add the PBR materials. The PBR is a replacement layer that *replaces* the old world texturing *if the PBR is defined*. "It's gray" happens if you skip the first step. A PBR material doesn't get down sampled into a phong material. -- The PBR "material" well and the companion Save button in that dialog are your friends. The Save button makes a material from the entire set of PBR textures and values. Use it early and often. Build up your material toolbox with a single click. A thing I do often: Tweeze a material, then "Save" it to inventory, click the material well and in the dialog, select "None" (that surface appearance now falls back to phong texture), select the material well again, and load that material that you just saved. Else, you may see a phantom material re-appear after editing and your changes gone. Maybe that's only me, or some bug I hit. - PBR alpha and glow are separate and distinct from phong alpha and glow (mostly). Setting Transparency and Glow and nothing happens to your PBR'ed thing? That's why. Use the Emissive texture in PBR to get things to glow. - Full Bright is also different and separate in PBR, but is an affront to humanity and should never be used. On the sort of plus side, full bright/Emissive can be defined with a texture now, and PBR glow only glows (mostly) against that Emissive texture. (and that Emissive texture can be manipulated separately with a script! All four PBR textures can do that. New!! Yay!!!) - Second Life light is NOT REAL LIGHT! Throwing up a bunch of lights blows out the subtle benefits of PBR. Things can only get as bright as (1.0,1.0,1.0) full white. The lighting and shadow simulation only works if "light" has some place to go. Dim your stuff down. Reserve about 20% of the top brightness to give light something to make brighter. Helps with shadows too. - Avoid editing a material on an object with a running script, especially ones that are modifying surface appearance. Weird persistence/caching bug things happen often when I don't. Return of the Zombie Material. Maybe I'm using llSetLinkPrimitiveParamsFast() too aggressively? Stop the scripts, edit appearance, then restart. Save yourself some grief. - Not PBR, but while I'm on the topic of editing... Something I still mess up after 20 years here: Don't edit scripts in live objects. Delete the old script from the object, edit a fresh copy out of inventory, and then drop it on the object to test. Unlike other programming platforms, in SL the one copy of your code can fly away, never to be seen again. Poof. Gone. Not returned. It still bites me from time to time. - To get good shiny fun, use reflection probes, but use them in a fixed location, not attached to an object or avatar. Rectangular reflection probes have a direction, with (6 sides with 4 orientations) 23 of them "wrong". "Wrong" will give you Inception levels of fake reflection upside-down-backwards-ness. You may like that. But knock it off with all the mirrors. Yeah, they sort of work ok, but you're killing fps. Try it, be impressed and disappointed, then move on. - And again, Second Life light is NOT REAL LIGHT, is NOT RAYTRACING, and is NOT a physics simulation. PBR is a parlor trick that's all about fake lighting dynamics. Showing restraint on light and texture brightness gives the best results. Test against several different skies. You may be surprised at how the PBR shader interacts with various sky lighting. Use Beacons and show "Bounding boxes for lights" to see how far you're casting light. Turn down "radius" to adjust it to spread only as far as needed. Two lights (usually) won't make things twice as bright, and full bright isn't bright and doesn't "emit" any light into the scene. Avoid except for special cases. (Please deliver us from rooms where the walls, floor, and ceiling are set to full bright) For better control, avoid using point lights and instead, drop a white circle on black gobo texture in the projector well to make a spotlight. You'll get less spillover, more control, and PBR shader underneath knows about those lights and responds well to them. -- that's it.

Everyone's inventory should include a Linden Standard Materials Library. Cover the basic metals, plastics, stones, wood, and glass. Indexed in folders. But that's it. Just the fundamentals, nice and clean. Under 100 or so. 50 even? Set the maps permission copy/mod/open, to facilitate learning, exploration and use. (hey SL21B moles out there...) In the early days of MIDI, there was an industry standard set of instruments so you could share compositions... they wouldn't sound perfect, but close enough for the '80s. A writer always knew there would be drum voices on ch10. Same idea. Please don't build them into menus (like our old bump maps), use the inventory tree, but standardize the names so they are recognizable and easy parsing for scripts: SML_mat_steel_1A, SML_color_maple_2B and SML_normal_maple_2B, SML_mat_mirrror_23E, with SML_refl_brushed_1A A vendor could do it, but it needs to be a ubiquitous Linden thing. - Good things will happen, in a better looking world.

The SL and Firestorm viewers water and skies look completely different, especially with how reflections appear. My water under Firestorm looks great but the newest (late 2023) SL viewer makes those settings almost invisible, and just wrong. Is it too early to tweeze water and sky? Will Firestorm inherit the SL viewer's meh water shader? Anyone have an inside track on where and when water and sky are headed?