simplicial complexes / "meshtypes"

[mattdesl]

I think simplicial complexes are a good approach for modularity but they have some drawbacks:

• "simplicial complex" is long-winded and intimidating; all of the search results related to it are extremely complex for somebody just trying to get a cube or sphere on screen
• they generally don't provide 3D rendering features like UVs or normals (lighting/texturing)

I am experimenting with a torus-mesh module and it would be great to have UVs baked in (like in @TatumCreative's geo-3d-box). It would also be good to standardize naming (mesh.uvs, module name, etc).

Normals would also be handy. So far I am using normals and glsl-face-normal, which seems to work well. Are there instances where they might provide less than desirable results compared to using the normals generated with the mesh?

/cc @mikolalysenko @hughsk

[gregtatum]

I would personally like to interact with data that most closely matches the other 3d model specs that exist, but in a JS/JSON format. "Mesh" for me makes more sense than simplicial complex from a 3d art and game perspective. It is more compatible with the terminology I already know, plus for the other reasons that Matt mentions.

I would also prefer to get everything by default in a mesh generator, and then be able to send flags in to not compute something. I think this helps with the fluency of writing a program first, but then allowing for optimizations when they are needed. I don't think this would go beyond the scope of a module of trying to do too much.

I'd be interested to see the commonalities between the various existing 3d object formats that are out there and the terminology that they use. Currenty the only real JSON format that I'm seeing is the assimp JSON format. The mesh parts are formatted like so:

meshes: [
    {
        name : ...
      , materialindex : ...
      , primitivetypes : ...
      , vertices : ...
      , normals : ...
      , tangents : ...
      , bitangents : ...
      , texturecoords : ...
      , numuvcomponents : ...
      , faces : ...
    },
    ...
]

box-mesh sounds like a more discoverable package name.

[mattdesl]

:+1:

@TatumCreative A lot of those are only relevant in the 3D software and/or game engine being used.

Tangents/bitangents are a bit obsolete in modern engines, see here. They add a fair amount of complexity to the code.

I think the following would cover most cases and still keep the module small / generic:

{ cells, positions, uvs, normals }

Another idea would be to take things the ThreeJS way and use the name geo-cube etc. Then "mesh" can be used by higher-level modules/frameworks for app-specific features like material, position, etc.

---

After a bit of testing it seems like normals sometimes produces undesired results.

Compared to the normals used when generating the torus:

[thibauts]

@mattdesl do you reuse the first ring indices to close the torus?

I'm all for *-mesh, the naming seems very intuitive and discoverable. If no annoying name collisions, that is.

As for positions, cells, normals, uvs for me they make perfect sense while keeping compatibility with simplicial complex, which is IMO very desirable to keep this feeling of openness toward the scientific end of the spectrum. Though I agree, the naming or at least the wording in tutorials / docs should be more welcoming to beginners.

[mikolalysenko]

Regarding things like uvs or whatever, the idea with libraries like simplicial-complex is that you would just stick them in another field. In this way you can have whatever crazy vertex/face attributes you want without being limited to just position/normal/uv/color/etc...

I'm totally fine with shifting conventions to rename these meshes or whatever (which would change nothing code-wise), but I would not like to see yet another complex mesh/geometry data type birthed. The problem with that is that there are just too many properties for meshes.

Also regarding functions which process simplicial complexes, it might be better to use destructured properties where appropriate since it makes fewer assumptions about the input type and requires less wasteful data type conversions. To illustrate this, here is a list of styles which I prefer in order:

//My favorite style, easily interoperable does not require assumptions about names of properties
// will just work with whatever data type you give it
var vertexNormals = computeNormals(cells, positions)

//Not as good in my opinion, but maybe acceptable if number of properties is too large
var vertexNormals = computeNormals(meshObject)

//Terrible style, causes peer dependency on meshObject. Bloats code unnecessarily
var vertexNormals = meshObject.computeNormals()

[mikolalysenko]

Also on that image, I think the issue is that the cells are not glued together at the end. You should call fuseVertices on your mesh first and then run normals on it so that you get something with correct topology:

https://www.npmjs.com/package/fuse-vertices

[gregtatum]

@mikolalysenko

but I would not like to see yet another complex mesh/geometry data type birthed.

I totally agree on that. The formats I've been looking at are kind of ridiculous, and very much targeted to specific application architectures. Mainly I want to be able to easily get at the data in a JavaScript friendly format, and the simplicial complex idea seems to get at that. It's just a simple object in its data representation.

@mattdesl

As far as mesh vs geometry, I've found three.js's use of mesh to be confusing. To me, a mesh is the definition of the surface structure more so than the way it is shaded. Googling "3d mesh" reveals a bias towards the surface definition. That said, I'm a little conflicted because I like conformity and the WebGL world is using three.js which does use mesh in a different sense.

{ cells, positions, uvs, normals }

I also agree that this approach is the best lowest-common denominator. Although my only gripe is the simplicial complex uses the word "cells" and most other formats I've looked at use "faces". That's pretty small though.

[mikolalysenko]

@TatumCreative In an earlier iteration of these ideas I used faces, but it ended up being somewhat restrictive. Part of the problem is that it is reasonable to store things like lines or tetrahedra in the same sort of data structure. This makes it awkward when dealing with meshes that are not 2D surfaces like volumes or graphs. A concrete example where this happens in practice is the convex-hull and delaunay-triangulate modules which can return simplicial complexes of any dimension.

In the future I hope to build more such modules for things like boolean operations, offsetting and so on.

[gregtatum]

Ahhh... ok, now that makes more sense. :+1: