Tim, I'm wondering if I should add that 3D_CA.vti file I posted in the 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:
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).
I'm happy to include 3D_CA.vti in the next release but I'm slightly 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.
On 27 March 2012 00:36, Andrew Trevorrow <and...@trevorrow.com> wrote:
> Tim, I'm wondering if I should add that 3D_CA.vti file I posted in the > 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:
> 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).
I've extended use_image_interpolation so that it shows cubes instead 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.
On 27 March 2012 11:28, Tim Hutton <tim.hut...@gmail.com> wrote:
> I'm happy to include 3D_CA.vti in the next release but I'm slightly > 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.
> On 27 March 2012 00:36, Andrew Trevorrow <and...@trevorrow.com> wrote: >> Tim, I'm wondering if I should add that 3D_CA.vti file I posted in the >> 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:
>> 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).
> 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:
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.
On 2 April 2012 23:28, Andrew Trevorrow <and...@trevorrow.com> wrote:
> Tim:
>> 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.
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:
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.
> 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.
On 3 April 2012 10:11, Tim Hutton <tim.hut...@gmail.com> wrote:
> 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?
On 2 April 2012 23:28, Andrew Trevorrow <and...@trevorrow.com> wrote:
> 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'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?
> 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:
>> 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:
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.
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?
On 4 April 2012 14:41, Tim Hutton <tim.hut...@gmail.com> wrote:
> 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?
>> 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:
> 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.
> 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?
> On 4 April 2012 14:41, Tim Hutton <tim.hut...@gmail.com> wrote: >> Ah, it crashes on Linux too with these changes. On Windows it catches >> the errors and says:
>> 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?
>>> 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:
> 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?
On 12 April 2012 07:08, Andrew Trevorrow <and...@trevorrow.com> wrote:
> Tim:
>> 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.
> 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.
On 13 April 2012 00:44, Andrew Trevorrow <and...@trevorrow.com> wrote:
> 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.
> 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.
In r777 I've added tetramesh.vtu which uses 3D cells (tetrahedra) to 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:
>> 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.
On 16 April 2012 15:34, Tim Hutton <tim.hut...@gmail.com> wrote:
> 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.
> 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.
