antimony

antimony copied to clipboard

@mkeeter Matthew:

1. Antimony -> About says © 2013-2014 Matthew Keeter does it mean the "parallel universe" time has stopped in 2014? :-)

2. seriously, do you plan to convert Antimony into abandonware any time soon?

Thank you.

Hi Andrei,

I'm not planning on archiving the repo, if that's what you're asking – I'll continue to accept PRs and do my best to keep things compiling as dependencies shift around.

Feature-wise, I don't have any major plans, for two reasons:

• Antimony is close to "done" as I imagine it – there aren't any more major features that I was itching to add.
• The feature-full GUI is hard to maintain in parallel with a robust geometry kernel, mostly due to my limited time.

I've been focusing my time onto the kernel side of things, with libfive – it's a faster / more robust / overall better kernel than Antimony's, but breaks backwards compatibility in a few ways that make it not a straightforward upgrade. It's also meant to be infrastructure for a variety of UIs – I've built one, there are a few of third-party UIs linked in the README, and there's at least one commercial product that's using it.

It would be a fun and worthwhile project to port Antimony to the newer kernel, but it's unlikely that I will get around to it myself.

As always, if folks step up with bold ideas for new features, I'd be happy to mentor and offer advice.

It would be a fun and worthwhile project to port Antimony to the newer kernel, but it's unlikely that I will get around to it myself.

Antimony is too nice of a tool to die. Hopefully someone can/will port it to the newer kernel.

do I understand correctly that the features like feature detection would be lost with such conversion?

also if

Antimony is under active development. It's at a beta level of stability: solid, but not recommended for mission-critical use.

in README is not true, it is to be updated. I'd make PR as I'm sure about active development, but I don't know about stability level

Good point, updated README in d875666b025ae3dc48b258d5810fc1cd9186e32f

Good point, updated README in d875666

FYI the project page on your site still says "active development":

• https://www.mattkeeter.com/projects/antimony/3/

[Noticed while writing a comment about how Antimony is an example of a great system for node-based 3D creation. :D I do hope it returns in some form, one day... :) ]

It would be a fun and worthwhile project to port Antimony to the newer kernel, but it's unlikely that I will get around to it myself.

I can see that you're doing quite a lively research recently. The question is - what should be the newer kernel? libfive, mpr, fidget? Fidget seems to have the greatest potential but it is still a startup. Do you plan to make it as stable as libfive some day or is it just an experimental foundation for another new project?

@p4l1ly Antimony is basically frozen at this point – maintaining a kernel + GUI is too ambitious, and my interests lie more on the kernel side.

With libfive, I was hoping that others would use the kernel and build their own UIs on top of it, so I scaled back the scope of the built-in UI. This experiment had mixed results: it seems like many people were still using the built-in Studio UI, but there were a few folks that built their own tools using the kernel.

At this point, libfive is mostly frozen; I may still do maintenance work on it, but don't plan to use it as a foundation for future development. After using Rust for personal and professional work for several years, coming back to C++ is painful – especially for side projects, which rely on my outside-of-work time and motivation.

MPR is totally frozen; I wanted to release code to go with the research paper, but do not intend to continue developing in that repo (if only because I no longer have a machine capable of running CUDA).

Fidget is, like you said, very experimental! I'm making slow progress, but even though it's more ergonomic than C++, my outside-of-work time has been limited over the past few months. It's even more narrowly focused (at the moment) on a fast evaluator, and I'm ambivalent about implementing higher-level algorithms (e.g. meshing) because I'm fundamentally unsatisfied with what's in the literature.

The situation is summed up in this comic 😅 . I hope that clarifies my current thinking, even though it doesn't give you a single solution for "what to build on right now".