[HN Gopher] CAD Sketcher, free and open-source project bringing ...
___________________________________________________________________
CAD Sketcher, free and open-source project bringing CAD like tools
to Blender3d
Author : lastdong
Score : 253 points
Date : 2023-02-19 10:47 UTC (12 hours ago)
(HTM) web link (www.cadsketcher.com)
(TXT) w3m dump (www.cadsketcher.com)
| codetrotter wrote:
| GitHub link is https://github.com/hlorus/CAD_Sketcher for anyone
| else looking for it
| sschueller wrote:
| This is awesome, I have been struggling with FreeCAD after
| switching from Fusion 360. However I find blender a joy to work
| with for 3d art so I have to give this a try.
| hummus_bae wrote:
| Thanks! And welcome to the CAD-Sketcher users community :) I
| hope you will continue to stay with us :)
| ranting-moth wrote:
| If Blender and FreeCAD could have a baby together then that would
| be amazing baby.
| progbits wrote:
| Blender has nice UX (the new versions, used to be horrible) but
| sadly what is holding opensource CAD back for me is the poor
| constraints and parametric modeling backend.
|
| Anything beyond simple polyhedra and booleans runs into a
| problem. Fillets, chamfers, sweeps and lofts don't work well.
| It's a shame.
| ezst wrote:
| Things have improved quite a bit in the latest freecad
| versions, and I remember reading somewhere that the next one
| promises to solve whatever's left over.
|
| My biggest gripe with freecad isn't necessarily that (it's
| easy enough to work around), but that going back few steps to
| edit things and apply it forward is very fragile. There are
| ideas floating around to better handle this workflow but
| we'll have to see how well that goes (it's probably a very
| difficult problem to solve with no general solution). In the
| meantime this gives me a lot of frustration and rework, but,
| running on Linux, there's no real alternative as far as I can
| see.
| jstanley wrote:
| There is certainly no general solution. Consider:
|
| You make a base sketch and pad it up to create a square
| part with a single hole in the centre. You chamfer the
| hole. You change the base sketch so that it is now a
| rectangular part with 2 holes, 1 at the left and 1 at the
| right.
|
| Should the chamfer apply to the left hole, the right hole,
| or both holes?
|
| Obviously there are special cases that FreeCAD doesn't
| currently handle optimally, but a general solution is
| impossible without FreeCAD reading your mind.
|
| (You could also asy "any of those 3 options is better than
| trying to apply the chamfer to a random bit of un-
| chamferable geometry". But a general solution is still
| impossible.).
| vba616 wrote:
| >a general solution is impossible without FreeCAD reading
| your mind.
|
| The goal of a well-written program is to give the user
| the opportunity to _express_ what is in their mind at an
| appropriate time, and to _change_ their mind after seeing
| some output. And to be told explicitly or implicitly
| _why_ their inputs don 't work.
|
| FreeCAD tends to get wedged so you can't back up, very
| unpredictably (for a newbie). This makes all its other
| issues worse because it inhibits experimentation.
| eternityforest wrote:
| If you moved the hole, it's the same hole, everything on
| it should follow. That seems to be how realthhunder
| handles things.
| phkahler wrote:
| It should remain on the hole it was applied to and new
| hole should not have the feature. Solvespace works this
| way although it doesn't do fillets or chamfers. The
| changes getting merged in the next version of freecad
| should help a lot with this.
| TheSpiceIsLife wrote:
| The chamfer applies to the first hole only, unless it is
| a copy of the first.
|
| Any changes to the first hole only apply to the first
| hole, unless that second hole is a linked copy of the
| first.
|
| ____
|
| Is there an argument against this general solution?
| jstanley wrote:
| Who's to say which hole is the "first"?
| mgdlbp wrote:
| From the user's perspective, the circle that was
| originally drawn, which wasn't touched when adding a
| second circle to the sketch. If the original was deleted,
| then it's unclear (possibly assume the first
| replacement).
|
| IIRC (not testing now) FreeCAD already handles this
| example sensibly. You can add circles to the sketch and
| the chamfer stays put. If you delete the circle and add a
| new one, it appears on the new hole. But if you add a
| square instead, it moves to a random edge of the
| rectangular hole.
|
| The 'edge' of the rectangular hole is actually a loop of
| four edges, so this is understandable. Commercial
| software can fix some of these cases - I don't think the
| Freecad link branch can, but it does at least detect that
| the original geometry was deleted and raises an error
| asking you to reselect instead of allowing things to move
| around. And unrelated features downstream don't break.
| Not dissimilar UX to when I mess with something that
| Fusion can't handle, I say.
| phkahler wrote:
| If the first is deleted then everything done to it
| afterward should be gone.
| tohnjitor wrote:
| It should gracefully fail and call for the hole feature
| to be redefined.
| ezst wrote:
| Agreed. I have no problem with this looking and feeling
| like a rebase operation in a version control system: fix
| the "conflict" to continue re-applying the sequence of
| changes linearly, drop steps along the way that are
| irrelevant or edit those needing to.
|
| I'm not even sure FreeCAD's editing model is anything
| like that (on the surface it seems that it understands
| geometries but disregards the process to obtain them).
| tohnjitor wrote:
| Does FreeCAD have a feature tree like in Solidworks or
| Inventor? It's an excellent system and makes it easy to
| switch from one software to another.
| Avlin67 wrote:
| but I try really hard to cut a circle in arcs with intersecting
| lines but it looks impossible
| Avlin67 wrote:
| also the nice things, lots of quality videos on youtube about it
| ezst wrote:
| I'm super glad this exists, this space definitely needs
| compelling open source alternatives to bring back the hobbyists
| scene from proprietary offerings (mostly fusion360), and every
| effort should be encouraged since this is a very difficult nut to
| crack.
|
| I known my way around CAD software and so I gave this a shot
| around 4 months ago, but it looked frankly alien and relied a lot
| on blender idiosyncrasies and baggage that most people with a CAD
| background would likely be missing. Basic things were hard to
| find and simple things were hard to do. I also had doubts that
| the foundations are sound (whatever engine props this up seems to
| be using floating point numbers instead of parametric equations,
| so things like pockets on top of coincident lines would
| incorrectly leave infinitesimal volumes of material).
|
| I should give it a new look but the road ahead will likely be
| very long.
| BMc2020 wrote:
| Autodesk has gone out of their way to destroy free F360. I
| finally quit when you had to reload the free version with a new
| account every 30 days. Forcing Eagle into F360 was just evil.
| Trying to use either is the hobbits being shown Frodo's clothes
| levels of anguish and despair.
|
| This may make me look at Blender again (too hard to learn at
| the time). Designspark Mechanical isn't too bad if you have
| become an F360 refugee.
| kitsunesoba wrote:
| I don't have a ton of experience with CAD software so maybe
| it's par for the course, but one of the things I dislike
| about F360 is how it runs like a dog regardless of your
| hardware.
| eropple wrote:
| FWIW, "reload the free version with a new account every 30
| days" does not match my experience with Fusion 360. Can you
| explain more?
|
| Don't get me wrong, I am not a big fan of it, but it does
| (mostly) work.
| BMc2020 wrote:
| Your Term Has Expired You can still administer your teams,
| but you now have 'basic' access to Fusion. If you would
| like to restore full access, click Subscribe Now.
|
| With basic access you can still: View projects Comment on
| and mark up files Download files
|
| _It used to be you had to switch every year. But the ts
| and cs are buried on the web site if they are public at
| all. You have have it installed to see your license
| details, which I no longer do._
| eropple wrote:
| OK, so you were using non-free-tier features, and they
| were pulled when you were no longer in the non-free
| trial? That's a different thing.
|
| F360 locks teams and some features (stress/strength
| modeling, for example) behind a paywall but for the
| actual free tier--useful for 3D printing, woodworking,
| etc.--is effectively unlimited for single-user use. (You
| have a limit of ten "editable" documents at once, which
| is silly but not of much consequence.)
| noveltyaccount wrote:
| F360 makes me so sad. I'd _gladly_ pay for it, but I make
| like 2 or 3 models as a hobbyist _per year_ and their
| cheapest plan is hundreds of dollars per year. I wish there
| was something in between that unlocked the full
| functionality. Or at least multi-page-PDF support.
| lastdong wrote:
| I started using blender again recently and the UI has major
| improvements, but mostly learning the shortcuts pays off big
| time (i.e. rx for rotate x, sy for scale y, gx for move x : in
| global space, gxx will move x in local space and so on).
| Changing space key in the settings to pop up a search toolbar,
| etc.
|
| My point being, each software has its own mechanics and takes a
| while to become productive at it. Blender has a lot of content
| online from users, with tips and tutorials, so it's currently a
| good space to be, learning wise.
|
| CAD support is lacking though. Glad linking CAD Sketcher here
| found more users willing to try it out. Hopefully it gets
| feedback/support, helping to its development.
|
| Thanks
| Matumio wrote:
| I've been using Blender a few times for 3D printing.
| Functional parts with playful/artistic touch. I can recommend
| it for that. I tried FreeCAD recently but it feels, well,
| constrained.
|
| FreeCAD is like entering values into a form, while Blender is
| like playing around with the model interactively. You can
| drag anything around, tear it apart, fix it again. It's
| possible to keep things editable, almost parametric, but this
| requires more planning and knowledge.
|
| For getting started you definitely want to follow tutorials.
| One for basic mesh modelling, and one with focus on CAD. (How
| on earth are you supposed to figure out that you want a
| "subdivision surface" modifier. It's the first thing I add in
| every project.) But I'm thinking now FreeCAD may be just as
| hard to learn as Blender (unless you already know CAD).
|
| (But now that I know the basics of CAD workflows, CAD
| Sketcher looks interesting. Before that, I wouldn't have seen
| the point.)
| phkahler wrote:
| >> FreeCAD is like entering values into a form, while
| Blender is like playing around with the model
| interactively.
|
| You should try solvespace, it has that fun feel but let's
| you apply constraints directly on the sketch.
| ezst wrote:
| Not disagreeing with any of that, I was just thinking that
| very little of what's generally useful in blender for making
| art transposes well into something useful or convenient for
| CAD. The whole mindset is different: you generally don't
| scale anything when designing a mechanical part, you specify
| or parametrize dimensions (because catalogue items like
| fasteners won't care that it looks awesome at 123.6%), and
| similarly, you don't move things by arbitrary offsets in
| arbitrary directions, you add assembly constraints so the
| kinematics make sense.
|
| I'm sure CAD Sketcher will grow a ton of convenient shortcuts
| too, I don't think they'll have much in common with the rest
| of blender.
| Avlin67 wrote:
| so after a few minutes of trial, I have to admit I did finally
| have a proper way to CAD on windows. Constraint sketching on open
| source, well, did try all options, at least now I can do it. Also
| the last version of blender did improve accessibility
| samwillis wrote:
| I always love to see these projects attempting to create an Open-
| source parametric CAD tool, but I think they will never get the
| the level of functionality and stability required. The
| fundamental issue for all of them is the lack of a robust open
| source "parametric CAD kernel", these the the central core that
| understands BREP and implements the geometric operations.
|
| The most widely used kernel is OpenCascade, the kernel used by
| FreeCad. However it is outdated, unstable and limited in
| significant ways with no realistic future prospects. It is
| unfortunately the limiting factor of FreeCads functionality and
| prevents any serious use of it.
|
| The most widely used commercial kernel is Parasolid, used in many
| packages including SolidWorks, OnSpace, and NX.
|
| What I would love to see is Siemens adopting a model similar to
| some of the game engines (Unreal and Unity) where it's free up
| until a revenue limit. Opening up Parasolid for "free" open
| source and small commercial operations would be both brilliant
| for society but also for Siemens, it would only result in a
| growth in the use of Parasolid and increased revenue.
| atonalfreerider wrote:
| I think you mean Onshape, not OnSpace
|
| Onshape is an amazing tool. Can't recommend it enough
| vba616 wrote:
| >no realistic future prospects
|
| Why? I've gotten far enough with FreeCAD despite its annoyances
| that I would be tempted to look into solving the problems with
| the kernel, and here you are discouraging people like me from
| getting involved by saying it's hopeless.
|
| The culture of constantly losing interest and starting over in
| many areas of software is one of the things I dislike the most.
|
| But I don't fight the tide.
| s1mon wrote:
| Nick Kallen has been working on an BREP based CAD tool with the
| sort of ease of modeling that things like Blender has.
| Originally it was based on C3D, but he switched halfway through
| to Parasolid.[0] It's amazing the amount of features he has
| built considering it's a one person project. It's worth going
| through his progress report videos.[1]
|
| [0] https://youtu.be/WvwiH1DOK1M
|
| [1] https://youtube.com/@nickkallen1
| Svenstaro wrote:
| I think some interesting developments are made in that sector
| in the form of https://github.com/hannobraun/Fornjot and
| https://github.com/ricosjp/truck. Let's see whether one of
| those will actually get anywhere near a usable level. Fornjot
| in particular is shaping up really well.
| Vespasian wrote:
| Interesting projects, Thanks for the links.
|
| As you say it's to early to judge but I like that the Fornjot
| author publishes regular updates on his progress.
| IshKebab wrote:
| SolveSpace's kernel seems rock solid to me. It just doesn't
| support fillets or bevels. :/
|
| I guess fillets are probably one of the most complex things for
| a CAD tool to support.
| phkahler wrote:
| >> SolveSpace's kernel seems rock solid to me. It just
| doesn't support fillets or bevels.
|
| Sorry, I work on Solvespace and can confirm it has some
| serious NURBS bugs. There are several open issues on github
| relating to NURBS boolean failures. The problems seem to fall
| into 4 or 5 categories, and we can probably fix some of the
| common ones. It's going to take time and some deep dives into
| the code though.
| canadianfella wrote:
| [dead]
| douglee650 wrote:
| The purpose is "CAD-like" -- that is, parametric surface
| modeling operations on polygonal geometry.
|
| Blender has its purposes, but I think surface or solid CAD must
| be pretty far down the roadmap. But there are often times where
| BREP or NURBS type workflows would be quite useful, and also
| some modeling operations such as "extend geometry from object A
| based on object B's coordinates and normals" can be very
| useful.
|
| If you need operations like variable radius fillets on tapered
| multiple intersections with G3 continuity--this is probably not
| for that. But selecting the midpoint edge of some other object
| and offsetting a plane by some radius? This makes that sooooo
| much easier.
| eternityforest wrote:
| Is there anything that can be done with GPUs being so fast to
| trade computer time for developer time? Like, would a point
| cloud or some other approximation be easier to work with?
| traverseda wrote:
| Yes! You've pretty much hit the nail on the head with your
| point cloud description, that's what the signed-distance-
| functions I was talking about basically are. You build a
| mathematical function that says whether a given point is
| inside or outside of your object and then you sample it a
| bunch of times and build a mesh based on that.
|
| Works quite well on modern CPUs, works very well on modern
| GPUs. The library I linked to uses numpy and numpy is _fast_
| on CPU, but a newer tool like jax would let you run pretty
| similar code on the GPU even faster. All this machine
| learning stuff actually makes python a very good choice for
| complicated numerical stuff like CAD.
|
| When I say "works quite well on GPUs" I mean "runs in real-
| time on a shader in a web browser"
| https://www.shadertoy.com/playlist/43cXRl . Note that none of
| those objects are meshes, it's a shader rendering the objects
| directly based on a signed-distance-function, every single
| frame.
|
| You still need to turn your SDF/point-cloud into a mesh, but
| that means you only need to implement one algorithm,
| something like marching cubes is good enough and dual
| contouring is a bit more complicated but also more precise.
| TaylorAlexander wrote:
| To clarify, can this method be used as a fully functional
| replacement to BREP for a mechanical (machine design) CAD
| system?
|
| I am a robotics engineer and 100% of my work is open source
| (see my profile). I understand that without fully open
| source CAD it is hard to make fully open source machines.
|
| If we were somehow able to rally support around a single
| project to create an open source CAD kernel and associated
| interface (perhaps built in to blender or FreeCAD to avoid
| building a new UI), what approach would you recommend? How
| long would you estimate it would take for three full time
| senior developers to get a useful system out?
|
| Any thoughts are appreciated. I am at the extremely early
| stages in my career where I hope to learn to raise money
| for open source non profit hardware projects. Open source
| CAD is a sort of linchpin and without it we cannot succeed
| in quite the way we would like.
| traverseda wrote:
| > To clarify, can this method be used as a fully
| functional replacement to BREP for a mechanical (machine
| design) CAD system?
|
| I think so, but there are some open problems. Also it
| depends on the senior people. Inigo Quilez is a world
| class expert in this domain, and for the most part we're
| copying his work, get him on board and you'll be golden.
|
| Fundamentally it makes sense, BREP is about representing
| boundaries and you can definitely use SDFs to represent
| the area under a boundary (infinite SDFs are possible,
| although obviously you can't turn them in to a mesh).
| Enclose a volume with boundaries and you can mesh that
| out just fine. A bit different from CSG-based SDFs, but
| entirely plausible.
|
| >what approach would you recommend?
|
| If I was to do this I'd take the constraint solver from
| solvespace (same one used in this post) and start using
| it to generate SDFs. At that point you're already 80% of
| the way to your end goal.
|
| I mean if I was personally to do this I'd start by making
| a system that implements everything openscad can do, try
| to get some funding going, and than add in a solvespace
| based workbench for doing 2D cad that you can import into
| an openscad-ish language. You can see my efforts here:
| https://github.com/traverseda/PySdfScad
|
| That's tackling it from a different angle than BREP
| though. I think that openscad but better is a
| surprisingly viable thing though, especially if you use
| it to do things like generate the gears/screws/whatever
| you import into your BREP based CAD project. Use
| scriptable CAD as the underpinning for more advances CAD.
|
| > How long would you estimate it would take for three
| full time senior developers to get a useful system out?
|
| Well define "useful"? Honestly I think you can get 80%
| done in under a month. I built the first pysdfscad in a
| week or two and replicated 80% of openscad's features.
| Fogleman built the library I used for pysdfscad in under
| a month.
|
| I'd expect something pretty good in under a year at that
| kind of rate. There would be some outstanding problems,
| like it would be a challenge to figure out how to apply a
| fillet/chamfer to an edge, but not an insurmountable
| challenge. Geometry import is another place where you're
| going to spend a lot of time/money but is very important.
|
| So let's say two or three years with three very competent
| seniors working on it to get a pretty good CAD program,
| with a GUI.
| cjbgkagh wrote:
| When I tried marching cubes and dual contouring against
| SDFs I ended up with a ton of performance issues that I was
| unable to resolve in the time I had allotted for
| experimenting. To get the resolution I needed I ended up
| with way too many triangles which used a lot of memory. I
| could later simplify the meshes but given the high number
| of initial triangles that process was quite slow. What I
| would like to explore (and hope that someone else does
| before me) would be a SDF optimized meshing algorithm that
| would make use of the extra distance and normal
| information.
| slavik81 wrote:
| Were you using OpenVDB? I'm not sure it solves that
| particular problem, but I found it to be a great library
| for dealing with this sort of data.
| cjbgkagh wrote:
| I did not, I'm away from my notes at the moment so I
| don't remember which libraries I used. I used a couple of
| different ones but not OpenVDB. Next time I try this task
| I'll try OpenVDB and see how far I get. Thanks for the
| recommendation.
| traverseda wrote:
| >these the the central core that understands BREP and
| implements the geometric operations.
|
| I've seen people quote a good modern CAD kernal as a 100 man
| year project. It's probably not going to happen, maybe there's
| some avenue for government funding?
|
| Alternatively Signed-Distance-Functions are pretty nice.
| They're not BREP, but they're a lot easier to implement, and it
| might be possible to shove them into a BREP-shaped hole.
|
| Here's a signed-distance-function based CAD kernal written in a
| few thousand lines of python+numpy, that seems to be about as
| fast as openscad. Maybe faster. https://github.com/fogleman/sdf
| gene-h wrote:
| How do you perform functions on faces, edges, points and
| other topological entities with SDFs? Such operations a
| necessary for parametric CAD.
| traverseda wrote:
| At the moment you don't. What I'm suggesting is that you
| could build up a conventional BREP-based datastructure, and
| than use SDF to "render" it. This gives you a very clear
| separation between your data structure and your meshing
| algorithm, and as I understand it a big chunk of those "100
| man years" would be in dealing with the meshing algorithm
| and edge cases in it.
|
| I suspect that having a generic meshing algorithm that will
| always mesh your datastructure with no edge cases would
| significantly reduce the time needed to implement a CAD
| kernel. You just need an algorithm that can tell you if a
| given point is inside or outside of your BREP. All you
| _really_ need for that is a surface that points at a given
| direction, and the ability to tell whether a point is under
| the surface or not. Define your surfaces as BREP, render
| them using SDF, only have to write one meshing algorithm.
|
| That being said I disagree with your definition for
| parametric CAD. Mostly the name, I get that you're talking
| about BREP based CAD. That is one way to do parametric CAD,
| but CSG can also work, especially if you can do more
| advanced operations like a filleted difference or union, or
| blends between two shapes, or other advanced CSG
| operations. I don't think that CSG-based CAD is inherently
| worse as long as you've got the ability to do things like
| fillet/chamfer CSG operations.
|
| You probably don't need to do a fillet along an edge if you
| can do a fillet where you subtract one object from another,
| something that SDFs can do easily:
| https://github.com/fogleman/sdf#smooth_difference
| virtualritz wrote:
| I would contest they are generally necessary. Applications
| of parametric CAD are many. Can a jeweller designing a
| parametric ring do without them? Probably.
|
| That said, you can e.g. calculate derivatives of the SDF
| and, simply speaking, when they 'flip' you know you found
| an edge or corner. You can project onto the SDF along a
| plane or line and 'record' the intersection, use it as
| input in your model etc.
|
| Similarly, you can treat an area bounded by such edges as a
| face etc.
|
| Just because there is nothing out there yet doesn't mean it
| can't be done.
|
| I also predict a great future for SDF based CAD for the
| simple reason that manufacturing methods mostly used for
| prototyping now (3D printing) will become more common for
| final pieces.
|
| And there is no need for an explicit representation (higher
| order surfaces or polygon meshes) of the shape to get tool
| paths (often derived from 2D bitmap slices) for these
| methods.
| gene-h wrote:
| One thing that probably won't change is the need for
| things which we design to be made of multiple parts which
| must be assembled together. For any serious application
| this requires specifying geometric dimensioning and
| tolerancing information, which ideally should be tied to
| the topological entities in question.
|
| I'd argue that this information is becoming even more
| important with the rise of 3d printing and other digital
| manufacturing tools. If this information can be included
| in the CAD data, the manufacturing tool might
| automatically determine how best to manufacture the part
| to meet the required tolerances.
|
| Topological information is also useful for analysis. We
| may wish to apply a load or boundary condition only on a
| face.
| seymourhersh wrote:
| [dead]
| Arcanum-XIII wrote:
| Funny, seems Russia did that in 2011. Now, which country,
| beside China would go that far ?
| elcritch wrote:
| Why is BREP so challenging? I hear these sort of statements a
| lot. But often they turn out complicated as much because it's
| a crusty code base built on hacks of hacks. What am I
| missing?
|
| SDF do seem like a cool option. They're computationally
| expensive but I'd bet the ray tracing features coming out in
| GPUs would help with that.
| traverseda wrote:
| I do think 100 man years is an exaggeration, or maybe
| they're talking about fully reverse engineering an existing
| CAD kernel and all the weird proprietary extensions it
| supports.
|
| In my uninformed opinion working with meshes is hard. In
| the interest of comparing apples to apples I'll compare a
| CSG-based approach (joining two mesh objects together) with
| an SDF-based approach (joining to SDF objects together).
|
| If you want to merge two mesh spheres together you need to
| do a lot of work. First you need some way of telling
| whether a point is inside or outside of another mesh. This
| is because you need to be able to delete all the
| vertexes/points/faces that are inside the other mesh. So
| you do that, and you delete all the points/vertexes/faces
| that are colliding with the insides of another object. Then
| you need to stitch the two meshes together. This is a whole
| thing, you need to find the boundary where the two meshes
| would have collided, create a bunch of new edges along that
| path while also taking into account where the existing
| faces on both objects are going to be.
|
| There's a lot that can go wrong during this as well, it's
| possible for your geometry to be "non-manifold" which means
| it has no clear inside or outside, and it's really easy to
| accidentally make an object non-manifold when you're
| stitching it together with another object. There are issues
| where sometimes meshes _look_ alright but in reality there
| are two edges on top of each other, or a face with zero
| area, or all kinds of crazy stuff. Making a tool that can
| reliably stitch two meshes together is a pretty big
| challenge. Than you start talking about adding fillets to
| vertexes, and how that affects the mesh geometry of other
| attached faces, and you 're having to write some really
| complicated error prone code for N different combinations
| of situations. Like what if the chamfer abuts another
| chamfer? What if it abuts a spheroid? A bunch of edge cases
| (heh) depending on the faces that your edge butts up
| against.
|
| With SDFs you just check if the point is inside one object
| or the other, and than re-generate the mesh from scratch.
| You write one not-too-difficult mesh algorithm and
| everything else is basically just OR/XOR/AND-ing things
| together. It makes defining geometry geometry about as
| simple as possible, just write a function that can say
| whether a point is inside your geometry or not. Something
| you need to be able to do for mesh based CSG anyway, but
| with a bunch more complications.
|
| This is also why tools like openscad can't do
| fillet/chamfer joins after 10 years and the tool I threw
| together in a few weeks can.
|
| https://github.com/traverseda/PySdfScad
| carterschonwald wrote:
| Sdf based approaches are just so much better! Agreed.
| phkahler wrote:
| How do you apply geometric constraints to SDFs?
| traverseda wrote:
| Excited to see you here!
|
| One approach would be to construct one solid SDF object
| out of a bunch of 2D SDF object segements:
| https://iquilezles.org/articles/distfunctions2d/
|
| The "Parabola Segment - exact" and "Polygon - exact"
| examples in particular. Probably requires some
| combination of the two for your use case. Basically turn
| your lines into 2D SDF objects that define the outside of
| your object.
|
| I think most of those objects actually could be chained
| together, like the actual quadratic bezier example has a
| real interior and exterior when you look at it more
| closely: https://www.shadertoy.com/view/MlKcDD
|
| So yeah, the intersection of a bunch of line segment SDFs
| like that could do it. Not sure about the performance...
| There is probably a more efficient way to do it, but I
| don't have the math skills to figure it out.
| VyseofArcadia wrote:
| > Opening up Parasolid for "free" open source and small
| commercial operations
|
| I've used Parasolid in a previous job. OpenCascade may be
| unstable and limited, but Parasolid can be too depending on
| your use case. Its not a silver bullet.
| nine_k wrote:
| To have access to something commercial for free may be nice.
|
| The ideals of free software though call to produce free and
| open code because it _remains_ free, open, and available.
| Siemens, were it to graciously offer some free tier access,
| would be also in a position to limit or withdraw such access at
| any moment. (This even applies to the paid licenses.)
|
| However limited OpenCascade is, it's here, and it's usable, up
| to a point. I hope that a successor to it will emerge, if
| there's a need.
| Avlin67 wrote:
| The addon utilizes the solver from solvespace (...)
|
| This is really nice, a proper solver
|
| So you get a really good solver and a really good 3D engine
___________________________________________________________________
(page generated 2023-02-19 23:00 UTC)