Overlapping connection point when extruding a ring

[ewice]

In my first project with ThreeJS I try to create a ring. I first create a cross section, which I then extrude with the following formula.

const radius = 25;

const path = new THREE.CatmullRomCurve3();
path.getPoint = (t) => {
  const radians = 2 * Math.PI * t;
  return new THREE.Vector3( radius * Math.cos( radians ),
    radius * Math.sin( radians ),
    0 );
};

const shape = new THREE.Shape();
shape.ellipse(0, 0, 5, 3, 0, 0, true, 0);

const extrudeSettings = {
  steps: 100,
  bevelEnabled: false,
  extrudePath: path,
  curveSegments: 10
};

const geometry = new THREE.ExtrudeGeometry(shape, extrudeSettings);

Is there a way to prevent this horrible looking connection?

[Mugen87]

I’ve converted your code to a live example but I’m unable to see the glitch: Edit fiddle - JSFiddle - Code Playground

@ewice

const path = new THREE.CatmullRomCurve3();

It does not make sense create an instance of CatmullRomCurve3 if you are going to overwrite getPoint(). Use the Curve class instead.

[ewice]

The glitch is only visible, when I do this (live example):

const geometry = new THREE.ExtrudeGeometry(shape, extrudeSettings);
geometry.center();
geometry.computeVertexNormals();
for (const face of geometry.faces) {
  if (face.materialIndex === 1) {
    for (const vertex of face.vertexNormals) {
      vertex.z = 0;
      vertex.normalize();
    }
  }
}
const buffer = new THREE.BufferGeometry().fromGeometry(geometry);

[Mugen87]

@ewice

geometry.computeVertexNormals();

That happens because of this line. When computing normals like that, you produce a seam where the (unconnected) start and end vertices meet.

In general, recomputing normals via computeVertexNormals() is not supported by all geometry generators.

[ewice]

First of all, many thanks for the explanation. As I am still quite new to the subject, I do not know how to proceed at the moment. How would you connect the ends? Or would a different geometry be more useful?

[Mugen87]

Could you produce your geometry in a DCC tool like Blender instead and then import it via GLTFLoader?

[ewice]

In the future, I would like to visualize parameter adjustments directly on the object in the browser, which is why constructing the object in a DCC tool would probably be to inflexible. Or is that wrong?

[Mugen87]

If you need to generate geometries on-the-fly then importing 3D assets is indeed the wrong approach.

[hofk]

@ewice

In the future, I would like to visualize parameter adjustments directly on the object in the browser,

You might find some suggestions in my addons. There shapes are also dynamically changed. I used self defined Geometry, indexed BufferGeometry and non-indexed BufferGeometry.

See

hofk - Overview

Addon. Produces almost infinite many time-varying geometries with functions

For the first time, I came across three.js in January 2016. Since September I have been working on this issue. In three.js core elementary geometries are defined. When designing my “Bumblebee Mara” I needed other shapes and produced them by deformation of sphere and cylinder. http://codepen.io/hofk/pen/eWdZMb Additionally inspired by https://threejs.org/examples/js/ParametricGeometries.js ( @author zz85 <<< old link, no longer available, see revision 100) I have programmed a three.js addo…

Addon to create special / extended geometries

updated NOTE: Modular bundling of multiple geometry definitions has some advantages, but also disadvantages if the overview and maintainability suffers. Therefore I created newer geometry creations in extra files and collect them on Github at GitHub - hofk/threejsResources: Resources for three.js There are also extra posts about it here in the forum. The THREEg addon is used to create special / extended geometries. [20180208-2112-21658] The addon generates non indexed BufferGeometries. Th…

Try it out
https://hofk.de/main/threejs/sandbox/

[ewice]

Do you have another idea how I could solve the problem?

[Mugen87]

I have to correct my previous post. The problem is that you convert to Geometry and back to BufferGeometry. The usage of computeVertexNormals() is actually fine as long as you don’t do it with Geometry. Try to make your geometry modifications without using Geometry.

[ewice]

Ok, but if I only use the BufferGeometry in combination with computeVertexNormals(), I get this result (live example):

[rrrr_rrrr]

@ewice

The glitch is only visible, when I do this (live example ):

Not a glitch, but completely normal and expected. Imagine forming a cylinder from a piece of paper. Where the edges meet, a seam is formed.

The light distortion you see is caused by vertices occupying the same space, but having different normals.

Since the geometry is mono-grouped and has no hard edges, the solution is to make sure these vertices also share the same normal values.

[ewice]

@rrrr_rrrr

Since the geometry is mono-grouped and has no hard edges , the solution is to make sure these vertices also share the same normal values.

So should I push the first values from the extrusion into the array again?

[rrrr_rrrr]

Image

Solution: ewice.txt (3.1 KB)

[ewice]

Thank you very much for your effort. The only problem I have now is this black border.

[GlifTek]

This is very interesting to me…
Is there any reason you’re not using LatheGeometry for this?

(I’m learning from this code, so may be a naive question)

[rrrr_rrrr]

@ewice

The only problem I have now is this black border.

The border is caused by modifying the vertex normals.
To counter it, any of the following might work.

• Add emissive att to Pong Mat.
• Revert back to your own light set up [upper left img]
• Soften the effect by assigning vertex.z to Math.sign(vertex.z)*0.005; [upper right img]
• Do not modify vertex normals [ lower middle img