IndexedFaceSet vs. TriangleSet

[andreasplesch]

The shape tesselator has an ExportShapeToX3DIndexedFaceSet() function:

pythonocc-core/src/Tesselator/ShapeTesselator.cpp

Line 373 in e87231d

std::string ShapeTesselator::ExportShapeToX3DIndexedFaceSet()

But the function actual generates a TriangleSet, not an IndexedFaceSet.

The naming may be for historic reasons ?

It would be preferrable if the function actually would generate a IndexedFaceSet or an IndexedTriangleSet. By iterating over the triangles to get the vertex ids, and then iterating over locvertexcoord to get the coordinates for each id. This would more efficient. But perhaps there is another reason for using non-indexed geometry.

If so, renaming the function may be possible:

https://github.com/tpaviot/pythonocc-core/search?q=ExportShapeToX3DIndexedFaceSet%28%29&unscoped_q=ExportShapeToX3DIndexedFaceSet%28%29

[tpaviot]

@andreasplesch you're right, the method indeed creates an X3D TriangleSet. I don't remember exactly the history of this piece of code, but I guess I started with an IndexedFaceSet, and then changed the method body without renaming its name, certainly for backward compatibility reasons. I agree that the method name should be changed. I leave this issue open until this is done.

[andreasplesch]

thanks.

[tpaviot]

@andreasplesch I changed the method name to reflect the actual method content.

The TriangleSet vs IndexedTriangleSet discussion is interesting. If you do think the latter would result in a performance improvement, then it might be worth trying to move to this representation (the pythonocc x3dom exporter has very poor performances compared to 3js). But I did not work on the x3dom exporter for months or even years, diving back into this would be a kind of start from scratch. If you have any idea or suggestion to make this move fast, please let me know.

[tpaviot]

This might not be as difficult as I thought, I just have to add a

std::string ShapeTesselator::ExportShapeToX3DIndexedFaceSet()

and only modify the method body

[tpaviot]

This is related to issue #351

[andreasplesch]

In terms of performance, I think you are referring to the rendering performance ? Threejs is generally more efficient but there should not be a drastic difference. x3dom does pass through the indexed geometries to webgl. Indices should reduce the number of vertices to store by a large fraction (each vertex is shared perhaps by about 6 triangles) which helps with the generated file/object size, and should also help with rendering.

I found that the OCCT VrmlAPI actually generates IndexedFaceSets. So it may be possible to either reuse that functionality which requires translating to x3d xml, or reproduce the code in python to output x3d xml.

[andreasplesch]

Testing some more, I was reminded that what helps x3dom with performance is to limit the number of x3d shapes, eg. by combining geometries. Here is an example:

https://nbviewer.jupyter.org/github/andreasplesch/OCCToX3D/blob/77cda237a7055d796b48623712c0c0296d579973/notebooks/stp_to_x3d2.ipynb

[scroll to the end]

The first rendering has >1000 shapes and is a little slow. The second rendering has < 100 shapes and performs well.

The first rendering uses the Vrml generated by OCCT. The second rendering uses pythonocc generated x3d, the TriangleSet.

So more important than using indexed geometries is to limit the number of Shapes because each has to managed, updated for each frame by x3dom.

[andreasplesch]

It looks like OCCT now has glTF export as well but I could not figure out how to use it or find an example. There is a glTF loader for threejs and one for x3dom. glTF geometries are in a gpu friendly binary format and should load and render well.

[tpaviot]

The glTF exporter is being developed at OCCT, it has not been released yet

[andreasplesch]

I think I saw glTF export for CAD Assistant, but was perhaps misled by early announcements.

[tpaviot]

@andreasplesch I agree that Indexed geometry would result in a smaller file, thus reducing loading time. For instance, exporting a meshed box currently export 36 vertices (2 triangles per face, each triangle requires 3 vertices thus) and 6 faces -> 236 = 66=36. That is to say 363=108 floats. Indexed geometry would only require storing 8 vertices * 3 floats/vertex = 24 float and 36 integers.

When I fisrt started working on x3d and threejs exporters, I wanted to have the smallest granularity (down to the Face and the Edge), to be able to select such low level entities and request, for example, the computation of the mass, center of inertia etc. It's possible using, on the server side, a bijective mapping between the shape id and the x3d mesh. And thus roundtripping from OCCT to x3d. This is a drawback when rendering huge models where thousands of faces / edges are added to the Scene. But, on the other side, have many shapes also enable async loading from the server, then progressive loading of the scene.

