Re: extend the smoothlife_smoothglider.vti

[Robert Munafo]

On 1/21/13, fededv <fed...@gmail.com> wrote:
> Is it possible to apply "smoothlife_smoothglider.vti" pattern to another
> mesh other than the default built-in plane?
>
> What I usually do with other
> patterns is to copy the formula and parameters and paste them into my new
> mesh (a sphere for ex.). I haven't had any luck with this extremely
> interesting pattern, maybe because is in Full Kernel Form. By the way I
> don't have a clue on how to modify formulas so can anyone help me with
> that? Is that a tough thing to do?

You're right, Full Kernel patterns are not the same in a grid
simulation vs. a mesh simulation.

The problem with SmoothLife (from Ready's point of view) is that it is
not a reaction-diffusion system. Nearby pixels influence each other in
a way that cannot be approximated by the normal Laplacian function.
Nor indeed, by any function that exists in real-world systems -- for
example, it's different from the inverse-square law of
electromagnetism or the weird distance-limited strong and weak nuclear
forces. Because of that, we cannot use any of the existing "magic" in
Ready that allows reaction-diffusion formulas to be interchanged
between grid and mesh models.

To compute the "force" exerted by the neighborhood on a given point,
SmoothLife requires an area integral (or volume integral) taken over
an annulus (or spherical shell) with two arbitrary radii and centered
on the point in question. Implementation and optimization of this
calculation is a major project -- initial work was done by Stephen
Rafler, see [1], and Mikola Lysenko has explained it thoroughly at [2]
and [3].

As you can see if you read the latter part of [3], the calculation is
very complicated, and completely different algorithms need to be used
for a mesh as opposed to a grid.

- Robert

[1] S. Rafler, “Generalization of Conway’s “Game of Life” to a
continuous domain – SmoothLife” (2011) Arxiv: 1111.1567 PDF at
http://arxiv.org/abs/1111.1567

[2] Mikola Lysenko, "Conway’s Game of Life for Curved Surfaces (Part
1)", blog article, 2012.
http://0fps.wordpress.com/2012/11/19/conways-game-of-life-for-curved-surfaces-part-1/
[3] ibid., "Conway’s Game of Life for Curved Surfaces (Part 2)",
http://0fps.wordpress.com/2012/11/28/conways-game-of-life-for-curved-surfaces-part-2/


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

Thanks Robert. Those 0fps posts are really good but the maths is a bit beyond me.

Presumably a reasonable approximation would be to take an extended neighborhood as including any point within radius R of a 3D point. On meshes where the sampling was high enough relative to the curvature this would come to the same thing as more complex methods. This is something we can look into implementing. I did previously consider a TNeighborhood::EUCLIDEAN_DISTANCE type that would cover this.
https://code.google.com/p/reaction-diffusion/source/browse/trunk/Ready/src/readybase/AbstractRD.hpp#163

Alternatively, we could have a pre-processing stage to compute the neighborhood list explicitly for every cell. This could be based on geodesic distance, and could be called TNeighborhood::GEODESIC_DISTANCE.

Thoughts?

Tim

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

[fededv]

Robert,

Thank you for your really exhaustive answer, I imagined it was quite different from a reaction-diffusion formula.

Let's hope someone would play around and come up with an approximated formula for a generic 3d mesh.

[Robert Munafo]

On 1/21/13, Tim Hutton <tim.h...@gmail.com> wrote:
> Thanks Robert. Those 0fps posts are really good but the maths is a bit
> beyond me.
>
> Presumably a reasonable approximation would be to take an extended
> neighborhood as including any point within radius R of a 3D point. On
> meshes where the sampling was high enough relative to the curvature this
> would come to the same thing as more complex methods. This is something we
> can look into implementing. I did previously consider a
> TNeighborhood::EUCLIDEAN_DISTANCE type that would cover this.
> https://code.google.com/p/reaction-diffusion/source/browse/trunk/Ready/src/readybase/AbstractRD.hpp#163
>
> Alternatively, we could have a pre-processing stage to compute the
> neighborhood list explicitly for every cell. This could be based on
> geodesic distance, and could be called TNeighborhood::GEODESIC_DISTANCE.

You define a lot of useful neighborhood types there, but I doubt that
EUCLIDEAN_DISTANCE (or any of the others) will support SmoothLife
gliders, unless you hugely increase the number of triangles in the
mesh. And then we'd still have to do a lot of computation to figure
out the weights (but that's a one-time procedure, right?).

I think the weight of the neighbor vertex would have to be determined
by performing the 2-D annulus integral over each of the triangles that
are shared between it and the center vertex. Worse than that, you have
to do this for non-neighbor triangles that might lie within the
annulus, so it's a bit like the implementation of the RANGE weights,
where you might have to walk the whole graph to figure out how much
triangle area, and therefore how much influence, each vertex has on
each other vertex.

I also think we'd have to compute the actual, exact 2-D integral, with
no cheating and no approximations. Otherwise, the SmoothLife gliders
(which are very delicate) will not glide.

SmoothLife is very difficult math, and it's beyond me but that author
I pointed you to can definitely grok it. Maybe they'd like to help.

[2] Mikola Lysenko, "Conway’s Game of Life for Curved Surfaces

(Part1)", blog article, 2012.