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
califax has quit [Remote host closed the connection]
califax has joined #openscad
snakedGT has joined #openscad
snaked has quit [Read error: Connection reset by peer]
peeps[work] has quit [Ping timeout: 265 seconds]
ur5us has quit [Ping timeout: 260 seconds]
<peepsalot> JakeSays: there is some code for DBUS driver which I believe can trigger UI events etc. I don't know much about how that works though.
<JakeSays> dbus.. i'd rather poke my eye out. lol
snakedGT has quit [Remote host closed the connection]
snaked has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<teepee> JakeSays: any cross plaform suggestions for that interface?
<JakeSays> teepee: i was thinking of something as simple as a socket and json
<teepee> in this area, I equate simple with buggy
<JakeSays> you make the assumption that the implementer of such a simple solution is incompetent
<JakeSays> which in my case is both incorrect and offensive
<teepee> no
<teepee> not at all
<teepee> so that accusation goes both ways
<JakeSays> i mean if you want complicated then grpc
<teepee> cross platform networking code is difficult, as can be seen with the issues in applications where I have big repect for knowledge of the developers
<JakeSays> Qt's networking code is pretty rock solid
<JakeSays> and quite portable
<teepee> which is an option if we go for gui stuff
<JakeSays> that's all i want - an automation interface to control the gui
<JakeSays> so i don't have to switch to oscad from my editor to do things like render/export stl, etc
<JakeSays> and open files
<JakeSays> and switch focus
<teepee> as peepsalot said, that exists via qt dbus, having some additional bindings seem ok
<teepee> the dbus stuff is mostly automatic, but not very portable
<JakeSays> teepee: where is the dbus stuff?
<JakeSays> teepee: no, the c++ side
<JakeSays> ah dbusinputdriver.*
<JakeSays> the dbus stuff doesn't offer enough functionality for what i want
<JakeSays> it handles what i'd want as far as controlling the active document, but it doesn't support opening/closing/focusing documents
<teepee> it supports menu actioms
<teepee> but no parameters
<JakeSays> right
J236 has joined #openscad
J23 has quit [Ping timeout: 260 seconds]
epony has quit [Remote host closed the connection]
<JordanBrown[m]> Scopeuk: or are you thinking of a way to support alternative UIs, so that a human is generating an OpenSCAD program but the UI is not OpenSCAD?
kintel has joined #openscad
fedorafan has quit [Quit: Textual IRC Client: www.textualapp.com]
snaked has quit [Quit: Leaving]
snaked has joined #openscad
<teepee> kintel: CPU(s): 2 Vendor ID: AuthenticAMD Model name: AMD EPYC 7571 CPU MHz: 2548.656 Hypervisor vendor: KVM Mem: 7706
<kintel> That's reasonable. How did you get the info?
<teepee> looks like the only way to get arm64 builds is using build hooks https://github.com/openscad/docker-openscad/blob/main/openscad/bookworm/hooks/build
<kintel> They didn't respond to the support request, despite offering commercial support. ..so remind me not to buy that service for the support :/
<teepee> yeah, I'm not even convinced it's a good option for the builds
<teepee> the setup is extremely limited and running everything via hooks is a bit annoying even though it gives total flexibility
epony has joined #openscad
<teepee> I can't even give build parameters per auto-build setup
<kintel> Wait, how does that work?
<kintel> Do they spin up an emulator and run docker on that ?
<kintel> (i.e. the arm64 stuff)
<teepee> yes, it's builtin via docker buildx command, that's what I'm using locally too
<kintel> so they ship qemu or smth. with docker now?
<kintel> Haven't used raw docker in a long while..
<kintel> They do offer 15 concurrent builds, so a crazy workaround for runtime issues could be to split up the dockerfile into parallelizable parts and spread out the load. Not something I'd want to maintain of course ;)
<teepee> yep, the amd64 build was fine, but buildx for amd64+arm64 just stopped a bit short of an hour, not sure why, there's no indication in the log, it just stops
ur5us has joined #openscad
<kintel> I remember docker having some odd per-layer time limitations in the past, I think related to whether a layer provided any stdio output back to the process who started it
<teepee> I suspect it was death by swap
<teepee> after 38 minutes the new build is much farther along at least in the amd64 build at an hour (50% vs. 5%)
<teepee> I'll check after getting some sleep if it did manage to build both images, splitting out the base image might still be acceptable
<teepee> everything else probably means docker-auto-build is unusable
<teepee> unless there's some build-hook trick :)
ur5us has quit [Remote host closed the connection]
ur5us has joined #openscad
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ur5us has quit [Ping timeout: 265 seconds]
ur5us has joined #openscad
ur5us has quit [Ping timeout: 240 seconds]
<gbruno> [github] cymplecy opened issue #4591 (Text isn't centered if ttb or btt direction used) https://github.com/openscad/openscad/issues/4591
ur5us has joined #openscad
epony has quit [Remote host closed the connection]
epony has joined #openscad
ur5us has quit [Ping timeout: 250 seconds]
<Scopeuk> JordanBrown[m] pretty much. I expect the most common case would be to use the engine to generate a solid but we would also see people want to wrap generative front ends (see blockscad for instance) arround the preview system
castaway has joined #openscad
LordOfBikes has quit [Remote host closed the connection]
LordOfBikes has joined #openscad
fedorafan has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
L29Ah has left #openscad [#openscad]
califax has quit [Remote host closed the connection]
califax has joined #openscad
rvt has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
rvt has joined #openscad
Abrasive21 has joined #openscad
Abrasive21 has quit [Client Quit]
L29Ah has joined #openscad
<JordanBrown[m]> It isn't clear whether blockscad would more naturally generate OpenSCAD language or just directly call a library. It'd probably depend on whether they wanted constructs that OpenSCAD doesn't have. But then again ... it isn't clear; something that consumes OpenSCAD source might well be exactly what they want.
<teepee> revision demo party is going on
<teepee> shader live coding - finals coming up soon-ish
<teepee> oof, already started, right on time, that's new :D
teepee_ has joined #openscad
<buZz> :)
* buZz watching since yesterday
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
pah is now known as pa
<teepee> I missed the qualification round, but it's on youtube already, so going to catch up soon
<teepee> what was that TIC80 stuff? that looked very crazy retro
<buZz> teepee: its a fantasy console
<buZz> like Pico-8
<teepee> ah, would have been my guess, I might even have heard of it before, but could not really place it
<buZz> i havent heard of it
<buZz> but i have a pico8 license
<teepee> I'd wish the hive retro style computer more use, but I suppose that's too late now
<juri_> i'm doing some retro-kerneling atm, trying to set up an openmosix/LinuxPMI cluster.
<juri_> of course, in a VM, with haskell based utilities.
guso78 has quit [Ping timeout: 260 seconds]
guso78100 has quit [Ping timeout: 260 seconds]
stefanct__ has joined #openscad
marcus has quit [Ping timeout: 255 seconds]
stefanct has quit [Ping timeout: 255 seconds]
Xeha has quit [Ping timeout: 255 seconds]
stefanct__ is now known as stefanct
marcus has joined #openscad
Xeha has joined #openscad
<foul_owl> Can openscad speed up the "render" process via cuda?
<juri_> likely no.
<foul_owl> gotcha
<juri_> i don't think there's a cuda CGAL port.
<foul_owl> I see. Rendering right now takes about an hour, but I do have a slow proc and a pretty decent video card
<Scopeuk> foul_owl it might be worth trying the nightly and enabling manifold in the experimental settings
<Scopeuk> it is experimental and in testing but it can have significant speed ups
<Scopeuk> it is still cpu based however
<InPhase> Nightly and choosing fast-csg will on average take an hour down to 6 minutes, and is pretty stable.
<teepee> Manifold does support CUDA
<teepee> but it's unlikely that will be enabled in OpenSCAD, there's even discussion dropping it in favour of something more cross hardware
<Scopeuk> excuse caps
<teepee> it did not give much benefit from what I heard, the overhead is too big
<Scopeuk> understandable
<teepee> so it would need some complicated heuristics to select when to use what strategy
<teepee> quoting from one of the github issues: "Probably a lot, at least for the CUDA case. On my laptop with a 3050Ti mobile and 12900HK CPU, small models are 10 times slower with CUDA enabled, and large models are only < 10% faster with CUDA."
<InPhase> teepee: Does it need to migrate data in and out repeatedly?
<teepee> I don't know the details, but I assume so, at least in context of how the algorithm is implemented
<InPhase> Ok. I'm also not personally interested in anything CUDA unless it works under a system like this: https://hothardware.com/news/cuda-on-intel-gpus-zluda
<InPhase> I haven't purchased any nvidia hardware in a very long time.
<teepee> I very much agree with the suggestion made in the discussion: "Thinking about this more, I wonder if we should just move to C++ parallel + vulkan compute shader for GPU acceleration, and ditch thrust and CUDA all together."
<teepee> I'd give 3 thumbs up, but that would need some surgery ;-)
<Scopeuk> you have a 3d printer, you can have as many thumbs up as you like
<teepee> do those count?
<Scopeuk> I think we can make a ruleing here
<teepee> the interesting part might be that vulkan compute shaders on unified memory architectures might be crazy fast even for smaller packets of data
<teepee> annyoingly that might hugely benefit M1 system, even though they don't even support native vulkan
<teepee> well, something to hope for in the next 10 years ;-)
kintel has joined #openscad
<kintel> teepee A possibly more interesting benefit could be Intel iGPUs, as I believe they're also on a unified memory arch
<kintel> ..and likely deployed across lower-end platforms which may really need the speed benefit
<teepee> yep, that would be nice too
<kintel> But first try to write some Vulkan code before dreaming ;) I scanned through a Vulkan tutorial once, and the amount of boiler plate is staggering
<teepee> yes, I've seen that, you need to start with memory management
<kintel> But good for code generation scenarios
<foul_owl> Scopeuk: Thank you, is that different from fast csg?
<kintel> Anyone have ideas about the following odd OpenGL issue?
<kintel> Context: I'm adding support for GLSL in OpenCSG, to replace the old ASM shader stuff.
<kintel> OpenCSG essentially works by writing _only_ z values for a CSG object into the framebuffer. We then subsequently render our own objects with appropriate colors using the GL_EQUALS depth test, allowing us to _only_ write colors where OpenCSG determined there should be colors
<kintel> _However_: If I run essentially the same vertex shader written in GLSL and ARB vertex program respectively, the produced z values seem to be very very close, but not identical, causing z-tearing-like effects when we render the final color
<kintel> ^ very puzzling, not sure where to take it next..
<kintel> It's especially weird because OpenSCAD's rendered also uses GLSL: https://github.com/openscad/openscad/blob/master/shaders/Preview.vert
<teepee> with which gl driver is that?
<teepee> that sounds a bit like the issue we saw sometimes with the macos software driver
epony has quit [Remote host closed the connection]
<kintel> This is nVidia on Linux
<kintel> The macOS SW driver is a different hell, which I
<kintel> 'm currently ignoring :)
<kintel> Note: All of the above is currently only tested in offscreen (FBO) mode, as I'm doing all this over ssh :)
<kintel> ..so still lots of avenues to figure this out, just hoping for some quick wins :)
<teepee> hmm, different floating point sizes?
<teepee> no really ideas, just guessing :)
<teepee> very cool soundtrack
castaway has quit [Ping timeout: 252 seconds]
<teepee> I'm pretty sure they used smaller bits to fit the last one into 4k
qeed has quit [Ping timeout: 250 seconds]
<J236> working with 0 and 0.1
qeed has joined #openscad
fedorafan has quit [Ping timeout: 248 seconds]
<kintel> teepee I think I figured it out: Turns out we don't use shaders in OpenSCAD unless we render with edges enabled
<kintel> ..and if I enable edges in my regular OpenSCAD build, I get z buffer tearing also on my Linux box
fedorafan has joined #openscad
<kintel> ^ Can anyone else reproduce that? example001.scad -> Show edges -> F5 -> tearing-like rendering bug
<teepee> ah, yes. IIRC peepsalot looked at that a while ago with no conclusive result
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<peepsalot> kintel: my hunch is that the depth buffer calculated by the old school fixed function opencsg and the shader depth buffer are off by some least significant bits
<peepsalot> and opencsg's whole rendering shtick relies on exact match of depth values
<peepsalot> also, fwiw the artifacts are way worse in perspective than in orthographic
kintel has joined #openscad
<kintel> Right, could be perspective division adding to the effect
<kintel> Anyway, my investigation so far tells me that fixed function transformations result in very slightly different vertex positions than shader transformations
<peepsalot> like if the order of operations to get to that z value is not exactly the same between opencsg and the shader, then all bets are off as far as matching them up as far as I see it
<kintel> ..which trips up any rendering with DepthFunc GL_EQUAL
<kintel> It's not really the order, but the path chosen in HW I think
<peepsalot> yes GL_EQUAL is what i meant by exact match