Then, this has to be balanced between:

1. few shapes/fast rendering/no async loading/poor granularity vs
2. many shapes/low rendering/async loading/good granularity.

Solution 1 is suitable for big scene visualization I guess. Solution 2 is more suitable for detailed work on a part or small model. I made the choice of solution 2, because that's I needed, but I confess I forced all users to follow the same path ! The choice between 1 and 2 should be left to the final user.

So here is what could done IMO:

a. Move from a TriangleSet to IndexedTriangleSet representation, to save bandwith/loading time. This is independent from any of the solution 1 or 2. This is still to do. It can be done at the c++ level, or, at the python level, using numpy to convert the TriangleSet representation to indexed geometry (I prefer this solution, if it's not too resource consuming).

b. Let the user choose the granularity level when calling the X3D exporter (whether the Compound, Solid or Face level). I did it for the threejs based renderer for Jupyter. You can have a look at the helloworld.ipynb example from https://mybinder.org/v2/gh/tpaviot/pythonocc-binderhub/7.4.0, and just change topo_level="Face" to topo_level="Solid".

[tpaviot]

@andreasplesch Talking about a numpy based solution, I was thinking to something lke that:

from OCC.Core.BRepPrimAPI import BRepPrimAPI_MakeBox
from OCC.Core.Tesselator import ShapeTesselator

import numpy as np

# use the tesselator to tesselate the shape
a_sphere = BRepPrimAPI_MakeBox(10, 20, 30).Shape()
sphere_tess = ShapeTesselator(a_sphere)
sphere_tess.Compute()

sphere_triangle_set_string = sphere_tess.ExportShapeToX3DTriangleSet()
print("Triangle Set representation:")
print(sphere_triangle_set_string)
triangle_set = sphere_tess.GetVerticesPositionAsTuple()

# convert vertex coordinates to a numpy array
triangle_set_np_array = np.array(triangle_set)
nb = len(triangle_set_np_array)
# following should be 108
print("Number of floats in the numpy array:", nb)
# reshape the array to get an array of 3 float arrays
vertices = triangle_set_np_array.reshape((int(nb / 3), 3))
print(vertices)
print("Length of vertices array:", len(vertices))
# among all these vertices, there should only be 8 different
unique_vertices = np.unique(vertices, axis=0)
print("Number of unique vertices:", len(unique_vertices))
print("Unique vertices:\n", unique_vertices)

indices = [np.where(np.all(unique_vertices==ar, axis=1))[0][0] for ar in vertices]
print("Vertices indices:\n", indices)

The original TriangleSet string is:

<TriangleSet solid='false'>
<Coordinate point='0 0 30 0 20 0 0 0 0 0 0 30 0 20 30 0 20 0 10 0 30 10 0 0 10 20 0 10 0 30 10 20 0 10 20 30 10 0 30 0 0 0 10 0 0 10 0 30 0 0 30 0 0 0 10 20 30 10 20 0 0 20 0 10 20 30 0 20 0 0 20 30 10 20 0 0 0 0 0 20 0 10 20 0 10 0 0 0 0 0 10 20 30 0 20 30 0 0 30 10 20 30 0 0 30 10 0 30 '></Coordinate>
<Normal vector='-1 0 0 -1 0 0 -1 0 0 -1 0 0 -1 0 0 -1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 0 -1 0 0 -1 0 0 -1 0 0 -1 0 0 -1 0 0 -1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 0 -1 0 0 -1 0 0 -1 0 0 -1 0 0 -1 0 0 -1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 '></Normal>
</TriangleSet>

After being processed by numpy, I get:

Number of unique vertices: 8
Unique vertices:
 [[ 0.  0.  0.]
 [ 0.  0. 30.]
 [ 0. 20.  0.]
 [ 0. 20. 30.]
 [10.  0.  0.]
 [10.  0. 30.]
 [10. 20.  0.]
 [10. 20. 30.]]
Vertices indices:
 [1, 2, 0, 1, 3, 2, 5, 4, 6, 5, 6, 7, 5, 0, 4, 5, 1, 0, 7, 6, 2, 7, 2, 3, 6, 0, 2, 6, 4, 0, 7, 3, 1, 7, 1, 5]

that would do it, no ?