<OlivierChafik[m]>
@ccox at least the new debug feature did output the offending operands neatly into .off files so I can try to repro in pure CGAL code :-)
<teepee>
but then, that ship might have sailed 10 years ago :D
<teepee>
anyway, need to get some sleep
<OlivierChafik[m]>
hahaha
<OlivierChafik[m]>
good night!
J2267 has joined #openscad
J22 has quit [Ping timeout: 256 seconds]
ScottJackson[m] has quit [Ping timeout: 240 seconds]
teepee_ has joined #openscad
ScottJackson[m] has joined #openscad
teepee has quit [Remote host closed the connection]
teepee_ is now known as teepee
<InPhase>
teepee: Okay, so sort of 50/50. A built-in downloader/manager, but scripts can suggest what to auto-download for a dependency.
<InPhase>
teepee: What are your thoughts on versioning? Should we ignore it for now?
<InPhase>
There are a couple ways to go. include <git:github.com/....^foo.scad>; could only grab foo.scad from the github marked directory, and if not there, suggest downloading it. Or it could be: include <foo.scad> from <git:github.com/...>; for which the logic might be use foo.scad if it exists, otherwise suggest grabbing it from the provided url.
<InPhase>
The latter provides more nuanced control to the user for version control of a particular library, but means name collisions.
<InPhase>
I guess it's more of a namespacing question than a version question at this point.
<InPhase>
If you grab a whole git repository, I suppose the only logical thing is to load it from within that repository directory for the purpose of relative links working out.
<InPhase>
maybe include <foo.scad @ git:github.com/...>;
<InPhase>
Or do we permit @'s in filenames?
<InPhase>
include <foo.scad> @ git:github.com/...;
IntelHD_ has joined #openscad
<IntelHD_>
beep
walterwhip has joined #openscad
califax- has joined #openscad
califax has quit [Ping timeout: 276 seconds]
califax- is now known as califax
IntelHD_ has quit [Quit: Ping timeout (120 seconds)]
<othx>
Junxter linked to "Parametric Involute Bevel and Spur Gears by GregFrost" on thingiverse => 2 IRC mentions
<Junxter>
openscad 2019.05 and 2021.01 get stuck making even the simplest spur gears
<Junxter>
eventually finishes, but can take up to many minutes to make a single gear (not rendering, only csg preview)
<Junxter>
the exact same gear csg preview takes only seconds with openscad 2015.03
myosotis has quit [Quit: Leaving]
<InPhase>
It takes a couple seconds in the master branch, but not minutes.
<InPhase>
I get 10 seconds without corefinement, 2 seconds with.
<InPhase>
Are you doing anything other than running the built-in test_gears();
<InPhase>
That calls it a "Complex Spur Gear Test"
<Junxter>
the gears library has been incorporated into my design for many years. It ran fine on 2015.03 many years ago, and I just verified they still run fine today on 2015.03.
<InPhase>
Well, perhaps you can share the code that's actually being benchmarked.
<Junxter>
upgrading OpenSCAD to 2019.05 and 2021.03 suddenly broke them, as they get stuck
<Junxter>
and I just tore out the code and tested making individual gear, 2019.05 and 2021.03 both get stuck, and 2015.03 ran fine, on single gear.
<Junxter>
i wonder if gears library itself has been changed ?
<InPhase>
I wasn't able to see a problem with the library as posted on thingiverse running its test, so maybe there's something different you are doing. https://bpa.st is a good way to share the code.
<InPhase>
It previews in 0.051 seconds and renders in 1.38s
<Junxter>
really ...
<InPhase>
That's with 2021.01
<InPhase>
You might have some settings really messed up or something?
<Junxter>
okay.. thanks .. good to know. i will test it on another local machine setup
<InPhase>
Or you're doing something other than what you are trying to do.
<InPhase>
Maybe in your gears.scad you cranked up $fn or something and didn't remember?
<Junxter>
$fn = 72
<InPhase>
You did not actually share gears.scad. I'm using the one from the thingiverse page as-is.
<Junxter>
but why the difference between 2015 and 2019/2021
<Junxter>
gears.scad is used as is . the relevant modification are pasted in
<Junxter>
i.e. small_gear and spur_gear
<Junxter>
basically just with prefilled parameters
<InPhase>
Do you know how to do a diff?
<InPhase>
It could be worth downloading it can and doing a diff to check yourself
<Junxter>
diff in openscad or svn ?
<InPhase>
At the terminal.
<InPhase>
To check for differing lines in the file.
<Junxter>
okay ... i will check the gears file for unintented tamperings
<InPhase>
That's certainly happened to me enough times. :)
<Junxter>
:-)
<InPhase>
I need to rest, but I'll check in the morning to see if you discover anything new. :)
<Junxter>
okay thank you
aiyion has quit [Ping timeout: 276 seconds]
arebil has joined #openscad
aiyion has joined #openscad
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
GNUmoon has quit [Ping timeout: 276 seconds]
arebil has joined #openscad
foul_owl has quit [Ping timeout: 240 seconds]
walterwhip has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
foul_owl has joined #openscad
GNUmoon has joined #openscad
walterwhip has joined #openscad
J2267 has quit [Quit: Client closed]
ur5us has joined #openscad
<bboett[m]>
<Junxter> "diff in openscad or svn ?" <- If you are a graphics guy you can use meld
ferdna has quit [Quit: Leaving]
J22 has joined #openscad
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
arebil has joined #openscad
<Junxter>
bboett: yeah thanks. i use meld on windows.
ur5us has quit [Ping timeout: 256 seconds]
<Scopeuk>
I always want to like meld, the spline lines are pretty and it sort of works but beyond compare (I know its commercial) has always just felt like it did a better job
<Scopeuk>
slip side, I do use meld at home because it's readily avaliable and does the job
<Scopeuk>
s/slip/flip
<Junxter>
i just hope meld getting dark mode
<Junxter>
maybe there is and i just don't know how to get it setup
<Scopeuk>
I think there is but only for the diff window
<Scopeuk>
meld -> preferences and then syntax highlighting scheme on the editor tab
<Junxter>
oh cool ...
<Scopeuk>
I guess the outside window is probably set through window manager, it looks gtk'y
<Junxter>
meld likes to list disk drives in reverse alphabet order during file select ... quircky
<Junxter>
maybe another gtk thing
walterwhip has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<J22>
both objects render ok but the intersection fails
<peepsalot>
OlivierChafik[m]: regarding errors on debug vs release, did you try CMAKE_BUILD_TYPE=RelWithDebInfo ?
<Scopeuk>
J22 generally I would expect that to be degenerate shapes. I would try to preform an intersection with each in turn in a large cube to identify if each item is fine (to force CGAL processing)
<Scopeuk>
it is possible to take two manifold objects and boolean them resulting in nonsense (shared vertex etc) but mor often than not its an imported object that broke
<J22>
adding an offset before extruding the first (meander thing ) solved that - however those error msg just doesn't help and maybe we should force CGAL - is there any advantage not to do it? - as the geometry can be faulty
<J22>
cuz if you try to find a problem and render with ! you need to make a union with a cube so CGAL show the error - this is not a good workflow especially for beginner
myosotis has quit [Remote host closed the connection]
myosotis has joined #openscad
arebil has joined #openscad
epony has joined #openscad
la1yv has quit [Remote host closed the connection]
la1yv has joined #openscad
ferdna has quit [Quit: Leaving]
ur5us has joined #openscad
<OlivierChafik[m]>
peepsalot: learning new cmake voodoo everyday, thanks!
<OlivierChafik[m]>
J22: we should ideally report this to CGAL. I'm thinking we should add some debug feature that would run sanity checks on solids before sending them to CGAL
<OlivierChafik[m]>
So I've tested sloriot's decimation PR and it's the perfect follow up to corefinement / seems to fix the bad performance cases
Junxter has quit [Read error: Connection reset by peer]
<teepee>
heh, with all the patching we don't even need to wait for the 5.5 release :)
<teepee>
appropos numbers... OlivierChafik[m] do you know which version would be minimum to compile at this point?
<teepee>
in readme we already propose cgal 5.3 and I suppose we should bump that soon with the performance fixes
<teepee>
but for cmake I think we should only force what's technically needed
<InPhase>
OlivierChafik[m]: The CGAL team has been resistant to the notion that they should provide better diagnostics, and has actually removed some. They do not seem to appreciate the impurities of the data we feed into CGAL, and regard the only acceptable inputs as proper manifold data, with anything else being undefined behavior. Obviously this is troublesome given that we end up having to feed in user
<InPhase>
input.
<InPhase>
OlivierChafik[m]: So yes, the only real way to deal with this is to increase the sanity checks that we run.
<InPhase>
OlivierChafik[m]: At the heart of this is that CGAL is a math-focused library developed by mostly math-focused people, and we are an applied user-focused program that faces a messy real world.
<InPhase>
OlivierChafik[m]: One thing that I think is particularly important to add is a manifold check at the import of stl files (or other geometry files). Many of these come in from other programs in an unacceptable form, and the error then happens downstream causing massive user confusion. Even if this does nothing more than provide a proper warning to the user that the stl is non-manifold and might cause
<InPhase>
later issues in processing, that alone would save tons of user diagnostic effort, and greatly reduce the number of non-bug issues that are opened on this topic. :)
<InPhase>
So once we get a manifoldness check implemented, it should be additionally run at all imports.
lastrodamo has quit [Quit: Leaving]
<InPhase>
Nearly all issues we experience in this area are either bad stl import, or difference/union overlap problems.
<InPhase>
If the check were fast enough and could be run at all differences and unions, it would sure improve the diagnostics there as well.
<peepsalot>
and, there could be some smart caching/memoization for const geometries with mutable tribool flags or some such
ferdna has joined #openscad
<peepsalot>
if we can guarantee that some input passes precondition but still fails some operation, then i would say that's undeniable evidence of an issue
califax has quit [Remote host closed the connection]
califax has joined #openscad
ur5us has joined #openscad
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
J22 has quit [Quit: Client closed]
GNUmoon has quit [Ping timeout: 276 seconds]
gknux has joined #openscad
GNUmoon has joined #openscad
<peepsalot>
teepee: style question, do we indent the contents of preprocessor conditional blocks? seems like uncrustify just leaves things however they are, is it meant to be handled manually on case-by-case basis?
<peepsalot>
i'm also just now setting up uncrustify in vscode, and not 100% sure i'm using it correctly. Ctrl-Shift-I seems to be the shortcut to invoke on Linux
foul_owl has joined #openscad
<teepee>
peepsalot: I'm not sure about the preprocessor stuff. I'm not seeing any config for that at the first glance
<teepee>
looks like in most cases we have all the # at the first column
<peepsalot>
teepee: hrm, didn't uncrustify also add comments like this on your original formatting commit? #endif // ORIGINAL_CONDITION
<peepsalot>
i thought i saw some of those added when i looked over the diff, did you add those manually? it doeasn't seem to add them for me
<teepee>
yeah, I think I saw some of those in the diffs
<peepsalot>
also, is there a version requirement for uncrustify? which one are you on?
<teepee>
0.72.0+dfsg1-2
<peepsalot>
hrm, okay, i only have 0.69.0+dfsg1-1build1
<teepee>
yep, no preprocessor option configured, those all would start with pp_ it seems
J22 has joined #openscad
epony has quit [Ping timeout: 240 seconds]
myosotis has quit [Quit: Leaving]
epony has joined #openscad
drkow has quit [Read error: Connection reset by peer]
peeps[win] has quit [Read error: Connection reset by peer]