- I'm not really sure. The water itself would be quite easy if done bruteforce, but I'm not sure if it is possible to pass the spatial grid to the GPU to speed up the calculations. Rendering with cube maps wouldn't be that hard, but tesselation is possibly quite difficult.
- 96 bytes. About half of it is needed for the integration (position, velocity etc.) and another half describes properties of the water particle itself (density, speed of sound etc.)
- I use a spatial grid with linked lists to speed up the water part (I think it is O(n*log(n))), but unfortunately, I cannot pass it from BMax to the C++ raytracer. Therefore, the metaball calculation is O(n²). I'm planning to write the SPH part in C++ too to speed up the rendering quite a bit.
Awesome work! Q's:
- How difficult would it be to calculate this on the GPU?
- How much data are you storing per Particle?
- Is the Perf pure O(n²) or are you doing some Space Partitioning?
BeAnAgeLabs 2 years ago
- I'm not really sure. The water itself would be quite easy if done bruteforce, but I'm not sure if it is possible to pass the spatial grid to the GPU to speed up the calculations. Rendering with cube maps wouldn't be that hard, but tesselation is possibly quite difficult.
- 96 bytes. About half of it is needed for the integration (position, velocity etc.) and another half describes properties of the water particle itself (density, speed of sound etc.)
Thunabrain 2 years ago
- I use a spatial grid with linked lists to speed up the water part (I think it is O(n*log(n))), but unfortunately, I cannot pass it from BMax to the C++ raytracer. Therefore, the metaball calculation is O(n²). I'm planning to write the SPH part in C++ too to speed up the rendering quite a bit.
Thunabrain 2 years ago