Boundingsphere radius is NaN when initializing raycaster.

[dotoritos-kim]

It seems to be a problem that does not include the z position in the matrix.
Considering the difficulty of development in the next release, I think we need a logic to put fake Z coordinate values.

[vagran]

What is the reproduction scenario for this issue? Currently there is no Z coordinates for rendering primitives, since this is huge memory wasting for planar designs.

[dotoritos-kim]

What is the reproduction scenario for this issue? Currently there is no Z coordinates for rendering primitives, since this is huge memory wasting for planar designs.

If you create a Raycaster object and ray tracing the object, the above image error occurs.

[vagran]

Yes, this will not be that simple with the current implementation. You can try to add Z coordinates in your fork. However, I doubt that approach used in three.js for Raycaster will have good performance with huge DXFs.

[dotoritos-kim]

Yes, this will not be that simple with the current implementation. You can try to add Z coordinates in your fork. However, I doubt that approach used in three.js for Raycaster will have good performance with huge DXFs.

logic is huge, so I failed to add the Z-axis as I thought. Could you please briefly tell me how to do it?

[vagran]

Probably some easiest "quick and dirty" way is modifying attributes arrays (instead of digging into batch construction code):

dxf-viewer/src/DxfViewer.js

Line 718 in 151b7de

const verticesArray =

dxf-viewer/src/DxfViewer.js

Line 735 in 151b7de

const verticesArray =

These arrays initially contain X/Y coordinates as [X1,Y1,X2,Y2,...], should be modified to [X1, Y1, 0, X2, Y2, 0,...].

vertices: new three.BufferAttribute(verticesArray, 2), <<< should be changed to 3

Shader code probably should be changed as well:

dxf-viewer/src/DxfViewer.js

Line 586 in 151b7de

in vec2 position;

in vec3 position;
...
vec4 pos = vec4(position, 1.0);

May be something else I missed. However, I doubt you will get what you want after that, each Three.js object is a whole batch, which consists from primitives from unrelated DXF entities, grouped by common material.

[dotoritos-kim]

It seems to work better than predicted.
The number of errors has been reduced from 62 to 38.

[KaldrArt]

What is the reproduction scenario for this issue? Currently there is no Z coordinates for rendering primitives, since this is huge memory wasting for planar designs.

yes，most memory wasting is due to TTF font entities. In my case, in order to catch mouse events by raycaster, I've added Z to my vertices, it costs lots of memory when there's lots of texts in the dxf file. And it wastes more time.

I think perhaps later we need to render shp fonts instead. Shp fonts have only lines instead of triangles which will save huge memory and rendering time.

[KaldrArt]

Yes, this will not be that simple with the current implementation. You can try to add Z coordinates in your fork. However, I doubt that approach used in three.js for Raycaster will have good performance with huge DXFs.

No performance problems on even low-profile integrated graphics, I've added some complicated animations in my case, for example, drawing and moving rectangle annotions, a small square that can be magnetically attached to the edge of the line and the intersection of lines.

Add an animate function in DxfViewer, when triggered some plugin, for example raycaster events, change some variable like somePluginEnabled , and call Animate()

    Animate() {
        if (this.HasRenderer()) {
            this.Render()
        }

        if(somePluginEnabled) requestAnimationFrame(this.Animate.bind(this))
    }

Because of your amazing work, three.js is perfectly combined with dxf-viewer.

[vagran]

I think perhaps later we need to render shp fonts instead. Shp fonts have only lines instead of triangles which will save huge memory and rendering time.

I had thoughts to migrate to text rendering based on signed distance field textures, which AFAIK is state-of-the-art, and combines advantages from both vector and raster worlds. Probably I should plan it as one more big feature in the next major release.

[dotoritos-kim]

    `function CreateObject(vertices, indices) {
        const geometry = instanceBatch
            ? new three.InstancedBufferGeometry()
            : new three.BufferGeometry();
        geometry.setAttribute('position', vertices);
        instanceBatch?._SetInstanceTransformAttribute(geometry);

        if (indices) {
            geometry.setIndex(indices);
        }

        const tmpVertices = geometry.attributes.position.array;
        const tmpPositions = new Float32Array(
            tmpVertices.length + tmpVertices.length / 2,
        );
        const tmpGeometry = instanceBatch
            ? new three.InstancedBufferGeometry()
            : new three.BufferGeometry();
        tmpGeometry.setAttribute(
            'position',
            new three.BufferAttribute(tmpPositions, 3),
        );

        let verticesIndex = 0;
        for (let posIdx = 0; posIdx < tmpVertices.length; posIdx += 2) {
            tmpGeometry.attributes.position.setXYZ(
                verticesIndex,
                tmpVertices[posIdx],
                tmpVertices[posIdx + 1],
                0,
            );

            verticesIndex++;
        }

        geometry.setAttribute('position', tmpGeometry.attributes.position);

        const obj = new objConstructor(geometry, material);
        obj.frustumCulled = false;
        obj.matrixAutoUpdate = false;
        return obj;
    }

    if (this.chunks) {
        for (const chunk of this.chunks) {
            yield CreateObject(chunk.vertices, chunk.indices);
        }
    } else {
        yield CreateObject(this.vertices);
    }`

If this code is added to DxfViewer.js CreateObject, it is possible to render at high speed without problems, and it is confirmed that the above errors do not appear.
Try adding this code to DxfViewer or local fork

[vagran]

If this code is added to DxfViewer.js CreateObject, it is possible to render at high speed without problems, and it is confirmed that the above errors do not appear. Try adding this code to DxfViewer or local fork

This should be done in a fork, since it is a workaround which has no value for the library at the moment.