I see that in the threejs shaders, there are include statements such as:
uniform float scale;
I’m not trying to be too esoteric here, but I was wondering if anybody could think of a reason for me not to use es6 template strings?
Just a personal preference (I like that I have intellisense for the possible includes), but thought I’d ask in case there were unforeseen problems with this.
(In general, regarding templates, keep in mind that you still have to use uniforms for any dynamic values though. Changing variable value in JS won’t change it on the GPU unless you recompile the shader.)
i wish three did this, it would help tree shaking and create explicit contracts between shaders and their parts. i believe currently our bundles always carry the full shader lib, even if you effectively use 1% of it, everything is pulled in. (last time i checked that was the case at least). also makes understanding shaders/reading code really hard because the material classes are just empty shells that are magically filled in later.
If a user writes a custom material by including built-in shader chunks and the material should run in older browsers like IE11, it’s not possible to use ES6 syntax. So the engine needs a backwards compatible way to resolve shader chunks.
I personally don’t care that much about the tree shaking problem – in most cases I’m going to use threejs from cdn as you’ll get a decent percent of users getting from cache. three weighs in at less ~160kb which is amazing for what it does.
still quite big compared to things like ogl (around 20kb). instead of cdns and script tags professional front end web dev revolves entirely around modules (node modules), they mostly expect things to work on slow internet connections which has gotten a much bigger issue with folks coming from countries where fast internet isn’t guaranteed.
This seems like a fairly straightforward change. Besides tree-shaking improvements we could also remove the functions from WebGLProgram.js that @mjurczyk linked above. @Mugen87 you are more familiar with this part of the code, are there any potential issues here?
Yes, but in the long run, there might be better ways of doing that than using .replace. Seems like a very fragile and unwieldy approach. Would it be possible to have a way to redefine includes like beginnormal_vertex instead?
On the other hand, my attitude towards anything like this in the current material system has just been “wait for node materials to replace it”. So I’m not gonna expend too much effort here.
wouldn’t they construct a shader in the exact same way as three would, only without string templates? if the argument is that three doesnt want to break “# import”, ever, then that’s the way it is - but i dont understand the internet explorer thing. it’s not about templates, even if three concetenates strings - that would be good enough. the problem is the “import” thing, which forces it to bundle all shader code.
Node materials are bad for performance, memory and to maintain, the cost of this is way higher than using .replace and is rather suited for beginners or non-programmers, asides of the work with this increasing drastically compared to simple code. It’s kinda the THREE.Geometry of shader, which is why i not understand why this would be preferable. As a optional feature it makes sense but really not as the default approach.
Patching works perfectly fine, the real issue is rather the missing consistency across all the standard materials, this would be doable to add a more consistent structure using comments asides of the includes, but so far it is already quite consistent, considering the most needed entry points.
The way THREE currently basically uses “includes” is much better than pre-assembling just everything as it makes patching of features that should be separated not possible anymore (asides of blowing up the files with redundant codeblocks). The string of a built-in material is very small currently thanks to these includes what makes patching easy and fast.