-
Notifications
You must be signed in to change notification settings - Fork 305
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updating state is not really done "correctly" #18
Comments
The modified Javascript file fixes that. I may modify the C++too but this might change the parameter settings to different numbers in order to reproduce similar patterns. For now, I'll leave it like that. |
Yes, not even sure you can get the same results if you make the simulation "correct" |
One other point to note is that the fx fy values are also iteratively updated, which means that if you were going to fully GPU parallelise the fx fy calculations, it wouldn't be possible in the current method as the earlier atom x, y positions are updated. If you fully calculate the fx fy values in parallel before applying any values to any given atom x y, it just doesn't look very good. I experimented with this using gpu.js and whilst it works (using matrices rather than objects), nothing looks anything as interesting as when the updates are applied progressively. You can, of course, apply parallelism to each individual atom, but there is no real performance benefit, in fact it is worse than using the basic matrices. |
Great minds thing alike. |
I don't have VR but I imagine interacting with the particles with attraction/repulsion gestures can be so fun |
As all the rules modify state, later rules are influenced by the effects of earlier rules... if this should be a "correct" simulation, all forces had to be calculated first, then applied to to the state. But the simulation is much more interesting with this bug ;)
The text was updated successfully, but these errors were encountered: