|
|
Reaction Diffusion (Composition by gtoledo3)
This is a grey-scott reaction diffusion simulation that's running in QC with the aid of a GLSL shader and feedback loop. The fragment shader is from the Reaction Diffusion example from Cinder (http://libcinder.org/) without the vertex shader (Cinder does a texture flip with things at a certain point, which this doesn't need). This is released under modified BSD license (re: Cinder). Thanks to toneburst for his explorations in it, which got me interested in getting this sweeter than my previous experiments. If you click down around the Viewer, you can clear out areas to let new pixel groups grow. (The screencap for this has an early setup with a little bit of color tweaking; the example composition won't have the goldish hue.) |
This version creates a cycle.
Thanks for sharing, gtoledo.
Cinder Project is very interesting.
Porting shaders into QC, a favourite hobby of mine; I note that there are a load of offset and kernel parameters commented out in the frag shader. I shall try seeing if they can be successfully incorporated.
Sweet effect the shader patch produces.
Here's the second kernel. It tends to need some different parameters (one of the tricky things for getting the reactions going in unique ways). In having a bigger kernel size (sampling more pixels) the look winds up different as well... it does the "color cycling" easily.
What would be kind of interesting I think would be to get something like this working with advection and more complex fluid dynamics (there's tons of papers on this... worth poking around at; some of the stuff looks like it may not be too hard to add.)
I had some experiments getting a metallic look that are going okey dokey...
Those are nice.
Thanks Vade!
George,
Very confused. The output on my 10.6.8 imac is very dull indeed. Either a white or black billboard on which "Reaction" appears for 1/2 second every time the composition is started or the left button is pressed. Using the default f=.008, k=.08, ru=.09, rv=.03. Style=0/1 does alternate the black/white.
Somehow, the feedback of the output image into the texture input port doesn't seem to do what you advertise.
Any ideas on what might be going on? Console messages of possible interest??
*** QCProvider_CoreGraphics: Interpreting monochrome with alpha CGImage as RGBA
*** QCProvider_CoreGraphics: Unable to extract native pixel format from CGImage (bitmap info = 0x00000003 | bits per pixel = 16)
The metallic versions are sweet - would you be happy to talk about how you achieved this?
Ie - how did you mess with the normals (assuming you have)
File a bug and let Apple know that they sold you a computer and/or gpu that doesn't work... or take it back and return it.
Maybe you could fiddle with bit depth on the RII, or render to another RII, and then loop back or something, but you shouldn't have to. If it doesn't work, it's because Apple has something wacky going on with your model computer (sorry). You could try taking a screengrab of what you're seeing and maybe I could help, but it seems like if it doesn't work, your GPU isn't supporting shaders correctly, or is maybe truncating bit depth, so things are falling apart.
I'll sleep on it :)
emboss me :-)
hmmm. The machine is an i7 cpu w Radeon 4850 gpu. Never heard or observed that it couldn't hack OpenGL (although sadly it doesn't do OpenCL). Does the shader require higher levels of OpenGL? I think the Radeon driver is supposed to do v3.3, but I'm not a glsl guy, so I'm not clear on what exactly is added in the latest versions.
I did try some of your suggestions on the RII settings, but no joy.
Exactly what do you suspect is wrong with the Apple product? Happy to file a bug if I can clearly state the issue.
I thought OpenCL was meant to drop to the multi core CPU if an incompatible GPU / unsupported GPU is apprehended by the kernel when executed.
Do you have any problems with running the standard GLSL shader .qtz examples from the Developer installation of xCode Tools?
I wonder when, or if ever, ATI / AMD multi core GPUs in Macs will be OpenCL supported . AMD have a got a lot of multi core GPU code posted, ATI Stream that is there deployment of Khronos.org OpenCL specification conformant code.
It's just that Apple's OpenCL doesn't currently include ATI support, isn't there some way in which Apple's OpenCL support can be extended to include these GPUs?
All the standard GLSL shader examples in the xCode Tools have always worked and seem to still function fine.
On the separate matter of OpenCL support, the best I've been able to figure is that the AMD Radeons until the 5xxx series don't have OpenCL "Image Support". The 4xxx series AMD sdk has "beta" support for images. This is optional in OpenCL, the card just returns not supported. But it appears that Apple's QC requires this for it's OpenCL implementation. Never have gotten a definitive answer on this, and I haven't upgraded to Lion to see whether the new drivers are more functional.
But in anycase, I am flumoxed by the reaction diffusion problem. It's glsl not OpenCL.
I would guess that all of your OpenGL textures are taking a CPU path, and that path isn't not working properly on top of that, making the setup not run. That's your problem with the OpenCL stuff as well, not OpenCL itself - it's that your OpenGL textures aren't working properly, so when you use OpenGL textures with the CL kernel, it fails, right? I would guess it's like that because the drivers suck.
No, I'm not using CIEmboss, though I could have.
Didn't mean the CIEmboss, nice patch though. Just thought the snapshots looked like emboss effects.
Liquid diffusions abounding.
:-)
Wow, I had no idea that OpenGL did anything on the CPU. Shader languages have always been for GPU's, no? I thought all that cpu-fallback stuff was OpenCL. Is it possible to execute glsl kernels on any cpu?
Well, I will be looking for more OpenGL examples with textures to try out and see if there is something about the handling of textures in and out of a QC glsl kernel that ain't kosher. Most of the Apple glsl examples are pretty rudimentary and generate textures inside the kernel, it looks. The OpenGL Info patch dutifully reports that I am using the Radeon, and it's got 8 texture units.
Wishing that dear mother Apple (having invented BOTH OpenGL and OpenCL) would take a more proactive approach to this. Seems all they do is insist that Khronos mention their copyright all the time. We never see much more than example code from the mothership. Phooey.
The only time GLSL should run on the CPU is when you're using a feature that's not implemented in hardware, which generally means the noise functions on most hardware (unless you're on an intel GPU, in which case it's pretty much everything ;)
The actual error is saying it's receiving the texture in the wrong format - it thinks it's a 16 bit LA texture when it's probably 8 bit RGBA or something.
My guess: There's something in the comp that doesn't work right on 10.6.8. I'm actually on a lower end (4670) GPU from the same series, on 10.7.1, and it's working fine here so it should run fine on your card too. OpenGL got an upgrade (from 2.x to 3.x I think) with lion, so maybe it's using a newer GLSL feature. Anyone else running it successfully on 10.6.x?
George: nice comp, but it's a bit slow moving. Is there a way to speed it up? It's very similar to my old 'lifeform' comp, where I got almost the same effect more or less by accident, so it'd be really cool to see this running at speed and tweaking it in realtime, especially with the nice paint feature :)
Psonice; my computer is 10.6.8 (or rather, the partition I'm on). It's definitely not the OS, it's his computer.
I'll have to check it out on a slower computer, as far as refining performance goes... it's really quick on my computer, so I'm not sure where I would tweak besides lowering the resolution. The first kernel should likely run a bit quicker on most machines I think, but that's conjecture.
Yeah... what I mean is, the framerate is ok, but the speed of motion is low. Well, they are tied together of course for something like this, but still. From my past experiments along these lines, some of them get MUCH more interesting the longer you run them (I had one that eventually formed the shape of a cell, with internal structure, and another that formed something like a level from an old 2d platform game that kept rearranging itself). So a bit more motion will help you find all the coolness that comes later a lot easier :)
Sure; by changing the relationship of the parameters, the actual speed and reaction time will change. Sometimes the numbers only need to shift by a very small fraction to have a wild difference in end result. I can't remember what they are, but the default parameters that cinder uses for the first kernel, for example, moves along fairly quickly... I slowed it down a bit on purpose so that the initial spread didn't happen in a flash.
You're totally right; they get way more interesting the longer they run. Once all the pixels spread, then reactions start taking place. Also, if you have it at one value, shift a value a bit lower, then higher, back and forth a few times, you create "pulses" that will continue to chase through the system. That's the real way to getting some "quick" looking reactions; fluctuating one or more of the parameters that you've determined to have cool effect with an lfo or something.
Here are some initial settings that get it moving along a bit quicker :) It can move quicker still, for sure. I wouldn't be surprised if it is slightly different on different computers given what a fine line everything rides on (apparently).
As was found later, harrisonpault's issue was because of kineme's AlphaBlend stuff.