I forgot to link to the demos' respective twitter announcements:

• https://twitter.com/ochafik/status/1499370626829762564
• https://twitter.com/autodrop3d/status/1499227810086465538 (includes a
  video walkthrough from the author)

--
Olivier
http://ochafik.com
http://twitter.com/ochafik

--
Olivier
http://ochafik.com
http://twitter.com/ochafik

On Thu, 3 Mar 2022 at 14:59, Olivier Chafik olivier.chafik@gmail.com
wrote:

It appears not to work in Firefox for Linux Mint mnt-001 - 1.0, 97.0.1
(64-bit):

EXCEPTION: ReferenceError: SharedArrayBuffer is not defined

Oddly, I only get that error the very first time I load it. The subsequent loads contain no
OpenSCAD code.

Both examples work in Chromium Version 98.0.4758.80 (Official Build, ungoogled-chromium) (64-bit)
but the preview of the more complex example looks a bit defective like the surface is unstable.
||

On 3/3/22 07:59, Olivier Chafik wrote:

--
Richard
http://www.kandarian.com/

Thanks for trying it out!

I'm using a service worker to trick the client into adding
Cross-Origin-Embedder-Policy / Cross-Origin-Opener-Policy headers to the
served WASM binaries, so as to be allowed to use SharedArrayBuffers.

For some reason the service worker only works after a reload in Firefox,
but works from the get go in Chrome.
(FF is / has been a bit challenging, had to jump through some hoops to get
it to accept emscripten WASM binaries in background workers)

That's odd, do you mean no source code / broken editor?

the surface is unstable.

I'm using an existing STL viewer, wondering what this instability looks
like / if it could come from the WebGL rendering somehow.
Just realized my fork
https://github.com/ochafik/openscad-wasm/tree/editor-ochafik.com doesn't
have an issues tab haha! (can't report this :-p), I'll see with the
OpenSCAD maintainers if we can maybe have a dedicated repo for this (or if
this should live inside the normal repo, once cleaned up a bit).

Cheers

Olivier
http://ochafik.com
http://twitter.com/ochafik

On Thu, 3 Mar 2022 at 15:17, Richard Kandarian richard@kandarian.com
wrote:

(64-bit):

subsequent loads contain no

ungoogled-chromium) (64-bit)

the surface is unstable.

are now two early demos in the wild that run OpenSCAD in the browser:

highlighting; should work in Chrome + hopefully Firefox, maybe)

it's time more people get a sneak peek of the future!

I just tried it again in Firefox and it's now working. I did not see the
error I saw before The viewer is leaving tracks, though:

I changed the size of the cubes in the editor and that worked.

This is the more complex model surface instability:

Looks like there are chunks missing from the surface. By unstable I mean
that the holes come and go as the camera angle changes.

On 3/3/22 15:17, Olivier Chafik wrote:

--
Richard
http://www.kandarian.com/

Hi Marius!

On Fri, 4 Mar 2022 at 00:14, Marius Kintel marius@kintel.net wrote:

I'll start polluting openscad/openscad-playground shortly ;-)

In terms of visualization, I started on an OpenCSG port to WebGL a long

Oh wow, WebGL as in, also porting the logic to JS? Or, as the Emscripten
hint
https://emscripten.org/docs/porting/multimedia_and_graphics/OpenGL-support.html,
update the native code to target the subset of OpenGL that's compatible
with WebGL? I have no clue how OpenCSG pulls things off tbh, does it
involve much shady shaders business?

