Sneak peek at Antimony successor

[Matthew Keeter]

Hi Antimony folks!

Everything has been pretty quiet on the Antimony front this year.  Since there are folks using it in the wild, I’ve been hesitant to make big, breaking changes, and the current set of features lines up well with my vision for the software.

Instead, I’ve been pushing my creative energies into a new kernel and bare-bones GUI to go with it.

I’ve put up a staging site at libfive.com, with username = libfive and password = implicit, and I’d love to hear your feedback.

The GUI takes a step back from node-graph-compositing, because I realized that I’d rather focus my efforts on the geometry kernel, but it’s got at least one new killer feature: you can define free variables in the script, then click-and-drag on models, and the changes will back-propagate through the f-reps to try and make it work.

The architecture is also nicely composable: you can use the GUI, or easily build custom CAD systems from lower-level components.

Whatever your involvement in Antimony use and development, thank you – it’s always a pleasure to hear from folks using these tools in the wild.  Since I’ve dropped it into maintenance mode, if you’re interested in taking on more ownership of Antimony in the new year, let me know.  I’d also enthusiastically take up volunteers to port the kernel to libfive!

Happy new year!

-Matt

[Andy Baker]

Hi Matt,

As someone who is new to both Antimony and liblive and interested in playing around with both - could you briefly summarise what might be possible with the new kernel that isn't possible inside Antimony? I'm not so worried about the GUI but I'm curious what geometric possibilities might open up.

[Matthew Keeter]

Hi Andy,

Other than oracles (detailed below), libfive and Antimony’s kernels mostly overlap, but libfive should be faster and more robust in doing all the things that they have in common.

The philosophical change is that libfive is meant as infrastructure, rather than as part of a specific end-user application.  I’ve built a minimal GUI around it, but that’s just an example, and there are other projects (both commercial and open-source) that are using the kernel for other things.

Part of being infrastructure is robustness.  Antimony’s geometry kernel has a handful of tests; libfive has over a hundred test cases that make tens of thousands of assertions.

I’ve gotten rid of the string-based representation of math trees (both old and new syntax), and replaced it with constructing the trees directly with overloaded C++ classes.  This is minor, but it makes the build progress a lot less messy, because I don’t have to wrangle lemon + flex to do the parser generation.

The kernel itself is still based on f-reps, but I’ve put a ton of time into making the meshing fast and robust, so you can use meshes for quick previews (rather than Antimony’s voxel rendering).  The meshes that come out are watertight, hierarchical, topologically manifold, and preserve sharp features.  It's not perfect, but it’s a very strong open-source f-rep mesher.

I’ve also added a universal backdoor to the f-rep paradigm: if you’re using the kernel at the C++ level, you can build black-box “oracles”, which plug into the f-rep tree, but do arbitrary computations.  This is a good way to work around the limitations of pure math trees.  There aren’t many open-source examples of oracles (yet), but commercial users have been using them to interface with other, non-f-rep model representations.

Regards,

Matt

--
You received this message because you are subscribed to the Google Groups "antimony-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to antimony-dev...@googlegroups.com.
To post to this group, send email to antimo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/antimony-dev/459e83ec-29bd-421a-a489-ae34c2d19296%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andy Baker]

> so you can use meshes for quick previews (rather than Antimony’s voxel rendering)

I actually thought it was a shame that the rendering was mesh based.

One of the things that attracted me to Antimony was the fact that at it's heart was a distance field based representation. This allows for geometry that would be insanely complex to represent as a mesh. It's a bit like taking an SVG and rasterizing it. You have to sometimes but it's a one-way, lossy transformation and should be left until the last possible moment.

Now - some things can probably be rendered faster as a mesh but I can think of a lot of cases that can't - and considering the internal representation fits better with a raymarching style approach than polygon approach I was a bit sad to see ugly old-fashioned triangles appearing in the preview! ;-)

(It's worth bearing in mind that I've got very little interest in 3D printing. If anything I'm looking for a way to create interactive applications using tools such as Antimony)

[Matthew Keeter]

libfive is still using the same underlying representation, and the voxel code is still there, but I got tired of not being able to interactively spin around shapes in Antimony.  It would be interesting to spin up a branch of Studio that uses the bitmap pipeline instead of meshing, to see how it compares.

I’d encourage you to try out the libfive + bitmap rendering pipeline for your applications, and I can offer guidance if you’re interested .  The library shouldn't get too coupled to the Studio GUI, so apps that exercise completely different parts of the API + rendering pipeline would be very valuable.

If you’re interested in pure raymarching, you should also check out Curv:

https://github.com/doug-moen/curv

It’s a DSL that compiles to GPU shader language and renders with ray marching / sphere tracing.

I’m generally skeptical about sphere tracing, because I want a rendering pipeline that works with any distance field, not just fields that are well-behaved / Euclidean / Lipshitz-continuous, but if you’re willing to accept those limitations, the demos for Curv are very cool.

Regards,

Matt

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

To view this discussion on the web visit https://groups.google.com/d/msgid/antimony-dev/740ef4ee-9bec-4cb4-b5f4-bdfba48c31ef%40googlegroups.com.

[Andy Baker]

 I got tired of not being able to interactively spin around shapes in Antimony.

I wonder if there's other optimizations that would give similar benefits. I've seen fractal raymarchers that drop into a center-weighted monte carlo kind of thing when you're interacting with it. That's both aesthetically pleasing and scales to be as fast as you need it to be. It could be handled in the fragment shader by just setting a "probability this pixel will exit before raymarching"

Anyway...

I'd love to tinker with the code but my C++ is pretty non-existent and I even struggle to get a build pipeline working properly on Windows.

I was half wondering if the core logic would be easy to port to C# so I could make a Unity native version. How much code is involved in the parsing and the shader generation? Would it be a massive task?

Curv is fab and I've been playing with that too. Interestingly - the author is planning to move away from pure distance fields too: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/curv/ujAV7ej4NZg

 

[Matthew Keeter]

Doing any kind of port to C# is not a great plan, because the codebase is quite optimized and handles a ton of corner cases; it would take a lot of effort to make a new codebase at the same level.

Especially for libfive, I’d look at binding to the C API instead (it looks like there are C# docs here, and a Stack Overflow discussion here).  libfive's C API is verbose and manually manages memory, but you could pretty easily wrap an object-oriented interface around it, including overloading arithmetic operations (e.g. in the C++ example).

That being said, neither Antimony nor libfive do shader generation.  Rendering is done with meshes, or CPU-side bitmap generation.  Antimony’s fab library does do its own math tree parsing, using a custom grammar (thanks, Martin!), but it’s less designed for embedding in other applications; libfive just gives you functions to manipulate math expression objects, and lets the higher-level language decide how to construct expression trees.

It would be pretty easy to walk a math tree and generate a shader from libfive, but no one has looked into it yet.

-Matt

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

To view this discussion on the web visit https://groups.google.com/d/msgid/antimony-dev/e6249b97-8c6a-40f4-a5d1-1f4022cd3864%40googlegroups.com.