<kintel>
teepee: Do you think your CGAL fix is still mirroring, or is something else wrong?
<othx>
kintel: 9 hours, 18 minutes, 22 seconds ago teepee tell kintel Ubuntu 18.04 builds on OBS look ok now, just waiting for the package mirrors to catch up so github sees the new package with lowered boost dependency
<teepee>
yeah, it's not upating the mirror, it's still showing the file from jan 2nd
<linext>
the wasm-snip tool might be useful
<linext>
i'm sure there's extra stuff that .wasm will never use because
<linext>
wasm-snip replaces a WebAssembly function's body with an unreachable instruction. This is a rather heavy, blunt hammer for functions that kind of look like nails if you squint hard enough.
<linext>
i wonder if the "preview" code exists inside the .wasm file
<linext>
F5
<teepee>
the code to generate the data, yes. the library to show it no
<linext>
if it can't be called, could it be replaced with "unreachable" ?
<teepee>
I'm not sure it's easy to isolate
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hypera1r has quit [Ping timeout: 272 seconds]
califax has quit [Ping timeout: 255 seconds]
hyperair has joined #openscad
J2342369 has joined #openscad
califax has joined #openscad
epony has joined #openscad
J23423 has quit [Ping timeout: 260 seconds]
ali1234 has joined #openscad
ali12341 has quit [Remote host closed the connection]
califax has quit [Ping timeout: 255 seconds]
califax has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
ur5us has quit [Ping timeout: 246 seconds]
epony has quit [Ping timeout: 268 seconds]
epony has joined #openscad
califax has quit [Ping timeout: 255 seconds]
califax has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
kintel has joined #openscad
<kintel>
It would be cool, to port all the OpenSCAD GL code to whatever subset of OpenGL4 is compatible with GLES, which should make the WASM build fully featured. Apart from the experimental VxO rendering, are anyone looking into that?
<kintel>
I guess the big question is: Are there still users on legacy OpenGL devices out there which we need to support?
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
RichardP_ has quit [Ping timeout: 268 seconds]
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
RichardPotthoff has joined #openscad
<peepsalot>
othx: tell kintel i think the biggest holdup with modernizing opengl is rewriting OpenCSG (and understanding it well enough in the first place to do so)
<othx>
peepsalot: I'll pass that on when kintel is around.
gwillen has quit [Ping timeout: 255 seconds]
gwillen has joined #openscad
castaway has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
TheAssassin has quit [Ping timeout: 255 seconds]
TheAssassin has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
J2342369 is now known as J23
Guest54 has joined #openscad
Guest54 has quit [Client Quit]
snaked has quit [Ping timeout: 246 seconds]
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
kintel has joined #openscad
<kintel>
peepsalot: Yeah, makes sense. Good thing is that we may get away with rewriting just parts of OpenCSG, and if we keep the rewrite GPL, we can reuse a bunch of the non-GL-related parts and limit the rewrite to the rendering aspects of the SCS algorithm.
<othx>
kintel: 6 hours, 34 minutes, 46 seconds ago peepsalot tell kintel i think the biggest holdup with modernizing opengl is rewriting OpenCSG (and understanding it well enough in the first place to do so)
<kintel>
If we can rely on relatively modern OpenGL, it's actually not a very complex thing, just a bit time consuming to get right.
<kintel>
Perhaps a good starting point would be to make sure OpenSCAD can request and handle an OpenGL4 core context everywhere _except_ preview rendering.
<kintel>
..or perhaps we can require a bunch of OpenGL2.1 extensions to be available to make the rendering code less fragmented.
<kintel>
It would still be awesome with a light-weight scene-graph/rendering engine which could help structure things a bit better.
<kintel>
Not finding a good one was the initial reason I never really got into rewriting any of the GL stuff
<kintel>
..but the macOS ecosystem is very small so I can figure out the details of when 4.1 support can be relied upon
<teepee>
moving to a 3.x core might already help with a number of those strange issues we have
<kintel>
3.2 seems to be the minimum in that case
<kintel>
As usual, getting offscreen rendering to work may be the hardest part. I'll look into it a bit, but I don't currently own a GPU-capable Intel box.
Guest85 has quit [Quit: Client closed]
<teepee>
do you get that github cloud thing on your account? I forgot that name again
<kintel>
Ah, good opportunity to test Codespaces. Too bad they don't offer Open Source plans, but 120 free hours per month is _something_
<kintel>
Wonder if they offer Windows instances too, as that's the next tricky OpenGL challenge to pull off
<kintel>
Yeah, bgfx seems to be two things; an abstraction of buffer objects etc. + a backend abstraction.
<kintel>
For the latter part we could always write GLES3 code and link against ANGLE for the same effect
J23 has quit [Quit: Client closed]
J23 has joined #openscad
J23 has quit [Ping timeout: 260 seconds]
<peepsalot>
kintel: a while ago i was looking into using magnum for graphics backend, but didn't get very far with it https://doc.magnum.graphics/magnum/
<peepsalot>
i remember briefly looking at bgfx at the time. i think i avoided it mostly due to my disdain for using C APIs in C++
<peepsalot>
another stumbling block (independent of library choice) was drawing of the axes, tick marks and their numeric labels. the issue is that GL_LINES is not a valid shader primitive IIRC
<peepsalot>
kintel: i actually wrote a shader for a sort of 3d grid POC, which was meant to cover all 3 orthogonal planes, rather than just the axes. https://www.shadertoy.com/view/Ndy3Rm
<peepsalot>
the shadertoy can't really store state afaik, so the interaction in that example is a bit awkward, you can't click-drag and to orbit and mousewheel zoom like we do in openscad
<peepsalot>
it seems a little busy in that example, but its hard to judge without any other geometry in place, and with the view pretty much always focused on the origin
<peepsalot>
then there's the more difficult problem of labeling the tick marks / divisions with text...
<peepsalot>
i think the way to go is to use a multi-channel sdf font (MSDF). it can reproduce clean characters from a pretty low resolution texture
<teepee>
nice, moving all that stuff into shaders would be great
<teepee>
maybe we can get the shader PR in first, even though it's not directly helping too much with all that
J23 has joined #openscad
kintel has joined #openscad
<kintel>
Yeah, moving to a rendering library will require a fair bit of refactoring, all of which can probably be done without using a rendering library at all
<kintel>
..although making a decent attempt at integrating one will help shake out all the issues
<kintel>
Anyway, I'll make an attempt at digging at this bottom-up: Make sure we can create good GL contexts everywhere and look into a glew replacement.
<kintel>
Back at work now though, but I'll try to carve out some OpenSCAD time. I'm doing 3D stuff at work finally, so my brain doesn't hurt so much switching contexts :)
<teepee>
nice! if you still have some cycles for non 3d stuff at some point, maybe we can have a look at some new file server :)
<linext>
does webGL require an open GL video card?
<teepee>
I have not looked into how that works with opencollective, but it would be useful for some extended hosting stuff
<kintel>
re. server, perhaps we could start a document/wiki to collect questions as a start? I assume the main questions are requrements, cost and maintenance
<kintel>
I haven't actually tried to request reimbursements yet, but I should as the mailing list comes off my personal credit card ;)
<teepee>
yeah, or even better if it would be possible to run it directly
ur5us has joined #openscad
<kintel>
yeah, I seem to remember they were working on a virtual credit card offering. I can look at that again
<kintel>
..ideally a one-card-per-vendor setup to limit abose
<kintel>
*abuse
<kintel>
linext: WebGL doesn't really have any requirements I think. Any GPU should work, probably even SW rendering works as a fallback
<kintel>
-> it all comes down to which browser you're using
<kintel>
Both Firefox and Chrome use ANGLE as a rendering interface, which can talk to OpenGL, GLES, DX9+, Vulkan, Metal, with SW fallback
<kintel>
..but any consumer SW is bound to maintain a list of disallowed GPUs to make sure driver bugs don't mess with user experience
<kintel>
Looks like Chrome allows you to disable that blocklist but YMMV: chrome://flags/#ignore-gpu-blacklist
<linext>
it would be nice to get preview rendering to work on openscad WASM
<linext>
rendering using F6 all the time is too slow
<kintel>
linext: Yes, the previous 50 messages are all on that topic :) Once we limit OpenGL usage to the OpenGL4/GLES3 core API, translation to WebGL should be automatic when building WASM binaries with emscripten
<linext>
another reason is that it would be nice to run OpenSCAD in VMs
<linext>
a headless docker for instance
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<teepee>
headless docker works already
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
teepee has quit [Remote host closed the connection]