Three-bvh-csg issue with r148

Hey, i know this is not directly a three.js question as it is mostly related to the three-bvh-csg library by @gkjohnson , i seem to have found a slight bug once updating from r147 to r148 and not entirely sure why as the csg library does not seem to have changed, i’m wondering if there’s internal threejs methods that have been updated related to merging vertices maybe? i’ll try an illustrate the issue, the following images are exactly the same setup but simply using seperate revisions of three…

r147 yeilds the following which seems to be perfect… it’s a simple taurus geometry with a cube subtracted from the top section…

updating to r148 and running the exact same functionality seems to treat the output mesh in a very odd way, there looks to be tiny little “splits” / “gaps” in the mesh where the geometry has been re calculated…
image
it’s quite difficult to see but there’s definitely some sort of “splits” there, resulting from either unwelded edges or vertices maybe. When zooming really close in they seem to dissapear so there’s not actually a gap which is really odd…

would anyone have any ideas on why this may be happening? as i say, my only point of supposition is that the methods to merge vertices in BufferGeometryUtils may have been updated…

any direction on this would be great

cheers :slight_smile:

@forerunrun

If you compare the buffer data (like, number of vertices, some hash value of their coordinates, and the normals) … are the r147 and r148 buffers identical?

  • if “yes”, then the difference might occur in the rendering (or changed default values of some properties).
  • if “no”, then something in the CSG process or its interaction with Three.js has changed

The closest phenomena that I have experienced is by placing two cubes next to each other, their joined surface should be solid colour, but sometimes there are bleeding pixels.

As a side note: if you construct torus with its default parameters, beware, that they have changed. For example, in r147 the default torus has radialSegments=8 and tubularSegments=6. In r148 they are radialSegments=12 and tubularSegments=48.

– Pavel

good question, the answer in yes, they look to be the same…

the functions and value properties are identical in both examples…

nice, i’ll keep that in mind, however the issue is persistent on all geometry…

But only after a CSG operation?

yes after running the identical csg operation

Huh –

I run out of ideas. If the data in the buffers after CSG are identical – I mean completely identical – then it should not matter how these data are generated.

– Pavel

Its almost as if a wireframe or line material is also being applied to the mesh.

Hard to tell, but it only appears to be on the original mesh, not the part that was calculated to be cut-out.

Yes actually you’re correct, I’ve only tested using the subtract modifier but it does seem to only affect the source model and not subtractions :thinking:

Try 1e-0
THREE.BufferGeometryUtils.mergeVertices(mesh.geometry,1e-0);

Hey, do you know if the BufferGeometryUtils.mergeVertices threshold distance calculation has been updated in three in r148? three-bvh-csg carries this function out internally but I can definitely try to update with your suggested tolerance

@forerunrun

Both r147 and r148 use tolerance 1e-4.

– Pavel

@forerunrun
I’m not seeing this when updating the library to use r148. It would be best to make a jsfiddle - and also make sure that the results in the position buffer are byte-for-byte the same before and after the three.js update.

do you know if the BufferGeometryUtils.mergeVertices threshold distance calculation has been updated in three in r148? three-bvh-csg carries this function out internally

It’s not the case that merging vertices is performed internally in bvh-csg.

1 Like

I’ll try setup a minimal demo today to share…

Oh! I’ve made a silly assumption there my bad, might the issue be that I need to merge vertices after the csg operation has been completed?

might the issue be that I need to merge vertices after the csg operation has been completed?

It’s odd that an update to three.js would have caused the need for that. It’s possible something meaningful changed in three.js that’ causing this, though - hard to say without a repro.

1 Like

OK, yes it was very odd, setting the “resultObject” to visible = false before the new BufferGeometry (resultObject.geometry) had been calculated was causing the “splitting” issue i’m not sure why it worked fine in earlier versions but hey

1 Like

hey, just an update on this, my answer before was incorrect, this actually happens when setting the result objects material side to THREE.DoubleSide and transparent = true… i’m not sure why this is exactly but chances are it has something to do with the update to the “side” property of materials after the added THREE.TwoPassDoubleSide maybe?

EDIT:
hey @gkjohnson the predominant issue seems to definitely be using THREE.DoubleSide on the resulting material, transparency seems to be ok, would you have any thoughts on why this may be?