Hi community!
Here is a pic:
And here is a working demo:
I would say it’s not the ultimate solution, but a concept. If you have any ideas of how to improve the code of the shader, feel free to post it here or PM me 
UPD An example based on @Fyrestar’s code: https://codepen.io/prisoner849/pen/qzZaye?editors=0010
This saves you the polygons for the corners, also by using a uniform cube you can use the boxSize property for sizing it.
https://codepen.io/Fyrestar/pen/pXJoda?editors=1010
This is awesome! 
I edited a little again, basically this line is all you need.
transformed = signs * subBox + normalize(position) * radius;
Needs a parameter to adjust the quality of the round edge 
Added 
also to prevent self-intersection if the size isn’t large enough for the rounding-radius.
Oh, nice. 
envMap projection breaks on faces not aligned with camera directional axis, much like what happens on my texture projection question.
edit: Oh, I know why.
The same thing happens on every envMap. You just can’t notice on @prisoner849’s example because the number of segments on each face of the box is a lot higher, so the effect is less noticeable. But if you test the same thing on a regular boxGeometry with just 2 faces on each side, you get the same distortion.
The way to fix that is by calculating the texture UV projection inside the fragmentShader using interpolated worldcoordinates, but that should add a really big overhead, not sure if it’s worth.
Yea you generally have that issue with low tesselation, using some for the inner faces would improve it again, maybe there is a generally better fix though.
Actually environemnt maps don’t use UVs, they use the normal, i just noticed prisoner used a MeshLambertMaterial which only calculates the reflection normal per vertex, a Standard/MeshPhongMaterial fixes this.
Actually environemnt maps don’t use UVs, they use the normal, i just noticed prisoner used a MeshLambertMaterial which only calculates the reflection normal per vertex, a Standard/MeshPhongMaterial fixes this.
Oh, I see. Good catch!
You’ve updated the code to use correct normals and it’s working fine 
Hey guys, i’m a bit late to the party, but I’ve been wondering since the start of this topic: “what’s the usecase for this?”. 
Can you share what you use/plan to use this for?
@Usnul
You can dynamically create a box with rounded edges, then transform it to a capsule, then to a sphere, without re-building of its geometry
I’ve started that theme long ago 
Round-edged box, Round-edged box 2, Round-edged box 3 These are at the level of a geometry, the current one is at the level of shaders.
Actually there is much pratical use for it, i used this technique before for a dynamic scene to add a little bevel/rounding to the boxes. On GPU it saves you geometry buffers and processing cost otherwise done with JS, for a lot boxes with varying or dynamically changing sizes it is quite more efficient.
The more the merrier!
Would it be possible to do this in JS?
We could have a THREE.RoundedBoxGeometry that extends THREE.BoxGeometry and “post-processes” the vertices in the constructor.
A BevelModifier would also be nice! And probably the more generic solution.
I agree! A BevelModifier sounds like the the best solution.
However, in order to work on a cube it’ll need connected faces pointing the same direction. Like the recent EdgeSplit.
