Orange/Encoded Normal Map Support?

http://wiki.polycount.com/wiki/Normal_Map_Compression

I’m confused I guess also with how this fits into three. I’d like some kind of a hook where I could do npm install normal-dxt5nm and just plug it in. I don’t want to have all this code imported by default if I’m making a demo that doesn’t even use normal maps for example. My company has no need for normal maps, but with the last upgrade we got the extra dead code for it by default.

onBeforeCompile will break material cloning functionality too. This is also confusing because I don’t want to chose between one or he other (able to clone materials, or use my normal map logic).

2 channel ones are for tangent space only (at least i’ve never seen them used in object space), since it’s about restoring z which isn’t necessarily required, but can’t be restored for free either. I don’t see an issue here.

It’s always AG?

Yeah nothing confusing. Would be cool if threejs actually used geometric tangents instead of that on th fly stuff :slight_smile:

They could be stored in any channel, but it’s not only about which channels, the one i use from Far Cry ensures better quality with least cost (how z is stored/restored, i use it for post processing).

You know a fiddle/pen isn’t a pull request :yum: but sometimes it might be only required for a single case/effect and really isn’t worth integrating it, that is what gives onBeforeCompile reason to exist at least, but this is rather for hacking an already assembled code again with regex again, not that regex is bad for extending code features, but inserting lines at some specific positions is really dirty by assuming code to identify it, and of course all the string allocations parsing that can be done much cleaner at least for the big chunks.

@pailhead
Maybe that’s clearer :yum:

#ifdef LOLonly2channels

@Fyrestar Out of curiosity (this is all off topic) why do you give so much weight to regexes? In your fiddle, could you say it’s merely swapping out a key with a value?

The regex is only necessary because the structure is a string. But it’s not doing anything too complicated, since it’s operating on the template and not the GLSL code itself.

Ie. what’s a different way of viewing something like this:

I could see it as

[
  'u_foo',
  'u_bar',
  '<pars_foo>',
  '<pars_bar>',
  '#MAIN',
  '<foo>',
  '<bar'>',
  someValidGLSL,
  '#WRITE',
  '<baz>'
]

To overcome some of the limitations of onBeforeCompile you could monkey patch this into the ShaderChunk, the normal map logic is the most contained, normal in normal out. Since it’s being controlled by defines anyway, you wouldn’t have to use regexes at all.