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…
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…
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.
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.
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
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.
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.
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
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?
