✨ Feature Requests

  • Search existing ideas before submitting- Use support.secondlife.com for customer support issues- Keep posts on-topicThank you for your ideas!
Request: Experience-gated post-process shaders
This is an attempted "Shaders in Secondlife" request from a different angle. I want to try to assemble a reasonably scoped, definable approach that a small dev team could realistically implement in finite time. I think most requests try to boil the ocean. This might not be best merged with other shader requests. It's a specific subset spec... ( See Language, Shader Contract, Effect Mask sections ). Shaders as a fully optional parcel or region experience. Problem Second Life is a single renderer trying to be every renderer for the game dev/creator resident. The set of real-time techniques available in SL is bounded by the requirement that a technique be either universal or absent. The mechanism to fix this exists everywhere else: let creators write a screen-space post-process pass, scoped to a place, opt-in per user. Non-goals These are excluded, not deferred. The design depends on their exclusion. No avatar or attachment shaders. Nobody else's avatar affects my render loop. VRChat allows this, it's very common, very powerful, and has serious performance implications. If we want it in SL, make it a separate feature. No material or surface shaders. That is a separate proposal. This is a fullscreen pass only. No compute shaders, storage buffers, atomics, or image writes. Fragment shader only, let the GPU dispatch the work. This eliminates an infinite variety of inscrutible future conflicts. No precompiled binaries. Assets are source text and the viewer is the compiler. Permit only assets declared in the manifest, subject to normal permissions. Accepting binaries runs too many risks (and is too much for LL to automate a red-team). No guarantee of pixel-identical output across GPUs. A custom viewer can disable any of this. Language Adopt WGSL and use Tint (from Dawn ) as the front-end. Dawn (and Tint) were originally Apache 2.0. Dawn was changed to BSD 3-Clause License a few years ago, which better matches SLV's LGPL. It has a decade of browser-adversary hardening, and emits GLSL, HLSL, MSL, and SPIR-V from one source. Shader contract One fullscreen fragment pass, executed after scene render and tone-mapping, before UI composite. Input scene_color | texture_2d<f32> | Post-tonemap, linear scene_depth | texture_2d<f32> | Linearized 0..1, a resolved copy effect_mask | texture_2d<u32> | R8Uint. Channel 0 through 7, where 0 is untagged history | texture_2d<f32> | Previous frame's output. Always bound; cleared on effect star samp | sampler | Viewer-owned, clamp-to-edge, linear filtering args | Args | Uniform. 16 vec4<f32> of creator parameters tex0..tex3 | texture_2d<f32> | Up to four manifest-declared texture assets env | Below. struct Env { resolution : vec2<f32>, // offset 0 time : f32, // 8 delta_time : f32, // 12 camera_pos : vec3<f32>, // 16 vec3 aligns to 16 near : f32, // 28 camera_fwd : vec3<f32>, // 32 far : f32, // 44 sun_dir : vec3<f32>, // 48 fov_y : f32, // 60 frame_index : u32, // 64 } struct Args { v : array<vec4<f32>, 16>, } Effect Mask Without pixel identity, a fullscreen pass can only ever treat the scene uniformly (eg, whole-screen toon shader). Mechanism: A 3-bit channel per face, values 0 through 7, where 0 means untagged. The viewer writes it during the existing geometry pass. The post-process pass reads it. Creators set it through the build tools and through LSL, exactly as they set a texture or a material. #Experience The Experience system provides a named responsible owner, grid-wide revocation (suspend the Experience and every effect under it dies), a consent flow users already understand, per-user blocking, and parcel scoping. LSL surface integer llSetScreenEffect(key agent, string effect_name, list params); integer llUpdateScreenEffectParams(key agent, list params); integer llClearScreenEffect(key agent); Effects clear automatically on region crossing, on teleport, on Experience revocation, and on watchdog trip. (GPU timer query around the pass, rolling median over N frames. If measured cost exceeds the declared ceiling by a fixed factor for a sustained window, the pass is disabled, the user is toasted, and the asset is blacklisted for the session.)
1
·
Rendering
Make physics work over sim borders
Optically you can see from a region to the next one - the sim border is invisible. Physically though the next region does not exist until you travel over the border between the recent region and the next one. Let's suppose you are traveling by boat. If you hit a pier in a region, your boat is bounced back. But if you hit a pier located on the next region reaching until the region's edge, your boat first travels over the sim border and suddenly gets caught in the pier bouncing like crazy. Suggestion: the physics engine of each region should also load (render?) the physical shapes of the neighbor regions borders, which are pointed to the region, so a vehicle is bounced back and does not enter the next region where it is blocked by some object. Advantage: physical experience would be far more natural, collisions on sim borders would not be special. Since it is very common to build right until the sim borders, this is issue not a trifle at all imo. Vessels that have a damage system responsive to collisions (to make sailing more challenging) use to sink immediately when hitting these sim edge builds (since being caught on an object causes plenty of collisions in a very short time), while they would only take some damage while hitting the same build from the other side. This particularly is annoying, if there is a very tiny or even invisible object on the sim border, so you have no chance to recognize it before your ship suddenly sinks for no obvious reason.
60
·
Rendering
·
tracked
Mesh with physics, fluttering clothes, hair, and accessories
Now the mesh in sl has no physics at all, you wear stiff clothes, with stiff hair, as you walk, the fabric stretches against your body into strange shapes, when you sit down, your long hair will bend 90 degrees to fit your legs. everything is very stiff. When i see those long flowing hair and those fluttering gorgeous skirts, i miss the good old days. Even though they look messy sometimes, but that's intuitive. But the prims is behind the times, everything is in mesh now. Why not give mesh physics too! Mesh greatly improves the quality of props in sl, but it loses the most intuitive physics, they just look good, but once they move, they will reveal their flaws. This is just like how people used to paint gloss on textures, only viewable from the front, otherwise it will be a mess. Now we have the advanced lighting, PBR, make objects looks more and more real, there's one step left, that is mesh physics! Imagine a cute girl with long flowing golden hair, wearing a flowing dress, dancing gracefully, her hair and clothes fluttering with dance, how beautiful! You must watched MMD dances! fluttering, inertia, collision, make MMD dances lifelike! SL need mesh physics, we can dance in sl like MMD! Many similar games already have these physics effects, but sl has not yet, please! If we have mesh physics, how to deal with rigged object is a problem. Could we make old items physics-enabled with edit? Or only the authors can handle it to release a update? What tools could authors use? There's really many problems.
17
·
Rendering
·
tracked
Load More