future directions

[Tim Hutton]

So Ready 0.4 is safely out of the door and seems to be working well,
apart from a couple of small bugs that have been fixed and can wait
for 0.5. If you're having any problems, however small, then please let
us know - anyone can email reaction-...@googlegroups.com.

I've put some links to people talking about Ready on our homepage:
http://code.google.com/p/reaction-diffusion/
The Penrose glider got us a lot of interest, and our support for
meshes seems to be a popular feature.

It's a good time to talk about where we go next:

1) Do we embrace N-state cellular automata? Originally we didn't want
to, to avoid competing with Golly. But the desire for arbitrary meshes
blurs this line, and I'm not sure how to proceed. If there's no
realistic prospect of Golly supporting meshes then it makes sense for
*some* package to provide that support, and Ready is very close
already - the only downside is that we only store floats, so the rules
are unintuitive for integer systems. We could support integer data on
meshes as a new data type, and adapt the UI for that. Or do we stick
with floats?

2) Dan Wills enquired whether he could use Ready as a back-end engine
to Houdini. In general this could be an awesome way to reach more
users - appear as a Houdini or Blender plugin, for example. I've added
a command-line version of Ready ("rdy") to demonstrate the
possibilities. At the moment it just loads a pattern, advances by 1000
timesteps and then saves it out. If we want to extend this with
command-line options like in bgolly then of course we can do. This
command-line utility doesn't use wxWidgets.

3) An Android/iOS version would be most excellent for finger-painting
RD patterns, especially on tablets. On Android OpenCL isn't supported.
"Renderscript Compute" seems to be the thing but kernels are compiled
at build time, which isn't what we want, but it could work as a
pattern viewer. (Using the NDK is another possibility.) On iOS I would
hope OpenCL support should arrive at some point - it was Apple that
created OpenCL after all. On either OS it looks like Qt is far ahead
of wxWidgets, which is another reason for looking into the
wxWidgets-free command-line version.

What other directions should we be thinking about?

--
Tim Hutton - http://www.sq3.org.uk - http://profiles.google.com/tim.hutton/

[Tom Rokicki]

I wouldn't worry about competing with Golly; the real question is,

how much of Golly's rule definition code pattern read/write code

can we use?  I think the two programs complement each other

well, even with overlap.

I'm curious, though; what's the definition of a "mesh"?  I want

to understand better what we're talking about here.

-tom

[Tim Hutton]

Ah, maybe this is a term from computer geometry. I meant a polygonal
mesh, like a Penrose tiling or a geodesic sphere (covered in
triangles).
http://en.wikipedia.org/wiki/Polygon_mesh
Or a volume filled with tetrahedra. The key idea being that each cell
has a set of neighbors, and we can define a CA on them in the usual
fashion. Although usually without any natural concept of compass
directions, and often the number of neighbors is variable.

Mathematically it's a graph but we keep the connection to a piece of
3D geometry in order to render it nicely.

There are a few papers that have looked at CA on such meshes but
there's not a lot of work in this area.

As far as rule definitions go, there's not much useful overlap as far
as I can see - the variable number of neighbors and lack of compass
directions means that in general we're limited to
outer-totalistic-style rules. Ready gives you access to the entire
mesh structure; here's the code for the Penrose glider:
http://reaction-diffusion.googlecode.com/svn/trunk/Ready/Patterns/penrose_goucher_glider.vtu
Documentation for writing kernels is here:
http://reaction-diffusion.googlecode.com/svn/trunk/Ready/Help/formats.html#kernel

(For Ready this ability to define rules by code snippets has become
the main reason to use OpenCL. Speed is a secondary concern!)

I suppose that Golly's key mission is hashlife, so support for
arbitrary meshes isn't really something we would want to add to it?

[Tom Rokicki]

Thank you for the very clear description!

I wouldn't say Golly's key mission is hashlife.  If I had to say

anything, I'd say it's 2D discrete automata on regular grids.

Hashlife is used both for its unique performance on many

interesting patterns, and as a cache-all (heh) to "speed up"

complicated rules.  The things that I would consider key

characteristics of any automata suitable for hashlife include:

1.  2D (or less); 3D requires a significantly different framework.

2.  Regular grids.

3.  Discrete states (right now up to 255 states plus empty).

4.  Empty background (as opposed to oscillating background).

But clearly we violate (4) in some (few) rules, but with a fair

amount of effort (too much in my view).

Right now support for things like bounded grids is inelegant

(not due to any fault on anyone but myself; the initial data

structures were really designed only for infinite universes, and

the fact that bounded universes work at *all* is a testament

to the perseverance of Andrew.)

I don't think adding meshes to Golly is a priority for anyone

at the moment.  I think the interesting opportunities for Golly

at the moment are getting it onto tablets and phones.

