For anyone interested - since its not immediately clear from the website (though the graphics are stunning) – TaiChi is a cross platform combined physically based animation and physically based rendering toolkit/ library. It wraps a lot of current state of art research algorithms and significantly simplifies doing graphics R&D. It is also a lot of fun to play with.
With a basic background in computer graphics, I found it took me about 4-6 months to understand and implement a paper like APIC from scratch. TaiChi's author, Yuanming Hu, apparently implemented that and 9 other papers in the same time. It probably helped a lot that he worked directly with the paper authors, but he certainly has been very productive.
I really appreciate that somebody is implementing these papers in the open. It's incredibly useful to have a reference implementation available to study alongside the paper. Seeing the same thing in a few different ways is great for learning.
His 88-line implementation of MLS-MPM is probably a little too much like code-golf, but when I expanded it out to 188 lines, I found it really enlightening.
It's the other way around, wu wei--the absence of effort. The extra wei in the front is the "doing" of "not doing" (wu wei) which seems to be something particular to this author. https://en.wikipedia.org/wiki/Wu_wei
Can the submitter explain this better? What sort of computer graphics? Real-time simulated? Path traced? I explored the website and the github and neither really made clear. "Computer graphics" is so broad as to be useless as a descriptor.
> Taichi is an open-source computer graphics library with implementations of 40+ graphics papers. It has a hybrid design: a C++14 kernel part, and a user-friendly Python 3 wrapper.
That's the extent of the information on that page.
Doesn't answer the questions I had. Is this real-time or batch rendered? Also, the site advertises it as a "computer graphics library" but many of these demos are more about physics simulation, which only adds more confusion...
Physics simulation is a very active computer graphics research topic (see e.g. the SIGGRAPH conference). The goal in computer graphics research will not be to have an exact result, but to have a visually plausible (and pleasing) result as fast as possible.
Yes, I know. But such libraries often call themselves "physics simulation libraries." The term "computer graphics" is typically reserved for rendering. So what is this library doing? The scene setup and rendering? The offline rasterization? The frame-to-frame physical simulations? More than one of the above?
It's a library of complete physically-based simulation and rendering algorithm implementations.
You seem to be assuming that "library" must mean a layer or an API providing certain runtime abstractions or functionality. That's not really what this is. It's more about code reuse and a rationalized core of tools for implementing the various techniques.
There's a number of interactive simulations. My impression is that it's for writing research code, which often requires scaling things down to iterate on the simulation behaviours at interactive rates, then scaling up and going offline to make a cool video.
You are clearly familiar with the latter. Perhaps take a couple of minutes to read through the linked project and answer the question here, for everyone's reference?
I'm actually not very familiar with it, other than it's meant for more real-time stuff and it supports a lot of different platforms. I'd love someone comparing that is actually educated on the topic (computer graphics) :P
Unity is a full blown game editing and creation suite with a complete engine (physics, rendering, assets, sound, so on). This is a graphics library using some very fancy, very modern research.
Yup, true uncanny valley - it's clear that this is something similar to banana but significantly different, it doesn't behave like a banana at all but like dough or modeling clay in the shape of a banana.
I'd never considered how a banana would look like when cut, and I'm not certain how it should look but I'm certain that it's not like this.
The banana example comes from the MLS-MPM paper[1]. MPM is basically a way of simulating deformable solids using particles. The big thing that the MLS-MPM paper achieved was that the particles wouldn't magically interact with their neighbours on the other side of a thin solid.
The example is kind of ugly, but it's really only trying to illustrate one specific property of their simulation: that the knife can properly separate neighbouring particles from each other without any spooky interactions between the banana on one side of the knife and the banana on the other side.
