GUI roadmap

[doug moen]

I just added syntax colouring support for Curv programs in the gedit text editor. But, in the long run, I'm going to drop gedit in favour of a dedicated Curv IDE. Here's a roadmap towards the Curv GUI.

1. The Viewer window

I've already dropped the dependency on glslViewer, and incorporated that code into the Curv project. Now I'm working to better integrate the language interpreter/compiler with the geometry engine, which includes the OpenGL code that powers the Viewer. This will lead to a lot of new capabilities. I'm adding the ability to import images, voxel arrays, fonts and triangle meshes into Curv. I am also implementing graphical value pickers for dynamically tweaking model parameters. These will initially be implemented in the Viewer window.

2. The Editor window

I plan to drop the dependency on gedit, and replace it with QScintilla, which will run in a Qt window, in the same address space as the Curv language and the geometry engine. This will allow tighter integration with the other Curv components, leading to an IDE. QScintilla supports syntax highlighting and code folding, so I'd probably start with that.

3. The Console

Once the QScintilla editor window is implemented, I can then add a console widget to the bottom of the window, replacing the use of the terminal window from which you started Curv. Once this is done, I will have a full GUI interface, and there will no longer be a need to use a terminal window to run Curv.

At this point, I'll have two windows. The editor/console window will use Qt. The viewer window will use GLFW and OpenGL, and a video game IMGUI library to implement the value pickers.

4. a Windows port

At some point, Curv will be ported to Windows. First I'll eliminate my dependencies on external components that don't support Windows, such as glslVIewer, gedit and GNU readline. Even depending on a terminal window is not a good idea on Windows.

There won't be a big bang where a GUI will suddenly appear. My plan is to implement this in a series of small steps, preserving full functionality at each step.

[Torleif Ceder]

I assume an integrated viewer also could have a fixed step ray marching mode as alternative to sphere tracing in cases of very bad distance fields albeit with worse performance.
Another thought was tho have a kind of geometry that renders but don't export to 3d file. grids, arrows, dimensions, construction helpers. etc. maybe with semi transparency.

[doug moen]

> I assume an integrated viewer also could have a fixed step ray marching mode as alternative to sphere tracing in cases of very bad distance fields albeit with worse performance.

Right, I definitely plan *something* like that. Instead of fixed step, I am thinking about prototyping this:

"CSG Operations of Arbitrary Primitives with Interval Arithmetic and Real-Time Ray Tracing"
https://www.cs.utah.edu/~aek/research/csgimplicits.pdf

I expect this algorithm to offer a better combination of speed and accuracy than fixed step, but I also expect it to be slower than sphere tracing. If I get good results from a test implementation, then I'll go all in and hack the Curv geometry compiler to implement interval arithmetic.

--
You received this message because you are subscribed to the Google Groups "Curv" group.
To unsubscribe from this group and stop receiving emails from it, send an email to curv+unsubscribe@googlegroups.com.
To post to this group, send email to cu...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/curv/915795cf-bd3d-4ccb-96f1-64f73e193f92%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[doug moen]

> Another thought was to have a kind of geometry that renders but don't export to 3d file. grids, arrows, dimensions, construction helpers. etc. maybe with semi transparency.

There are two ideas here.

First, I would like to implement translucent objects. Curv is intended to support advanced 3D printers. There are already 3D printers on the market that can print full colour objects with opaque and translucent regions. I'd like to be able to model such objects in Curv, view them and print them.  For example:

http://idarts.co.jp/3dp/wp-content/uploads/2017/12/GRABCAD-VOXEL-PRINT-4.jpg

I don't have a clear idea how this will be implemented yet, though.

Second, yes Curv already has operations like `show_axes` and `show_dist` which add debug information to the scene you are viewing. If I'm using these helpers, currently I comment out the code before generating an STL file.

On 27 June 2018 at 11:50, Torleif Ceder <torlei...@gmail.com> wrote:

--

[Garreau, Alexandre]

Le 27/06/2018 à 12h57, doug moen a écrit :
> First, I would like to implement translucent objects. Curv is intended to
> support advanced 3D printers. There are already 3D printers on the market
> that can print full colour objects with opaque and translucent regions. I'd
> like to be able to model such objects in Curv, view them and print them.
> For example:
> http://idarts.co.jp/3dp/wp-content/uploads/2017/12/GRABCAD-VOXEL-PRINT-4.jpg
>
> I don't have a clear idea how this will be implemented yet, though.