The Penrose glider was quite a coup for Ready, and a

well-deserved one; I'm very happy it was in such a good state

when all that happened so people could play with it!

-tom

[Andrew Trevorrow]

Tim:

> 1) Do we embrace N-state cellular automata? Originally we didn't want
> to, to avoid competing with Golly. But the desire for arbitrary meshes
> blurs this line, and I'm not sure how to proceed. If there's no
> realistic prospect of Golly supporting meshes then it makes sense for
> *some* package to provide that support, and Ready is very close
> already - the only downside is that we only store floats, so the rules
> are unintuitive for integer systems. We could support integer data on

> meshes as a new data type, and adapt the UI for that. ...

Sounds good to me. I've no problem with Ready being able to do some
things Golly can do, even if the overlap grows over time. I see
Ready and Golly as companion apps -- each with their own strengths
and weaknesses. One of Golly's weaknesses is poor generating speed
on bounded grids, so it's nice to see Ready support such grids.
But probably no need to implement the more exotic topologies
which I added mostly to keep my mathematician friends happy
(although nobody has done anything interesting with them).

> 2) Dan Wills enquired whether he could use Ready as a back-end engine
> to Houdini. In general this could be an awesome way to reach more
> users - appear as a Houdini or Blender plugin, for example. I've added
> a command-line version of Ready ("rdy") to demonstrate the
> possibilities. At the moment it just loads a pattern, advances by 1000
> timesteps and then saves it out. If we want to extend this with
> command-line options like in bgolly then of course we can do. This
> command-line utility doesn't use wxWidgets.

Good stuff -- could be a very useful option.

> What other directions should we be thinking about?

Maybe scripting capabilities? Perhaps not as critical in Ready given
that the initial_pattern_generator stuff is quite flexible.

Andrew

[Tim Hutton]

On 15 August 2012 14:01, Andrew Trevorrow <and...@trevorrow.com> wrote:
> Tim:

>
>> 1) Do we embrace N-state cellular automata? Originally we didn't want
>> to, to avoid competing with Golly. But the desire for arbitrary meshes
>> blurs this line, and I'm not sure how to proceed. If there's no
>> realistic prospect of Golly supporting meshes then it makes sense for
>> *some* package to provide that support, and Ready is very close
>> already - the only downside is that we only store floats, so the rules
>> are unintuitive for integer systems. We could support integer data on

>> meshes as a new data type, and adapt the UI for that. ...
>
> Sounds good to me. I've no problem with Ready being able to do some
> things Golly can do, even if the overlap grows over time. I see
> Ready and Golly as companion apps -- each with their own strengths
> and weaknesses. One of Golly's weaknesses is poor generating speed
> on bounded grids, so it's nice to see Ready support such grids.
> But probably no need to implement the more exotic topologies
> which I added mostly to keep my mathematician friends happy
> (although nobody has done anything interesting with them).

I've just added a couple of patterns: hex_buss.vtu and tri_life.vtu,
on hex and tri grids respectively. I've realised that by using round()
we can write the B45/S34 rule as below:

__kernel void rd_compute(
__global float* a_in,
__global float* a_out,
__global int* neighbor_indices,
__global float* neighbor_weights,
const int max_neighbors)
{
const int x = get_global_id(0);
// count neighbors
int n1=0;
int offset = x * max_neighbors;
for(int i=0;i < max_neighbors;i++)
{
if(neighbor_weights[offset+i]<0.0001f)
continue; // not a neighbor
int y = round(a_in[neighbor_indices[offset+i]]);
if(y==1) n1++;
}
// update step
int a = round(a_in[x]);
if( a==0 && (n1==4 || n1==5) )
a_out[x] = 1.0f; // B45
else if(a==1 && (n1==3 || n1==4) )
a_out[x] = 1.0f; // S34
else
a_out[x] = 0.0f;
}

This is pretty close to an ideal way of specifying a rule. Maybe this
is the universal rule format we've been looking for.

Have a play with these patterns and tell me if we need to change the
UI to be integer-specific - I'm not sure we do.

>
>> 2) Dan Wills enquired whether he could use Ready as a back-end engine
>> to Houdini. In general this could be an awesome way to reach more
>> users - appear as a Houdini or Blender plugin, for example. I've added
>> a command-line version of Ready ("rdy") to demonstrate the
>> possibilities. At the moment it just loads a pattern, advances by 1000
>> timesteps and then saves it out. If we want to extend this with
>> command-line options like in bgolly then of course we can do. This
>> command-line utility doesn't use wxWidgets.
>

> Good stuff -- could be a very useful option.
>

>> What other directions should we be thinking about?
>

> Maybe scripting capabilities? Perhaps not as critical in Ready given
> that the initial_pattern_generator stuff is quite flexible.

