three.js: RoundedBoxBufferGeometry is buggy
RoundedBoxBufferGeometry should render correctly for the default argument values.
geometry = new RoundedBoxBufferGeometry(); // no args
//
RoundedBoxBufferGeometry should be a box with rounded edges. That means the six sides should have faces that are coplanar. That is, the vertex positions are not correct.
geometry = new RoundedBoxBufferGeometry( 10, 10, 10, 6, 2 ); // number of segments is even
//
UVs are not correct.
//
The normals for the triangles in the six primary faces must be parallel to the coordinate axes. That is, the vertex normals are not correct.
- Three.js version: [r.123dev]
/ping @gkjohnson If you want to have a look at this, that is fine with me. I am not going to pursue this.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 3
- Comments: 18 (7 by maintainers)
It is better, but the default values are not fixed, and passing in 1 for segments is buggy.
Also, the bounding box is too small. It should be the same size as the equivalent
BoxBufferGeometry. In other words, the vertex positions are still not correct.I’d suggest reopening this, or creating a new issue.
I’ll do the change 👌
@WestLangley
You’re right now that I’ve thought about it more I agree. That means the code should change to
segments = segments * 2 + 1and the lottie example should change to set the segments to7. @mrdoob do you want to just make the change? Otherwise I can make another PR.I’ve just changed the defaults in the other PR to what you suggested. I’ll leave the segment count in the example up to @mrdoob – lower segments counts can be noticeable in the box silhouette, though.
I suggest you do this so the default looks like a box with rounded edges:
Also, I think setting 15 for
segmentsin the example is overkill. Four to six should be adequate when using smooth normals.Yeah I noticed the normals weren’t exactly right when I was working on it given how the box is generated but I think it’s still a useful as a primitive. I don’t think I’ll be investing more time into this since I just wanted to get the UVs looking reasonable but thanks for bringing it up. If I think of a simple solution I may add it.
Regarding the particularly poor quality with an even segment number per side we could just enforce that the arguments be odd (add 1 if it’s even) or document that it needs to be odd to get the expected look. If the rounded box is being generated from a segmented cube I’m not sure what the “right” thing to do for an even number of segments would be – you want an even number of segments for the rounding corners on each side and one segment for the plane in the middle.