<J2248>
i use a 6mm POM sheet with adhesives onto the bed (for homing a just place a 6mm spacer on the switch) - printing with raft and use a chisel to remove the raft (also have thin kapton grid to minimize adhesion of the raft )
<J2248>
( kapton film with laser cut holes works well but is more work to prepare )
gsker has quit [Remote host closed the connection]
Curt has joined #openscad
TheAssassin has quit [Ping timeout: 276 seconds]
califax has quit [Remote host closed the connection]
califax has joined #openscad
<ccox>
I've got a few 3D editor color schemes ready to test. They're designed more for folks used to 3D sculpting, to minimize blown highlights and shadows, and be easy on the eyes when moving between 3D apps. You'll have to install these in the app resources folder yourself. But I want feedback on them before putting them in github. https://www.dropbox.com/s/cpo9jlqtzy70j63/OpenSCAD_3DView_ColorSchemes_Test1.zip?dl=0
ur5us has joined #openscad
<buZz>
1 feedback ; zips with images are horrible
<buZz>
maybe use imgur? :P
<ccox>
they aren't images, they're JSON files.
<buZz>
oh nevermind , dropbox isnt even working :D
<dalias>
:-p
<buZz>
ccox: right, take screenshots? :D
<ccox>
Screenshots don't let you test them with your 3D designs. But I'll make some screenshots to show them anyway.
<OlivierChafik[m]>
(another learning curve I suppose)
<J2248>
Ü
califax- has joined #openscad
LordOfBikes has quit [Ping timeout: 256 seconds]
califax has quit [Ping timeout: 276 seconds]
califax- is now known as califax
Guest36 has joined #openscad
Guest36 has quit [Client Quit]
LordOfBikes has joined #openscad
<OlivierChafik[m]>
J2248: With fast-csg your cog / wheel renders in 16sec, you might wanna try it in nightly :-)
<J2248>
i am definitely looking forward to it
<OlivierChafik[m]>
(hehe, the library of examples - apart from being absolutely fantastic - is already providing me with some crash cases, Fillets.scad in particular)
<J2248>
oh .. maybe they have issues i am not aware off
<J2248>
or it is from the segmented modules where linear_extrusion and rotate_extrusions are mixed with overlap parameter
<OlivierChafik[m]>
I'll investigate more tomorrow :-)
ToAruShiroiNeko has quit [Ping timeout: 256 seconds]
<J224888>
ok i probably found what is causing this https://pasteboard.co/AXk0x6pAAmLT.png it is how faces a generated when giving 4 points the left has the issues as there are faces with 4 points.. CGAL seems to have a problem with this
<J224888>
ecraven: looks like a paraboloid try .. scale([1,1,3]) sphere(10);
<J224888>
(cut away the lower part you don't need)
<J224888>
or use rotate_extrude with a parabel
peepsalot has quit [Ping timeout: 256 seconds]
<J224888>
teepee inphase can you confirm this?
<J224888>
https://pasteboard.co/AXk0x6pAAmLT.png that the left version causes problems -- when exporting the 4point faces are 3point in both cases but i assume CGAL gets different information and the 3 point faces are done via the 3mf export when feeding 4 point faces
<J22>
the question is also how can there be 4-point faces in the first place - i can't imagine the points are in one plane
<J22>
oh great .. i closed scad and reopened and now the faces are both 3point and it renders without error
<OlivierChafik[m]>
Thanks for the report btw, that's a new kind of issue I hadn't seen!
<J22>
haha and when opening fillets now .. only the middle objects still has errors .. this is some annoying behavior
<J22>
OK this has to do with the cache .. as my lib changes the fn value between preview and render
<J22>
when i preview with the same fn as in render the faces are 3-point
<J22>
so my guess that the render takes some cashed data from the preview without recognizing the changes
<OlivierChafik[m]>
oh, I would assume the cache doesn't mix things up
<OlivierChafik[m]>
I think it uses the csg tree dump string of each node as key, and you can see in Design / Display CSG Tree that this does include $fn
<J22>
so what is it .. if i use the same module one with one without the render fn .. both work .. if i remove it both fail
<J22>
so render of object A depends on object B's parameter in preview
<OlivierChafik[m]>
the F5 rendering glitch could be due to some wrong face orientations after the corefinement, I'll have to dig a bit deeper
<J22>
it seems there is information that is not flushed when flush cache
<J22>
ah no my bad ( with one object CGAL is not involved)
<J22>
.. flush cache .. F6 ⇒ error .. but F5 F6 works (also error if i remove the first object and replace with cube)
auctus has joined #openscad
<auctus>
lol. NICE work on the speedup. I love it
<auctus>
my personal hobby model i am working on, cartridge reader game console thing
<auctus>
on the stable version it takes 15 seconds to render, on the latest nightly it takes 8 seconds to render, and with fast-csg it takes 1.4 seconds.
<OlivierChafik[m]>
J22: could you please update https://github.com/openscad/openscad/issues/4115 with your findings? (if it's still about the same model) Today I'm treating myself with some graph algorithms, will enter bugfix mode tomorrow :-)
<OlivierChafik[m]>
auctus: thanks, glad it works for you!
<OlivierChafik[m]>
(hopefully more improvements are coming - minkowski on its way - and bugfixes!)
<J22>
OlivierChafik[m]: the bug i fonud has nothing to do with fast CSG
<OlivierChafik[m]>
J22: ah ok, I'm half-relieved then haha!
_xxoxx has quit [Quit: Leaving]
_xxoxx has joined #openscad
_xxoxx has quit [Remote host closed the connection]
Junxter has joined #openscad
<buZz>
auctus: oo can i see your game console? :)
<Junxter>
InPhase, I'd like to report an apparent bug. still relating to issues that show up with the parametric gears library.
<Junxter>
preview of simple spur gears takes mere seconds in openscad 2015, but hangs for minutes in 2019 and 2021
<Junxter>
this happens when .scad files are located on a samba network share. if .scad files are local, there's no difference across 2015 / 2019 / 2021, they all preview quickly
<Junxter>
so apparently there's a change in behavior of how openscad handles files located on network shares vs local
<buZz>
Junxter: just a hunch, is your ipv6 working?
<Junxter>
i had ipv6 turned off locally
<buZz>
maybe the later versions try to do ipv6 samba to your shares, timing out on failures
<buZz>
also remotely?
<Junxter>
the samba share is also local, on a linux vm
<Junxter>
host is win7
<Junxter>
buZz: good idea. let me test see if ipv6 makes a difference
<buZz>
Junxter: just a hunch based on a pile of 'weird issues' i solved recently by turning 'half working ipv6' off :D
<Junxter>
buZz: okay
<Junxter>
on a separate issue, is there a way to combine the following two functions inline? I am using them across my design as a associative array lookup.
<Junxter>
on complex designs, i am packaging relevant dimension of subassemblies into associative array, to avoid naming conflict across different subassemblies
<Junxter>
and using dict() function to pick out the element from the associative array, as implemented, can be either one dimensional (one key) or two dimensional (two keys)
<Junxter>
the dict function is very compact, but must be included into every subassembly with dimension variable definitions. I wonder if there's a short hand that could allow in-line definition of dict()
<OlivierChafik[m]>
Got some promising results to do the remeshing by myself... (using a corefinement visitor to keep track of the faces that were split in both operands, keep track of the edges that were added, and use the existing remeshing routines on those faces, protecting all but those edges and their descendants).
<teepee>
nice, would it make sense to try changing the behavior?
<teepee>
I suppose it's probably better to leave that for later and separate
<OlivierChafik[m]>
you mean fence the change under some feature? the behaviour should be unchanged otherwise
<OlivierChafik[m]>
(famous last words)
<teepee>
no
<OlivierChafik[m]>
I was seeing this as a bug fix, given how convoluted the conversions back and forth with the nef was
<teepee>
the question might be even more obvious for hull, but I think it would apply to minkowsi too
<teepee>
both are currently not able to mix 3d and 2d
<teepee>
and a least in theory that's not a needed separation
<teepee>
so yeah, it's probably not a good idea to do both things at once
<OlivierChafik[m]>
yes the point cross-product part seems easy to generalize to 2d
ur5us_ has quit [Ping timeout: 240 seconds]
<OlivierChafik[m]>
I'm still not 100% sure how the algorithm works, except that it works so much faster than CGAL's own (is it just because of our "weak" convexity testing?)
<OlivierChafik[m]>
I mean, happy to look into the 2d/3d mix as a follow up
<OlivierChafik[m]>
is there already an issue for that?
<teepee>
not sure, I think the weak part is just trying to skip those polygons which are slightly non-planar due to numerical issues
<teepee>
but that change was done a long time ago and unfortunately Oskar did not follow up on some of the extremely cool stuff he was working on
<OlivierChafik[m]>
ah makes sense
<OlivierChafik[m]>
oh, what kind of stuff?
<teepee>
there's a 2D sweep PR which is mostly working and he was working on 3D sweep too
<OlivierChafik[m]>
oh nice!
<OlivierChafik[m]>
is it using the CGAL sweep functions, or custom?
<teepee>
I think it was all custom, but still based on some CGAL stuff IIRC
<teepee>
oh, my 2014 - that's pretty much the time I got involved with OpenSCAD :)
<OlivierChafik[m]>
wow that is pretty awesome!
<teepee>
yep, there's a couple of more awesome animations scattered somewhere, like moving gummi bears moving on a sweeping 3d thing :)
<teepee>
sadly he did not have the time to finish the bigger topics, but he certainly brought some nice smaller changes like that minkwoski optimization
<OlivierChafik[m]>
hehe, hope someone picks it up again someday
<OlivierChafik[m]>
I haven't been using minkowski much to date, still unsure what it can do for me
<OlivierChafik[m]>
also, minkowski and hull aren't exact currently, wanted to try switching them as a next step
<OlivierChafik[m]>
at least now the user-space sweeps based on unions of "delta" hulls are feasible to render
<teepee>
true, and some other point I've seen might help too
<teepee>
in one of the CGAL discussions there was also the self-intersections mentioned
<teepee>
right now those pretty much mean breaking the model, if those could be handled in a bit more relaxed manner that would help a lot too
<OlivierChafik[m]>
I was toying wiht the idea of a `repair` function that would use the full power of CGAL
* teepee
imagines lazy script like repair() do_something() repair() do_something_else();
<teepee>
:)
<teepee>
I assume it would be very useful, especially for external stuff like STL
<OlivierChafik[m]>
one problem is where do we draw the line. do we include decimation / mesh simplification / etc (That normally you'd do in other tools)
<OlivierChafik[m]>
if there's appetite for that I'd love to try something, maybe we could open an issue on cgal to ask them for guidance re/ how to best repair things
<teepee>
long time ago there was a subdiv() which was never implemented :)
<OlivierChafik[m]>
but first maybe some disk caching haha
<teepee>
the code for that is mostly ready in a PR
<J22>
if available why not offer it .. nobody is forced to use it - Ü
<teepee>
that was a GSoC project
<teepee>
well, the point of just extending the language has some drawbacks for future use
<teepee>
e.g. if we start forcing everything to be handled as a mesh, there's no way to also extend to SDF
<teepee>
the language does not dictate that at this point, except maybe for minkoski and hull which are difficult with anything except mesh
<J22>
can't it be optional?
<teepee>
yes, but also in an obvious way to the user
<teepee>
like flagging a number of operations as "do not use if you want to export to STEP or use the SDF engine" is probably fine
<OlivierChafik[m]>
the risk is this stops working in the future
<OlivierChafik[m]>
what about... external calls
<teepee>
if we do things like linear_extrude(..., fix_mesh = true); then it really becomes difficult to explain what's going on
<OlivierChafik[m]>
define ffi to external plugins that do whatever, and integrate into the rendering workflow
<OlivierChafik[m]>
then we'd provide a set of plugins, they'd read their input in some well defined serialized format
<teepee>
maintaining interfaces it quite some burden on the dev side, I'm not sure we could handle that
<OlivierChafik[m]>
instead of having to maintain N new features we then have to maintain the plugin interface
<teepee>
it's fine to have things in the language that may not be used in some contexts
<teepee>
i'm just saying it needs to consideration on how to do it to not incentivise people to write scripts in an inherently incompatible way
<J22>
.. or like cura "experimental"
<OlivierChafik[m]>
right now I assume lots of people would preprocess their imported stl in another tool
<OlivierChafik[m]>
going in the direction of pipelines: has there been efforts to show users a profile of the rendering? I was thinking like an overlay on the source code, with what is executing right now, etc
<OlivierChafik[m]>
when something is slow it's quite mysterious right now
<OlivierChafik[m]>
if we had a multiprocess model with some of the work done in the PR that serializes things over, we get better potential for monitoring and for FFI
<teepee>
there was some idea, but it's also 2 topics. evaluation and mesh-calculation
<OlivierChafik[m]>
but yeah a big power of OpenSCAD is it's quite a standard & stable thing
<teepee>
as with the big user space libraries the evaluation becomes important too, not so much for "classic" scripts
<OlivierChafik[m]>
maybe we could have a separate batch "pipeliner" binary for the heavy renders, supporting render farms, etc
<OlivierChafik[m]>
it would work off the .csg dumps (do they support everything?)
JakeSays_ has joined #openscad
JakeSays has quit [Ping timeout: 256 seconds]
<teepee>
minus some glitches, they should
<teepee>
but there's some complications with includes and imports as those are passed into csg without change
<teepee>
well, use<> not include
<OlivierChafik[m]>
oh! maybe we we could inline the geometry in place of the import?
<teepee>
but there was some effort to make include<> a Node too, not handled like it's now in the parser
<teepee>
that would be an idea, and even something useful for caching stuff like text() and svg() converted to scad instead of direct geometry
<OlivierChafik[m]>
use<> imports the definitions but not the content, right? wouldn't impact csg?
<teepee>
probably, but right now I think it just writes out the use<> again?
<teepee>
actually I'm not 100% sure
<teepee>
no, looks like it's not included in the csg
<teepee>
I guess that's not a problem for normal geometry
<teepee>
but would be a problem if use<> defines a font file
<OlivierChafik[m]>
ah, so I guess the nodification effort would help as we'd then "just" have to flatten more of the tree
<teepee>
it might, yes. all that is not used too much, so there's probably lots of corner cases nobody really looked at yet
<teepee>
the only bigger use case for CSG files is the FreeCAD importer I think
snaked has quit [Remote host closed the connection]
snaked has joined #openscad
<ccox>
(wonders why fast-csg is being so slow.... forgot that I launched a debug build.... doh!)
<OlivierChafik[m]>
from that perspective I guess we wouldn't want any new feature that doesn't export to inlined geometry in the csg output, short of breaking that importer and any other csg readers
<OlivierChafik[m]>
ccox: I've had a few panic moments like this!
Xeha has quit [Ping timeout: 240 seconds]
<ccox>
Hmm, should light colors and positions be part of the render color scheme, or considered separate settings from the render color scheme?
<ccox>
Logically (and code-wise) they are separate, but I can also see a viewpoint where they should be related and changed together.
<OlivierChafik[m]>
(unfamiliar with that, but does that impact what can be done with animations?)