We probably will need scripting at some stage. Good point.

[Andrew Trevorrow]

Tim:

> I've just added a couple of patterns: hex_buss.vtu and tri_life.vtu,

> on hex and tri grids respectively. ...

Nice!

> Have a play with these patterns and tell me if we need to change the
> UI to be integer-specific - I'm not sure we do.

Agreed -- the new rules look clean and simple.

One thing has me puzzled though. In Help/tips.html we say:

"Any reaction-diffusion pattern can be changed in size using the
dimensions control in the Info Pane."

But this only seems to be true for .vti files. When I load hex_buss.vtu
or tri_life.vtu or penrose_life.vtu I can't edit the Dimensions.
I'd really like to increase the number of cells in those patterns
(without having to muck about editing files).

After loading penrose_life.vtu the Dimensions are listed as 2 x 2 x 0.
What do those numbers mean (ie. how are they related to the number of
cells)? I couldn't find anything in the help docs about that.

Andrew

[Tim Hutton]

On 22 August 2012 05:00, Andrew Trevorrow <and...@trevorrow.com> wrote:
> Tim:
>

>> I've just added a couple of patterns: hex_buss.vtu and tri_life.vtu,

>> on hex and tri grids respectively. ...
>
> Nice!

>
>> Have a play with these patterns and tell me if we need to change the
>> UI to be integer-specific - I'm not sure we do.
>

> Agreed -- the new rules look clean and simple.
>
> One thing has me puzzled though. In Help/tips.html we say:
>
> "Any reaction-diffusion pattern can be changed in size using the
> dimensions control in the Info Pane."
>
> But this only seems to be true for .vti files. When I load hex_buss.vtu
> or tri_life.vtu or penrose_life.vtu I can't edit the Dimensions.
> I'd really like to increase the number of cells in those patterns
> (without having to muck about editing files).

Yes, the docs are wrong. I agree this is a problem. I don't know how
best to do it though - we support arbitrary meshes which may or may
not be expandable, like the bunny. For those grids where we *could*
add another 2D ring or 3D shell around the outside we would need to
specify:
- the mesh generator that was originally used
- the values to set each chemical too in the new bits

This is conceivable if our mesh generators had unique string
identifiers that could be stored in the vtu file. Each generator would
have two functions:
1) generate a mesh from scratch
2) extend a mesh (guessing the scale/extent from the existing mesh somehow)

It would be a lot of work.

An alternative approach would be to support copy and paste. Then a
copied pattern of chemical values could be copied onto a different
mesh. Extending a grid would then become a process of:
a) copy the data
b) generate a bigger mesh
c) paste the data

Getting the pasted data to align onto cells in the new mesh might be a
problem, especially with 3D cells and aperiodic grids.

> And some sort of progress dialog so people don't think Ready has
> hung when they ask for a new pattern with lots of cells. We could
> copy the BeginProgress/AbortProgress/EndProgress code from Golly's
> wxutils.h/cpp.

Yes, I'll have a look at this.

>
> After loading penrose_life.vtu the Dimensions are listed as 2 x 2 x 0.
> What do those numbers mean (ie. how are they related to the number of
> cells)? I couldn't find anything in the help docs about that.

I'll have a look at the docs.

They are the spatial size of the mesh along the x, y and z axes, in
whatever distance units you are using. The cells can be of any size so
there is no relation to the number of cells.

The dimensions are rounded to the nearest integer, which is
unfortunate for meshes where the units are such that the values are
small, like the bunny. Maybe I should just hide the dimensions for
mesh data.

[Tim Hutton]

Been having a think about this idea (can we enlarge mesh grids?) and
had two thoughts:

1) A command to "enlarge the current grid" could probably work by
looking at the existing mesh and *detecting* whether it matches any of
our generators. e.g. All cells 2D with six sides => hex grid. M cells
in 2D with four sides and N verts in total => Penrose P3. As long as
it works for our generators that will be enough. It might fail on
user-provided meshes but that would be expected.

2) We've got a similar issue with the "wrap" toggle. At the moment
this is a file option that is only supported on images but it would be
nice to make available on 2D and 3D tilings like hexagonal meshes and
truncated octahedral meshes.
http://reaction-diffusion.googlecode.com/svn/trunk/Ready/Help/formats.html#rule
The same mesh-detection code could be used to identify meshes that are
known to be toroidable and connect their opposite sides together. It
wouldn't affect the rendering, only the neighbor list as computed in
MeshRD::ComputeNeighbors().

And the nice thing about this approach is that we wouldn't need to
store anything extra in the file. Unless anyone can see an obstacle
I'll add this to the TODO list.

[Andrew Trevorrow]

Tim:

