I have an npm package stored on a private azure cloud that provides me an artifact. In that project, there is an html example file that I used to test the rendering of a mesh. The mesh renders here without issue.
However, when I load the npm package into my angular project everything compiles. BUT the mesh is not rendered and throws a
WebGL: INVALID_ENUM: bufferData: invalid usage… I can’t find much about what this would mean and why this is happening. Other meshes render fine.
It seems the error is traceable to three.module.js in the createBuffer function of the WebGLAttributes function at line 14435. Does anyone have an idea what this might be?
I can see in your screenshot that
undefined. This value is of course not valid when it’s passed to
The default value of BufferAttribute.usage is
THREE.StaticDrawUsage. Is it possible that you set the property to
undefined at some place in your app?
@Mugen87 I cant find any indication that I could have. However I have found out that this warning appears a total 84 times. The function is afterwards called a few extra time but I think those first 84 are trying to render my mesh which is failing.
EDIT: Tracing the stack up the data is undefined as well
Can you please explain in more detail what you mean by
artifact? Is this an instance of
artifact is an npm module compiled on our azure cloud. this contains a base layer for cross-platform mesh data. We are then converting this data to a 3D object using the ECL3D library (found here). The module is imported into our angular project where I am taking the data from the base layer, converting it to a threejs buffer geometry and adding it to the scene.
EDIT: I can confirm the conversion works within the actual project that is compiled. As we have tested it before building the npm package on the cloud.
EDIT: it is not a mesh in itself, it is a base layer that has a function to create a mesh.
Not sure this is related but it is a real problem if different components of your app use different instance of
three.js. This becomes even more complicated if the version do not match. Say you use
R108 in one component and
R113 in another one.
Could this be an issue between patch versions? So 113 and 113.2? or would this be limited to minor version updates?
Depending on how the app works, it is already an issue if you have two instance of
three.js with the same version.
For example, one instance creates geometries with IDs which are unknown in the other instance of
three.js. Hence, the engine can’t find the respective (internal) vertex buffers for these geometries.
That makes sense, tho the npm package is merely generating the geometry and passing it to my project. I am currently fixing the version mismatches and using the version from the generating library. I’ll let you know once that has built.
three version on the ECL3D library is specified as
"three": "^0.113.0" which means my version from npm will be 0.113.2. Changing that value to 0.113.0 statically made no difference. I am currently looking in the console for any information on why the mesh fails. This is the stacktrace of what is going on, in case you can see anything that would relate to my issue…
While looking into the geometry data I found that the attributes position array is null. could this be the cause I am looking for? this is after the geometry has been defined so that seems odd to me.
That is strange since it obviously has a defined
count property. Its value is computed from
array so it seems it was set to
null after the buffer attribute was constructed.