teepee changed the topic of #openscad to: OpenSCAD - The Programmers Solid 3D CAD Modeller | This channel is logged! | Website: http://www.openscad.org/ | FAQ: https://goo.gl/pcT7y3 | Request features / report bugs: https://goo.gl/lj0JRI | Tutorial: https://bit.ly/37P6z0B | Books: https://bit.ly/3xlLcQq | FOSDEM 2020: https://bit.ly/35xZGy6 | Logs: https://bit.ly/32MfbH5
<gbruno> [github] kintel edited pull request #4570 (Refactored all the various GL error checking macros) https://github.com/openscad/openscad/pull/4570
Av8r has joined #openscad
<gbruno> [github] kintel pushed 8 modifications (Style fixes) https://github.com/openscad/openscad/commit/2f5ad86598dccb16313a198d6693e065d6c4d8b2
<gbruno> [github] kintel synchronize pull request #4570 (Refactored all the various GL error checking macros) https://github.com/openscad/openscad/pull/4570
TheCoffeMaker has joined #openscad
TheCoffeMaker has quit [Remote host closed the connection]
TheCoffeMaker has joined #openscad
TheCoffeMaker has quit [Client Quit]
TheCoffeMaker has joined #openscad
<gbruno> [github] kintel pushed 2 modifications (Fix trace statements with compiler errors) https://github.com/openscad/openscad/commit/e092d354d23345a79940484c908d5561b942bfea
<gbruno> [github] kintel edited pull request #4570 (Refactored all the various GL error checking macros) https://github.com/openscad/openscad/pull/4570
<gbruno> [github] kintel synchronize pull request #4570 (Refactored all the various GL error checking macros) https://github.com/openscad/openscad/pull/4570
<gbruno> [github] kintel edited pull request #4570 (Refactored all the various GL error checking macros) https://github.com/openscad/openscad/pull/4570
<gbruno> [github] kintel edited pull request #4570 (Refactored all the various GL error checking macros) https://github.com/openscad/openscad/pull/4570
<kintel> To everyone writing GL code: My GL macros are ready to merge, if you have any comments: https://github.com/openscad/openscad/pull/4570
<linext> one reason why the menger sponge render might be reporting as failed / passed unreliably under the manifold library update
<linext> the render time is so short
<linext> less than 1 second
<linext> almost as fast as the preview
<linext> another thing i noticed, when cranking menger up to n=5 or n=6... the entire PC gets laggy like the late 1990s
<linext> you might want to cap how much CPU openscad can now use during multi-core
<linext> this is with openscad for windows, not the wasm
<InPhase> kintel: Right right. I went searching for your -11 for a while, trying to figure out what this was from... But it's just a question of how ctest is reporting the number. For return from a segfault, the error code on Linux is 139. That's bit 7 being 1 to indicate a signal, and 11 in the lower 7 bits to indicate signal 11, segfault. ctest is then reporting this as "-11". So your problem is just that
<InPhase> OpenSCAD is segfaulting.
<InPhase> kintel: With emphasis on "just", I guess.
<InPhase> kintel: Although as long as that's only happening intermittently within the Manifold branch, I suppose that sort of problem is to be expected at this early stage.
<kintel> InPhase Thanks, that helps, I guess we just keep an eye out for it for now..
<InPhase> Unfortunate that it's intermittent.
<InPhase> Potentially a threading issue.
<InPhase> Hopefully we don't have a problem with non-threadsafe mutables or something.
<InPhase> Although that might also explain the intermittent render failures I was seeing.
<InPhase> There's definitely a pile of non-deterministic failure going on.
<InPhase> Maybe I'll leave a note on that issue. That could be a helpful direction for ochafik to think in tracking it down.
<linext> is there a tutorial for making a chamfer using slices that are scaled based on sin/cos and smoothed with hull?
<linext> or maybe log or exp
<InPhase> What do you mean by "scaled based on sin/cos"?
<linext> making a smooth chamfer
<linext> if i use sin/cos i can get a curv
<InPhase> You mean "a circle"?
<linext> i guess a quarter of a circle
<linext> that's good enough for my needs
<InPhase> I've often done the rotate_extrude of a square with a circle eaten out of it to do this.
<linext> i like this guy's design and want to improve upon it using openscad: https://www.thingiverse.com/thing:4814030/files
<Virindi> for chamfers of a single edge, you can just make a cube with that edge inside it, subtract a cylinder from that, and then subtract that from your object
<linext> i like that idea
<Virindi> it is quite simple
<Virindi> it gets more complicated when you want to deal with corners
<InPhase> There's often no clear definition for what a chamfer should do at a corner anyway.
<linext> dschroer published a program designed to fill that missing feature
<Virindi> yeah especially corners with an arbitrary number of edges entering them
<linext> i haven't tested it yet
<linext> "It offers some novel ideas such as:
<linext> chamfer and fillet operators to simplify part creation
<linext> "
<InPhase> linext: I put some very basic stuff designed to be stolen here: https://github.com/rcolyer/smooth-prim
<InPhase> linext: Some libraries are ones to include. That one I advocate just taking the bits you want, treating them as examples, and tweaking them if needed, as there are very few interdependencies.
<InPhase> And each one is short.
LordOfBikes has quit [Ping timeout: 276 seconds]
<linext> thx
<linext> InPhase, did you get a chance to try the manifold feature update?
<InPhase> I did. It's truly impressive. And unstable, but that's to be expected.
<InPhase> I got up to 0.8 meters by 0.8 meters of millimeter thick strands of interwoven thread rendered with it.
<InPhase> And it took only about 4 minutes. The limit is not time, but it's that it fails from bugs above that size.
<InPhase> So with them fixed I will push that much larger. :)
<InPhase> I had tried large sizes like that in 2016, and it was a complete failure.
<InPhase> So already it has turned impossible into possible. (With the help of a couple computer upgrades since then.)
<linext> i ran some of the 3d recursive trees we were playing around with a month ago
<linext> some truly amazing results when the numbers are cranked up
<linext> i haven't added the manifold wasm update to 3dcustomizer yet
<InPhase> I intended to do relative benchmarking of preview vs render, but unfortunately it was too unstable to complete my testing. So I left an issue report.
<InPhase> Also I accidentally picked a design that was hitting manifold a bit during preview. But I will try this again later.
<linext> manifold is enabled on ochafik
<Virindi> manifold seems faster than preview for a lot of cases
<linext> and WASM won't lock up your PC
<Virindi> lock, pfft
<Virindi> it doesn't with linux :)
<linext> i've got a top of line 7900x with 32gb of ram
<linext> when i really push openscad, my cursor gets jumpy like it's 1990s
LordOfBikes has joined #openscad
<Virindi> that is windows being stupid?
<linext> could be, but CPU usage spikes
<linext> i don't know if manifold is to blame for using all my threads
<linext> ram usage doesn't get too high
<linext> for example, try the menger sponge example and crank up to n=6
<Virindi> wow it is using a lot of ram
<Virindi> it allocated 56gb
<Virindi> openscad segfaulted.
<linext> ah maybe windows started using my SSD page file
<Virindi> it didn't run out of ram though, I have 128gb
<linext> it handled n=5
<linext> 59.9 GB used
<Virindi> no doubt the problem is that your computer is swapping
<linext> i guess manifold feature doesn't matter so much for ram usage
<linext> maybe InPhase can benchmark memory usage as well
<Virindi> I tried it again and this time it is acting completely differently
<Virindi> memory is only going up slowly and it is only using a single core
<Virindi> and progress is stuck at 666/1000
<Virindi> oh, there it goes
<Virindi> aaand segfault
<Virindi> luckily that is a ridiculously unrealistic test ;)
linext has quit [Ping timeout: 276 seconds]
little_blossom has quit [Ping timeout: 276 seconds]
little_blossom has joined #openscad
J2385 has joined #openscad
J23 has quit [Ping timeout: 260 seconds]
<InPhase> Virindi: Manifold is currently randomly segfaulting.
<InPhase> We were just discussing that above a bit.
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
ur5us has quit [Ping timeout: 240 seconds]
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
splud has quit [Ping timeout: 248 seconds]
splud has joined #openscad
L29Ah has quit [Ping timeout: 276 seconds]
J2385 has quit [Quit: Client closed]
J2385 has joined #openscad
use-value has joined #openscad
L29Ah has joined #openscad
castaway has joined #openscad
Guest62 has joined #openscad
fedorafan has joined #openscad
L29Ah has left #openscad [#openscad]
Guest62 has quit [Quit: Client closed]
castaway has quit [Ping timeout: 265 seconds]
Wolf480pl has quit [Quit: ZNC disconnected]
Wolf480pl has joined #openscad
Guest62 has joined #openscad
<Guest62> Hello!
castaway has joined #openscad
Guest62 has quit [Quit: Client closed]
use-value has quit [Quit: use-value]
use-value has joined #openscad
snaked has quit [Quit: Leaving]
<Scopeuk> 23 seconds impressive
kintel has joined #openscad
<Virindi> I don't even care honestly, it hasn't segfaulted yet in real use for me, even if it does every once in awhile that is still probably worth it
guso78 has joined #openscad
ente` has joined #openscad
ali1234 has quit [Remote host closed the connection]
ali1234 has joined #openscad
<gbruno> [github] kintel closed pull request #4570 (Refactored all the various GL error checking macros) https://github.com/openscad/openscad/pull/4570
<gbruno> [github] kintel pushed 15 modifications (Refactored all the various GL error checking macros (#4570) Refactored all the various GL error checking macros into common macros in system-gl.h) https://github.com/openscad/openscad/commit/40f973eab5bee6ef961542818a2905ffea4ec495
<gbruno> [github] kintel pushed 9 modifications (Remove support for OpenGL < 2) https://github.com/openscad/openscad/commit/b6a91837a10be6995c3e0cdb4669aa07d9b675e5
<gbruno> [github] kintel synchronize pull request #4550 (Remove support for OpenGL < 2) https://github.com/openscad/openscad/pull/4550
<gbruno> [github] kintel pushed 1 modifications (Removed test func) https://github.com/openscad/openscad/commit/d3fac609f42bea6941336e7c233e6fc2541609c6
<gbruno> [github] kintel reopened pull request #4549 (Add support for GLAD) https://github.com/openscad/openscad/pull/4549
<gbruno> [github] kintel synchronize pull request #4549 (Add support for GLAD) https://github.com/openscad/openscad/pull/4549
<gbruno> [github] kintel pushed 3 modifications (beautify) https://github.com/openscad/openscad/commit/fb603d7c8f8cb2cecb830bc32598f6259b708e7d
<gbruno> [github] kintel synchronize pull request #4549 (Add support for GLAD) https://github.com/openscad/openscad/pull/4549
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
<ente`> moin
teepee_ is now known as teepee
<gbruno> [github] kintel synchronize pull request #4549 (Add support for GLAD) https://github.com/openscad/openscad/pull/4549
<gbruno> [github] kintel pushed 7 modifications (beautify) https://github.com/openscad/openscad/commit/d550a6144e763813c36022afb76443850b4c51c3
<J2385> ente` moin
fedorafan has quit [Ping timeout: 260 seconds]
fedorafan has joined #openscad
<Virindi> hmm. if I have a cube and subtract a cylinder from it with a diameter of 0.5mm, then take a projection cut, I get
<Virindi> ERROR: CGAL error in CGAL_Nef_polyhedron3(): CGAL ERROR: assertion violation!
<Virindi> Line: 418
<Virindi> File: /usr/include/CGAL/Nef_3/SNC_FM_decorator.h
<Virindi> Expr: e_below != SHalfedge_handle()
<Virindi> strangely it works when I try to break out the offending code into a separate test
<Virindi> should I file a bug report on this? or is it a known problem or something I am doing wrong? I made a minimal repro file: https://pastebin.com/HERn6MEL
<Virindi> 2023.03.21.nightly
<Virindi> oops
<Virindi> apparently I removed one too many things from that
<Virindi> this one definitely does it https://pastebin.com/mRnQTzz0
<Virindi> strangely, if I try to preview a second time, it just says no geometry to render
<Virindi> fooled me with that, the first one does cause it.
<InPhase> Looks fine to me.
<InPhase> Did you flush cache?
<Virindi> open new process of openscad, paste in first link into editor, select preview from the menu
<Virindi> assertion failed
<InPhase> Virindi: As for segfaulting on Manifold, a bigger problem is that the probability of a render failure seems to go up with design complexity.
<Virindi> 2023.03.21.nightly, debian bullseye x86_64
<InPhase> I was testing on a 2023-03-18 build, so I'm pulling and rebuilding to try again.
<InPhase> I'm using your mRnQ link.
<Virindi> both do it
<InPhase> First preview looks fine, and the ridiculously tiny holes are visible. First render also looks fine.
<InPhase> 2 more sequences of preview in a row also work, no errors from any of those.
<InPhase> Likewise fine for multiple renders in a row with or without flushing cashes.
<Virindi> okay, I have enabled: manifold, all vbo options
<Virindi> vertex-object-renderers, vertex-object-renderers-indexing, vertex-object-renderers-direct, vertex-object-renderers-prealloc
<InPhase> I tried those settings, still works.
<Virindi> hrmm
<Virindi> what could be different.
<InPhase> No error either with those settings, nor with the latest 2023-03-22 nightly downloaded as an AppImage with or without those settings.
<Virindi> I can try that version.
<InPhase> Manifold should probably not be giving you CGAL errors anyway.
<Virindi> it happens with preview
<Virindi> there isn't a render() in there
<Virindi> so it is while it is generating the preview?
<InPhase> Do we even have preview displaying CGAL errors? I thought there was a bug eating those during preview.
<teepee> I suppose projection() still needs CGAL
<InPhase> Oh... Damn it. I deleted the projection() as a test.
<InPhase> Trying again...
<Virindi> hmm, I only see "2021.01" as an appimage to download
<InPhase> Scroll down.
<Virindi> ah
<Virindi> sorry :)
<Virindi> cannot launch that one, it segfaults.
<InPhase> Ok. When I put the projection back it gives your CGAL error now with your settings.
<Virindi> phew
<InPhase> Specifically Manifold is required to trigger it.
<InPhase> Without Manifold, no error.
<Virindi> interesting
<InPhase> And both on the nightly and my build, with Manifold enabled, if and only if projection is there.
<InPhase> You should post that as a Manifold issue.
<InPhase> Note in the issue that the projection is the trigger point.
<InPhase> It seems reliable, so it's passing data wrongly into CGAL most likely.
<InPhase> reliable meaning consistently erroring
<Virindi> if you change any of the geometry it doesn't happen, which is amusing because it is so specific
<Virindi> are my advanced tab settings changed from default? I don't remember if I set them to that or not
<Virindi> want to know if I need to note that in the report
<Virindi> I think I might have changed the cache sizes
aliervo[m] has quit [Quit: You have been kicked for being idle]
<Virindi> guess I will just link the pic
<gbruno> [github] Virindi-AC2 opened issue #4574 (Manifold - CGAL assertion failed with projection()) https://github.com/openscad/openscad/issues/4574
<Virindi> :)
<InPhase> You can always test defaults by closing, renaming your config directory, testing, deleting the new config directory, and renaming the stored one back.
<InPhase> Just make sure you close each time before messing with the config directory.
<InPhase> If you leave it open you might get an unpleasant surprise.
<gbruno> [github] kintel edited pull request #4549 (Add support for GLAD) https://github.com/openscad/openscad/pull/4549
<gbruno> [github] kintel edited pull request #4549 (Add support for GLAD) https://github.com/openscad/openscad/pull/4549
L29Ah has joined #openscad
Ckat has joined #openscad
guso78 has quit [Ping timeout: 260 seconds]
krab_mozga has joined #openscad
<gbruno> [github] kintel pushed 2 modifications (Build fix) https://github.com/openscad/openscad/commit/96836dcd7392fbe99b769c74bdb6f140e78f419c
<gbruno> [github] kintel synchronize pull request #4549 (Add support for GLAD) https://github.com/openscad/openscad/pull/4549
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<krab_mozga> Hello! Could you explain me general approach to model partitioning. Something like https://github.com/revarbat/BOSL2/wiki/partitions.scad partition or like freecad slice apart in part workbench. I want to a) define model b) define partition surface and c) get two separate models as stl for printing.
<InPhase> krab_mozga: It's basically just intersection or difference with a large cube oriented correctly.
<krab_mozga> If you partiton by plane then yes. But if it's more complicated than plane?
<InPhase> krab_mozga: Although sometimes it's beneficial to plan ahead and design two pieces separately, so that you can think about printability of each piece more carefully, and so you can think about options for attaching them, such as with metal screws, printed screws/threads, or snap-fit components.
<InPhase> Most often I do them separately for this reason.
<InPhase> I will then simply have a preview-mode where I overlap them appropriately to visualize the assembled part.
<krab_mozga> I saw people do that. Say single procedure that take flags as a parameter to select which part of partition to create.
<Virindi> if you want a complex separation, make some geometry that encloses one side of it and subtract from the model, and for the other side make a huge cube, subtract your geometry, and subtract that from the model
<teepee> usually it's better to keep the parts separate and have an assembly view
<Virindi> yeah that is true but you can also have a part with a complex internal structure that you want to display
<teepee> but as always, it depends on the model, like there might be reasons for a full single design and using some sort of puzzle-cut library to separate
<teepee> aww, no manifold yet and WASM just crashed firefox :)
krab_mozga has quit [Ping timeout: 260 seconds]
<gbruno> [github] kintel pushed 7 modifications (Green refactoring: Move duplicated FBO handling out of platform-specific context code) https://github.com/openscad/openscad/commit/ed11963b0cbbe028e0cba9d689510a7ebbc8aff6
<gbruno> [github] kintel pushed 9 modifications (Remove support for OpenGL < 2) https://github.com/openscad/openscad/commit/64e2a4298187a279d7f2f06f9adf69f47a7deb8d
<gbruno> [github] kintel synchronize pull request #4550 (Remove support for OpenGL < 2) https://github.com/openscad/openscad/pull/4550
<gbruno> [github] kintel opened pull request #4575 (Green refactoring: Move duplicated FBO handling out of platform-specific context code) https://github.com/openscad/openscad/pull/4575
L29Ah has left #openscad [#openscad]
fedorafan has quit [Ping timeout: 248 seconds]
Joel has quit [Read error: Connection reset by peer]
fedorafan has joined #openscad
Joel has joined #openscad
<kintel> Any concerns related to killing off OpenGL 1.x support? https://github.com/openscad/openscad/pull/4550
<Virindi> what operating systems/configurations/whatever does that eliminate?
<Virindi> it seems bad to eliminate support just because you can
<Virindi> maybe someone out there is having fun running openscad on win98, heh
<gbruno> [github] kintel pushed 2 modifications (Build fix) https://github.com/openscad/openscad/commit/b44940b2f32b5de8c7983a149e652413ede515bb
<gbruno> [github] kintel synchronize pull request #4549 (Add support for GLAD) https://github.com/openscad/openscad/pull/4549
<kintel> It eliminated OSes which haven't updated drivers in 19 years :) I doubt there are any users out there with such workflows. This is a baby step towards modernizing OpenGL, and to make refactoring cheaper in the future as we have no good way of testing this
<InPhase> kintel: I checked logs going back to May 2021. The last mention of it was teepee in November struggling with the Windows CI system dll only having OpenGL 1.3, but he resolved it by msys2 installing mesa.
<kintel> Our Windows build requires Windows 7+ anyway ;)
<InPhase> kintel: That and repeated mentions by this kintel guy who ponders regularly about wanting to get rid of it.
<Virindi> 7, wow, that is a newer windows version than I have used :P
<kintel> Yeah, Microsoft deprecated OpenGL a loong time ago, so you always need to install drivers under Windows
<teepee> it eliminates plain windows (no dedicated graphics driver), but that does not work right now anyway
<teepee> I think windows 7 currently does not work, as it needs some sort of extra DLL
<teepee> so at this point it's probably Win10 minimum
<teepee> introduced by the MXE toolchain / compilers / libraries, not actually OpenSCAD itself
<kintel> I guess Windows7 may be a Qt limitation
<gbruno> [github] kintel ready_for_review pull request #4575 (Green refactoring: Move duplicated FBO handling out of platform-specific context code) https://github.com/openscad/openscad/pull/4575
<teepee> I could not find that DLL entry in Qt, and gcc seems to be setup for win7+
<teepee> so I don't know what introduces that DLL dependency that's only available in later version
<teepee> I seem to remember I found some separate DLLs shipped with a Java application (SoapUI IIRC) which might actually have that
<guso78[m]> If offscreen Contest IS PNG writer IT might solve my Texture issue
<teepee> hmm, not sure if that's merged, there's a PR for PNG writing via offscreen
<teepee> the older way was grabbing the Qt viewport
<teepee> or do you mean from command line? that's always offscreen of course
<gbruno> [github] kintel pushed 2 modifications (Build fixes) https://github.com/openscad/openscad/commit/ee1dd6d82c21cdfc338bfdd42ab1eed66edb18a6
<gbruno> [github] kintel synchronize pull request #4575 (Green refactoring: Move duplicated FBO handling out of platform-specific context code) https://github.com/openscad/openscad/pull/4575
<guso78[m]> Yes ctests are Always command Line. ITS Just about to make Them happy 🤣
<Scopeuk> If someone really wants it on bare win7 with no acceleration Mesa can be used as a shim
* Scopeuk has done it for a different application on win10 on a server with no hardware acceleration. No application support required
<kintel> guso78: In terms of your texture issue, did you try run the cmd-line tests without VBO support?
<guso78[m]> Kintel, few Tests failed on command Line, but all of Them were ok in GUI. The failed cmd Line Tests were ok without vbo Buffer. When i Tried to disable vbo for All ctests i got many many failed Tests. Actual Picture was incorrectly Red.
<kintel> right, so it sounds like you perhaps didn't implement (correctly) texture coordinate handling for the VBO renderer?
<kintel> anyway, I expect one of the outcomes of my GL cleanup project will be to rewrite the VBO renderer and make it the default.
<kintel> ...one day
n1essa has quit [Ping timeout: 250 seconds]
<kintel> teepee Not sure if you saw my message from a night or two ago: Our Manifold build system integration is really scary; it leaks stuff back into the OpenSCAD build. Did you look at or have any thought about how to manage/derisk that?
n1essa has joined #openscad
<InPhase> kintel: Was include() used instead of add_subdirectory()?
<kintel> no, add_subdirectory() is used, but it creates cached global variables
<InPhase> But it's not supposed to?
<kintel> The bug I was chasing was caused by some submodule under Manifold looking for Python and preferring Python2
<kintel> ..and that was overriding our own python check
<InPhase> I believe you. But I'm confused... Since it seems to say that shouldn't happen.
<kintel> ..and I have no idea what else could break
<kintel> it's possible that it leaks through env. variables or other side effects
<kintel> If there is some cmake guarantee we could trust that would be very nice.
<teepee> kintel: I don't see an easy way doing that. I would prefer including a library but Manifold does not even have a make-install at this point (it does install Clipper2 only when actually running make install)
<teepee> it would be good moving into that direction, but it's lots of places to update so it's going to take some time
<InPhase> We could also brutally exec cmake instead.
Abrasive21 has joined #openscad
Abrasive21 has quit [Client Quit]
<kintel> InPhase I guess cmake _variables_ are scoped, but cmake _targets_ are global
<kintel> ..so FindMacros which create targets will potentially leak out of add_subdirectory()
<InPhase> Well we have EXCLUDE_FROM_ALL set to exclude targets from ALL.
<InPhase> But I guess it's not very comprehensive.
<teepee> that was what I found for prevening Clipper2 installation
<teepee> if that's a good idea, not sure, there seems to be a debate if that's even officially supported
<teepee> I think ideally everything that's not just header-only libraries should really be an actual library
<teepee> but who knows how many years it will take to just do install manifold-dev
<gbruno> [github] kintel synchronize pull request #4575 (Green refactoring: Move duplicated FBO handling out of platform-specific context code) https://github.com/openscad/openscad/pull/4575
<gbruno> [github] kintel pushed 1 modifications (More build fixes) https://github.com/openscad/openscad/commit/c1ef7ed4601707e5a8c213017c863856558f19c4
<teepee> hmm, minimum would be 1) get a make install into manifold 2) homebrew 3) mxe 4) OBS packages
RichardPotthoff has joined #openscad
<teepee> WASM shoud be ok-ish, AppImage probably too. Snap, meh
<teepee> hmm, scratch homebrew, that would go via the macos build script
<Virindi> is it expected that Manifold says "ERROR: The given mesh is not closed! Unable to convert to CGAL_Nef_Polyhedron." when two geometries overlap? was trying to workaround my problem and it generated a totally different error heh
<teepee> that means you are using an operation that needs CGAL
<Virindi> yeah I was modifying my projection() code which caused the previous bug and now instead I get this
<teepee> minimum projection() and minkowski(), but there might be more
RichardP_ has quit [Ping timeout: 250 seconds]
<Virindi> is it worth mentioning the code which causes not closed in the bug, or is it expected?
<Virindi> not sure if it is another manifestation of the same problem
<teepee> if it's reasonably sized, more info is usually better
guso78 has joined #openscad
<guso78> Python-OpenSCAD is finnallly running in Windows!
<teepee> well, more specific and related information :)
<teepee> guso78: oh, nice, what's the trick?
<guso78> its not yet perfect
<guso78> first i tried to compile python with mxe, but failed
<guso78> but i simply reused the libpython-3.10.dll.a from msys2-64 and it worked out of the box
<teepee> hmm :(
<guso78> not your expectation :)
<Virindi> I guess if it works without manifold but fails in manifold, it must be a bug
<teepee> well, if we want to integrate with the normal builds, there's some limits to the messieness ;-)
<Virindi> which it does
<guso78> i understand. but for myself  i see gain
<teepee> that said, getting things to run is still a great first step
<guso78> teepee, my python did compile with mxe after some patches and it starts up.
<teepee> and as was discussed earlier, maybe it's possible to use the msys2 build for packaging
<guso78> but there still many issues during python initialization which prevents me from actually running python code
<guso78> python "import" command cannot  intiialize itself(wants to become a real python object). this prevents further processing
linext has joined #openscad
J2385 has quit [Quit: Client closed]
J2385 has joined #openscad
ur5us has joined #openscad
pfla has joined #openscad
<pfla> does anyone have good examples of what openscad is capable of?
<teepee> gallery page maybe?
<pfla> I work in engineering as a mechanical designer and am intrigued by it
<pfla> didn't realize there was gallery
<pfla> thank you
<pfla> thank you
<pfla> wow some awesome stuff
<teepee> but as general note, it's mostly a tool for generating 3d meshes
<teepee> not so much for the "typical cad workflow"
<pfla> can you elaborate?
<teepee> also an interesting project - https://openflexure.org/projects/microscope/
<pfla> I am checking that one out now
<linext> 3dcustomizer.net
<linext> you can filter thingiverse.com for customizers
<pfla> are you saying the software isn't typically for creating fabrication or real word parts and more so for 3d design?
<linext> it's for both
<pfla> I am a javascript/angular programmer as a hobby but use inventor at work with a little VBnet, main reason why i'm interested in this.
<pfla> thanks linext
<pfla> it looks to be from the stuff I see
use-value has quit [Remote host closed the connection]
<pfla> I can't imagine programming some of this stuff line by line, how many lines of code would something like that microscope take up?
use-value has joined #openscad
<teepee> there's quite powerful libraries right now which can make things like gears a single line
<teepee> so it's hard to say
<pfla> there are libraries for openscad?
<teepee> yep, collection of some of the more notable (and open source) ones: https://openscad.org/libraries.html
<Virindi> the best library is nophead's :)
pfla has quit [Quit: Client closed]
<teepee> best is relative, it's huge and very versatile
<teepee> I often just need the thread library for non-spec printed threads, so I tend to use the special case library from InPhase a lot
<kintel> InPhase teepee: OK, so I dug deep into the CMake leakage issue:
<kintel> Turns out cache variables are not scoped in CMake, and find(PythonInterp) invoked from googletest (which is called from Manifold) caches PYTHON_EXECUTABLE as python2
<kintel> ..and hence our own find(PythonInterp) will reuse that cache, even though we ask for a different Python version
<kintel> ..so I guess one rule of thumb: Don't call find macros or set cache variables from CMake files included via add_subdirectory()..
<InPhase> kintel: https://cmake.org/cmake/help/latest/command/block.html#command:block Do you think this magic works?
<InPhase> Or maybe I misunderstand it. I often read cmake docs multiple times and still don't know what they're actually trying to say. It's like they use a different form of English.
<kintel> I don't think block does anything to the cache
<teepee> also "New in version 3.25."
<kintel> The cache is just a single txt file at the root of the cmake execution
juri_ has quit [Ping timeout: 248 seconds]
<teepee> is there a way moving slowly from include to "real" library?
<teepee> or would that make cmake so much more messy
juri_ has joined #openscad
<teepee> InPhase: shall we sign up as GSoC mentors? not seeing much action anyway, so I suppose we probably will not get a proposal anyway
<linext> for writing OpenSCAD, or OpenSCAD scripts?
<teepee> you mean GSoC? both would be possible, but the current project suggestions are for the C++ code only
L29Ah has joined #openscad
<linext> hmm...
<linext> emmett works for google
<kintel> linext So does ochafik, and I :)
<guso78> ahh, did not know
<guso78> suppose in google you work on another application ...
<kintel> yeah, this is completely isolated from work. I think that's the case for the others as well..
J2385 has quit [Quit: Client closed]
J2385 has joined #openscad
<guso78> kintel , i am just wondering.  did you apply at  google or did google apply for you ...
<kintel> I went through the same door as everyone else...
<guso78> kintel, i am still thinking with my texture branch: all failed ctests render ok in the GUI. and for all ctests my variable "texturefactor"is set to 0.0 which should  make them obsolete,
<guso78> but still there is this major difference
fling_ has joined #openscad
use-value has quit [Remote host closed the connection]
use-value has joined #openscad
fling has quit [Ping timeout: 255 seconds]
<guso78> can you list me the key differences  between png-export and gui  ?(all stuff in Renderer.cc is not, because its common to them)
<kintel> I believe the only difference should be which features are enabled
<kintel> Which platform are you executing on?
<guso78> I got a fedora fc37 linux in a virtual box
<kintel> and offscreen renders to a FBO instead of directly to the Window
<kintel> oh, virtualbox. You're kind of on your own with OpenGL on virtualbox...
<kintel> try running on bare metal
<guso78> kintel you mean  i could get strange results?
<kintel> I don't trust VirtualBox' OpenGL driver
<guso78> ok message taken. probably i should buy proper hardware  first ;)
<kintel> I guess you must have _some_ useful hardware. ..unless you're on a Mac ;)
<guso78> all ctests have option --enable-vertex-buffer-object (or similar) . is this the option to render to FBO ?
<guso78> kiintel. i see 3 different mac targets in openscad build scheme, it can't be so bad :)
<kintel> no, offscreen is always FBO
fling_ is now known as fling
<kintel> Mac is fine, you just cannot meaningfully run Linux or Windows on it..
<guso78> MAC essentially runs a linux kernel. just the commands are little different ...
<teepee> mach kernel, quite different
<kintel> and the apis and the compiler and the system libs and the dynamic loader and the window sysyem
<kintel> so, ~5% ? is the same - it beats Windows for my purposes though :)
<kintel> anyway, if you build and run OpenSCAD on your bare metal, you should have a much better OpenGL experience
<teepee> or see if gpu passthrough works, but I've never tried that myself
<Virindi> Hrm, okay, just noticed manifold broke some triangles in my exported stl. Guess I will turn it off for now
<Virindi> slic3r worked on the model anyway though
<guso78> i just realized, the  python openscad does not have options to mark elements  with % and !
<guso78> teepee,  maybe an OO operator :)
<gbruno> [github] kintel pushed 9 modifications (Remove support for OpenGL < 2 (#4550)) https://github.com/openscad/openscad/commit/2f06a638f678635c532f5067f27e8bdbfd8772f4
<gbruno> [github] kintel closed pull request #4550 (Remove support for OpenGL < 2) https://github.com/openscad/openscad/pull/4550
<InPhase> teepee: Sure, I'm in if we can get an applicant willing and able to do the stuff.
<teepee> InPhase: they changed the process again, we need to first sign in as mentor and then Sean will be able to add to the project
<teepee> probably for accepting the terms upfront
<kintel> wasm playground on openscad.org would be a nice project, but may be a bit early for a gsoc
<teepee> yeah, and we really need that new server :)
guso78 has quit [Ping timeout: 260 seconds]
<teepee> InPhase: can't find the mentor signup yet. I would assume they don't close it as before, but right now I only see contributor signup
<kintel> we could probably host a wasm app from github pages
guso78 has joined #openscad
<kintel> ..but it would be awesome with a pastebin server
<teepee> hmm, linext already does that, so maybe a readonly tutorial/playground is fine plus removes the need for backups
<kintel> true, bare minimum is fine, perhaps smth. synced with nightly master
<linext> i'd like to integrate git into the saves
<linext> so we can keep track of the code changes
<linext> yes, 3d customizer has a "playground"/"sandbox" for testing
<teepee> and I'd be ok with just linking to your site for the saving possiblities
<teepee> and on the openscad.org site having some read-only / tutorial stuff
<teepee> well maybe editable but non-save :)
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<joseph_> InPhase teepee: Hello again, I know it's been several months since I've been active here. I logged on just now to ask about something unrelated, but coincidentally I saw you were talking about GSoC. Out of curiosity, what's the task being discussed?
<teepee> no task, the question if the mentor signup still works :)
niyawe_ has quit [Ping timeout: 265 seconds]
niyawe has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<joseph_> teepee: I still get emails from another organization whose mailing list I joined early last year. It seemed like they are handling mentor applications internally. So maybe the form needs to get sent by the org admin
<teepee> from what I've seen the process is supposed to be 1) register with google site and accept terms 2) tell org-admin 3) org-admin can select person and add to the org
<teepee> but the site only shows contributor signup which I would assume is the wrong one as it's also showing the wrong rules and option to join the "student" mailing list
<teepee> we'll see, I've asked Sean
<joseph_> Okay
<teepee> I would assume the mentor application needs to be open all the time in case a mentor needs to drop out so another one could be added
<teepee> anything else would be at least strange and also different from previous years
<teepee> but as they rewrite the website every year, this happens all the time :)
<joseph_> Also, I looked at the contributor rules this year. It seems that it is now permitted to participate up to two times. I'd be interested in potentially submitting a proposal again, so I started looking through the tagged opencax issues. It seems like there is some interest by other applicants for the 175h language help feature.
knielsen has quit [Ping timeout: 268 seconds]
knielsen has joined #openscad
<teepee> yes, but I'm not sure how solid that specific interest is
<teepee> remains to be seen, there's still 2 weeks time
<InPhase> Only two weeks for participants to sign up yet?
<joseph_> Am I also correct in remembering that a contributor must work on one of the existing ideas that are posted, because those ideas needed to get approved by Google a while back?
<teepee> it was always relatively short like 2-3 week IIRC
castaway has quit [Ping timeout: 246 seconds]
<teepee> no, unless that changed, google does not check the proposals in detail (other than requiring actual coding) and it's fine to propose something else
<teepee> it's just more difficult in general
<InPhase> Which reminds me I was so brain-swamped I forgot weeks back to even think about ideas to add to that list.
<joseph_> Looks like the contributor deadline is April 4th, depending of course on time zone
<teepee> yep, with me usually suggesting ignoring that last day completely :)
<linext> i'd like to let people fork the code and save it to a git server too
<linext> dschroer got back to my email, and said he hadn't heard about manifold library update as an option to CGAL
<linext> the files his build process produces are slightly different than what you're running
<joseph_> teepee: Exactly, better to have a safety buffer. I will be thinking about possible proposal topics, including those that are already listed. Ideally I would want to try getting my PR from last year merged before starting to code something else. Last year's is "ready" in the sense that tests pass, but I left it as a draft until there could be further discussion
<teepee> well, right now Manifold is contained in the openscad checkout so it does not affect the WASM base image build at all
<teepee> joseph_: yes, that would be a useful topic, kintel is currently working on brushing up the OpenGL code, so that might need some coordination but might be very nice in combination
<linext> is there a way to checkout the openscad code that has the manifold update?
<InPhase> linext: It's the master branch.
<InPhase> linext: It's just marked as an experimental feature that you need to click to turn on.
<InPhase> linext: Or for command line, pass a flag.
<teepee> yep, it's currently a git submodule so git clone --recursive will give you also the manifold code
<teepee> or if you have a repo: git pull && git submodule update --recursive
<linext> what aboou this fork: https://github.com/ochafik/openscad
<teepee> maybe it needs --init too
<teepee> I'm never sure when that's needed
<teepee> this only says "4 commits behind"
<linext> yea, appears that it was added two days ago
<teepee> so it would be just missing some of todays stuff
<joseph_> teepee: The OpenGL was actually what I originally logged on to ask about. As you might remember I had a slower on-ramp last year due to some of the render process being harder to mentally trace. Now that I eventually became familiar with it, I might be able to assist with refactoring
<linext> ok, then maybe i'll just run the build script on my ubuntu VM and see if it produces what i need for 3dcustomizer
<teepee> joseph_: that would be great, I would assume it's possible to find some area that can be worked on mostly separately
<teepee> we need to get that registration sorted, but meanwhile could try catching kintel and checking for his opinion on that