include 3D_CA.vti in next release?
Andrew Trevorrow
forums for the next release. We might get more people interested
in trying Ready if they know it's possible to experiment with 3D CA.
The only reason I'm reluctant to do this now is because of the ugly way
we currently use to set individual cells. How difficult would it be
to allow overlays to do something like this:
<setorigin3D x="32" y="32" z="32" /> (default is 0,0,0)
<setcell3D x="2" y="-1" z="3" value="1" />
<setcell3D x="-1" y="0" z="0" value="1" />
etc...
Also, it would be nice to have a rendering option for changing the
cell shape from the current octahedron to a cube or sphere.
Does VTK make that easy?
If these suggestions are tricky to implement then best to leave them
for a future release (and I'll add them to the TODO file).
Andrew
Tim Hutton
wary of following this line of integer-CA too far because to do this
properly we would have to:
- store char/int arrays instead of floats
- render cubes instead of using contouring algorithms (not too hard, in itself)
- allow the user to specify the mapping for integers to colors
- allow the user to set some states to transparent
- make a UI for painting individual cells with integers
And even if we did all that it wouldn't be the fastest way of doing
things because of all the conditional branching in the kernel.
A better long-term approach might be to develop a 3D implementation of
(multi-state) hashlife and extend Golly to support 3D CA. Or to
develop a whole new app for integer 3D CA that may or may not include
OpenCL.
These kind of questions are inevitable because of the continuum
between continuous and discrete CA. We just need to be careful that we
don't start down the wrong route - just as it would have been a
mistake to shoehorn Ready's continuous CA stuff into Golly.
--
Tim Hutton - http://www.sq3.org.uk - http://profiles.google.com/tim.hutton/
Tim Hutton
of smooth surfaces for 3D renders. And there's a new overlay type:
pixel, for setting individual cells. Together these make the 3D CA
looks reasonable, so I've gone ahead and added it: CarterBays_3D.vti.
I renamed to be a bit more specific because we anticipate other 3D CA.
As things stand the rendering of 3D CA with 3 or more states will be a
bit odd - the contour_level parameter is used for some control but
it's not really the right approach.
It's all a bit of a compromise but hopefully enough to be going along
with for the moment, and doesn't pull us too far from our central
mission.
Andrew Trevorrow
> I've extended use_image_interpolation so that it shows cubes instead
> of smooth surfaces for 3D renders.
Thanks! Why are cubes so much slower to render? My naive expectation
was that displaying cubes would be faster than smooth surfaces.
> And there's a new overlay type: pixel, for setting individual cells.
Would it be possible to allow multiple pixel elements per overlay?
Ditto for rectangles and other shape elements.
Or is this a limitation of XML?
> Together these make the 3D CA
> looks reasonable, so I've gone ahead and added it: CarterBays_3D.vti.
> I renamed to be a bit more specific because we anticipate other 3D CA.
Minor nitpick, but maybe "bays_3D.vti" would better agree with the
existing pattern names such as conway_life.vti and grayscott_3D.vti.
I see that you reduced the file size by shortening the AppendedData.
I should probably mention that when I tried to do such things it
was very easy to crash Ready, so maybe our XML reading code needs
to be more robust. Eventually I discovered the shortest solution was
to delete almost everything and just have this:
<ImageData WholeExtent="0 63 0 63 0 63" Origin="0 0 0" Spacing="1 1 1" />
Some other things I've been meaning to mention:
Blank lines in the kernel code are displayed as 2 blank lines in the
Info pane.
Clearly we need to obey linebreaks in the kernel/formula code, but
I think it would be better not to do that for the description text.
This would be nicer for people (like me) who don't use autowrap
and like to insert hard linebreaks when writing html text.
Probably the only formatting change we should make to the description
text is to replace "\n\n" with <p> so people don't have to use <p>
to start a new para.
Andrew
PS. I'll be away for a week from tomorrow.
Tim Hutton
> Tim:
>
>> I've extended use_image_interpolation so that it shows cubes instead
>> of smooth surfaces for 3D renders.
>
> was that displaying cubes would be faster than smooth surfaces.
I think the pipeline
(vtkImageWrapPad->vtkThreshold->vtkGeometryFilter) is inefficient.
I'll keep an eye out for better options.
There's a slight issue that our new responsive UI approach of dividing
up the timesteps_per_render means that the vtkImageWrapPad gets pumped
more times than is necessary. But that doesn't affect patterns where
timesteps_per_render=1, like our new one.
Instead of pipelining we could remake the scene every time the image
changes - put a cube wherever the pixel is >contour_level. This would
give more rendering primitives (internal faces) but would probably be
faster for sparse patterns. I'll look into it.
>> And there's a new overlay type: pixel, for setting individual cells.
>
> Would it be possible to allow multiple pixel elements per overlay?
> Ditto for rectangles and other shape elements.
> Or is this a limitation of XML?
Oh, good point. I'll look into it.
XML itself imposes almost no limitations.
>
>> Together these make the 3D CA
>> looks reasonable, so I've gone ahead and added it: CarterBays_3D.vti.
>> I renamed to be a bit more specific because we anticipate other 3D CA.
>
> Minor nitpick, but maybe "bays_3D.vti" would better agree with the
> existing pattern names such as conway_life.vti and grayscott_3D.vti.
OK, yes.
>
> I see that you reduced the file size by shortening the AppendedData.
> I should probably mention that when I tried to do such things it
> was very easy to crash Ready, so maybe our XML reading code needs
> to be more robust.
I'll look into it.
> Eventually I discovered the shortest solution was
> to delete almost everything and just have this:
>
> <ImageData WholeExtent="0 63 0 63 0 63" Origin="0 0 0" Spacing="1 1 1" />
Yeah if that works then fine. I tend to use the New command and then
Save and then snip out the image bit from that blank image.
When we support initial_pattern_generator editing we should have an
option to save a pattern with an empty image if
apply_when_loading="true" because in those cases the image gets
overwritten anyway.
>
> Some other things I've been meaning to mention:
>
> Blank lines in the kernel code are displayed as 2 blank lines in the
> Info pane.
>
> Clearly we need to obey linebreaks in the kernel/formula code, but
> I think it would be better not to do that for the description text.
> This would be nicer for people (like me) who don't use autowrap
> and like to insert hard linebreaks when writing html text.
> Probably the only formatting change we should make to the description
> text is to replace "\n\n" with <p> so people don't have to use <p>
> to start a new para.
>
> Andrew
>
> PS. I'll be away for a week from tomorrow.
--
Tim Hutton
> On 2 April 2012 23:28, Andrew Trevorrow <and...@trevorrow.com> wrote:
>> Would it be possible to allow multiple pixel elements per overlay?
>> Ditto for rectangles and other shape elements.
>> Or is this a limitation of XML?
>
> Oh, good point. I'll look into it.
This worked really well.
https://code.google.com/p/reaction-diffusion/source/detail?r=744
There's a related issue that sometimes multiple overlays use the same
shape. e.g.
https://code.google.com/p/reaction-diffusion/source/browse/trunk/Ready/Patterns/CPU-only/grayscott_2D.vti
The COLLADA format uses IDs for this, which we could do too if we find
it necessary:
<initial_pattern_generator apply_when_loading="true">
<overlay chemical="a">
<overwrite />
<constant value="1" />
<everywhere />
</overlay>
<overlay chemical="b">
<overwrite />
<white_noise low="0" high="1" />
<rectangle id="rect01">
<Point3D x="0.2" y="0.2" z="0.6" />
<Point3D x="0.5" y="0.5" z="0.8" />
</rectangle>
</overlay>
<overlay chemical="a">
<subtract />
<other_chemical chemical="b" />
<rectangle ref="rect01" />
</overlay>
</initial_pattern_generator>
Tim Hutton
> I should probably mention that when I tried to do such things it
> was very easy to crash Ready, so maybe our XML reading code needs
> to be more robust.
I'm having trouble reproducing this. Deleting random bits of the file
just gives me read errors and Ready carries on. Could you send me one
or more files that crash Ready on your machine?
Andrew Trevorrow
> I'm having trouble reproducing this. Deleting random bits of the file
> just gives me read errors and Ready carries on. Could you send me one
> or more files that crash Ready on your machine?
Just truncate the AppendedData in bays_3D.vti to "_IAAAAA".
Or simply delete all of <AppendedData ... /AppendedData>.
On trying to load the file Ready crashes with errors like this:
Exception Type: EXC_ARITHMETIC (SIGFPE)
Exception Codes: EXC_I386_DIV (divide by zero)
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 ...gle.code.reaction-diffusion 0x00000001006f47c9 vtkXMLDataParser::ReadCompressedData(unsigned char*, long long, long long, int) + 299
1 ...gle.code.reaction-diffusion 0x00000001006f584a vtkXMLDataParser::ReadBinaryData(void*, long long, long long, int) + 220
2 ...gle.code.reaction-diffusion 0x00000001006f5976 vtkXMLDataParser::ReadAppendedData(long long, void*, long long, long long, int) + 108
3 ...gle.code.reaction-diffusion 0x00000001006fcecc int vtkXMLDataReaderReadArrayValues<vtkArrayIteratorTemplate<float> >(vtkXMLDataElement*, vtkXMLDataParser*, long long, vtkArrayIteratorTemplate<float>*, long long, long long) + 220
4 ...gle.code.reaction-diffusion 0x00000001006fa700 vtkXMLDataReader::ReadArrayValues(vtkXMLDataElement*, long long, vtkAbstractArray*, long long, long long) + 346
5 ...gle.code.reaction-diffusion 0x0000000100707b8f vtkXMLStructuredDataReader::ReadSubExtent(int*, int*, long long*, int*, int*, long long*, int*, int*, vtkXMLDataElement*, vtkAbstractArray*) + 489
6 ...gle.code.reaction-diffusion 0x000000010070770c vtkXMLStructuredDataReader::ReadArrayForPoints(vtkXMLDataElement*, vtkAbstractArray*) + 300
7 ...gle.code.reaction-diffusion 0x00000001006fb127 vtkXMLDataReader::ReadPieceData() + 937
8 ...gle.code.reaction-diffusion 0x00000001006f965a vtkXMLDataReader::ReadPieceData(int) + 50
9 ...gle.code.reaction-diffusion 0x0000000100709311 vtkXMLStructuredDataReader::ReadXMLData() + 2225
10 ...gle.code.reaction-diffusion 0x00000001007048e9 vtkXMLReader::RequestData(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 1265
11 ...gle.code.reaction-diffusion 0x000000010070315e vtkXMLReader::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 232
12 ...gle.code.reaction-diffusion 0x0000000100930aa6 vtkExecutive::CallAlgorithm(vtkInformation*, int, vtkInformationVector**, vtkInformationVector*) + 126
13 ...gle.code.reaction-diffusion 0x000000010092a4a7 vtkDemandDrivenPipeline::ExecuteData(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 101
14 ...gle.code.reaction-diffusion 0x000000010092e483 vtkDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 1187
15 ...gle.code.reaction-diffusion 0x0000000100a147e6 vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 1642
16 ...gle.code.reaction-diffusion 0x000000010092dfd1 vtkDemandDrivenPipeline::UpdateData(int) + 693
17 ...gle.code.reaction-diffusion 0x0000000100a12fa5 vtkStreamingDemandDrivenPipeline::Update(int) + 201
18 ...gle.code.reaction-diffusion 0x00000001009314bb vtkExecutive::Update() + 61
19 ...gle.code.reaction-diffusion 0x000000010092c495 vtkDemandDrivenPipeline::Update() + 21
20 ...gle.code.reaction-diffusion 0x0000000100a0b891 vtkStreamingDemandDrivenPipeline::Update() + 21
21 ...gle.code.reaction-diffusion 0x00000001008e1666 vtkAlgorithm::Update() + 38
22 ...gle.code.reaction-diffusion 0x000000010005742c MyFrame::OpenFile(wxString const&, bool) + 1970
Andrew
Tim Hutton
the errors and says:
Failed to open file. Error:
OpenCL_RD::CreateBuffers : buffer creation failed: Invalid buffer size
On 3 April 2012 21:42, Andrew Trevorrow <and...@trevorrow.com> wrote:
> Tim:
>
>> I'm having trouble reproducing this. Deleting random bits of the file
>> just gives me read errors and Ready carries on. Could you send me one
>> or more files that crash Ready on your machine?
>
--
Tim Hutton
just "_IAAAAA") crashes both Paraview (on all platforms, I'm guessing)
and Ready (on Mac and Linux but not on Windows). BAD3 (with other data
deleted) gives errors in both Ready and Paraview but doesn't crash
them.
So to me it looks like a bug in VTK - it is causing a floating point
exception on some bad input. These are different to STL exceptions,
and aren't caught by VTK's error handling mechanism it seems. I'll
submit a bug report.
(I don't know why Ready on Windows can cope with BAD2 but Paraview on
Windows can't. Some subtlety in how their VTK's were built perhaps.)
I'm not even clear on how to handle floating point exceptions in our
own code. Is there a cross-platform way?
Andrew Trevorrow
> Attached two files, both with bits of their data deleted. BAD2 (with
> just "_IAAAAA") crashes both Paraview (on all platforms, I'm guessing)
> and Ready (on Mac and Linux but not on Windows). BAD3 (with other data
> deleted) gives errors in both Ready and Paraview but doesn't crash
> them.
Yep, I can confirm that the Mac version of ParaView behaves like Ready.
> I'm not even clear on how to handle floating point exceptions in our
> own code. Is there a cross-platform way?
Sorry, no idea.
Andrew
Tim Hutton
>> just "_IAAAAA") crashes both Paraview (on all platforms, I'm guessing)
>> and Ready (on Mac and Linux but not on Windows). BAD3 (with other data
>> deleted) gives errors in both Ready and Paraview but doesn't crash
>> them.
>
I submitted a bug for this:
http://vtk.org/Bug/view.php?id=13057
Andrew Trevorrow
> Blank lines in the kernel code are displayed as 2 blank lines in the
> Info pane.
This only happens if the kernel/formula code is not indented.
I couldn't find any way to fix this in InfoPanel::Update so I've
just indented the kernel code in bays_3D.vti (along with minor
changes to the description, and removing all of the unnecessary
image data stuff).
> Clearly we need to obey linebreaks in the kernel/formula code, but
> I think it would be better not to do that for the description text.
I've implemented this (trivial) change. It's much nicer for people
like me who don't use autowrap and like to insert hard linebreaks
when writing html text. There was no need to change any of the
existing descriptions, except in schlogl.vti where I've improved
the formatting a bit. Hope that's ok!
PS. Just noticed a strange bug after loading the new sphere.vtu file.
Toggling wireframe mode from the View menu works fine, but when I click
the "edit" link for wireframe mode in the Info pane's render settings
the render window is not updated.
Andrew
Tim Hutton
> PS. Just noticed a strange bug after loading the new sphere.vtu file.
> Toggling wireframe mode from the View menu works fine, but when I click
> the "edit" link for wireframe mode in the Info pane's render settings
> the render window is not updated.
It's odd that that ever worked, since I wasn't using
render_settings.use_wireframe in MeshRD::InitializeRenderPipeline().
Maybe the 'w' key was being sent to the VTK window. If so then we need
to be careful because the user might assign 'w' to something else and
then get confused when the mesh keeps going wireframe.
Andrew Trevorrow
> It's odd that that ever worked, since I wasn't using
> render_settings.use_wireframe in MeshRD::InitializeRenderPipeline().
> Maybe the 'w' key was being sent to the VTK window. ...
I'm pretty sure that can't happen. Anyway, your recent changes
have fixed the problem.
Another possible problem: the sphere.vtu and cow.vtu files don't show
any spots when run -- they just turn green. Are spots meant to
appear (as suggested by the description text) or maybe you just
haven't finished implementing the mesh code?
And while I think of it, a couple of files are missing descriptions:
grayscott_3D.vti, pulsate.vti.
Andrew
Tim Hutton
fill a volume. This sort of thing is the reason for adopting
vtkUnstructuredGrid for MeshRD, rather than vtkPolyData which only
supports 2D faces (polygons). Imagine a growing embyro shape where we
want the RD chemicals to diffuse throughout the volume.
It's a temporary file, just for our testing (as are cow.vtu and
sphere.vtu) and will be replaced by something more suitable before the
next release.
As you've noticed, MeshRD isn't finished yet - it just has a hardcoded
heat equation. I need to work out how to get OpenCL working when each
cell has an arbitrary-length list of neighbors to work with. (If this
is fast enough then we might consider unifying ImageRD and MeshRD,
since a 3D image is equivalent to a cubic honeycomb.)
tetramesh.vtu shows up the wireframe bug again: hitting 'w' or using
the menu command shows the wireframe of the outer surface, while
changing use_wireframe in the Info Pane changes
render_settings.use_wireframe as we expect (shows internal edges, see
MeshRD::InitializeRenderPipeline). (Tested on Windows and Linux.) This
must have something to do with the fact that by the VTK render window
interactor accepts the 'w' key to show the actors in wireframe.
On 14 April 2012 01:19, Andrew Trevorrow <and...@trevorrow.com> wrote:
> Tim:
>
>> It's odd that that ever worked, since I wasn't using
>> render_settings.use_wireframe in MeshRD::InitializeRenderPipeline().
>> Maybe the 'w' key was being sent to the VTK window. ...
>
> I'm pretty sure that can't happen. Anyway, your recent changes
> have fixed the problem.
>
> Another possible problem: the sphere.vtu and cow.vtu files don't show
> any spots when run -- they just turn green. Are spots meant to
> appear (as suggested by the description text) or maybe you just
> haven't finished implementing the mesh code?
>
> And while I think of it, a couple of files are missing descriptions:
> grayscott_3D.vti, pulsate.vti.
>
> Andrew
--
Tim Hutton
> tetramesh.vtu shows up the wireframe bug again: hitting 'w' or using
> the menu command shows the wireframe of the outer surface, while
> changing use_wireframe in the Info Pane changes
> render_settings.use_wireframe as we expect (shows internal edges, see
> MeshRD::InitializeRenderPipeline). (Tested on Windows and Linux.) This
> must have something to do with the fact that by the VTK render window
> interactor accepts the 'w' key to show the actors in wireframe.
r780 fixes this. We were passing 'w' and 's' to the VTK window for some reason.
Andrew Trevorrow
> r780 fixes this. We were passing 'w' and 's' to the VTK window for
> some reason.
I see your later change removed that DoCharEvent hack I added -- good!
Everything works as it should in latest Mac build.
Andrew