Do you mean how to render them? Because I guess the simplest (and
intuitive) way for API would be a forth “alpha” channel to the color
function? I mean, except for rendering, it’s not different than color,
and is akin to them.

Also, what about more complex and advanced material properties? I’ve
seen a mail on this list about an HP printer with material with
translucency, flexibility, electroconduction, and smoothness (and their
counterparts), all these with variable levels… and even more advanced
fine-tuning (we already have PLA filaments mixed with wood, bronze or
stain).

This later might be quite complex as it might easily extend with more or
less material (each one with different linear levels), so maybe we
should have a record to represent them?

That might also allow material physical simulation, with another
software or maybe with curv far in the future (afaik sdf physical engine
not planned for it?). Or at the opposite that may not need to render…
or need to render with just different colors, to visualize them… or,
more complex: select only what’s in X or/and Y material and display it,
maybe allowing CSG / set operations on colors (like “intersect the red
part of this shape with the green part of this other shape”), but I
guess it’s currently not possible with the current mechanism of two
separate functions for shape and colors?

[doug moen]

I agree, it makes sense to support translucency by adding an alpha channel to the colour function. But, I don't know how to ray-trace this. I just haven't spent any time researching the issue. I am open to the possibility that there might be a different representation of translucency that is easier to render in 3D.

If we extend colour with an alpha channel, then we can combine two colour fields using Porter/Duff compositing operators.

 

Also, what about more complex and advanced material properties? I’ve
seen a mail on this list about an HP printer with material with
translucency, flexibility, electroconduction, and smoothness (and their
counterparts), all these with variable levels… and even more advanced
fine-tuning (we already have PLA filaments mixed with wood, bronze or
stain). 

This later might be quite complex as it might easily extend with more or
less material (each one with different linear levels), so maybe we
should have a record to represent them?

That sounds reasonable. We could have a `material` function that maps (x,y,z) to a material value, which is a record. Still lots of details to work out.

With multi-material models, the questions are: How is it represented as a Curv shape? How is it rendered in the Preview window? How is it exported as a file for 3D printing? The latter is very dependent on how the 3D printer hardware works. So far, I've investigated output formats for multi-head FDM 3D printers (need multiple triangle meshes, one for each material), and for the Stratasys J750 (need a voxel array with a material ID in each voxel: there are only 14 material IDs). I don't have any detailed info about the HP Multi Jet Fusion, but the current generation only does opaque single-material full colour printing, which I already support. Future generations of the HP Multi Jet Fusion might have more interesting requirements.

 

That might also allow material physical simulation, with another
software or maybe with curv far in the future (afaik sdf physical engine
not planned for it?).

Engineering people use finite element analysis to simulate the physical properties and behaviour of a 3D object, and to guide the design of the object, which might later be 3D printed. It's possible that the Curv geometry engine could be used in this context: I'm designing it as a C++ library that could be used by other apps. But I'm not personally building a 3D simulation app.

 

Or at the opposite that may not need to render…
or need to render with just different colors, to visualize them… or,
more complex: select only what’s in X or/and Y material and display it,
maybe allowing CSG / set operations on colors (like “intersect the red
part of this shape with the green part of this other shape”), but I
guess it’s currently not possible with the current mechanism of two
separate functions for shape and colors?

I can see how to do this with new features I'm planning for the geometry engine.

An "intensity field" is a function that maps (x,y,z,t) onto an intensity, which is a number between 0 and 1. Similar to the alpha component of an RGBA colour field.

In order to isolate "the red part of this shape", you could map the shape onto an intensity field that answers the question "how red is the shape at this point" with an intensity value between 0 and 1. Then you convert the intensity field to a signed distance field by extracting an isosurface (eg, the isosurface at intensity == 0.5). The operation of "converting a scalar field to a signed distance field by extracting an isosurface" is only planned to work on voxel arrays. See: Distance Transform. I'm adding pixel and voxel arrays as an alternate representation of 2D/3D scalar and colour fields.

[Torleif Ceder]

Tripple OS support with easy install seams crucial for wider adoption when Curv is ready for prime time.

What's your general take on browser based "shadertoy" like playgrounds?

[doug moen]

Playgrounds are a great idea. I like the idea of an online repository of Curv modules that you can browse and reference in your own code, borrowing ideas from shadertoy and github. I've purchased the domain 'curv3d.org', which could be used for this.

