I’ve tested most of the basic shapes and it looks like anything more complicated than a plain plane or box will fail, so I’ve moved this from Questions to Bugs, although maybe there’s something I’m just missing.
I’m not sure because it works here:
Hmm it works with Cubes, but not spheres. That is interesting. We would have to go look at the parser and take a look but with the error that is dropping I’m assuming there is a index error on binding the color buffer for larger sets of vertices? Not sure, but kinda thinking thins might actually be a bug.
Thanks. I’ve never tried it with cubes, but it also fails with extruded meshes. This was just the simplest example I found
So it for sure sounds like something along the path is not incrementing correctly while constructing the buffers. We would have to look at when the “registerInstancedBuffer” is parsed before being passed the the glb export is truly giving the correct data. If that is, then the next step would be to look at the glb exporter and how it is accessing that data.
But then again I’m not really sure tbh.
Well, this pretty much kills a major use for my Lsystem generator, since I need to use instances to get reasonable performance
If I don’t create an instancedBuffer for color, then all the examples work.
This PR will fix the problem:
Note, however, that glTF does not support instanced meshes (the InstancedMesh class of Babylon.js), so the instances are exported as regular meshes. Also, it does not support a “color per mesh” property, so the two spheres of the PG are exported with the same material and have the same color (the color from the material, not the color from the instance data).
1 Like
Thanks! Are there any exporters that do support instances with colors? .babylon? The docs are a bit sketchy on most of the exporters, and most seem to be addressing importing
Yes, exporting to a .babylon file should normally support everything.
1 Like