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>
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>
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…]
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]
<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>
WOULD BE INTERESTING TO TEST WITH IT AND SEE WHAT IT CAN DO, CROSS PLATFORM WOULD BE BETTER
<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>
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..
<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