Ready as a lib

[Scott Richmond]

I thought I'd have a go at compiling the readybase project into a lib or dll to use in other projects, however its quite the task trying to unravel it into a single lib or dll given all the VTK integration it appears to have.

Anyone managed to successfully do this?

[Tim Hutton]

Hi Scott,

Look for readybase.lib (on Windows) - this is the core of Ready without the GUI stuff. You should be able to include this lib in other projects. It uses VTK, which we use internally for data storage, so don't try to strip out VTK.

As a demonstration of this, when you build Ready it should also produce a command-line utility, called rdy.exe (on windows). This is a very simple cpp file (src/cmd/main.cpp) that is linked against readybase.lib. This command-line version doesn't link against wxWidgets.

Our build file is CMakeLists.txt, which shows how this all works. Worth learning about CMake.

If you really want to strip out VTK then it would be easier to rewrite the reaction-diffusion code from scratch. Part of Ready's goal is to collect all the reaction-diffusion formulae for such a project, so help yourself.

Regards,

Tim

On 18 January 2013 12:21, Scott Richmond <s.t.ri...@gmail.com> wrote:

I thought I'd have a go at compiling the readybase project into a lib or dll to use in other projects, however its quite the task trying to unravel it into a single lib or dll given all the VTK integration it appears to have.

Anyone managed to successfully do this?

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

[Scott Richmond]

Regarding the VTK stuff - Agreed. I can see its quite heavily used and I'd rather not touch it. This is fine. Will I need to import other VTK libs as well as the readybase lib in a new project?

[Tim Hutton]

I had to check. You can see in the CMakeLists.txt file, starting from line 333:
https://code.google.com/p/reaction-diffusion/source/browse/trunk/Ready/CMakeLists.txt#333

VTK libs (we're using vtkCommon vtkGraphics vtkIO vtkRendering vtkHybrid) are linked into readybase.

${CMD_NAME} is the command-line utility. readybase is linked into it but not VTK again, since it will already be included.

(After that, ${APP_NAME} (which is the Ready GUI application) links readybase and ${wxWidgets_LIBRARIES}.)

[Scott Richmond]

Okay I've successfully managed to get AbstractRD working in an external DLL and project. I had to just copy n paste the huge amount of linked vtk libs into the project and let it sort itself out. :P

Can you tell me a bit more about how AbstractRB works? I've used the SystemFactory::CreateFromFile() method to load in a pattern just like the rdy project. But I'm not really sure how to then look around in the data as I update().

Its not clear what SaveFile() outputs as either.

For all the current calculations I want to perform I'd like more direct access to the data so I can look at individual gridpoints or pull out entire blocks of the data. I'd rather not introduce any extra latency by pushing the data to image and then grabbing that and read it.

On the subject of images though: I was doing

[Tim Hutton]

Hi Scott,

Great to see you getting into the Ready code! I'll help as much as I can.

On 19 January 2013 09:12, Scott Richmond <s.t.ri...@gmail.com> wrote:

Okay I've successfully managed to get AbstractRD working in an external DLL and project. I had to just copy n paste the huge amount of linked vtk libs into the project and let it sort itself out. :P

You should only need the five VTK libs listed in the CMake file.
 

Can you tell me a bit more about how AbstractRB works? I've used the SystemFactory::CreateFromFile() method to load in a pattern just like the rdy project. But I'm not really sure how to then look around in the data as I update().

Its not clear what SaveFile() outputs as either.

You could use AbstractRD::GetValue() to retrieve individual pixels. (On image data it gives the closest pixel. On mesh data it gives the nearest cell.)

If you want to access the whole image more quickly you could try a dynamic_cast from the AbstractRD to ImageRD, and then use ImageRD::GetImage(int iChemical).

SaveFile() outputs in Ready's file format, which is XML. It is the same as VTK's file format (vti for image data) but with an extra XML element (RD):
http://reaction-diffusion.googlecode.com/svn/trunk/Ready/Help/formats.html

The code documentation is useful for exploring the code:
http://reaction-diffusion.googlecode.com/svn/doc/Ready/trunk/index.html
(You can generate this yourself in the build, by specifying where doxygen lives when configuring with CMake and then building the 'doc' target.)
 

For all the current calculations I want to perform I'd like more direct access to the data so I can look at individual gridpoints or pull out entire blocks of the data. I'd rather not introduce any extra latency by pushing the data to image and then grabbing that and read it.

In between updates, ImageRD pulls the data off the GPU back into the vtkImageData storage, which you can directly access by using GetValue() which calls ImageRD::GetImage(int iChemical), so there's no unnecessary copying beyond what we do anyway. (In theory we could leave the data on the GPU and render directly from there somehow I think but I don't know how to do that.)
 

