Make texture offsets work the same way for phong and PBR textures
closed
HereToHorse Resident
Texture offsets for phong and PBR textures work differently now. If you apply a phong texture and offset it, then do the same thing with a PBR texture, you'll end up with a different result. The PBR Y axis texture offset (but not the X) must be inverted in order to display the same area of the texture.
In a similar vein, when you scale a phong texture it stays centered. Scaling a PBR texture "zooms into" the top left corner of the texture, instead.
The attached images showcase both issues. In order to display the white part of the texture, phong requires a <-0.25, -0.25, 0> texture offset while PBR requires <0, -0.5, 0>.
As an example of why this is a problem, think of a chess game that has all its piece textures in a single texture atlas. Each tile on the board is a separate texture face, and you can choose which piece is in which position by adjusting the offsets for each face. Since PBR offsets work differently, if you want to add PBR support to this game you'll be forced to add additional code and use more memory to change the different offsets. As keeping both texture sets synced is a must, this means extra work for developing and maintaining this kind of code, while also adding to the extra memory load required to handle PBR textures in a script.
Making offsets and scaling work the same way for both PBR and phong would make this sort of scripting much easier.
Log In
Spidey Linden
closed
Hello, and thank you for your feature request.
Incoming suggestions are reviewed in the order they are received by a team of Lindens with diverse areas of expertise. We consider a number of factors: Is this change possible? Will it increase lag? Will it break existing content? Is it likely that the number of residents using this feature will justify the time to develop it? This wiki page further describes the reasoning we use: Feature Requests
This particular suggestion, unfortunately, cannot be tackled at this time. However, we regularly review previously deferred suggestions when circumstances change or resources become available.
We are grateful for the time you took to submit this feature request. We hope that you are not discouraged from submitting others in the future. Many excellent ideas to improve Second Life come from you, our residents. We can’t do it alone.
Thank you for your continued commitment to Second Life.
RestrainedRaptor Resident
Spidey Linden Can you please provide a reason why this was closed? See also: https://feedback.secondlife.com/feature-requests/p/answering-to-our-feedback-before-closing
Honey Puddles
Alternatively, offer us something akin to DEG_TO_RAD and RAD_TO_DEG for converting between these two standards in a more simple way.
offset = <0.25, 0.75, 0>;
pbrOffset = offset * PHONG_TO_PBR;
or something?
I feel like this is going to turn into some maddening math if there's scaling and rotation involved that's changing..
Maestro Linden
under review
Kristy Aurelia
I believe the glTF standard specifies that the textures need to be mapped this way so they either have to make it not conform to the standard, making glTF compatible imports not compatible, or change legacy materials to match, breaking all existing content.
HereToHorse Resident
Kristy Aurelia Understandable. In that case, perhaps there could be some kind of script function to automatically take this into account and sync up the texture settings (scaling/offset/rotation) between gltf and phong? (or simultaneously change both)
Admitedly it's not too hard to just handle this manually, but anything that removes the extra busywork caused by this would be apreciated. It feels unnecessary and adds to the extra memory cost from scripting PBR materials.
Qie Niangao
HereToHorse Resident It's not exactly trivial by script, either, as one resident recently discovered: https://community.secondlife.com/forums/topic/510811-programmatically-convert-between-gltfpbr-texture-coordinates-and-legacyblinn-phong-coordinates/#comment-2714912
but we at least need boilerplate LSL functions in the wiki to handle this —and to translate between glTF coordinates and llDetectedTouchUV (and -TouchST, maybe)
Also, manually, this will be a lot easier to handle when https://feedback.secondlife.com/bug-reports/p/pbr-why-arent-scale-rotation-offset-outlined-on-the-object-surface-when-adjustin is fixed
HereToHorse Resident
Qie Niangao Good lord, I didn't know there were more complications. I feel like this calls for a proper solution, yeah.
Honey Puddles
This difference is absolutely maddening when doing any kind of scripted texture positioning/scaling/rotating.