Update from 16.01 to 16.12 Material
03 January 2017 20:31
Hello,
I am in process of updating the engine, and I have a problem with the node materials.
Previously, I used every slot, searching at the object batches, changing the textures as needed.
Now, on exporting, the textures are not named as before (there's no texture.name, but at least I have batch.bpy_tex_names for that), but it is not showing all my texture slots, only 4 of 7, and kind of random between different exports (it doesn't always show the same ones).
I am trying to understand if it is an export problem, something broken with my nodes or if something has changed since many versions ago.
Could you please provide some guidance on what to look for?
I am in process of updating the engine, and I have a problem with the node materials.
Previously, I used every slot, searching at the object batches, changing the textures as needed.
Now, on exporting, the textures are not named as before (there's no texture.name, but at least I have batch.bpy_tex_names for that), but it is not showing all my texture slots, only 4 of 7, and kind of random between different exports (it doesn't always show the same ones).
I am trying to understand if it is an export problem, something broken with my nodes or if something has changed since many versions ago.
Could you please provide some guidance on what to look for?
03 January 2017 22:00
Hi,
It is generally not a very good idea to use internal properties. They can be changed, renamed and they are completely messed up when an application is compiled.
I would recommend going with this method and just iterate over the obtained array changing the required textures.
It is generally not a very good idea to use internal properties. They can be changed, renamed and they are completely messed up when an application is compiled.
I would recommend going with this method and just iterate over the obtained array changing the required textures.
04 January 2017 10:57
Hello,
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.
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.
04 January 2017 11:57
Could you please attach a simplified example so that I can figure out what causes the problem? Maybe, there is some sort of a bug related to the recent textures refactoring.
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?
What is the best way to do that?
04 January 2017 16:29
You can send the example to my email: evgeny-ar@blend4web.com
05 January 2017 14:29
I've checked the attached file.
The problem with pos2 object is that it has the Do Not Render flag. The get_texture_names function returns only textures which are actually used by the material. If you make this object renderable, the array will be ["df_texturecubemap", "df_texturediffuse_b", "df_texturespecular", "nm_texturenormal"]. And I wasn't able to find 7 textures inside this material. Maybe, you meant Texture Nodes? If so, there is no need to iterate over them because some of these nodes use similar textures.
Anyway, as you haven't attached the images, it looks like I've found one bug not directly related to your question. Thanks for the report.![]( "smiling")
The problem with pos2 object is that it has the Do Not Render flag. The get_texture_names function returns only textures which are actually used by the material. If you make this object renderable, the array will be ["df_texturecubemap", "df_texturediffuse_b", "df_texturespecular", "nm_texturenormal"]. And I wasn't able to find 7 textures inside this material. Maybe, you meant Texture Nodes? If so, there is no need to iterate over them because some of these nodes use similar textures.
Anyway, as you haven't attached the images, it looks like I've found one bug not directly related to your question. Thanks for the report.
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?
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?
05 January 2017 16:15
I checked the example one more time and now I see what you are talking about. Those diffuse texture nodes really use the similar image and this is why they are optimized inside the engine. In order to fix this you need to assign different images to these textures. We'll fix the behavior in the next release.
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!
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!