|
|
N-Body I reconnected the numBodies output port to the corresponding input on the kernel. This composition was really making my computer flip out when I would adjust the published numBodies; I believe this is because of the fact that the Initial Values javascript is still attached, which then causes the Position/Velocity calculations that happen with the feedback loop to be off. The composition has been performing OK for me since doing that.
|
Funnily enough, I only got & get problems with this if I try to feed a varying amount of n-bodies in at the Parameter patch, but otherwise find this to be a real breeze .
I can disconnect that n-bodies count noodle and restart the file no problem, perhaps this is partly hardware dependent? Don't know why that would be though.
I just love the rainbow effect you get by applying the vertices structure to the colours input on the Mesh Creator patch
Yep, it actually still turns my computer into a sputtering mess when changing the n-body count.
I was hasty.
That'll be a memory-related issue again. Changing the dimensions of an input to an OpenCL kernel always seems to be a good way of crashing it and/or the whole computer. YOu can kinda see why though, given GPUs lack of protected memory.
Also, the N-body kernel is doing a LOT of stuff for each particle, since every particle is effected by every other (think that's what 'N-Body' means, in fact). Adding more particles therefore exponentially increases computation-load.
Don't be too hard on your computer for choking on this one- it's an OpenCL demo precisely because it's so hardcore....
a|x
Workspace dimensions - they can kind of cramp one's style and trip one up. Either from an excess of input, or a lack of input. Both extremes can occur.