Comments (9)
I see. Is there any elegant solution to this? When developing new shaders I used an unfinished "layer" system for a moment, where each layer could have only 1 UV set, and we could have all kinds of maps assigned to one layer. I also wanted to make an ability to add multiple layers with different blends over each other. But it would break old mapTransforms in old projects.
As a workaround, I decided to convert mapTransforms to layers by analyzing if there are equal transforms at the moment of shader creation and grouping them into 1 layer (and 1 varying).
But the downside of such idea was that once the shader is compiled, you can't dynamically change mapTransform of one texture without affecting all other textures that shared the original transform at generation time. Or you should recompile the shader when changing mapTransform a few times at runtime. In the end I just dropped the idea and returned all map transforms back.
That's it...
- can we drop mapTransforms and replace it with something better performance-wise? (I guess no, projects will break)
- should we allow users to create UV transforms in UI and assign them to maps? We may also allow users to use position as UV and other funky stuff. But maybe it would be too complex and unusual for users?
- if we're just leaving mapTransforms as they are now, we then have to silently couple multiple equal transforms in one, as I tried. Should we compile multiple shaders instead of just one in case if user decides to dynamically change transforms after original shader generation? Should we recompile the shader each time any transform changed (not great)? Should we transforms maps in PS by uniform when no varyings available? This will make it a dependent read though...
from engine.
Actually, since we recompile & cache on any serious material change, the best option for now would be to check transform equality of different maps, and recompile if it's changed.
from engine.
Here's another suggestion: if you run out of varyings, disable normal mapping and print a warning to the JS console. At least you are then almost certain to have enough varyings since you can drop the binormal and tangent. And at least the program will link and the mesh will render (albeit not quite as prettily). I'm not saying I like this option, but it's better than what we have currently.
can we drop mapTransforms and replace it with something better performance-wise?
What did you have in mind?
But maybe it would be too complex and unusual for users?
It depends on the interface. I can't quite visualize what it would look like.
Actually, since we recompile & cache on any serious material change, the best option for now would be to check transform equality of different maps, and recompile if it's changed.
Yeah, this is probably the way to go for now.
By the way....I did just look at the GLSL generated for the floor plane in the project. It has 9 varyings:
- vPositionW
- vNormalW
- vTangentW
- vBinormalW
- vUv0
- vUvDiffuse
- vUvNormal
- vUvOpacity
- vUvSpecular
It looks like vUv0 isn't needed. You could use a temporary instead. I guess at the moment, the linker isn't able to drop vUv0 because it's kind of being used.
from engine.
OK, I'll fix it. So the total list of stuff to add is:
- use 1 varying where transforms have equal value;
- remove vUv0/1 when these aren't used;
- disable normal/parallax mapping when we exceed varyings and print a warning.
from engine.
I would say it would be best to remove uUv0/1 where possible first (as the top priority because it's easy to fix).
Ultimately, it's a question of the engine doing something sensible in every case when there are only 8 varyings possible. A failed program link must always be avoided.
from engine.
I just ran into this recently on an iPad 2 (pretty old at this point). Shader results in too many varyings. If you look at base.frag, you guys recently commented out vVertexColor. Could you also comment out the other varyings not being used? Specifically vUv1 and vNormalV. There's a comment at the top about the compiler removing unneeded stuff, but I don't think this always applies to varyings.
from engine.
@guycalledfrank I just wanted to completely understand the current status of this in the engine. Am I right in saying this is still technically an issue? What are the circumstances where the number of generated varyings can still exceed 8?
from engine.
@guycalledfrank is this still an issue, or have been addressed? This ticket been stalled, and shall be at least updated or requires a closure.
from engine.
Closing due to age. I have not seen any shader compilation/linking issues relating to a lack of varying in the last few years.
from engine.
Related Issues (20)
- Standalone engine extras import failed
- Changing opacity of transparent material forces shader recompilation HOT 6
- WebXR direct hand input HOT 2
- Docs: update normals in mesh example
- Anim Blend Tree takes incorrect name HOT 1
- Some WebXR examples throw error when refreshed HOT 2
- Add support for the XR emulator HOT 2
- Mesh collider no longer scales in real time HOT 1
- Weighted Blended Order Independent Transparency HOT 1
- Anim Blend Tree accessor override
- Anim Blend Tree 1D weights issue
- Debug bundled ESM engine build fails to build with Vite HOT 2
- Source map shows incorrect scope HOT 5
- Copy-Paste folder HOT 1
- Examples - build step takes progressively longer each time
- Camera non-default viewport size ignores camera clear color HOT 1
- Compute shader enhancements
- Engine requires Node 18.0 to build
- Simplify Gizmo code geometry generation
- Allow using geometry to generate collision shapes
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from engine.