<gbruno>
[github] kintel pushed 7 modifications (glview: in impelementations, move the corresponding declaration header to top. (#5371) This is the last directory in src/glview for this to be done. (All the others have been done in #5327 already). Co-authored-by: Marius Kintel <marius@kintel.net>) https://github.com/openscad/openscad/commit/8c8ec424d897959df723d8dc37b2ac00da7efad9
<InPhase>
nihil: I didn't know freecad was still crashing a lot... I stopped using it many years ago from too much crashing, but had heard it stabilized.
mmu_man has quit [Ping timeout: 265 seconds]
<InPhase>
nihil: But one can achieve fillets in OpenSCAD just fine. I don't really hit cases where I don't succeed at my objective on that. You just need to plan ahead for it, thinking of it as an earlier design feature, rather than try to slap it on as an extra.
<J24k80>
nihil one key is to design with the fillet - not putting it there after
drkow has joined #openscad
kow__ has quit [Ping timeout: 260 seconds]
mmu_man has joined #openscad
mmu_man has quit [Ping timeout: 255 seconds]
<J24k80>
hmm got a lot "parsing warning: polygone not closed. closing it" - and 600mb pov files wow ok
<J24k80>
teepee when exporting 3mf would it be difficult to just number the objects so their name matches the ID - would make easier to identify in slicers - and if importing them by "ID"
<J24k80>
currently they are just named "openscad"
<J24k80>
so if they are "open SCAD Model 1" ↦ 2, 3 would be nice
<pca006132>
nihil: I think the main problem is the lack of edge selection function in openscad...
<nihil>
it's close
<pca006132>
and it is hard to figure out which edges are the edges the user want to apply fillet to, and which edges are considered a curvature...
<nihil>
there's measurement
<pca006132>
measurement is interactive, but openscad code is supposed to be static code
<nihil>
it is yes
<nihil>
just need to add persistent edge identification and modifier routine
<nihil>
basic identification is there
<pca006132>
I think if the user can select edges, adding fillet will not be too hard... at least it should be easier than mesh offset
<pca006132>
hopefully
<J24k80>
But if you select them like measurements by mouse - those can't be in the code
<J24k80>
you sure could do some postprocessing of the edges
<nihil>
no reason you can't do it both ways
<nihil>
each edge gets assigned an identifier, you can either pick that UID via GUI or $mathandfunctionsandstuff
<nihil>
then write that into your code
<nihil>
hell, give the user the ability to assign a UID to an object, and select thismost or thatmost edge
<J24k80>
you want to use identifier in the code that are given when evaluating the geometry?
<J24k80>
nihil most cases can be solved by using the right design - else openSCAD (CSG) is not the right tool for that task
<nihil>
I'm well aware of what it is currently capable of
<nihil>
granted I'm still learning, only been using it for a decade or so
<nihil>
I'm also well aware that the design process doesn't always incorporate every single detail from the start
<nihil>
sometimes your models evolve a bit more organically
<J24k80>
if you like mouse clicking design you use autodesk blender maya CATIA - but open scad need to run with the scad file only
<nihil>
and revisions that can include a fillet/chamfer later on alleviate having to redesign something from scratch or a much earlier iteration
<nihil>
you're not listening
<J24k80>
so if you change geometry by clicking, this would need to add and change your code
<nihil>
not a single bit
<nihil>
the only thing said about "clicking design" was mention of the measurement ability, which does imply a level of edge detection
<nihil>
if you assign an identifier to that edge in your scad code, then you should be able to operate on it programatically
<J24k80>
There are two fundamental different CAD approaches - one is CSG and the other dealing with curves/edges
<nihil>
recommending some random shit you read about on the internet as an alternative is daft
<nihil>
I work in engineering, I deal with all of the big-boy CAD/FEA/CFD stuff on a daily basis
<J24k80>
nihil ? read about? I am lecturing that at the university
<J24k80>
but you seem very weird - have a nice day - bye
<nihil>
lecturing what "here's why mentioning a possible feature to one program should yield an arrogant response and recommendation of something else"?
<nihil>
I guess that's the difference between real-world and academia, you don't actually have to get work done in academia, you just sit around talking about why everybody else is "wrong"
<nihil>
(for what it's worth, that gear, in ABS, lasted me 2 years with the car, and last I heard from its new owner is still working like a champ 8+ years after I printed it)
<nihil>
well, 7+, I haven't talked to its current owner in a year or so
<J24k80>
attaboy
<nihil>
outperforming all the NOS nylon gears on the market by a decent margin
<nihil>
bottom line though "mAYbE yOu ShoUlD uSe auTOdEsk" or suggesting redesigning a part from scratch is an inappropriate response to mentioning that since edge detection is coming along, perhaps it could be leveraged programatically for some very common CAD operations
<J24k80>
you use point and polyhedra for those
<nihil>
it's short sighted, and doesn't do anything to further development or evolution of the software itself
<nihil>
you use that if you're starting from scratch
<nihil>
again, you aren't paying attention
<nihil>
evolution and iteration of designs is a thing
<nihil>
there's an entire segment of the industry built around change management
<nihil>
and they kinda frown on "oh you should have known you were going to need that feature when you first started the project, do it over"
<J24k80>
You should have learned that selecting the right tool for a task is essential
<nihil>
doubling down on arrogance
<nihil>
good going
<J24k80>
obviously you don't need any help - so again bye!
<nihil>
you keep saying bye, but you dont leave
<nihil>
is it an attention thing?
<J24k80>
I am indicating that i am finished communicating with you - why should i leave, do you think you are the reason i am here? What the hell is wrong with you?
<nihil>
yet you keep engaging
<nihil>
that is unhealthy behavior
<nihil>
like a desperate need for approval
<teepee>
knielsen: hi! regarding the build-depends issue, I think we just don't need libcgal-qt5-dev, I don't have it listed in the OBS builds and those never had an issue with that
<knielsen>
teepee: ok, thanks for the heads up! I'll try to look into it and see if I can simply remove the dependency or what's needed.
<teepee>
I hope so, otherwise we are a bit in trouble. but first lets hope for the best :-)
<pca006132>
well... I think the current openscad language is limited in terms of introspection
<pca006132>
using some unique id for edges/vertices/faces may not be the best idea because those cannot be composed together and cannot express design intent
<teepee>
what's much more interesting is if there's a reasonable way of *declaring* this information
<pca006132>
yes
<teepee>
one related thing would be the attachment stuff guso explored which I think is a neat thing we would want to have
<pca006132>
I think build123d provides some syntax for identifying features, maybe that can inspire some syntax...
<teepee>
probably like cadquery? which is to say a horrible 2nd language?
<teepee>
or did they implement a new way of doing that?
<pca006132>
idk, I just remember someone talking about it, didn't check further
<teepee>
hmm, looks different
<teepee>
cadquery has some perl style character soup ;-)
<teepee>
like |Z+-XY
<teepee>
or something
<pca006132>
oh... I don't really like this kind of syntax sugar
<teepee>
I don't think it's syntax sugar, it's a dedicated query language for selection in addition to the otherwise native python for the objects
<teepee>
hmm, eigher readthedocs is almost dead, or my internet connection is acting up :(
<teepee>
result = result.mirror(result.faces(">X"), union=True)
<teepee>
base = cq.Workplane(origin=(0, 0, -2)).box(12, 12, 10).cut(sphere).edges("|Z").fillet(2)
<teepee>
sphere_face = base.faces(">>X[2] and (not |Z) and (not |Y)").val()
<teepee>
yay! ">>X[2] and (not |Z) and (not |Y)"
<teepee>
it's probaby quite powerfull, basically a full geometry query language, but not exactly easy to teach
<pca006132>
I see
<J24k80>
like anchors in BOSL you can add a special variable carrying that info about connection points or edges - but is only available for children - so if a cube support children you could place spheres at each corner and with a hulll()
rvt has quit [Quit: rvt]
<teepee>
yes, just as built-in for the primitives and even better also for user module (which will likely need the object feature to progress)
<teepee>
I'm not sure how to express that yet, the vague idea would be some sort of specialized transformation like attach("from", "to") maybe
<J24k80>
I see an problem with the enormous number of possble connections .. a cube has 6 center sides + 8 corners + 12 edges - that is nothing a normal user can use with ease
<teepee>
J24k80: about the 3mf export, adding a number seems like an easy win. ideally I would want to be able to name the parts, and even define them as support
<J24k80>
BOSL afaik is using "up" "down" etc to choose one of these points to translate the origine
<J24k80>
naming parts would be great but seems to be very difficult - if it is a module you could use that name (but those are not part of the CSG tree)
<teepee>
yeah, I think guso used a matrix for the specification so the attachment does not just have a point but also a direction. that's essential to make it work nicely I think
<teepee>
oh, we had the code already for extra meta data :-) it's just not an agreement on how to type that
<teepee>
like the # and ! modifiers are already that kind of data. those are additional tags on any instantiated module in the csg tree
<J24k80>
a sphere would have unlimited connection points and need some azimuth and altitude angle to find
<J24k80>
Ah so some » character would indicate "support" ?
<J24k80>
as modifier?
<J24k80>
maybe easier to add some material() object working like color but with free names
<teepee>
yeah, we probably don't want to have too many names, I do think a dedicated annotation syntax would be better
<teepee>
like most modern languages have, but there's people who don't like that, and yes, it can certainly be abused to make things unreadable
<J24k80>
or just numbers
<teepee>
but somethings like @export(id = "obj-id", name="top-part", type="model") seems not too bad to me
<J24k80>
i mean if a part is one color it can get the color name and we could add "support" as a valid color name too
<teepee>
this could then be handled by the export if the format allows that information to be attached
<teepee>
but what actual color would that be and what happens if you do have a 2nd color?
<J24k80>
the "@" wouldn't be needed
<teepee>
it would be an indicator for the parser
<teepee>
export is not a module here
<teepee>
it't the name (or type) of the annotation
<J24k80>
ah so how do you indicate for which part the export is valid
<teepee>
the one it's attached to like #
<teepee>
so the whole tree coming after that
<teepee>
@export may need to be limited to just top-level
<teepee>
export *selection* may be top-level
<teepee>
but it could still define nested objects, but that's potentially a huge can of worms
<teepee>
the top-level only is mostly doable already due to the lazy union hackery
<J24k80>
what i see what users need is to export a 3mf with multiple objects that have different names (and lazy union is misused more and more to get that)
<teepee>
yes, so it probably makes sense to go with that first as it seems reasonable to do before the sun burns out
<J24k80>
i see so i define multipe @export (meta ) followed by the objects
<teepee>
all the other stuff may come later
<teepee>
yes
<teepee>
with the notable difference that this is not a module *executing* the export
<teepee>
just attaching some meta data for the export later
<teepee>
the export gui could then also have a toggle for "export to single file (if supported) or multiple files"
<J24k80>
but you could use a module to attach that data without execution like color does
<teepee>
so with the same information it could also export x STL files instead of a 3mf with multiple objects
<teepee>
yes, but this only works for instantiated modules - fine for the export use case
<teepee>
I would want to use the same feature also to tag variables, e.g. for the customizer
<teepee>
so @parameter(typehint="slider", range=[0:10]) var = 3;
<teepee>
woud attach meta data to an assignment instead of the ugly messing with comments
<J24k80>
so it could be used for @meta(author="openSCAD") too
<teepee>
and for BOM info you could have it on a module *declaration*
<J24k80>
that is a nice feature to find what is in that library (still need to know what the parts do and parameters should be equal) - wondering that if "no library" was selected why did those show if they are defined as MDAC
<J24k80>
MCAD ..
<J24k80>
teepee reminds me somehow of Doxygen style - while that are comments too
ooxoo has quit [Read error: Connection reset by peer]