Object.Geometry.Mesh faces and vertices question

I have been trying to get to the bottom of why my Meshes are borked. I have a simple example and would appreciate some simple guidance. As background, I have been translating my knowledge of Mesh definition from BabyloJS and can appreciate that it would be different for Speckle.

Mesh Scenario 1 (One mesh per triangle):

// Triangle 1
vertices = new List<double> { 0, 0, 0, 1, 0, 0, 0, 1, 0, };
faces = new List<int> { 0, 1, 2,};

Objects.Geometry.Mesh baseMesh = new Objects.Geometry.Mesh( vertices, faces );
baseMeshes.Add( baseMesh );

// Triangle 2
vertices = new List<double> {  0, 0, 0, 0, 0, 1, 1, 1, 0 } ;
faces = new List<int> { 0, 1, 2,  } ;

Objects.Geometry.Mesh baseMesh = new Objects.Geometry.Mesh( vertices, faces );
baseMesh[ "renderMaterial" ] = TranslateMaterial( geom );
baseMeshes.Add( baseMesh );

Success :heart_eyes: but is it a problem for the viewer handling large displayValue arrays?

Mesh Scenario 2 (Single mesh two triangles):

// Triangle 1
vertices = new List<double> { 0, 0, 0, 1, 0, 0, 0, 1, 0, };
faces = new List<int> { 0, 1, 2,};

// Append Triangle 2 vertices
vertices = new List<double> {  0, 0, 0, 0, 0, 1, 1, 1, 0 } ;
faces = new List<int> { 3, 4, 5,  } ;

Objects.Geometry.Mesh baseMesh = new Objects.Geometry.Mesh( vertices, faces );
baseMeshes.Add( baseMesh );

Fail :sob:

1 Like

@Jedd will confirm, but from what I see in there you’re missing out on the face vertex count. This face array is supposed to have two triangles (from your second commit):

image

but it displays only one because of it being malformed.

The faces array works like this:

faces = [ face_vertext_count, vertex_index_1, vertex_index_2, vertex_index_3, face_vertex_count, vertex_index, etc ]

Another thing to note, which looks like it’s not clear yet, is that displayValues is an array of any number of displayable things, including meshes. If you put any number of single triangle meshes in there, they will be each treated separately, resulting in many draw calls (not cool).

Let us know if this helps!

1 Like

The not cool displayValue being array was my gut feeling.

The bit I was missing is faces not being a direct synonym to indices ?

Adding 3 prior to each triplet will work?

yes this should work! the reason for this is that meshes can be composed of n-gons – not just tris – so we need more information to know how many indices to grab from the array to form the next face

2 Likes

Thanks.

I actually followed the hint from ConvertMeshUtils.cs Line 299 and used 0 as a triangle flag.

Now that has some sweet mesh :stuck_out_tongue:

This geometry is now cool but jittery which is I guess a distance from zero issue. Is there an OOTB transform to zero routine to use / recommended. I know I’ve seen the select which origin to use for Revit discussion. I can go dig there.

2 Likes

fab! and yes, the jitter is prob the distance from zero issue which will be resolved in the viewer at some point soon.

re the 0 tri flag, we used to only support tris (0) and quads (1) in meshes, but have upgraded to allow any n-gons. this upgrade led us to go with 3 and 4 as the more logical tris and quads flag, though everything remains backwards compatible. if you’re building something new though, I’d probably suggest using 3 as the flag as the 0 and 1 flags will prob be depreciated in the future.

1 Like

Yas, spatial jitter is solved now by @alex! It wasn’t exactly easy:

We’ll be pushing a new viewer release soon™️.

3 Likes

Jitter aside I’m seeing that I may be seeing impacts on meshes and accuracy possibly within my conversion.

Mesh fidelity maybe a distance from zero thing or a simply oddness in a matrix transformation I’m applying precommit.

Reading in to GH still slight oddness (might be float vs double issue)


The original flatbar in Navisworks

Hi @jonathon

Indeed, the same fp32 precision issues (distance from 0 thing) that cause jittering will also cause poor mesh fidelity. In extreme cases, very bad ones.

1 Like

Thanks, @alex, @dimitrie & @izzylys

I’m parking this for now. However, I have audited the imported meshes and the vertical fidelity is intact, so I will log an issue to myself to resolve this somehow when I have more bandwidth. Or there are leet codez to steal from the speckle team :smiley:

yeah, it looks a floating-point error (the fact that Z coordinates are correct points also in that direction). Maybe speckle for Rhino/GH is not using double precision meshes?

BTW, working far from origin has been always a source of problems in Rhino, some of their command will create artifacts of every kind

1 Like

Update

I have fixed my geometry conversion routines which were, as suggested, all in the fidelity of conversion from compressed coordinate space and the matrix calculation per mesh to bring into real coordinate space.

Just waiting on the anti-jitter upgrade :smiley:

4 Likes

Great stuff! It does look much better than before. Also happy to report the anti jitter meds that @alex cooked up are gone!

We’ve just pushed an update to latest, and i console-log hacked the viewer to load that commit there:

jitter-gone

Correct meshes & buttery smooth spinning :smiling_face_with_three_hearts:

4 Likes

No jitter on latest :smiling_face_with_three_hearts: but the fidelity of geometry in the viewer isn’t quite right. :sob:

The good news is that the Connectors read it correctly:

1 Like

Hi @jonathon

There is something wrong indeed there. I’ll be looking into this and I’ll keep you posted!

1 Like

FWIW. Blender seems equivalently borked.

For now (because I don’t have any other needs) I will store a transform matrix from bbox centre to rw coords as a property and commit with bbox centred at 0,0,0.

have not investigated this mesh in particular, but blender does not support double precision coordinates so if precision is the issue here then it’ll definitely also be the issue in blender!

1 Like

Yup, I assumed as much. Hence the fallback option to abandon (but record) the transform.

A million years ago when I was first dealing with the differences between AutoCAD and Microstation for rail projects, the Bentley approach was a dynamic memory solution to maintain the accuracy for the real-world (sort of like a floating bbox window to the data - more complicated than that as it maintained accuracy over kilometres) whereas back then AutoCAD was similarly borked.


plus ça change, plus c’est la même chose

Hi @jonathon

I’ve looked into this a bit more. There may be a solution which I’m very curious to try out. I’ll let you know about the results soon(-ish)

1 Like

I have added a relocate bounding-box-centre > world-zero routine behind an option flag.

Everything that you’ve been doing has it all tip-top now.

Once the ideas for Setting Out Points or Transforms or whatever settle, I can amend it to fit whatever schema it ends up with.