Hi, I'm the author of Taichi. Thank you so much for your attention on this project.
As you may have noticed, Taichi is still a work in progress and far from perfect. Actually, I plan to bring this project to you guys after a stable interface and comprehensive documentation are finished. I didn't plan to ``promote'' it today but for some reason it just gets some attention. I'm so surprised and my website taichi.graphics went down for the first time due to increased traffic. Thus I upgraded the server on GoDaddy...
About the Chinese name 太極, as noted in the FAQ section at http://taichi.graphics/misc/, I chose this word in the intersection of traditional Chinese (which is still used in some parts of China nowadays) and modern Japanese, since a significant part of Taichi was done during my internship at the University of Tokyo.
GPU support is absolutely meaningful, especially for the simulation part (like the snow and smoke). If I'm given more time (and access to GPUs) I would definitely try GPUs someday. For the rendering part, it's like CPUs are still widely used in the industry, though there are renderers with GPU support like LuxRender. Another consideration is that CPUs are more friendly to programmers and researchers for prototyping.
I'm recently doing a full-time internship at Microsoft Research Asia and have very limited time for this project. If you would like to contribute, that's truly appreciated.
Thank you again for your support and encouragement.
Really nice! I'm not into the graphics world enough to contribute code, but I noticed in your Gallery it mentions running stuff on your laptop. I have access to some nice dual socket Xeon servers with tons of memory, so I could run some bigger simulations for you. Email me if interested.
Thank you very much. I believe Taichi will provide end-users with a friendly enough Python interface so that everyone can play with large-scale simulations. As noted it's still a work in progress and I believe after the stable release you can freely simulate whatever you want with the servers :-)
It's a good idea to rent some CPUs/GPUs on the cloud like EC2 :-> but for me currently the major limitation is time - I have to first finish the documentation and stable interface, and then people can play with it.
Hmm. I'm looking for a procedural renderer with C++ integration for my moon rendering project (http://cowlark.com/flooded-moon/). Right now I'm using a customised version of Povray, but it's not very satisfactory.
The trouble is, I need to render planets, which are very very big objects, typically seen from very very close up; Povray's the only renderer I've ever found which could cope, and even then it needs clever tricks to avoid floating point errors. I'd like to switch to something else.
I do see that Taichi is based on embree (https://embree.gi) for doing the raytracing heavy lifting, which I did briefly look at; looking at it again I see there's a standalone renderer now (https://embree.github.io/renderer.html).
I'll certainly take a look. I wonder if Taichi does Rayleigh scattering? I need it to do atmospheres...
I would imagine you could benefit from a bit of thought about how to handle your coordinate system to avoid floating point precision problems. There are ways to avoid huge numerical precision ratio issues. It should only be a problem if you are simultaneously visualizing very large and very small objects, but in that case there are other methods (e.g. pre-rendering small objects that won't change much based on the viewing angle). If you are blindly throwing huge numerical ratios at your renderer you are bound to have problems.
It's not ideal, of course it would be better to ignore such issues and just find a system that can "handle it" but dealing with numerical issues and the need for "clever tricks" is simply a reality of dealing with numerical approximations of reality.
Well, I am rendering very large and very small objects, many of which intersect. Planets are modelled as a single huge object (earlier versions of the project used a Povray isosurface, but I'm now generating a mesh for the area around the camera). That's pretty much unavoidable based on the goals of the project.
What I'm currently doing is arranging things so that the camera's at (0, 0, 0) in world space, which means that precision loss caused by arithmetic is minimised. That solved the problem completely for me, by which I mean that I haven't noticed any more artifacting. But it does mean that I have to be aware of where each object is going to be in space rather than just creating them using local coordinates and translating them later.
I guess my point was more that you can't really expect another renderer to do much better, as it's a problem with what you (were) doing rather than a problem with the renderer per-se. Making things closer to the camera coordinates probably overall makes sense. But, I still think it's not a bad idea if you run into more trouble, you could also try rendering small and large objects separately and compose them afterwards. You'll still have to mess around with coordinate systems of course but separating the large and small objects might make it easier to do that. (e.g. make large objects smaller, camera closer, and render, make small objects bigger, camera same distance, overlay the two images.. it's to force the vector coordinates to be in ranges that are tractable for the rendering algorithms. Annoying, but possibly necessary in your case.)
Taichi currently supports volumetric scattering but I guess Rayleigh scattering involves spectral rendering, which is a planned feature in the future. :->
“太極” is a word from not only traditional Chinese, but also modern Japanese. Considering the fact that a significant part of Taichi (10+ papers and the general software framework) was done during my internship at The University of Tokyo hosted by Prof. Seiichi Koshizuka and Prof. Toshiya Hachisuka, I thereby chose this word in the intersection of two languages in memory of my time at UTokyo.
I think the question of whether this is interesting is based on assuming the author is Chinese. This assumption isn't unwarranted, given information on the About page.[0] For example, he participated in the China National Olympiad in Informatics and he's attending Tsinghua University, in Beijing. Given how sensitive cultural assumptions can be, I'd like to make clear that I'm very clear that this is pure speculation based on circumstantial evidence and more than happy to learn more about this and be corrected as needed.
From my reading, traditional characters are still in use in China (distinguished for the purposes of this discussion from Taiwan).
Traditional characters are used informally in regions in China primarily in handwriting and also used for inscriptions and religious text. They are often retained in logos or graphics to evoke yesteryear.
An application name is not all that different from a business name or a logo. Given this, choosing to use traditional Chinese characters (in this case 太極 in contrast to the simplified 太极) is consistent and not necessarily unusual. Of course, this is all speculation without hearing from the author.
My understanding is historically simplified writing systems are met with a lot of resistance when there is a small educated class interested in holding on to their status since they are intended to help bring literacy to the masses. A sort of parallel can be drawn with the Luther Bible. This was a threat to an intellectual class (the clergy) who's status was in part due to their knowledge of Latin. A similar thing also happened with Hangul in Korea. Taiwan still uses traditional characters. Beyond these facts, I'm not sure of the particular connotations the grandparent is referring to.
Simplified Chinese isn't really any easier to read than Traditional (actually, learning Chinese I find Traditional characters a tad bit easier¹). It's just easier to write by hand. With computers and IMEs I would say there's not much difference in ease of reading or writing.
1. There seem to be more phono-semantic compound characters.
As you may have noticed, Taichi is still a work in progress and far from perfect. Actually, I plan to bring this project to you guys after a stable interface and comprehensive documentation are finished. I didn't plan to ``promote'' it today but for some reason it just gets some attention. I'm so surprised and my website taichi.graphics went down for the first time due to increased traffic. Thus I upgraded the server on GoDaddy...
About the Chinese name 太極, as noted in the FAQ section at http://taichi.graphics/misc/, I chose this word in the intersection of traditional Chinese (which is still used in some parts of China nowadays) and modern Japanese, since a significant part of Taichi was done during my internship at the University of Tokyo.
GPU support is absolutely meaningful, especially for the simulation part (like the snow and smoke). If I'm given more time (and access to GPUs) I would definitely try GPUs someday. For the rendering part, it's like CPUs are still widely used in the industry, though there are renderers with GPU support like LuxRender. Another consideration is that CPUs are more friendly to programmers and researchers for prototyping.
I'm recently doing a full-time internship at Microsoft Research Asia and have very limited time for this project. If you would like to contribute, that's truly appreciated.
Thank you again for your support and encouragement.