I am not sure about putting all of Curv inside a browser, though. Yes, the current tech could run in a browser. But when I look at where I'd like to take this technology, I don't like the limitations of the browser executable environment, and at this stage I don't want to design primarily for the browser. I prefer to have full access to the GPU and full control over performance, so that I'm free to use any technology that might be used in an AAA video game or desktop 3D design tool. I want to build up the capabilities of the underlying Curv geometry engine, so that I can render fonts, meshes and voxel data as Curv shapes, and maybe implement ray tracing. The geometry engine needs to be written in C++ or maybe Rust. I might need to use Vulkan instead of OpenGL at some point.

It is likely possible to compile the Curv language engine and geometry engine into Web Assembly and execute it on a browser. But long term I expect that only a subset of Curv will work in a browser. I know that you can't port the entire OpenSCAD language to a browser, because the `text` module can't be ported: there's no low-level access to fonts available in Javascript.

So that means the primary way of using "playgrounds" in Curv will be using a native desktop app, not a browser.

On 13 July 2018 at 02:38, Torleif Ceder <torlei...@gmail.com> wrote:

Tripple OS support with easy install seams crucial for wider adoption when Curv is ready for prime time.

What's your general take on browser based "shadertoy" like playgrounds?

--
You received this message because you are subscribed to the Google Groups "Curv" group.
To unsubscribe from this group and stop receiving emails from it, send an email to curv+unsubscribe@googlegroups.com.

To post to this group, send an email to cu...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/curv/9bee6371-c339-48ac-aefa-dd69330702e2%40googlegroups.com.

[doug moen]

> What's your general take on browser based "shadertoy" like playgrounds?

One limitation of shadertoy.com is that there is only a fixed set of image/audio/video files that you can choose from. You can't upload your own texture files to shadertoy.com. I think the reason is that these files can be huge, and the owners of shadertoy.com can't afford to host huge amounts of video and other such data files.

I have the same problem. I want Curv to be able to import meshes, images and voxel grids. So Curv programs might contain large data files alongside Curv source code. And that means I won't have the resources to operate a web site similar to github or shadertoy, that centrally hosts large numbers of Curv programs, together with all of their data files.

So I'll use a distributed model, where Curv packages are hosted anywhere the author likes, but there is still a centralized index of Curv packages that you can search, or browse, or register your package with. This system is part of the the Curv package manager.

A Curv package is a collection of files, together with some file naming conventions, that contains Curv source code, data files, and metadata. Multiple versions of a Curv package may be hosted in a git repository. You can reference a package from within a Curv program using a git repository URL and an optional version number.

There will be an index of popular Curv packages hosted on curv3d.org. The Curv IDE will let you search or browse the index. With git integration, the IDE could offer a shadertoy-like experience of browsing, running and editing Curv packages hosted 'in the cloud'.

 

On 13 July 2018 at 02:38, Torleif Ceder <torlei...@gmail.com> wrote:

Tripple OS support with easy install seams crucial for wider adoption when Curv is ready for prime time.

What's your general take on browser based "shadertoy" like playgrounds?

--
You received this message because you are subscribed to the Google Groups "Curv" group.
To unsubscribe from this group and stop receiving emails from it, send an email to curv+unsubscribe@googlegroups.com.
To post to this group, send an email to cu...@googlegroups.com.

[doug moen]

Long term, I'd like to support 5 platforms: Linux, macOS, Windows, Android, and web browsers.

There are challenges. I currently use the OpenGL API. My planned next gen renderer requires compute shaders.

* macOS has an old, deprecated version of OpenGL with no compute shader support.

  I would have to use either Metal or Vulkan.

* On Windows, the WIN32 API is terrible for porting Linux code, but at least it supports OpenGL and Vulkan.

  If someone wants Curv in a UWP app, then OpenGL and Vulkan are forbidden, you must use DX12.

* WebGL 2 is available in less than 50% of deployed browsers, and despite being new, it doesn't have compute shaders.

  Some browsers on some platforms have a compute shader extension (eg, Firefox on Linux).

* The big 4 browser makers have agreed to define a new standard called WebGPU, which will fully support Curv on all platforms.

  This is some years from being released.

Realistically, supporting 5 platforms will require a multi-person development team. Right now, I need to focus on implementing the rest of the core features of Curv. I expect Curv will become more popular once a full implementation is available, and maybe that will attract developers.

[Andy Baker]

I'm especially interested in some level of integration with Unity. 

Now - It's fairly simple to manually grab the distance function from the Shadertoy output and to paste it into an existing Unity HLSL shader (the syntax differences are usually trivial to fix).

