|
|
Color orbiter hello, This composition is an attempt to go over the problem of integrators not working in iterators by using "force + feedback" macro patch. I've read that behaviour of integrators has been improved in Lion, is it true ? This composition run smooth enough in 64-bits but fps decrease dramatically in 32-bit mode. Each arrow adjusts its velocity vector (angle + value) according to hue and luminosity it reads under itself. Does anybody have an idea to make it faster ? (2 attached clips are needed) Thanks a lot !
|
Very Cool - Not sure why you get the performance difference between 32/64 but I also get it under lion
I get around 2fps for 32 bit with a mid 2010 mbp and 15 for 64 bit
in Lion
64 bit HD 720 , 4:3, 16:9, 16:10 - pretty consistent performance at 18 to 20 fps.
In 32 bit also consistent - would start at about 250 fps and descend quickly to about 2 to 3 fps.
iMac 2.66 GHz Core 2 Duo nVidia 9400 4 GB 1067 MHz DDR3
hello,
Thanks for your tests. Your results are pretty close to mine ( 12-15 fps on a Mac book pro i5 2,4Ghz, 4Gb RAM, 10.6.8, QC in 64 bits)
I do not see how I can optimize this composition or if there is a totally different way to do such things. (speed is not the real problem actually. I would like more iterations)
I also noticed that programs with iterations of "feedback + force macros" are crashing frequently. Did it crash at least one time when you tried ? Do you see something obviously ugly in this way of doing ? Are such macros known to be unstable ?
Thanks a lot and have a nice day !
Its never crashed for me - seems fine 32 or 64
I tried swapping out your javascript in the pixel sensor sub patch for some math expressions but that made it slower not faster
hello,
I've tried to re-do the pixel sensor too with same conclusions.
So, population of "autonomous" objects (like these pixel-readers-moving-arrows) with self (and/or mutual behaviours) remains hard too do with QC-only programs ?
I would like to know your opinion : writing code is it better in such case ? does it make things more clear ? Is QC definitely not a good way of doing this ?
thanks for any explanation ! jf
you're using the image pixel patch in your macro, which is then iterated. It is not good because for each iteration, QC reads all the image lying in the GPU, sends it back to the CPU to get one pixel data. Not optimized at all.
You'd be better getting all the pixels values outside the iterator, make a structure out of it _ using for instance M.Oostrik's image pixelS patch _ and then test your hue against this structure INSIDE the iterator.
courage !