.obj exporter?

[MrLeap]

Would be handy to be able to export the meshes as something commonly supported by gamedev engines.

.obj seems suitable to the task, it's a very easy, human readable format. The only format perhaps more ubiquitous is .fbx, which is far less friendly.

.gltf is another good candiate.

Really any of these would open a gateway of silliness.

[virtualritz]

It would be even more handy if the OBJ could also/alternatively contain the (trimmed) NURB surfaces from the b-rep.

Few people today know this but Waveront OBJ is perfectly capable of storing these (scroll down to Free-form curve and surface types).

Among the apps that ingest such OBJs with higher order geometry are Maya and Rhinoceros 3D. The latter together with the procedural Grashopper modeling tool makes for a very interesting combo with DSLCAD.

I wanted to look into adding at least NURBS + trim curves support to tobj anyway.

Generating the .obj data through Maya &| Rhino was the plan but if this comes to DSLCAD I'd prefer that to get some generative regression testing going for NURBS support in tobj. I.e. DSDLCAD→.obj→tobj.

[DSchroer]

I have moved the export format from stl which is basic to 3mf to try to be forward looking. I think its better to support one format well rather than have a bunch of different formats. Its should be trivial to convert 3mf to obj with a tool like meshlabs.

Closing this for now since multi type export is not something I think the project needs. There are plenty of good converter tools.

[virtualritz]

The point I made in this ticket, was having a way to export NURBS that is easier to implement than STEP.

If you have a B-rep modeling tool, you want to have a way to export data as lossless as possible.

For example, if I want to create CAM tool paths in something like Fusion360, your input data should not be a triangle mesh.

Furthermore, if you mesh a surface, you can create a quad mesh and only use triangles sparsely, e.g. at trimmed edges. This has advantages if you want to further process the mesh to make it an asset in a game or VFX context, e.g. to be rendered as a Catmull-Clark subdivision surface.

AFAIK 3MF only supports triangles.

The whole point of using a B-rep modeler in the first place is moot then if all you can export are triangle meshes. Use a SDF modeler instead. ;)

[DSchroer]

The 3MF format is forward looking and moving to allow volumetric specification. At the moment its likely not very supported but I am not sure if OBJ B-rep is very supported either at this point.

https://github.com/3MFConsortium/spec_volumetric/blob/master/3MF%20Volumetric%20Extension.md

[DSchroer]

What matters most if the development flow. User experience if you prefer that term. B-rep vs SDF should be hidden from the user in a tool like this. It shouldnt matter.

[virtualritz]

I think the misunderstanding comes from the fact that you assume people export from dslcad and then just 3D print.

If I want to use a CNC to mill from a block of metal, plastic or wood, polygon meshes are the worst input geometry.

If you come from a polygon modeler, you'd likely convert to subdivision surfaces or T-spline nets and then convert those to bicubic patches to get higher order geometry to feed into the CAM for the CNC.

But when you come from a B-Rep modeler, like dslcad, that makes no sense. You already have high quality, higher order geometry to start with. Why would you tessellate that into polygon soup, in between? Worse, you can never recover the original shapes from their meshed approximations that way.

So the way to go is to offer OBJ export to trimmed NURBS (low hanging fruit) and then STEP (potentially a lot more work). Check out the truck project for the latter.

To test OBJ files containing NURBS geometry you can use Maya or Rhino3D (both have test versions).

[DSchroer]

@virtualritz from your experience. Would the BREP object file from Opencascade work or is it pretty non standard?

https://dev.opencascade.org/doc/occt-6.7.0/overview/html/occt_brep_format.html

[virtualritz]

STEP is kind of the industry standard for exchange of B-Rep data. It's to B-Rep data what OBJ (still) is to mesh data. The other one is IGES. OpenCascade is product-specific. Just like CATIA or Solidworks formats are. I.e. I wouldn't make supporting them a priority.

As for STEP: hence my suggestion to look at the truck crate, specifically their truck-stepio which in turn is based on ruststep.

That said, I would still support OBJ, both for meshed geometry (especially if the mesher can produce n-gons instead of dicing everything into triangles) and for trimmed NURBS export.

Simply because it is a vety low hanging fruit and the NURBS part is easy to verify via Maya or Rhino3D demo versions. They both read OBJ files containing higher order geometry.

As a user, OBJ export should give me those advantages:

• Meshed OBJ works almost everywhere (3MF does not).
• It can store n-gons. So if the dslcad mesher is clever, it can e.g. create meshes mainly consisting of quads instead of triangles. For me this the main reason why I have a copy of Moi. It's mesher can do this whereas most meshers will always generate only triangles.
  • If I want to refine the meshes elsehwere and ultimately render them as Catmull-Clark subdivision surfaces, e.g. for VFX applications, getting quads, as much as possible, is a hard requirement.
  • It can store NURBS. Again, in a VFX context this means I can get data into Maya, lossless, and then either send it to a renderer supporting trimmed NURBS as-is or use Maya's mesher to convert it to polygons with more control than I have in dslcad.
  • If I want to do more modeling in a NURBS modeler, I need to get data in there as NURBS. STEP is probably the most important one but OBJ may still be the easiest to implement.

[DSchroer]

Looks like I am in the position where work could start on this. From what I can tell there are no out of the box obj file libraries with free form curve support so it would need to be hand written.

@virtualritz would you be able/willing to help with that development?

[DSchroer]

I suspect we could implement it here: crates/persistence/src/lib.rs

[virtualritz]

I suspect we could implement it here: crates/persistence/src/lib.r

Cool! But maybe change the name of this crate so you can eventuall publish it on crates.io (name clash, AFAICS).

Format specs are in the section Free-form curve/surface attributes here.

I can offer help like so:

Sample Files

These can be inspected to see how a (reasonably) well-formed OBJ containing these geometry types should look like.

• [x] Contact a friend who's a professional designer and ask them to export OBJs from Rhino3D
  • A sphere.
  • Some simple CSG operation that results in a bunch of trimmed, joined surfaces.
    • It will be particuarly interesting to see it the join information from Rhino is retained in the OBJ via the connect statement (see Connectivity between free-form surfaces in the spec. linked above). dslcad should strive to preserve this information in the OBJ, if possible, even if Rhino turns out to not do this.
• [ ] Ask another friend who's a VFX artist do the same from Maya.

I can contact different people for samples if you want to add STEP support, eventually.

Testing

• [ ] Install a Rhino3D & Maya demo on my Windows VM and import OBJ files from dslcad.

Code Review

I can also look at code but I can't make any promises when or how much.

I just started a new job and as such my spare time has become a scarce resource.

[DSchroer]

Name may change later. Right now its not really intended for publishing. All the crates are pretty connected to dslcad themself.

[virtualritz]

Here are the promised examples from Rhino. Sorry this took so long.

A sphere and some CSG union operation between a sphere and a cube.

Sadly, from the looks of it, Rhino does not export join information to the OBJ.

Maybe we have more luck with Maya data that contains attached (Maya lingo), trimmed surfaces.