However the comment below got me thinking. One thing Unity does do remarkably well is abstract away the various underlying GPU APIs. Unity's flavour of Cg/HLSL can cross-compile to OpenGL, Metal, Vulkan, OpenGL ES, DX12 etc. Compute shaders work in most cases where the underlying platform supports them.

I'd actually be worse off with a version of Curv that generated Metal/Vulkan code as I would have to deal with platform differences directly.

Ideally I'd like a build of Curv where I could add a light C# wrapper, call it with a piece of curv code and get back just the distance function. The sphere tracing and any other boilerplate would be part of my Unity app. Sadly my C++ is fairly rudimentary so it wouldn't be a simple task for me to achieve this on my own but I can't help but think that making curv more modular might benefit a wide variety of use cases - not simply my own. A light version that could be compiled without any of the display or OS integration might be a really useful building block for other projects. I can imagine the Python community finding it pretty useful. Compiling it to Web Assembly and plugging it into three.js or would also probably interest many.

(one of my eventual potential goals is to make an interesting interactive toy - potentially a VR-based one - along the lines of Structure Synth and it's ilk)

/ramble mode off. Not sure what I'm trying to say but probably just hoping to provoke further debate.

Incidentally - what do compute shaders buy that the current architecture lacks? I would imagine it opens up optmisations such as monte carlo / fixed foveated rendering for one thing. What else?

To unsubscribe from this group and stop receiving emails from it, send an email to curv+uns...@googlegroups.com.

To post to this group, send an email to cu...@googlegroups.com.

[doug moen]

WebGPU is going to be a clean, cross-platform API layered on top of Vulkan, DX12 or Metal, with implementations in C++, WebAssembly and web browser Javascript. It's backed by Apple, Google, Mozilla and Microsoft. Once they deliver this, then I can replace OpenGL with WebGPU, and not worry about targeting multiple GPU rendering APIs. I'm currently using OpenGL. In the future, in order to get cross-platform compute shaders, I'll transition to Vulkan (which works on Linux, macOS, WIN32 and Android). Then finally, I'll transition from Vulkan to WebGPU. As long as this is a one-man project, I don't want to simultaneously target multiple GPU render APIs, so I won't target DX12 or Metal directly.

I'll continue to emit GLSL until I have a clear reason to change. When I transition to Vulkan, I'll grab a library that translates GLSL to SPIR-V. If you are just relying on FRAG export, then you shouldn't be affected.

How about if I add a '-o glsl' export option? This exports the dist and colour function of a shape, plus the bbox, but nothing else. You can invoke the curv command line tool from your C# wrapper.

Internally, Curv *is* modular. The '-o glsl' export can be implemented with just the Curv C++ libraries. But not yet. The libcurv API is highly unstable, and is not available for public use. I might stabilize libcurv and provide a public API once Curv reaches version 1.0.

Python integration is on my long term roadmap, once libcurv is stabilized. Compiling to webassembly is a goal, but under my current plan, I won't have that until WebGPU is ready. Adding more C++ developers to the project would speed things up.

I want Curv to support programming in the style of Structure Synth and Context Free -- 2D and 3D shapes generated by context free grammars. There's no detailed design for that yet, it's just that I want Curv to support all the techniques for algorithmically generated shapes. I think that shape grammars will generate large unions. In order to make this efficient, I think I need compute shaders.

Currently, Curv is based on the signed distance field/sphere tracing techniques explored by the demoscene, shadertoy, and fractal forums. The union of a list of shapes is the minimum of the distances to each shape. The rendering cost of a union is the cost of the sum of the costs of the component shapes. This means large unions are slow: it's an O(N) algorithm, and we'd prefer something faster, like O(log N). Also, compiling a large union into a single monolithic GPU kernel doesn't give good ray-casting performance. Once the kernel gets too big, you run out of registers and overwhelm the instruction cache.

To speed up rendering, I want to use a GPU pipeline, which requires compute shaders. Large unions are factored into a tree, a bounding volume hierarchy (BVH), with small GPU kernels at the leaves. This is essentially the same as an "acceleration structure" used by ray tracers. The first kernel in the pipeline is the "culling" kernel, which partitions the viewport into "beams" (eg, 16x16 pixel arrays). For each beam, we traverse the BVH and make a list of shapes that intersect that beam. The next kernel performs ray casting within each beam, using the list of shape ids as input. The lighting model is handled by subsequent kernels in the pipeline. Ambient occlusion doesn't need to be computed for each pixel, we can compute it at a lower resolution, so that happens in a separate kernel.

That's the current idea, anyway. Once I start coding this pipeline, the design will evolve. And getting this kind of pipeline to work in a web browser is no doubt ambitious, but if I wait for WebGPU, then it might be more feasible.

Monte Carlo rendering is a ray tracing technique, and fixed foveated rendering is a VR technique. That stuff is interesting, but it's beyond my planning horizon. I want simple ray-*casting* to work more efficiently, and for a wider range of distance functions, and with an improved lighting model, before I start thinking about ray tracing.

To unsubscribe from this group and stop receiving emails from it, send an email to curv+unsubscribe@googlegroups.com.
To post to this group, send email to cu...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/curv/a3ffe6a4-0477-46b4-aa5c-b8bb3bc8dfea%40googlegroups.com.

[Andy Baker]

> How about if I add a '-o glsl' export option?  

That would be fantastic. Of course I'd also need some way to generate a binary on Windows (Unity has Linux support but most users are Mac/Windows and most people who want to do crazy things with their GPU are on Windows). Is there any way to get something built on Windows minus the OS and graphical side of things? Just something you can call and get back the fragment code?

  > I want Curv to support programming in the style of Structure Synth and Context Free 

That sounds fascinating. I was playing with both of those recently and thought it was a real shame development had stopped. 

> To speed up rendering,... [snip] ...in a separate kernel.  

Do we lose any of the peculiar benefits of raymarching with this approach? It may be a little niche but one of the things that fascinated me in the first place with raymarching are those things that are incredibly cheap which would be astonishingly expensive with most other approaches - infinite fields of repeated geometry and the ability to make huge global changes to structures almost instantaneously.

> Monte Carlo rendering is a ray tracing technique, and fixed foveated rendering is a VR technique

I might be using the terminology incorrectly but I've seen some fractal raymarch renderers that use an approach along the lines of "Don't render every pixel immediately. Randomly pick a point with a bias towards being in the center of the screen and render that"

It allows you to interactively move around complex shapes that would usually slow your GPU to a crawl. It's a lot more pleasing than simply rendering at a lower resolution. And of course it works especially well in VR. (Actually I wonder if there's a hacky way to do something similar with fragment shaders. Send in an extra parameter when the user is moving the view that gives each fragment a >1 probability to bale out instead of marching it's rays...)

To post to this group, send email to cu...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/curv/a3ffe6a4-0477-46b4-aa5c-b8bb3bc8dfea%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

ixxy.co.uk • t 01273 906061 • m 07968 119324

[doug moen]

Hi Andy.

There is no native WIN32 Windows port. I don't have the resources to tackle this right now. It's far easier for you to spin up a VM, install Ubuntu, and install Curv in that VM, than it is for me to do a Windows port. If you have Windows 10, then WSL (Windows Services for Linux) gives you a Microsoft provided Ubuntu Linux environment (with no GUI). I imagine that Curv would build just fine on WSL, but that you would get an error message if you tried to open a GUI window. Using -o frag or the proposed -o glsl should work just fine in WSL. If you try this, let me know if it works, or if you run into problems.

> infinite fields of repeated geometry and the ability to make huge global changes to structures almost instantaneously

That flexibility comes from the representation of shapes as Signed Distance Fields (SDFs). I want to preserve the flexibility of the SDF representation, but I want to render them faster than what is possible with the standard ray-marching algorithm (which is actually called Sphere Tracing). You get into trouble with standard ray-marching if you try to render a union with thousands of elements. So I'm going to fix that problem by using the acceleration structures that were originally designed to make ray tracing fast.

> I've seen some fractal raymarch renderers that use an approach along the lines of "Don't render every pixel immediately. Randomly pick a point with a bias towards being in the center of the screen and render that". It allows you to interactively move around complex shapes that would usually slow your GPU to a crawl.  It's a lot more pleasing than simply rendering at a lower resolution.

Can you provide a reference for this? Progressive rendering (like in Fragmentarium) is something I want in Curv. But I was intending a dumb implementation where you render in low resolution first, then fill in the details. If there is a better way to do it, I would like to learn about that.

To unsubscribe from this group and stop receiving emails from it, send an email to curv+unsubscribe@googlegroups.com.

To post to this group, send email to cu...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/curv/a3ffe6a4-0477-46b4-aa5c-b8bb3bc8dfea%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

ixxy.co.uk • t 01273 906061 • m 07968 119324

--
You received this message because you are subscribed to the Google Groups "Curv" group.

To unsubscribe from this group and stop receiving emails from it, send an email to curv+unsubscribe@googlegroups.com.

To post to this group, send email to cu...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/curv/CAM1wKe%2BU1ALcHP9e9z9NFAWg9Bucv3V_XVp%2BrW1aNUfPmhgaeQ%40mail.gmail.com.

[doug moen]

Although you could invoke a WSL executable from within a Unity program, that's not suitable if you are shipping a game to end users. It would work for your own personal experimentation. And if you want to directly invoke the Curv library API from another language (like C#), instead of just running the Curv command line executable, then the best solution is for Curv to offer a public C API. Otherwise, you won't be able to link with the Curv API without writing C++ code.

Prebuilt executables, and a library with a public C compatible API, are things I need to consider offering in Curv 1.0, but it won't happen this year. 

[Torleif Ceder]

Thank you.
Very interesting discussion (the parts that i do understand).
I wonder if accessing distance functions made in Curv from other program can stoke some interest in  Curv from other communities.
I image some one for example interested in polygonization algorithms could use a versatile sdf back end. Maybe I'm being naive here.

To unsubscribe from this group and stop receiving emails from it, send an email to curv+uns...@googlegroups.com.

To post to this group, send an email to cu...@googlegroups.com.

[Andy Baker]

> Can you provide a reference for this?

The app I was thinking of is https://nshelton.github.io/vr/fractals/2017/12/30/RTA.html

Reading that post - he mentions reprojection in addition to the "foveated and stochastic sampling pattern" mentioned later. It's really a remarkable experience compared to other fractal renderers I've tried. Feels very responsive.

Yeah - I'd want anything I built on Curv to be usable by others. I guess I could offer WSL as an option with a fall-back to calling a remote Curv running on a remote server. Hacky - but it would be feasible as a stop-gap. Assuming I actually end up with something I want to distribute that is!

Thanks for your time.

To post to this group, send email to cu...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/curv/70500f1e-f912-45e3-8856-7edfe2241f67%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[doug moen]

Andy said: https://nshelton.github.io/vr/fractals/2017/12/30/RTA.html

Wow, that is nice technology. When it's time to implement progressive rendering in Curv, I will definitely be looking at his algorithms. Now that I've seen the demo, the "foveated and stochastic sampling pattern" seems like a good idea for progressive rendering, even if you aren't doing VR or raytracing.

Torleif said: I wonder if accessing distance functions made in Curv from other program can stoke some interest in  Curv from other communities. 

I image some one for example interested in polygonization algorithms could use a versatile sdf back end.

Most polygonization algorithms run on the CPU. For that use case, I have the ability to export the distance function as C++ source code (using -o cpp).

If you use

    curv -o foo.stl -O jit foo.curv

to export an STL file, then the -O jit option will tell Curv to export the distance function as C++ code, invoke the C++ compiler to compile the source into a shared library, then load the shared library into memory. Now I have an in-memory version of the distance function compiled into optimized machine code, so I use that as input to the polygonizer.

To unsubscribe from this group and stop receiving emails from it, send an email to curv+unsubscribe@googlegroups.com.

To post to this group, send email to cu...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/curv/70500f1e-f912-45e3-8856-7edfe2241f67%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

ixxy.co.uk • t 01273 906061 • m 07968 119324

--
You received this message because you are subscribed to the Google Groups "Curv" group.

To unsubscribe from this group and stop receiving emails from it, send an email to curv+unsubscribe@googlegroups.com.

To post to this group, send email to cu...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/curv/CAM1wKe%2BENwsifoUiWL9RVo1ReQK7AX8vJcSVWC9uLsnoOTCwLw%40mail.gmail.com.

[Hans L]

On Fri, Jul 13, 2018 at 4:40 PM doug moen <do...@moens.org> wrote:
> It is likely possible to compile the Curv language engine and geometry engine into Web Assembly and execute it on a browser. But long term I expect that only a subset of Curv will work in a browser. I know that you can't port the entire OpenSCAD language to a browser, because the `text` module can't be ported: there's no low-level access to fonts available in Javascript.

This is a bit of a delayed reply, but I noticed a recent update for
OpenJSCAD where someone is working on a font library:
https://github.com/jscad/OpenJSCAD.org/issues/396
https://github.com/nodebox/opentype.js/