On the subject of images though: I was doing

I think you accidentally
 

[Scott Richmond]

You should only need the five VTK libs listed in the CMake file.

Unfortunately not - At least vtkImage was required, plus more. Its okay. The compiler will only link what I'm using. 

You could use AbstractRD::GetValue() to retrieve individual pixels. (On image data it gives the closest pixel. On mesh data it gives the nearest cell.)

Okay yeah I saw that. That will be fine. 

If you want to access the whole image more quickly you could try a dynamic_cast from the AbstractRD to ImageRD, and then use ImageRD::GetImage(int iChemical).

Great I'll give that a go. 

In between updates, ImageRD pulls the data off the GPU back into the vtkImageData storage, which you can directly access by using GetValue() which calls ImageRD::GetImage(int iChemical), so there's no unnecessary copying beyond what we do anyway. (In theory we could leave the data on the GPU and render directly from there somehow I think but I don't know how to do that.)

Yeah actually are you able to provide any information on how you're rendering the meshes? I've spent some time digging around and have seen that you use vtk to generate the surface and store the mesh there. My main question is whether you keep it all on the GPU or do you copy the data back, generate the mesh, then push the mesh back to the GPU for rendering?

 

On the subject of images though: I was doing

I think you accidentally

Heh ah yeah. Not sure where I was going with that! 

[Tim Hutton]

On 19 January 2013 14:19, Scott Richmond <s.t.ri...@gmail.com> wrote:

You should only need the five VTK libs listed in the CMake file.

Unfortunately not - At least vtkImage was required, plus more. Its okay. The compiler will only link what I'm using. 

Do you mean vtkImaging.lib? Not sure why it would be needed, if we can link Ready without it. Maybe the other libs include it somehow?

You could use AbstractRD::GetValue() to retrieve individual pixels. (On image data it gives the closest pixel. On mesh data it gives the nearest cell.)

Okay yeah I saw that. That will be fine. 

If you want to access the whole image more quickly you could try a dynamic_cast from the AbstractRD to ImageRD, and then use ImageRD::GetImage(int iChemical).

Great I'll give that a go. 

You can get at the float data in a vtkImageData directly, as can be seen in ImageRD::GetValue().

In between updates, ImageRD pulls the data off the GPU back into the vtkImageData storage, which you can directly access by using GetValue() which calls ImageRD::GetImage(int iChemical), so there's no unnecessary copying beyond what we do anyway. (In theory we could leave the data on the GPU and render directly from there somehow I think but I don't know how to do that.)

Yeah actually are you able to provide any information on how you're rendering the meshes? I've spent some time digging around and have seen that you use vtk to generate the surface and store the mesh there. My main question is whether you keep it all on the GPU or do you copy the data back, generate the mesh, then push the mesh back to the GPU for rendering?

We need to pull the data back to the CPU before pushing it back out for rendering because the processing uses OpenCL and the rendering uses VTK (which uses OpenGL). In theory we can do something where we keep the data on the GPU (if the image fits) and render it in-situ with OpenGL but that's the bit I don't know how to do. I think also it would mean losing VTK.

For 2D image rendering we call ImageRD::InitializeVTKPipeline_2D(). You can see the various options inside, pulled from the render_settings. VTK works on a pipeline system - after the pipeline is created it can be pumped many times as the image data changes. Only when a render setting changes do we need to recreate the pipeline.

VTK is big and complicated, so worth learning separately if you want to.

[Tim Hutton]

On 19 January 2013 14:50, Tim Hutton <tim.h...@gmail.com> wrote:

On 19 January 2013 14:19, Scott Richmond <s.t.ri...@gmail.com> wrote:

You should only need the five VTK libs listed in the CMake file.

Unfortunately not - At least vtkImage was required, plus more. Its okay. The compiler will only link what I'm using. 

Do you mean vtkImaging.lib? Not sure why it would be needed, if we can link Ready without it. Maybe the other libs include it somehow?