> Been having a think about this idea (can we enlarge mesh grids?) and
> had two thoughts:
>
> 1) A command to "enlarge the current grid" could probably work by
> looking at the existing mesh and *detecting* whether it matches any of
> our generators. e.g. All cells 2D with six sides => hex grid. M cells
> in 2D with four sides and N verts in total => Penrose P3. As long as
> it works for our generators that will be enough. It might fail on
> user-provided meshes but that would be expected.

That sounds a bit hacky. Why not just store the mesh type in
the vtu file as a new element? Various attributes could help with
decisions on enlarging, doing copy/paste, wrapping, etc.
Something like:

<mesh_type name="hexagonal">
<can_enlarge value="true" />
<can_copy_paste value="true" />
<can_wrap value="true" />
...etc...
</mesh_type>

Sorry I can't help with the implementation of all this. These days
I'm more of a Ready user than developer, so I'll just be happy
with *any* easier way to enlarge a mesh.

>> ... Maybe I should just hide the dimensions for mesh data.

Yep, that would be best. Also hide the "Block size" info as well?
(Is that info useful in any way? I can't change it even if it
is useful.)

Another thing I find confusing about New Pattern: If I select a
Triangular mesh I get a dialog with options for selecting the
grid size, eg. "30x30 - 1682 cells". What does the 30x30 mean?
Shouldn't it be "58x29 = 1682 cells" or (better) "30x30 = 900 cells"?
The resulting Dimensions are displayed as "59 x 50.229 x 0" which
just adds to the confusion.

Andrew

[Tim Hutton]

On 22 August 2012 05:00, Andrew Trevorrow <and...@trevorrow.com> wrote:

>> Have a play with these patterns and tell me if we need to change the
>> UI to be integer-specific - I'm not sure we do.
>

> Agreed -- the new rules look clean and simple.
>
> One thing has me puzzled though. In Help/tips.html we say:
>
> "Any reaction-diffusion pattern can be changed in size using the
> dimensions control in the Info Pane."
>
> But this only seems to be true for .vti files. When I load hex_buss.vtu
> or tri_life.vtu or penrose_life.vtu I can't edit the Dimensions.
> I'd really like to increase the number of cells in those patterns
> (without having to muck about editing files).

I've corrected and added more detail to our tips.html to hopefully
make it all clear to our users.

> After loading penrose_life.vtu the Dimensions are listed as 2 x 2 x 0.
> What do those numbers mean (ie. how are they related to the number of
> cells)? I couldn't find anything in the help docs about that.

Ready now hides the dimensions completely for meshes. I think this
makes sense - it's not a useful thing to see, and advance users won't
need it anyway.

[Tim Hutton]

Hi fededv,

Thanks for the kind words!

For users without OpenCL installed, the default behavior is to use the
inbuilt rule (Gray-Scott). There is no way to change the rule, just
the parameters.

For users with OpenCL the default behavior is to create a
formula-based rule. You should be able to change the formula within
Ready by clicking "edit" next to the "Formula" in the Info Pane. To
change to the Ginzburg-Landau rule you will also need to change the
parameters (Add Parameter... and Delete Parameter... on the Action
menu).

There is not currently a way to change to a kernel-based rule, without
editing the file. This is on the TODO list for the next release. If
you don't mind editing the files then the easiest way is to copy the
entire <rule> ... </rule> section from one file to another. As long as
the two files have the same number of chemicals then it should work.

If you want to get a specific file working then feel free to send it
to the list and we will try to debug it.

Regards,

Tim

On 31 October 2012 10:45, fededv <fed...@gmail.com> wrote:
>> Hi everybody,
>
> I find Ready a wonderful software and would spend hours experimenting with
> it. The only thing I find bugging and inexplicable is that every time I
> import an external mesh it loads a standard Gray-Scott formula all the
> times. It would be nice to be able to apply all the other great formulas
> (Ginzburg-Landau for ex.) to any imported 3D mesh. I tried to copy and paste
> other, added parameters with no luck: I always get error messages, the most
> recurring of which is "Failed to open file. Error:
>
>
> OpenCLImageRD::CreateOpenCLBuffers : buffer creation failed: Invalid buffer
> size"
>
>
> Thank you very much guys and keep up the good work!

[fededv]

Hi Tim,

Thank you for your detailed answer. I actually had tried the very thing that you are suggesting a couple of time with no success: I imported an .obj mesh and I got the

inbuilt rule (Gray-Scott), then I manually tried to change the rule and parameters from another formula but couldn't get it to work. In the end I succeeded but I suspect there can be a problem of scale/resolution of the 3D mesh that prevents you to see the formula running its effects.

It would be great in fact if, in the next release, we could have a global parameter which controls the 3D scale of the reactions.

I will keep on trying and looking forward to the next release.

Regards

Federico