Reconstructing mesh connectivity

[sailsman63]

@pspeed

Why are you starting with JME meshes? Why not catch the data earlier in the process rather than “right before it’s rendered”?

Here:

ISO: mesh-editing library

Does anyone have a mesh-editing library for JME3? For years I’ve contemplated writing one, but there’s not much point in “reinventing the wheel”. I envision such a library would include routines to: subdivide edges/triangles merge meshes into one convert a mesh from one mode to a different mode calculate vertex normals for a smooth mesh calculate triangle normals for a faceted mesh simplify a mesh by decimation merge duplicate vertices/edges/triangles (for various definitions of “duplicate”) d…

And similar requests at other times…

@Darkchaos

Can’t you use jme to import j3os?

I am. Getting the buffer data (triangle soup? I like that phrase!) Is almost trivial.

@Darkchaos

there probably is a well defined way the GPU would do this

There is. The GPU renders each triangle that it is given as an independent entity, without regard for ‘adjacency’ or ‘connectivity.’ it does not care that some of the vertice data is shared. Unfortunately, this does not work so well for editing. Especially anything that adjusts topology.

@1000ml

There are data structures that provide this kind of connectivity/neighborhood information, for example Half-Edge, Quad-Edge etc.

I have such a data structure. What I’m looking for is hints about heueristics to intelligently import ‘triangle soup’ into such a data structure.

For instance, two triangles in JME might rightly be adjacent and continuous, but not share any vertex indices, because they are on opposite sides of a UV seam.

Conversely, three triangles could very well share a pair of vertice indexes, if all of the parameters match. But in the editing structure, they must be represented as separate.