You could use AbstractRD::GetValue() to retrieve individual pixels. (On image data it gives the closest pixel. On mesh data it gives the nearest cell.)

Okay yeah I saw that. That will be fine. 

Oh sorry, I've given you wrong information. GetValue() has been repurposed to sample values from the 3D scene as rendered. This is what we need internally for painting but not what you need, since there's no nice way to access a specific chemical. Best to use ImageRD::GetImage(int iChemical) instead. I'll rename GetValue() to GetValueFrom3DScene() or similar.
 

[Scott Richmond]

Ah hrm. So I'd have to pull the entire image? I'd like to get direct access to the array that holds the latest after getting back from the GPU if possible. I assume doing a GetImage will make a local copy of the array every time I call it. Could be wasteful.

[Tim Hutton]

On 19 January 2013 15:06, Scott Richmond <s.t.ri...@gmail.com> wrote:

Ah hrm. So I'd have to pull the entire image? I'd like to get direct access to the array that holds the latest after getting back from the GPU if possible. I assume doing a GetImage will make a local copy of the array every time I call it. Could be wasteful.

No, ImageRD::GetImage(int iChemical) returns a pointer, no copying.
http://code.google.com/p/reaction-diffusion/source/browse/trunk/Ready/src/readybase/ImageRD.cpp#149

(There's another function ImageRD::GetImage(vtkImageData *im) that copies the chemicals into a multi-channel image but you don't need that one.)

[Tim Hutton]

On 19 January 2013 15:15, Tim Hutton <tim.h...@gmail.com> wrote:

On 19 January 2013 15:06, Scott Richmond <s.t.ri...@gmail.com> wrote:

Ah hrm. So I'd have to pull the entire image? I'd like to get direct access to the array that holds the latest after getting back from the GPU if possible. I assume doing a GetImage will make a local copy of the array every time I call it. Could be wasteful.

No, ImageRD::GetImage(int iChemical) returns a pointer, no copying.
http://code.google.com/p/reaction-diffusion/source/browse/trunk/Ready/src/readybase/ImageRD.cpp#149

(There's another function ImageRD::GetImage(vtkImageData *im) that copies the chemicals into a multi-channel image but you don't need that one.)

Oh wait, ImageRD::GetImage(int iChemical) is protected. You'll need to subclass to use it.

Hmmm... User code accessing data isn't really a use-case we've considered, so perhaps our API needs to grow. Feel free to ask for what you need.
 

[Scott Richmond]

Well I think Ready is a really cool tool. But it probably needs to be a bit more API friendly.

If you want a big goal to start with I'd say to pull VTK out of readybase, if you can. I assume that when you pull data back from the GPU its in the form of float arrays and not any form of image array. If so then decoupling it would be best as its an unneeded requirement.

I understand that is a tall order however, given how much VTK code you have in there.

In the short-term it would be nice to be able to get as close to the data as possible.

I'd also like to see some form of event callback when new data has just been pulled from the GPU, otherwise I think I'll be blindly checking in a loop. Its a bit wasteful.

[Tim Hutton]

On 19 January 2013 15:38, Scott Richmond <s.t.ri...@gmail.com> wrote:

Well I think Ready is a really cool tool. But it probably needs to be a bit more API friendly.

If you want a big goal to start with I'd say to pull VTK out of readybase, if you can. I assume that when you pull data back from the GPU its in the form of float arrays and not any form of image array. If so then decoupling it would be best as its an unneeded requirement.

I understand that is a tall order however, given how much VTK code you have in there.

Yes, this might work. Then the rendering code and file save/load code and anything else that uses VTK could go in a separate module. One complication is the polygonal and polyhedral meshes, where the data connectivity comes from the 3D topology, which uses VTK. We'd have to make our own connectivity storage, which is a bit of a duplication of effort. There might be other obstacles too. Worth looking into though.
 

In the short-term it would be nice to be able to get as close to the data as possible.

I'd also like to see some form of event callback when new data has just been pulled from the GPU, otherwise I think I'll be blindly checking in a loop. Its a bit wasteful.

I don't think you need to keep checking. Update(n_steps) only returns when the computation has completed. If the frame rate is dropping too much then simply reduce n_steps.

(We probably should multi-thread things, to separate the worker threads and render threads. Although I don't know if this would cause problems since both want to use the GPU.)