✨ Feature Requests

  • Search existing ideas before submitting- Use support.secondlife.com for customer support issues- Keep posts on-topicThank you for your ideas!
Prim flag to suppress interpolation of position, scale, and rotation
Although interpolation and movement smoothing are generally A Good Thing, there are many situations where it is distracting and undesirable behavior because the change represented is supposed to be instantaneous. In these cases, the visibility of the motion impinges on the convincingness of the situation, leading to either a threat to the user's suspension of disbelief (for objects in-world) or a reduction in the perceived quality of the product (mainly for HUDs.) Personally, I find this happens a lot when repositioning HUD elements that were previously off-screen; particularly annoying are cases where the final state of an element is, due to rounding errors, imperfect. But it can also happen with in-world objects that are meant to suddenly appear or move, such as a door that snaps between open and closed positions (and unintentionally tweens through a space it shouldn't), or an "instant" forcefield that actually takes a half second to stretch to the intended size. In these situations, interpolation causes "jank," which is not in-line with the goal of presenting users with a polished, modern virtual world. The interface for this would probably be something like: llSetPrimitiveParams([PRIM_INTERPOLATE, <TRUE/FALSE>]); which would default to TRUE. Ideally, if a child prim has PRIM_INTERPOLATE set to FALSE, then movement applied to the entire linkset would still cause interpolation for even that child prim. If this is inconvenient to implement on a per-prim basis, then a simpler per-object basis (maybe a new llSetStatus flag?) would also be very usable.
2
·

tracked

Rigged meshes does not support Glow effects. Layer Stacking
Greetings This has been a bug for nearly 2 years now since all the recent FPS gain viewer updates and forward. ~I thought it may have been reported and hoped it would be fixed over the viewer updates, But now after 2 years i am here to file this report. This only seem to affect Rigged Meshes,. Unrigged prims/meshes are unaffected by this issue. Steps to produce the issue: Blender, create a cube and rig it to SL Skeleton... any bone lets say (mChest) for this test Copy the Cube 2 times and make each cube slightly bigger than the other. So we create a layer stack. SO Base / Middle and Top layer. So 3 seperated meshes intotal Export and upload the Rigged cubes to SL Now in SL. The Base layer can be left untouched Middle Layer, Set it to a color and assign a glow and give it some transparency lets say 0.5 glow and 0.5 Transparency The Top layer, Assign a Transparent texture >>> Give it a Default Normal map >>> And blank specular map Now activate Animated mesh on it and you will then see the glow does not shine through the very top layer. Solution to avoid glow being eaten.. Is to remove the Normal Map from the top layer, for some reason then the glow on the middle layer shines through. This bug does not affect default unrigged prims but does however affect rigged meshes. Can this be fixed please. This may even resolve the alpha blending issue on layer mesh stacking in SL Provided some image on information on bug within SL
3
·

tracked

Re: HDRI Preview feature and future wishes
I just tried the HDRI Preview feature. I did love the effect it had on the environment light, but using the HDRI I tried with (the one initially recommended by you at LL for PBR work) did cause a field to be drawn on the sky dome, which looks really funny and out of place... screenshot attached with a view from an unenclosed skybox. In my case, a simple sky-and-maybe-clouds texture there would probably be better. I'd love to see this feature evolve to where one is able to upload an EXR or HDR file and apply it to the environment. I'd also love to see the feature evolve such that... The light from the HDRI is kept but the rendering of the image on the dome can be disabled. This effect is possible to set in both Blender and Substance Painter for example, also an option to blur it. In conjunction with the above feature, combining the use of an HDRI and the animated cloud texture we already have today, and the clouds should of course cast shadows! This would be great especially when you have very small or no clouds in the HDRI texture when you choose to keep it rendered. I'd love to be able to have one HDRI above, and another one under sea surface. Combining this with the previous mentioned features could allow for really cool effects under water! The ability to set one HDRI for environment light, and a separate HDRI for "texturing" the dome. Setting this texture to a built-in Transparent texture (or a new one like that for HDRI) could be the mechanism to cause the first-mentioned feature of hiding the image of the HDRI on the dome, only keeping its light. Without the above few features, I wonder if this feature would end up only really being good when you're taking photos. Hope this makes some sort of sense... Thank you! =)
1
·

tracked

Load More