gtoledo3's picture

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.

N-Body.qtz28.07 KB

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

cybero's picture
Re: N-Body

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

gtoledo3's picture
Re: N-Body

Yep, it actually still turns my computer into a sputtering mess when changing the n-body count.

I was hasty.

toneburst's picture
Re: N-Body

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....


cybero's picture
Re: N-Body

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.