We know that a cube has eight vertices，Because of the principle of triangle drawing, we need to draw 12 faces
So, to draw a cube, we need to draw 12 triangles with eight vertices
posiiton:8
indices:12 * 3=36
I built a custom cube using Babylon based on this principle,and there’s nothing wrong with that
However, when I parse the built-in Cube data of different open source libraries, I noticed a difference
1.three.js
position:8
indices:12 * 3 = 36
2.babylon.js
posiiton:72 / 3 = 24
indices: 36
？？？
According to this post below
Each face has independent vertices so you can control UV or normal per face
I wonder if all the mesh in Babylon is treated this way to support this feature.
In this case, will tripling the data amount lead to performance loss, or is there any performance compensation for this, or how to cancel this feature
What you have outlined for Three.js is the representation on the javascript side of a cube (vertices / faces). If you look with Spector.js what is sent to the GPU, you will see there are 24 vertices / uvs:
(I took the geometry / cube sample from their demos)
For position: bufferLength = 288 => 288/12=24 vertices (12=stride=3 floats)
For uv: bufferLength = 192 => 192/8=24 uvs (8=stride=2 floats)
So it’s the same thing than in Babylon.js
If you want to reduce the number of positions/normals, you will need to apply a simplification process that would de-dup positions that are identical (or near identical) and average the normals at those points. For uvs, though, there’s no simplification that would work if you really use different uvs for the same vertex position (which is usually the case)…
For position: 96 / 12 = 8
According to the principle of drawing in PG, we can actually transmit less vertex data.
But three.js just looks like it’s passing very little data.
Is there a possibility that users don’t actually want different uvs, at least this feature is rarely used in regular web development
So both frameworks (three.js & babylon.js) force the performance of webgl to be sacrificed to provide features that users may not necessarily use ?
So, are there any plans to add an option to it later to improve performance?
I’m not sure what you mean here as they are passing the same data than Babylon.js in the sample I looked at.
As soon as you have uvs you will probably have cases where the uv for a vertex must be different depending on the face the vertex pertains to. For eg, for a cube, the uv for a face could be (0,0), but for the other two faces it will probably be either (1,0), (0,1) or (1,1). Only if you are not texturing can you save the uv attribute and potentially reduce the number of vertices of the geometry.
Also, if you don’t want smooth normals at the vertices you will need to have 24 vertices to be able to have 3 different normals per vertex (one for each face the vertex pertains to). Or you can also do as you did in your PG, not creating the normal attribute: in that case the normal will be generated in the shader, but it will cost a little more perf.
I don’t think so, but you can do the processing on your end:
I have adapted the _OptimizeNormals function from the OBJ loader to create the OptimizeMesh function above. You can adapt it if you don’t have normals or if you have additional attributes.
In fact, one of my most recent projects required raw data in this minimal rendering method, which is 8 points and 36 indices
Now it seems that if I use babylon, I can’t get this kind of data structure. In fact, I can do some deduplication processing to achieve my purpose, but this is a bit of a detour.
If babylon’s existing functions can’t provide such data, I wonder if I can try three, after all, that data structure is exactly what I want
By the way, my recent problem is to extract points that are on the edge based on geometry data, like the edge of a piece of paper
If you are speaking about the data sent to the GPU, Three.js is doing like Babylon.js, as demonstrated above.
If you are speaking about the javascript layout, then it’s a bit different in Three.js than in Babylon.js indeed, so you should pick the engine that bests suit your needs if this layout is the most important factor to you.
1 Like
You are right, different projects have different requirements, it is very important to choose the right engine
Thanks for making me realize that Three.js and Babylon.js are the same when it send data to the GPU, at least for the cube geometry
@ecojust from what I see you could also create a quick helper to generate or handle the geo data the way that best fit your project.
I am usually doing this no matter what engine I use as soon as I need a lot of control on my data structure.
@sebavan thanks for your suggestion.
emm,what I need to deal with is an imported arbitrary model, so I don’t want to spend too much time on data processing. If there is a convenient way to get the data I want directly, I prefer to do less.
You have several ways to access the info after import through either getVerticesData or through facets data:
@Evgeni_Popov
For an externally imported model, Three also failed to provide the kind of data I wanted, so I still had to deal with the data myself…
