<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.
<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>
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>
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]
<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
<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.
<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 :)
<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 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
<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>
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
<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>
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 !
<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
<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