Complex Ginsburg-Landau Micro-Maps
19 views
Skip to first unread message
Dan Wills
Sep 30, 2012, 9:24:20 AM9/30/12
to reaction-...@googlegroups.com
Hi Ready ones :)
I have been toying with some formulas, trying to get a better grip on CGLRD, and instead of taking Robert's good advice about how one might make a map (which I do intend to follow eventually), instead I decided to hack together a formula that works like a kind of navigation portal. By varying controllable amounts of the parameters across the frame using a horizontal tent-function, you can get a preview of how the behavior changes with respect to them - like a little adjustable micro-map.
The attached vti contains the modified formula, based on Robert's gl-magnitude formula that he posted a while ago. I did make several attempts to hack together a smaller filesize version of this vti without the saved state, but most of the attempts failed to load or segfaulted ready on load, so here's 600kb's worth of mainly some completely regenerate-able noise :/ I'm keen to hear any tips on how to save without the binary blob :).
About the actual formula, I wonder whether there's a way to implement the ramp without using a reagent channel, or to compute it only once at the start of the sim rather than recomputing it on every frame. It seems quite cheap to compute this way, but I'd like to know if there's a better way, perhaps I could use a variable instead of a persistent buffer?.
I've just been running the simulation multiple times to write out 1 sequence per reagent. I've even been wastefully writing out the magnitude reagent even though I can compute it from a and b later, but it's convenient and fast enough just to run the sim 3 times with different filenames for the moment. I would be very keen to look into how easy it might be to support writing out multiple reagent frames in one go, or a multichannel image with a selection of the reagents in it. That would certainly save some time with this kind of thing.
I've been taking the multiple sequences into the compositing context in Houdini (Apprentice HD) and combining the channels back together using a bit of color math logic. The idea is to try to help show what's happening in the simulation, and also just to look nice :). I'd love to be able to render sequences looking like these directly out of Ready, which seems like it should be possible - I will have a look at the code and see if I can do any work towards that :).
I've put a few vids using this method on youtube:
http://www.youtube.com/watch?v=mLJI7z-o1rM
http://www.youtube.com/watch?v=Exwy0LXluio
http://www.youtube.com/watch?v=zUxXBWjdtjg
Ready is magnificent! :D Thanks again for everybody's work on it!
All the best,
Dan
I have been toying with some formulas, trying to get a better grip on CGLRD, and instead of taking Robert's good advice about how one might make a map (which I do intend to follow eventually), instead I decided to hack together a formula that works like a kind of navigation portal. By varying controllable amounts of the parameters across the frame using a horizontal tent-function, you can get a preview of how the behavior changes with respect to them - like a little adjustable micro-map.
The attached vti contains the modified formula, based on Robert's gl-magnitude formula that he posted a while ago. I did make several attempts to hack together a smaller filesize version of this vti without the saved state, but most of the attempts failed to load or segfaulted ready on load, so here's 600kb's worth of mainly some completely regenerate-able noise :/ I'm keen to hear any tips on how to save without the binary blob :).
About the actual formula, I wonder whether there's a way to implement the ramp without using a reagent channel, or to compute it only once at the start of the sim rather than recomputing it on every frame. It seems quite cheap to compute this way, but I'd like to know if there's a better way, perhaps I could use a variable instead of a persistent buffer?.
I've just been running the simulation multiple times to write out 1 sequence per reagent. I've even been wastefully writing out the magnitude reagent even though I can compute it from a and b later, but it's convenient and fast enough just to run the sim 3 times with different filenames for the moment. I would be very keen to look into how easy it might be to support writing out multiple reagent frames in one go, or a multichannel image with a selection of the reagents in it. That would certainly save some time with this kind of thing.
I've been taking the multiple sequences into the compositing context in Houdini (Apprentice HD) and combining the channels back together using a bit of color math logic. The idea is to try to help show what's happening in the simulation, and also just to look nice :). I'd love to be able to render sequences looking like these directly out of Ready, which seems like it should be possible - I will have a look at the code and see if I can do any work towards that :).
I've put a few vids using this method on youtube:
http://www.youtube.com/watch?v=mLJI7z-o1rM
http://www.youtube.com/watch?v=Exwy0LXluio
http://www.youtube.com/watch?v=zUxXBWjdtjg
Ready is magnificent! :D Thanks again for everybody's work on it!
All the best,
Dan
Tim Hutton
Oct 1, 2012, 9:21:23 AM10/1/12
to reaction-...@googlegroups.com
Hi Dan,
On 30 September 2012 14:24, Dan Wills <gda...@gmail.com> wrote:
> Hi Ready ones :)
>
> I have been toying with some formulas, trying to get a better grip on CGLRD,
> and instead of taking Robert's good advice about how one might make a map
> (which I do intend to follow eventually), instead I decided to hack together
> a formula that works like a kind of navigation portal. By varying
> controllable amounts of the parameters across the frame using a horizontal
> tent-function, you can get a preview of how the behavior changes with
> respect to them - like a little adjustable micro-map.
Yes, very good. Nice to be able to tweak the map at runtime. I had
thought we'd need a separate implementation for that but actually I
like the way you've used Ready's buffers to achieve the same thing.
>
> The attached vti contains the modified formula, based on Robert's
> gl-magnitude formula that he posted a while ago. I did make several attempts
> to hack together a smaller filesize version of this vti without the saved
> state, but most of the attempts failed to load or segfaulted ready on load,
> so here's 600kb's worth of mainly some completely regenerate-able noise :/
> I'm keen to hear any tips on how to save without the binary blob :).
Where did you get the noise from for this version?
For now, do Action > Blank, then File > Save and then edit the file
and manually construct an <initial_pattern_generator> section. Here is
the one from the existing CGL files:
<initial_pattern_generator apply_when_loading="true">
<overlay chemical="a">
<overwrite />
<white_noise low="-0.1" high="0.1" />
<everywhere />
</overlay>
<overlay chemical="b">
<overwrite />
<white_noise low="-0.1" high="0.1" />
<everywhere />
</overlay>
</initial_pattern_generator>
In future we will allow the user to edit these interactively, or something.
>
> About the actual formula, I wonder whether there's a way to implement the
> ramp without using a reagent channel, or to compute it only once at the
> start of the sim rather than recomputing it on every frame. It seems quite
> cheap to compute this way, but I'd like to know if there's a better way,
> perhaps I could use a variable instead of a persistent buffer?.
Using extra chemicals as you do here is fine, unless the speed is
bothering you. But a few approaches spring to mind:
a) Use an initial_pattern_generator with linear_gradient to get the
map you want (see grayscott_parameter_map.vti). To tweak the map at
runtime you will need to edit the file and reload. (Make an
accelerator key for the Reload from Disk command!)
b) Convert the formula rule into a kernel. Action > View Full Kernel,
copy-paste this into the <kernel> section in a saved file. (Compare
with the other kernel rules for guidance. Format documentation is
under Help > File Formats.) Use 'x' and 'y' variables in your formula.
These tell the kernel where it is. You'll probably need 'X' and 'Y'
too. Then you can do whatever you like. You'll need to edit the kernel
(in Ready) instead of using parameters.
c) Bit of an undocumented feature, but a 'formula' rule is simply a
snippet of the full OpenCL kernel - we insert your formula into the
kernel harness to run it. (Type nonsense in the formula then use
Action > View Full Kernel to see what I mean.) This means that you can
use any of the variables that you see defined, including 'x' and 'y'
in your formula. This is actually a really nice idea - see the formula
in the attached file, which I've also pasted here:
float hpos = x/(float)X; // [0,1]
float vpos = y/(float)Y; // [0,1]
float k = k1 + (k2-k1)*hpos;
float F = F1 + (F2-F1)*vpos;
delta_a = 2.0f * diff * laplacian_a - a*b*b + F*(1.0f-a);
delta_b = diff * laplacian_b + a*b*b - (F+k)*b;
>
> I've just been running the simulation multiple times to write out 1 sequence
> per reagent. I've even been wastefully writing out the magnitude reagent
> even though I can compute it from a and b later, but it's convenient and
> fast enough just to run the sim 3 times with different filenames for the
> moment. I would be very keen to look into how easy it might be to support
> writing out multiple reagent frames in one go, or a multichannel image with
> a selection of the reagents in it. That would certainly save some time with
> this kind of thing.
Yes, something to think about.
>
> I've been taking the multiple sequences into the compositing context in
> Houdini (Apprentice HD) and combining the channels back together using a bit
> of color math logic. The idea is to try to help show what's happening in the
> simulation, and also just to look nice :). I'd love to be able to render
> sequences looking like these directly out of Ready, which seems like it
> should be possible - I will have a look at the code and see if I can do any
> work towards that :).
No reason it wouldn't be possible - make a new chemical and composite
into that using whatever formula you want.
>
> I've put a few vids using this method on youtube:
>
> http://www.youtube.com/watch?v=mLJI7z-o1rM
> http://www.youtube.com/watch?v=Exwy0LXluio
> http://www.youtube.com/watch?v=zUxXBWjdtjg
>
> Ready is magnificent! :D Thanks again for everybody's work on it!
> All the best,
> Dan
--
Tim Hutton - http://www.sq3.org.uk - http://profiles.google.com/tim.hutton/
On 30 September 2012 14:24, Dan Wills <gda...@gmail.com> wrote:
> Hi Ready ones :)
>
> I have been toying with some formulas, trying to get a better grip on CGLRD,
> and instead of taking Robert's good advice about how one might make a map
> (which I do intend to follow eventually), instead I decided to hack together
> a formula that works like a kind of navigation portal. By varying
> controllable amounts of the parameters across the frame using a horizontal
> tent-function, you can get a preview of how the behavior changes with
> respect to them - like a little adjustable micro-map.
thought we'd need a separate implementation for that but actually I
like the way you've used Ready's buffers to achieve the same thing.
>
> The attached vti contains the modified formula, based on Robert's
> gl-magnitude formula that he posted a while ago. I did make several attempts
> to hack together a smaller filesize version of this vti without the saved
> state, but most of the attempts failed to load or segfaulted ready on load,
> so here's 600kb's worth of mainly some completely regenerate-able noise :/
> I'm keen to hear any tips on how to save without the binary blob :).
For now, do Action > Blank, then File > Save and then edit the file
and manually construct an <initial_pattern_generator> section. Here is
the one from the existing CGL files:
<initial_pattern_generator apply_when_loading="true">
<overlay chemical="a">
<overwrite />
<white_noise low="-0.1" high="0.1" />
<everywhere />
</overlay>
<overlay chemical="b">
<overwrite />
<white_noise low="-0.1" high="0.1" />
<everywhere />
</overlay>
</initial_pattern_generator>
In future we will allow the user to edit these interactively, or something.
>
> About the actual formula, I wonder whether there's a way to implement the
> ramp without using a reagent channel, or to compute it only once at the
> start of the sim rather than recomputing it on every frame. It seems quite
> cheap to compute this way, but I'd like to know if there's a better way,
> perhaps I could use a variable instead of a persistent buffer?.
bothering you. But a few approaches spring to mind:
a) Use an initial_pattern_generator with linear_gradient to get the
map you want (see grayscott_parameter_map.vti). To tweak the map at
runtime you will need to edit the file and reload. (Make an
accelerator key for the Reload from Disk command!)
b) Convert the formula rule into a kernel. Action > View Full Kernel,
copy-paste this into the <kernel> section in a saved file. (Compare
with the other kernel rules for guidance. Format documentation is
under Help > File Formats.) Use 'x' and 'y' variables in your formula.
These tell the kernel where it is. You'll probably need 'X' and 'Y'
too. Then you can do whatever you like. You'll need to edit the kernel
(in Ready) instead of using parameters.
c) Bit of an undocumented feature, but a 'formula' rule is simply a
snippet of the full OpenCL kernel - we insert your formula into the
kernel harness to run it. (Type nonsense in the formula then use
Action > View Full Kernel to see what I mean.) This means that you can
use any of the variables that you see defined, including 'x' and 'y'
in your formula. This is actually a really nice idea - see the formula
in the attached file, which I've also pasted here:
float hpos = x/(float)X; // [0,1]
float vpos = y/(float)Y; // [0,1]
float k = k1 + (k2-k1)*hpos;
float F = F1 + (F2-F1)*vpos;
delta_a = 2.0f * diff * laplacian_a - a*b*b + F*(1.0f-a);
delta_b = diff * laplacian_b + a*b*b - (F+k)*b;
>
> I've just been running the simulation multiple times to write out 1 sequence
> per reagent. I've even been wastefully writing out the magnitude reagent
> even though I can compute it from a and b later, but it's convenient and
> fast enough just to run the sim 3 times with different filenames for the
> moment. I would be very keen to look into how easy it might be to support
> writing out multiple reagent frames in one go, or a multichannel image with
> a selection of the reagents in it. That would certainly save some time with
> this kind of thing.
>
> I've been taking the multiple sequences into the compositing context in
> Houdini (Apprentice HD) and combining the channels back together using a bit
> of color math logic. The idea is to try to help show what's happening in the
> simulation, and also just to look nice :). I'd love to be able to render
> sequences looking like these directly out of Ready, which seems like it
> should be possible - I will have a look at the code and see if I can do any
> work towards that :).
into that using whatever formula you want.
>
> I've put a few vids using this method on youtube:
>
> http://www.youtube.com/watch?v=mLJI7z-o1rM
> http://www.youtube.com/watch?v=Exwy0LXluio
> http://www.youtube.com/watch?v=zUxXBWjdtjg
>
> Ready is magnificent! :D Thanks again for everybody's work on it!
> All the best,
> Dan
Tim Hutton - http://www.sq3.org.uk - http://profiles.google.com/tim.hutton/
Andrew Trevorrow
Oct 5, 2012, 6:20:35 AM10/5/12
to reaction-...@googlegroups.com
Dan:
> The attached vti contains the modified formula...
Thought I'd better mention that the Mac version of Ready produced this
(rather useless) error message on trying to load your file:
cvmsErrorCompilerFailure: LLVM compiler has failed to compile a function.Program build failure
I was able to avoid it by changing 0.5 to 0.5f in the 1st line of your
formula. (We've seen before that Apple's kernel compiler is very fussy.)
Andrew
> The attached vti contains the modified formula...
Thought I'd better mention that the Mac version of Ready produced this
(rather useless) error message on trying to load your file:
cvmsErrorCompilerFailure: LLVM compiler has failed to compile a function.Program build failure
I was able to avoid it by changing 0.5 to 0.5f in the 1st line of your
formula. (We've seen before that Apple's kernel compiler is very fussy.)
Andrew
Tim Hutton
Oct 5, 2012, 6:43:49 AM10/5/12
to reaction-...@googlegroups.com
On 1 October 2012 14:21, Tim Hutton <tim.h...@gmail.com> wrote:
> Hi Dan,
>
> On 30 September 2012 14:24, Dan Wills <gda...@gmail.com> wrote:
>> Hi Ready ones :)
>>
>> I have been toying with some formulas, trying to get a better grip on CGLRD,
>> and instead of taking Robert's good advice about how one might make a map
>> (which I do intend to follow eventually), instead I decided to hack together
>> a formula that works like a kind of navigation portal. By varying
>> controllable amounts of the parameters across the frame using a horizontal
>> tent-function, you can get a preview of how the behavior changes with
>> respect to them - like a little adjustable micro-map.
>
> Yes, very good. Nice to be able to tweak the map at runtime. I had
> thought we'd need a separate implementation for that but actually I
> like the way you've used Ready's buffers to achieve the same thing.
Just to say: I've modified our grayscott_parameter_map.vti to include
> Hi Dan,
>
> On 30 September 2012 14:24, Dan Wills <gda...@gmail.com> wrote:
>> Hi Ready ones :)
>>
>> I have been toying with some formulas, trying to get a better grip on CGLRD,
>> and instead of taking Robert's good advice about how one might make a map
>> (which I do intend to follow eventually), instead I decided to hack together
>> a formula that works like a kind of navigation portal. By varying
>> controllable amounts of the parameters across the frame using a horizontal
>> tent-function, you can get a preview of how the behavior changes with
>> respect to them - like a little adjustable micro-map.
>
> Yes, very good. Nice to be able to tweak the map at runtime. I had
> thought we'd need a separate implementation for that but actually I
> like the way you've used Ready's buffers to achieve the same thing.
this idea of being able to tweak the map range on the fly. This is a
big improvement and means I don't need to code up a whole separate map
explorer module. Thanks Dan!
Dan Wills
Oct 5, 2012, 9:05:39 PM10/5/12
to reaction-...@googlegroups.com
Cool, thanks for letting me know that Andrew.
I will try to remember to check over my code for that kind of thing... bit hard to know how far i need to go but if I just try to always use the 'f' for this kind of thing, I guess that would be a good start. There'll probably be lots of other cases that work fine in one opencl kernel compiler but not others. Hopefully a better picture of what properly multiplatform openCL code looks like will emerge in time. Are we sure that Apple's kernel compiler is the most fussy one? ;)
Thanks again :)
Dan
I will try to remember to check over my code for that kind of thing... bit hard to know how far i need to go but if I just try to always use the 'f' for this kind of thing, I guess that would be a good start. There'll probably be lots of other cases that work fine in one opencl kernel compiler but not others. Hopefully a better picture of what properly multiplatform openCL code looks like will emerge in time. Are we sure that Apple's kernel compiler is the most fussy one? ;)
Thanks again :)
Dan
Dan Wills
Oct 5, 2012, 9:14:09 PM10/5/12
to reaction-...@googlegroups.com
Awesome work Tim! Nice to be able to save some code! :D
Is the new grayscott_parameter_map.vti checked in? I should svn update and check it out!
Feel free to include or use (modified or otherwise) versions of anything I post btw.
How does the out-of-the-box vti list get curated? Just curious.
By the way thanks heaps for your reply to my OP!! heaps of useful info there.
Nice one! :D
Dan
Is the new grayscott_parameter_map.vti checked in? I should svn update and check it out!
Feel free to include or use (modified or otherwise) versions of anything I post btw.
How does the out-of-the-box vti list get curated? Just curious.
By the way thanks heaps for your reply to my OP!! heaps of useful info there.
Nice one! :D
Dan
Robert Munafo
Oct 6, 2012, 4:30:41 AM10/6/12
to reaction-...@googlegroups.com, Tim Hutton, Dan Wills
On 10/5/12, Tim Hutton <tim.h...@gmail.com> wrote:
> Just to say: I've modified our grayscott_parameter_map.vti to include
> this idea of being able to tweak the map range on the fly. This is a
> big improvement and means I don't need to code up a whole separate map
> explorer module. Thanks Dan!
I just tried it. This is really nice, thank you both.
> Just to say: I've modified our grayscott_parameter_map.vti to include
> this idea of being able to tweak the map range on the fly. This is a
> big improvement and means I don't need to code up a whole separate map
> explorer module. Thanks Dan!
>>> [...] By varying
>>> controllable amounts of the parameters across the frame using a
>>> horizontal tent-function, you can get a preview of how the behavior changes with
>>> respect to them - like a little adjustable micro-map.
--
>>> horizontal tent-function, you can get a preview of how the behavior changes with
>>> respect to them - like a little adjustable micro-map.
Robert Munafo -- mrob.com
Follow me at: gplus.to/mrob - fb.com/mrob27 - twitter.com/mrob_27 -
mrob27.wordpress.com - youtube.com/user/mrob143 - rilybot.blogspot.com
Tim Hutton
Oct 6, 2012, 7:38:24 PM10/6/12
to reaction-...@googlegroups.com
On 6 October 2012 02:14, Dan Wills <gda...@gmail.com> wrote:
> Awesome work Tim! Nice to be able to save some code! :D
>
> Is the new grayscott_parameter_map.vti checked in? I should svn update and
> check it out!
Yes, it was commited in r1091:
> Awesome work Tim! Nice to be able to save some code! :D
>
> Is the new grayscott_parameter_map.vti checked in? I should svn update and
> check it out!
http://code.google.com/p/reaction-diffusion/source/detail?r=1091
> Feel free to include or use (modified or otherwise) versions of anything I
> post btw.
> How does the out-of-the-box vti list get curated? Just curious.
policy. Let us know what you want to see.
My personal preference is to keep it more scientific than psychedelic
but we should still have an 'art' folder, given the amazing work that
is being done with RD systems by Jonathan McCabe and others.
Andrew Trevorrow
Oct 6, 2012, 7:44:11 PM10/6/12
to reaction-...@googlegroups.com
Dan:
> ... Are we sure that Apple's kernel compiler is the most fussy one? ;)
Pretty sure. Tim tests Ready on Win and Linux systems and I don't
remember him reporting any compiler differences on those systems.
So far it's only on the Mac that kernel changes have had to be made,
and from memory most (all?) have been of the "add f" type.
Andrew
> ... Are we sure that Apple's kernel compiler is the most fussy one? ;)
Pretty sure. Tim tests Ready on Win and Linux systems and I don't
remember him reporting any compiler differences on those systems.
So far it's only on the Mac that kernel changes have had to be made,
and from memory most (all?) have been of the "add f" type.
Andrew
Reply all
Reply to author
Forward
0 new messages