Giters

CADmium-Co / CADmium

A CAD program that runs in the browser

Home Page:https://cadmium-co.github.io/CADmium/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Very nice :)

twitchyliquid64 opened this issue · comments

commented

Just stopping by to say that I like your work :) I'm also working on something similar.

I was wondering two things:

  • The code you have for doing extrusions from shapes using truck seems to accumulate wires before converting to a face last, and then extruding. Does that approach result in correctly-formed STLs?
  • Your solver seems to be a spring-force solver, which is pretty cool, I've never thought of doing it that way but that makes a ton of sense cuz you can reuse all the best practices from the gamedev world. How has it been working? Does it converge well? (I went the other way and tried doing a numerical solver using derivatives and it kinda works lol)

-Tom

commented

Hey Tom, thanks for stopping by! I took a look at Liquid-cad earlier, looks promising!

In answer to your questions:

  • I've never tried to export a solid to an STL file--I always export to an OBJ file and that has always worked correctly for me. If the next step in your toolchain is to generate tool paths, maybe you could adopt the same strategy.
  • Thanks! Convergence is very fast for simple cases, but for more complex cases I don't actually know yet! I'm hoping to learn more soon. For stiffer problems I need to decrease the dt to maintain stability, so I may switch to RK4 integration away from simple Euler. Eventually I'd like for users to be able to specify regular constraints like they're used to: length = 10cm but also offer a new way. Something like length = 10 cm [+/- 1 cm], or length = 10 cm [+0cm - 0.5cm]. Doing it as springs also provides the benefit that over and under constrained systems present no issue at all to solving--there's no need to even check whether the number of constraints equals the number of degrees of freedom. Lastly, if you draw a truss using spring constraints on the lengths of all the beams, then simulate a load on the truss, you get a kind of poor-man's FEA. I obviously wouldn't recommend doing that over real FEA, but it should yield correct qualitative answers.
commented

Oh, one thing that tripped me up at first is that in my experience most downstream software that consumes OBJ files assumes the units are millimeters. If you happen to be outputting files which should be interpreted in meters, downstream software may appear to fail. Since STL files do not guarantee that their solids are properly closed, it is possible that a mesh tool might be checking for approximate equality by checking if certain points are closer than some small epsilon to each other. That epsilon may not be satisfied for a file that's in meters, if the checks are written assuming millimeters.

commented
  • My approach had issues with OBJ files as well so I think I'll try switching to yours, thanks!
  • Fortunately all units are in mm for me ;) as an Australian it will be hard to get used to freedom units even though I live here now lol
  • Convergence is also very fast for simple cases, but drops off exponentially as the number of free variables in the system increases. I'm sure theres an optimization to be made where I work out which variables aren't actually free variables (and are actually fully constrained by others) and I solve those precursors separately and then just do substitution. Perhaps that can be in order from the dragged/last-created point.
  • As for over/under-constrained systems: My (gradient descent in the direction of the derivative) approach has worked surprisingly well here. For underconstrained systems, each iteration will progress close to satisfying the equations in some way before stopping once the error is low enough. For over-constrained systems, consistent systems will be solved to a valid solution, and inconsistent systems will progress to a local-ish minima of the total error.
  • Your idea around specifying length = 10 cm [+/- 1 cm] sounds a lot like tolerance analysis, will definitely be very useful!
commented
  • Cool, let me know if the new approach lets you generate valid obj and stl files!
  • Nice, I default to metric as well, but unfortunately I defaulted to meters. I just meant to stress that millimeters are the norm here
  • Yeah, one of the big benefits I'm hoping to unlock with the spring-based approach is O(n) performance
  • Glad to hear that! I would worry that any optimizations you do to help with the exponential increase in solve time might be directly at odds with the tolerance to over/under constraints, but maybe not!
  • Yep, tolerance analysis!