User posts Aludev
21 September 2021 08:33
Just in case someone finds this useful, here the link to the bug report:

It seems to be fixed already, I will test once the update is available.
20 September 2021 08:41

We have been using B4W for a few years now, and didn't feel the urge to change as it worked really well.
We use version 17.12, because the latest 18.05 introduced some performance problems, but other than that no problems until the day.
We know as well it has been a while without updates nor movement around here, but maybe there are some people that may be able to help us.

The fact is that the new iOS 15 update makes the application crash, and it seems to be something related to the webgl shader.
We have been testing around, though low level GLSL is not precisely our thing, and we have obtained some insights.
The main error from B4W says: Shader compilation/linking error: postprocessing/postprocessing.glslv, postprocessing/postprocessing.glslf, materials: ""
Throwing some logs around, we see that at the "init_shader" function, "gl.getError()" returns a "INVALID_OPERATION" after "gl.linkProgram".
Then, "gl.getProgramInfoLog(program)" shows a not very useful but human readable error: Internal error compiling shader with Metal backend. Please submit this shader, or website as a bug to
We will submit the bug there just in case, and if this post receives some kind of response I will copy here the link to it as well for reference.

We have been trying to mess with the shader, apparently everything is correct but they must have changed something on the way the process it and even removing all "postprocessing.glslf" logic (leaving only an assignment to a plain color) won't work.

Here you can find a link to our main app with a slightly modified version of the B4W engine, just to show extra debug logs on console:

We hope somebody can help us, please.

Best regards,
21 March 2017 11:23

Thanks for the response.
I tried that flag, but didn't work.
I am quite sure it is some kind of bug with this specific GPU.
Damn Chrome, it was going so well…
20 March 2017 14:06
Hello there,

Just in case you didn't know about this, we have two Mac computers to test B4W and with the latest Chrome update to version 57 one of them does not render WebGL (no demos, not even
Both use AMD Radeon HD Graphics cards, the one that works is 6970, the one that doesn't is 6750, which I would say is the only remarkable difference.
It was working perfectly until now, Safari and Firefox still work well.
I just wanted to share the info with you guys, maybe you fint it useful.

Great work with the last release by the way!
16 January 2017 11:04

Indeed, I use the API to change values and RGBs, but we developers always want more
Glad to hear you are planning to work on it, I hope it doesn't cause you guys so much pain as it looks!
13 January 2017 13:44

I know this is an old thread, but the first/main question is exactly what I have been trying to achieve, so I wanted to ask.

The material I want to copy or reuse has a node-tree. The target object has a simple/other material as default. I observed that the inherit_material() function only copies the standard material params to the new object.

Is there anything (or plans to do it) for that?
My main objective is to have a library of objects/scenes to load dynamically, and instead of reexporting them with new materials (kind of heavy work and useless duplication), just export the main environment with a material container, so the rest of the objects can inherit different materials from it.
Exploring the current "inherit_material" function, still copies only simple properties and some fixed textures, nothing about nodes.
It would be nice to have the material container with, for instance, Copper and Velvet, then transfer to new objects as needed.
Any ideas?
05 January 2017 17:32
Wow, well yes, this actually solves it!
As I said, I tried to initialize the slots (they are usually empty), but didn't think they were "erased" from the object because of using the same texture, so I reused the "null.jpg".
Now I have tested using null1, null2, null3…. null7, and respects the 7 slots.
As it is used as a dynamic material, it would be nice to be able to initialize the slots with null/empty textures and a check or something to not optimize them like this.

Anyway, thanks a lot for your help, much appreciate it!
05 January 2017 14:40
I have no need to render the object, it is just a container for the material I later apply to an actual object to render.
The problem is exactly that, the array contains only those 4 texture names instead of the 7 texture slots.
I use those 7 nodes, changing the texture on runtime by name.
I haven't understood why you say there is no need to iterate over them because of similar textures.
¿How can I force it to return every 7 texture slots?
04 January 2017 14:23
I would gladly send you the .blend file used for exporting, so you can take a look at the node material, but that must be private and direct message (sorry, everything about this is company secret, that's why I pay PRO and don't attach examples or screenshots in the first place).

What is the best way to do that?
04 January 2017 10:57

Yes, I use that function too, but still returns an array with 4 texture names instead of 7, like if some slots are missing when exporting, still cannot figure out why.
So when I apply changes to the object materials they lack, for example, diffuse or normal map, depending on what 4 of the 7 texture slots they have (and you can imagine the weird look they present on screen!).
My export process is as follows:
1- I have a base scene with the environment, the camera, …, and the big, multi purpose, Node Material, among other required materials.
2- Import the objects to display from the collection (usually a shoe)
3- Select the materials for the different parts (an script does that depending on the part type)
4- Export the objects as b4w json

I use to start with the texture slots empty, tried to initialize them with null/blank textures, manually assign materials and exporting… still 4 of 7.
I don't know, maybe I have something broken or incompatible.