taichi-dev
Release the first working version
I think in order to release the first working version with minimal functionality, you need to do the following:
- [x] Seed particles from arbitrary geometry #5
- [ ] Add simple colliders #17
- [ ] ~~Ability to specify domain boundaries using cube object~~ not necessary
- [x] Ability to specify a range of frames for simulation
- [x] Add the ability to visualize and render particles
- [x] Add sand material model
- [x] Add simple documentation (nodes descriptions, workflow, installation, using)
- [x] Make release script #38
After the implementation of these features, it will be possible to advertise the simulator to get more feedback, tips, help with development.
Thank you so much for putting together this list. I think this is a great plan. I have too many things to do recently, so please forgive the delay on my end...
@yuanming-hu I want to ask where it is better to add documentation? In this repository as md files or in a wiki? https://github.com/taichi-dev/taichi_elements/wiki
I made the Emit Frame option work: https://gfycat.com/givingcrazybushsqueaker
How about using Sphinx so that we can host the document on readthedocs? Taichi uses this approach：https://taichi.readthedocs.io/en/latest/
Sphinx uses rst instead of markdown. For example, the source code for https://taichi.readthedocs.io/en/latest/hello.html is https://raw.githubusercontent.com/taichi-dev/taichi/master/docs/hello.rst
Blender itself uses Sphinx rst for documentation. If you think it's a good idea, I can quickly setup a documentation scaffold.
The video looks very cool!!!
Yes, I think using Sphinx would be a better option. True, I never used it.
I have some news. I managed to assign different shaders to the particles. Now in one simulation there can be snow of different colors and with different shaders. Previously, it was possible to set only a different color (but not a shader). True, this method does not look very good, this method is a kind of workaround. I am retrieving information from a Particle Info node from an Angular Velocity socket.
https://giant.gfycat.com/SecondUnfitFattaileddunnart.webm
Cool! It's great that we can assign different materials to different groups of particles.
(Sorry I got rather occupied these days. I'll have more time after this Friday.)
@PavelBlend Do you need anything else from me for #17? If not, I'll improve the simulator to support "Ability to specify domain boundaries using cube object", by this Sunday :-)
Is it now possible to create a collider based on a mesh object? Or are there currently only spheres among colliders? I would like to create colliders from arbitrary geometries.
I reread #17 and saw that you said that you would add this function later. Then I do not need anything for #17
I will wait until it becomes possible to create colliders from meshes, but for now I will not add colliders to the blender.
Sounds good - adding arbitrary mesh as colliders might take me one more week. I can do that later. Before this Sunday I'll just try to do "Ability to specify domain boundaries using cube object" and maybe converting the mpm solver to sparse grids as well.
Update on specifying domain boundaries and sparse grids:
- [x] I implemented sparse grids locally, now the voxel grid has size
[0, 4096) x [0, 4096) x [0, 4096), with voxels allocated on demand. This means in the simulator the domain can automatically extend along X+, Y+ and Z+. - [ ] To move on I need to modify Taichi to support negative coordinates, so that the domain would be
[-2048, 2048) x [-2048, 2048) x [-2048, 2048). This means we can extend along X-, Y- and Z- as well. - [ ] I also need to upgrade the voxelizer so that we can see particles in any parts of the domain.
- [ ] Once we have the above done, the domain boundary can be specified arbitrarily and we can easily get rid of the bounding box.
Considering this week I'm getting rather occupied at work, I don't think these can be finished within this week. Sorry about the delay.
Really sorry for the delay. I finally implemented negative coordinates in Taichi: https://github.com/taichi-dev/taichi/pull/945. Changes have to go through code review there.
Now we can get rid of the bounds. Of course, users will be able to specify bounds if they want. (In this example I set the ground as a bound.)
This is very impressive. To achieve such granularity with a static domain, you need a lot of time and RAM.
Is ground an infinite plane? Or does it have borders? And is it possible to set ground in the form of a vertical plane?
Thanks. Taichi has dynamic memory management and everything is allocated on demand.
Is ground an infinite plane? Or does it have borders?
It is virtually infinitely. The grid resolution is [-4096, 4095]x[-4096, 4095], and we are using [-256, 256]x[0, 128]. You can assume we will never touch the boundary.
And is it possible to set ground in the form of a vertical plane?
Sure. I'll implement that once I have a chance.
And is it possible to set ground in the form of a vertical plane?
Sure. I'll implement that once I have a chance.
Done in #53 (MPM.add_surface_collider)
the pointer SNodes do not yet work with the Metal backend... would it be possible to have a version not using them? (it would mean having a metal alternative for lines 74-78 in mpm_solver.py)
@yuanming-hu hello.
Do you have any plans to add new features to the engine?
I also need to upgrade the voxelizer so that we can see particles in any parts of the domain.
This opportunity is severely lacking. Voxelizer severely limits the simulation. You have to set objects in positive coordinates.