Use as CAD modeling core

[dumblob]

Any plans to generalize the capabilities a bit to allow using this technology as a simple CAD core (imagine FreeCAD or CadQuery editor)? The workflow seems the same as how CAD 3D modeling is being done.

The needed adjustments shouldn't break things much as the underlying SVG standard already defines dimensionality etc. quite well.

[dumblob]

Any thoughts @adam-urbanczyk @jmwright @wwmayer @yorikvanhavre @berndhahnebach @mlampert @realthunder @jrheinlaender @paullee0 @carlopav @triplus @donovaly @Moult @looooo @vocx-fc @sliptonic @DeepSOIC @luzpaz @abdullahtahiriyo @WandererFan ?

[dalboris]

Thanks for shining in!

It is a bit complicated to answer this in a GitHub answer, but the short answer to "any plans?" is no.

Obviously, there are a lot of similarities between the data structures I use in VPaint (VGC / VAC), and those used in CAD. So your question makes perfect sense and is absolutely pertinent. In fact, if you look at my research papers, you'll see that half the papers I cite (and the basis for the maths I develop) are references to topological data structures traditionally used in CAD. Also, it is true that in theory, you should be able to decorrelate the topological kernel from the geometrical kernel, and use the VGC core topological data structure for 3D modeling (where 3D means the space you immerse your topology in. The topology itself represents surfaces, and therefore is a 2D-complex in the topological sense).

However, there are some subtleties. The Vector Graphics Complex data structure (=VGC, not animated), is really designed with 2D vector graphics in mind, and I don't see much advantage in using it for CAD over more traditional non-manifold CAD structures, e.g., the radial-edge data structure. For example, in VGC, the geometry of a "face" is very simply represented via a "winding rule" (in theory, a "set of integers, possibly infinite", in practice, an enum with two values: "non-zero" or "even-odd"). You can then rasterize the face (or triangulate it) based on this rule and the geometry of its bounding edges.

