Curl-Noise "Black Hole" Behaviour about cnpf

[stegu]

Great to hear about your problems! Seriously. From an educational standpoint, this is a "good bug", and I appreciate your structured approach to resolving it. Having said that, please be advised that my analytical derivatives might have bugs. To make sure It's not my code that is causing you headache, consider validating the analytical gradient against finite differences. I remember doing that, but I might have messed it up somehow. (Perhaps you did this already as well, in which case I apologize for insulting your intelligence.) /Stefan G

…

On 7 Apr 2017 11:08, "Erik S. V. Jansson" ***@***.***> wrote: When attempting to apply velocities to the particles in respect to the generated curl-noise we get these "black holes", where all particles seem to converge to a singular point around them. Martin has fixed the issue with the "particle lines" that seemed to happened before, now only this issue remains. We need to figure our what's the source of the problem. Rasmus has created a Processing demo of the particle simulation using curl-noise, and seems to be getting the correct behaviour. My suggestion is that we analyze both the curl-noise implementation and the particle system implementation of his demo and try to see if there are any discrepancies in the results we get (alternatively we can see what other people seem to be getting by applying curl to the simplex noise). In particular, I suggest we do the following: we generate the curl-noise in the Processing application, since we know that it produces a valid curl vector field, write it to an image, and load it in our C++ implementation. If the particles behave better, then we need to look into where our C++ curl-noise implementation differs from the Processing one and fix it, or, if the behaviour is still wrong in our C++ implementation, despite having the correct curl vector field, then in the particle system we must have missed something or made some erronous assumption about the field. It would be nice if we could get some images of the problems here so we can discuss it better, I still have problems with my open-source drivers which I'll try to fix in the weekend (alternatively, I'll implement a software backend for the particle simulation). We should discuss this problem, and see if anyone can find a solution or motivation why we get these weird particle "black holes" (alt. motivate why they are correct). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAplarDV6CCpBL9w8rBFEnwR7Vy7HdTTks5rtf0MgaJpZM4M2pNh> .

[CaffeineViking]

Thanks for giving your insight in the issue!

I don't think we have checked the gradients against the finite differences. However, it was @hedin94 and @alfredRundqvist that worked on most of the curl-noise module, so perhaps they already checked that. Anyway, we'll find out the problem out eventually (by bisecting it).

To keep you to date, we'll post if any breakthroughs have happened regarding this. After fixing this issue, the idea is that we proceed with the two remaining parts: interactivity/knobs and visualization/shaders in parallel (as before). The preliminary plan is that the interaction will be in the form of camera movement (some sort of rotation around the field and zooming in/out) plus some way to affect/modify the system (e.g. amount of particles, velocity multiplier, noise frequency etc...) using e.g. http://anttweakbar.sourceforge.net/doc/ as a GUI. The visualization isn't completely decided yet, but we think that adding support for billboards to the particles with an alpha channel would provide for some nice effects (e.g. fire and smoke), and maybe some sort of "trails" by blending previous framebuffers. All of this is still preliminary, we will have a couple of meetings to decide for sure after we have fixed this bug.

Again, thanks for the help!

[sci10n]

I can't see anything wrong with the noise algorithm (verified by testing a different noise library and by switching to Perlin), and the curl operation also produces expected results. It seems the problem lies in our interpretation of the creation of the potential field which we extract our velocities from.

My current theory is that the "Black Holes" are created as a combination of accumulated rounding errors , linear interpolations in the texture lookup, and velocity field implementation. The last point should we be able to fix by examining the code for the original article. The other two would probably have to be fixed by either reducing the time we simulate or by introducing some randomness to the particles.

[stegu]

If you are interpolating the vector field, you are not strictly preserving its zero divergence property. You can interpolate the scalar field, but its gradient and curl need to be computed for each point. The errors are small, but they occur at critical locations where the field changes rapidly, and errors would probably accumulate over time if you don't animate the field by animating the field (e.g. by using 4-D noise). The randomness is supposed to be generated by the curl noise. Adding an arbitrary randomness to the particles kind of defeats one of the main purposes of using this method. However, this is computer graphics, so cheating is allowed, so to speak. Just make sure to comment on it if you take that approach.

[sci10n]

The issue seems to have been resolved now that I have moved the entire "curl noise" function to be evaluated continuously without interpolation on the GPU. The problem seems to have been caused, as @stegu pointed out, by linear interpolation of the vector field which over timed accumulated rounding and interpolation errors.

This solution also helps with codebase management since we don't need a large C++ system for different scenarios. We can simply specify the OpenCL kernel to use at runtime.