It looks to me that we might be using too many Qt modules to compile the
entire UI for the web straight away (cf. what they say they support
https://doc.qt.io/qt-5/wasm.html), but if we had a simpler UI entry point
that uses whatever emscripten likes (say, SDL) to open a GL window that
hosts a newly WebGL-compatible OpenCSG renderer (and handles mouse
interaction, maybe reacts to file changes from the fake Emscripten file
system), that would bring us much closer to the real deal.

Cheers

Olivier

WebGL as in a JS+WebGL implementation of the algorithm + three.js integration. It did involve a bunch of shady shaders and multi-pass rendering. When I wrote it I was also constrained by WebGL 1.0 with limited extensions available in browsers; not sure if that’s an issue any longer.

At the time I was aiming for a full OpenSCAD implementation in JS, but I lost steam when I got to ttf font parsing and CGAL. With WASM maturing fast, this should be so much more doable today.

One challenge with native OpenCSG is that I believe they still rely on some immediate mode GL calls, so a port may be needed in any case. With WASM, it could be feasible to leave the C++ parts of OpenCSG alone and just manage the rendering passes and shaders in WebGL.

Porting the Qt UI sounds like the definition of an anti pattern :)
..but could be a useful proof of concept and a tool to help iteratively decouple some of our UI logic. I saw an OpenOffice port which did that (not sure what UI framework they use).

-Marius

On Fri, 4 Mar 2022 at 22:30, Marius Kintel marius@kintel.net wrote:

wrote:

Emscripten hint, update the native code to target the subset of OpenGL
that's compatible with WebGL? I have no clue how OpenCSG pulls things off
tbh, does it involve much shady shaders business?

integration. It did involve a bunch of shady shaders and multi-pass
rendering. When I wrote it I was also constrained by WebGL 1.0 with limited
extensions available in browsers; not sure if that’s an issue any longer.

Hah cool, ambitious!

lost steam when I got to ttf font parsing and CGAL. With WASM maturing
fast, this should be so much more doable today.

some immediate mode GL calls, so a port may be needed in any case. With
WASM, it could be feasible to leave the C++ parts of OpenCSG alone and just
manage the rendering passes and shaders in WebGL.

Whatever works, but I have the feeling the interop story might be easier if
you manage to keep everything in C++ (reusing much of the WebGL-compatible
porting work you've already done).
Alternatively we could also look at using OpenCASCADE as a CSG-rendering
library in the browser (and/or on desktop?), it looks to work great e.g. in
https://github.com/zalo/CascadeStudio

Yeah the bit of the UI I'm the most after is the customizer, but it would
be trivial to implement in JS if we add some customizer metadata JSON
output format (that also provides the errors/warnings in the same run; for
bonus points it can output the AST in JSON format so the editor can do
semantic highlights, go to definition, contextual breadcrumbs - like
"you're inside module X", etc without having to write an .scad parser in
JS).

decouple some of our UI logic. I saw an OpenOffice port which did that (not
sure what UI framework they use).

I can really see how a barebones UI with just an OpenCSG / GL window +
listen to file changes would give us all we need.

Currently I'm firing the binary in a background worker which either just
checks the syntax, or renders to an STL file. The advantage of that is I
can kill the worker / process without any ceremony, and the main UI stay
super snappy.

If / when we start having some live rendering, the WebGL renderer will
probably work in the main UI thread. We probably want to keep as much heavy
lifting as possible in the background, for instance we could have the
background worker output a self-contained .csg with inline-import
https://github.com/openscad/openscad/pull/4124 (ready for review :-)),
that we can pipe back to the emscripten OpenCSG/WebGL rendering running in
the main thread.

.scad source --> openscad --enable=inline-import -o out.csg --> update
file used as input for OpenCSG/WebGL foreground process that listens to
file changes.

And keep the current lightweight background runs that just check syntax
errors on the fly:

.scad source --> openscad -o out.ast --> update errors/warnings highlights

Oh, and on another note I'm now trying to prototype ways to add external
libraries by Git URL & keep it trivial to share examples (+ their git deps)
as deep links.

Exciting times :-D

Olivier

Related to that, I also wrote an .scad parser in JS, but it hasn’t been maintained: https://bitbucket.org/openscad/openscad-js.
I do have a (partial) JS customizer parser somewhere as well with a basic React renderer.
I need to spend some time locating that stuff, and see if anything can be salvaged..

Exciting indeed!

-Marius