In 3D, however, such geometric representation of faces is impossible: you need some more explicit geometry to describe a face, not just a winding rule. This could be the algebraic parameters of a quadric, or NURBS control points, etc. Then once you have such explicit representation, it is a bit trickier to just edit the edges in the boundary of the face, and expect the face to automatically adapt its geometry to conform to its boundary. It's not impossible, but it's more complicated. In the case of VPaint, however, this is trivial: just re-render (re-triangulate) the face! Since the geometry of the face is fully described by the winding rule (which typically doesn't change), there is no need to alter the definition of the geometry to have it conform to its boundary. In a sense, it is always conforming, by definition.

This is why in VPaint, you can have the luxury to have a very flexible definition for edges: hand-drawn, dense representation that you can sketch, sculpt, etc., and see the result in real time. And in turns this is why it looks so intuitive to use. But it wouldn't be as trivial to implement these things in 3D (but again, not impossible).

Finally, there is the obvious user interface design. Even if you did use the VGC as a topological core for 3D CAD, you would still have to almost entirely change the UI, since specifying 3D geometry is quite different from specifying 2D geometry. Implementing a new UI, and implement/port a whole 3D geometric kernel are complicated, and with no clear competitive advantage over existing software, e.g., FreeCAD.

To summarize, the novelty of VGC / VPaint is indeed its use of a topological data structure to represent a drawing (and a more powerful one than just planar maps, which can't represent overlapped faces). For this task, I have taken inspiration from existing topological data structures, such as radial-edge, but changed it a little. I generalized some aspects (e.g., added support for closed edges) and simplified some aspects (no explicit ordering of the "star" of each cells, no representation of volumes), to make it a better fit for vector graphics. But I don't think these changes bring a lot of advantages for 3D CAD, so I don't think it is worth pursuing rather than just improve the UI and/or geometric kernel of existing software, e.g., FreeCAD.

Anyway, if someone wants to fork the code and try that, I'm happy to bring consulting help, as I'd be curious to see what comes out of it. However, it's definitely not on my priority list ;-)

[dumblob]

Thanks for the warm reaction!

For example, in VGC, the geometry of a "face" is very simply represented via a "winding rule" (in theory, a "set of integers, possibly infinite", in practice, an enum with two values: "non-zero" or "even-odd").

This I wasn't aware of. Thanks for pointing it out.

and with no clear competitive advantage over existing software, e.g., FreeCAD. ... But I don't think these changes bring a lot of advantages for 3D CAD, so I don't think it is worth pursuing rather than just improve the UI and/or geometric kernel of existing software, e.g., FreeCAD.

I have to admit, what motivated me the most to ask here is the very very old yet still unsolved "topological naming problem" in FreeCAD [1] [2] [3] which has much broader negative effect on users than how it's being handled by FreeCAD core community. It's probably because only programmers are used to properly report bugs and write it to the FreeCAD forum; but FreeCAD is actually meant for non-programmers who'll rather try a different product because it's enormously frustrating experience disregarding how powerful all other capabilities of FreeCAD are (and they are).

Btw. I always thought the CAD backend FreeCAD uses is pluggable and the fact, that OCC is being used is just because it's state of the art CAD kernel. Not sure though, whether that still holds. If it does, than it's still a viable option to constantly look for other possible CAD kernels :wink:.

[dalboris]

I see :-) This topological naming problem looks quite annoying, and in fact, seems to be a side-effect of (the generally good idea of) trying to separate concerns between geometry/attributes and topology. If these things are handled by different libraries, developed separately, then it might not be possible/practical to keep pointers and back-pointers between these libraries, and thus as a workaround they rely on naming to keep track of changes. In a sense, it's harder to talk to each others.

I haven't looked into the code of FreeCAD (and barely ever used FreeCAD besides toying around), but I would say adapting the code of VPaint/VGC to be able to use it as a CAD kernel for FreeCAD would be quite a very complicated and time-consuming task, and probably wouldn't even solve this problem :-(

[adam-urbanczyk]

This looks like a really cool project but I don't think what you are proposing is realistic (even assuming that it is possible) @dumblob .

[jmwright]

@dumblob @dalboris Thanks for this discussion, even if nothing comes of it right now. You never know what things might come together in the future if the right connections are made ahead of time.

[adam-urbanczyk]

@dumblob regarding topological naming I think that the kernel (OCCT) has this capability (cf. https://www.opencascade.com/doc/occt-7.4.0/refman/html/package_tnaming.html ).

[dalboris]

@jmwright Yes, we never know :-)

Although it really seems like for this to work, there would be way too many things to implement which aren't otherwise needed at all for VPaint/VGC. I'm not a big fan of "too generic" libraries (reusability is good, but up to a point). I prefer writing minimal implementations fine-tuned and optimized for a specific use case. In this case, I feel that even if I were to develop a 3D CAD program myself, I would probably not share its topological structure with VPaint/VGC, but rather I'd develop another one, fine-tuned for 3D. Genericity often has a performance and/or readability cost (or time-of-development cost).

Like all things though, "it matters": it's not black and white, and at least some level of sharing might be useful.

[vocx-fc]

@dumblob regarding topological naming I think that the kernel (OCCT) has this capability (cf. https://www.opencascade.com/doc/occt-7.4.0/refman/html/package_tnaming.html ).

@adam-urbanczyk FreeCAD is aware of this, but it has been decided not to use it. See Topo Naming Solution in OCC 7.4.0 very important

[paullee0]

Just watched some videos, sounds interesting project ! Though I am not an user of similar application at the moment :)

[dalboris]

@paullee0 Thanks!

By the way, I'm still leaving this open a few days to encourage discussion, but then I will most likely close it, unless the discussion brings arguments that increase somewhat the likelihood of the original request being implemented.

[dalboris]

I'm closing this issue now, but anyone should feel free to continue the discussion if you're interested or would like to take part in such use case / endeavour :)

[dumblob]

Thank you all for contributions.