rdy commandline improvements

[danwills]

Hi Ready/Golly gang : ) I have just set up a pull request (rdy-commandline-improvements->gh-pages) for my recent work on the rdy command-line utility, and wanted to give some background.

In summary, the changes add a number of arguments to the 'rdy' command, that make it print out parts of the system such as kernel formula, reagent and parameter info etc - even initial-states! - as text in a terminal environment.

Doing this has made it possible to import many of my (2d formula-based) Ready simulations (VTI files) into Houdini, by having a setup that runs the rdy command (via a python script, with VTI file as -i argument), and from the output of this, creates custom simulation (Dop) objects that import the kernels and the initial states and so on, and then Houdini hosts and runs the sim (with the sim continuing exactly as expected without any bump) without needing to actually even link the Ready binaries. Indeed once the thing is imported, it doesn't need Ready at all after that, and this aspect seems kinda useful, much as I do enjoy Ready :).

Once imported you also get Houdini's awesomely flexible power to feed out of and in to the simulation if so desired.. seems like a mind-boggling number of possibilities here.. this version has only been tested with 2d formula-based simulations so far, and I know it doesn't work with full-kernel yet and it would probably be fairly easy to add support, I guess I'm disclaiming that this is v01 and I am definitely thinking about what's next, but this is a good start I think, would love to hear your thoughts! :)

The changed arguments to the rdy command are probably best described by the output of the new help argument:

Options:
  -h [ --help ]                        Print the help message
  -n [ --num-iterations ] arg (=0)     Number of iterations to run before
                                       saving
  -k [ --print-kernel ]                Print (full) OpenCL kernel source (when
                                       possible)
  -f [ --print-formula ]               Print kernel formula (when possible)
  -r [ --print-reagent-info ]          Print reagent info
  -p [ --print-parameter-info ]        Print parameter info
  -s [ --print-render-settings ]       Print render Settings
  -d [ --print-formula-description ]   Print formula Description
  -m [ --print-initial-state-images ]  Print initial state images (Warning: May
                                       be large!)
  -i [ --vti-in ] arg                  VTI file to load (required)
  -o [ --vti-out ] arg                 VTI file to save (optional)
  -l [ --opencl-platform ] arg         OpenCL platform number (Currently will
                                       crash if incorrect!)
  -g [ --opencl-device ] arg           OpenCL device number (Currently will
                                       crash if incorrect!)
  -v [ --verbose ]                     Verbose output.

As far as I'm aware, these are the things that might need to be sorted out, pull-request-wise:

Whether at line 416 of CmakeLists.txt it's ok to comment out the if (UNIX AND NOT APPLE) block.. this makes the build fail for me, but maybe that breaks the GUI build for others? Anyone know who added this part and whether it is still necessary?

Whether we're cool with going to vtkRenderingOpenGL2 down at line 457 in CmakeLists.txt (I'm actually uncertain whether this is even strictly required, but it seemed like a good upgrade to me!)

Finally, whether including boost as a dependency is of any concern. I tend to think that any modern build environment will probably already have boost and I suspect that by having VTK as a dependency we may have already been implicitly depending on it anyway.

As mentioned in the commit message, I have built some Houdini Digital Asset (hda) files that call this improved rdy binary and use the text it outputs to reconstruct the RD-simulation (including initial-states) in Houdini using Gas OpenCL Dops. I intend to commit these HDAs to the Ready repository too, but I want to get the changes to the 'rdy' tool committed (and hopefully accepted into gh-pages) first.

To check out the branch, this is the git command:

git clone https://github.com/GollyGang/ready.git --branch rdy-commandline-improvements --single-branch rdy-commandline-improvements

I appreciate very much any testing (and/or pull-request accepting) you can contribute! Thanks gang! Dan

[timhutton]

Hi @danwills,

(BTW, the PR is the best place for these comments. I'll add specific comments there.)

I don't really understand the interaction with Houdini (I don't use it) but I'm happy if this change is useful to you and others.

Tim

[danwills]

G'day @timhutton, Thanks so much for taking a look at my PR and helping with landing the changes! I'm still a bit new to the whole git/github thing :)

Houdini has these nodes in its simulation context ("Dops") that allow one to write (or enter) an openCL kernel, and use it to process voxel data in a feedback/simulation context. It's called the "Gas OpenCL Dop". I have made a tool that - by calling the new rdy binary with the right arguments - retrieves the formula code, the parameter values and simulation initial states from a vti file, and hooks it all up so that the simulation can run natively in Houdini. Once imported it can work without the VTI file present.

This makes interesting things possible, but the main great thing is that you can display your simulation in an unlimited number of new ways, including voxel grids with a color per grid, which can look rather nice (youtube videos soon I promise! have just been more focussed on the code and making it work part recently)

It is also quite easy to bring in other voxel fields on each simulation step and use them to affect the simulation, making it possible to do things like "collide" (ie remove) the "b" reagent where the voxels are inside some object elsewhere in the Houdini scene, or: make the RD behave differently based on anything that you can generate and turn into a 2d volume: Offset F+K in shadowed areas? No problem, different diffusion where density exists from a 2d-fluid simulation? easy! It makes it much easier to connect things to the simulation.

You can also continuously feed in animated values for the parameters (to create rd simulations who's behaviour is synchronized to other things in the scene, or just varies according to some animation you've made).

This is also just scratching the surface as ultimately this could surely work just as well for 3d-voxel sims and also the on-polymesh type. In fact that is one thing that my system makes much much nicer: changing sim resolution and reusing a voxel initial state, but I'll write more about that later.

Guess I should move this discussion over to the PR anyway, but I hope this has thrown a small amount of light on what these changes are about : )

Have a choice one, Dan

[timhutton]

@danwills Sounds great. Will you add an .html file in Help/ with a tutorial on how to do this?

[danwills]

Yes absolutely! I am really ultimately interested in making RDs more accessible, so writing some help is a very on-point suggestion! :) I'll move on to solidifying the hdas now and once they are releasable I'll write some proper help for sure!

Thanks again so much for your input and assistance with getting the rdy changes through, seems it was much more complicated than I thought from inside my weird gentoo-linux bubble! I will try to get more familiar with the whole Travis thing and hopefully things will be smoother next time.