C interface

Deprecated Krakatoa SR Beta Discussion
1

A C inteface to SR is on the roadmap, but i’m not sure exactly when it will show up. I’ll let Ian jump in…

cb

2

We have written Krakatoa SR in such a way that it could have an identical C interface to the Python interface. The planned C interface would have an advantage in that you can directly input particles without the need to read a PRT file (and also meshes).

To use the C interface, you would need to write your own executable program, and link to our dll/lib. Your executable would make Renderman-Style calls to our interface to construct a scene.

Another option that I am currently debating is to add plugin-style support to the python/c interface. In this scenario, you would write a dll/lib that would implement a “get_next_particle” function that would feed Krakatoa particles one by one. To use it in Python, your plugin would then be registed/called in the python scene description file.

Which would be more/less useful? Any feedback here is very valuable to us. We are hoping to be as flexible as possible in the way people can use it.

3

Hi Conrad,

I may have misunderstood the intent of the Scene Description Language and the corresponding API so I will explain what I understand and you can correct me, I will use RenderMan as a comparison

RenderMan

(1) lib3delight.so [using the 3delight library on Linux as an example]
(2) We can write C/C++ using the library to either a renderer/procedural-dso OR an external file (*.rib)
(3) No standard python binding (except from Pixar recently) but there are projects like code.google.com/p/ribclients/ [self plug]

Krakatoa SR 2

(1) KrakatoaSR.so
(2) Unsure what the scene file extension is (.kkt ?), or is the scene description the python code
(2.1) For complex production scene, it is usually useful to break up a scene into reusable/shareable parts so that we can tweak on going farm jobs without regenerating massive scenes, without a generated scene file, it may be harder to tweak.
(3) Does it make sense to have an external scene file because KrakatoaSR will consume the instruction to produce an image without an external scene description file
(4) Is there an API (C/C++) for writing out the *.prt file and corresponding viewer (which is discussed in a separate post)
(5) I believe you are leveraging BoostPython for the binding generations so I suppose keeping things in sync should be straight forward.

Regards

4

Krakatoa SR scene description:
Krakatoa SR is not a RenderMan renderer, but it does use a similar style to define scene descriptions. We don’t have a scene file type. The user interacts with the renderer by making Python calls. So you are right, the scene description is a Python script. Yes, we are currently using Boost Python (although we may stop using it since it adds an additional dependency). You could definitely break up your Python file into reusable/sharable parts. To do so, you would need to use Python’s way of importing functions from separate .py files, which would be a little different than if you were using a RenderMan renderer. Additionally, the scene assets (particle and mesh files) are already separate from the Python scene description, so that is another way that scenes are separated out into parts.

Specifying particles:
Getting particles directly into Krakatoa can currently only be done with .PRT files. These files can be created using PRTTranslator (3rd party Maya plugin), H2K (3rd party Houdini plugin) or using Krakatoa MX (3ds max plugin). It is possible to write your own .PRT files since PRT is an open format. We will soon be providing sample C++ code that you can use as a template for programs that write PRT files. Once you have a PRT file, it can be referenced in the Python scene description like this:

ri.PointsFile( "myfile.prt" ) #python code

Krakatoa SR planned C/C++ plugin support:
This is planned as an alternative to writing out PRT files. We plan on having a way for the user to provide particles directly to the renderer when constructing a scene description in Python. This plugin support would be somewhat analogous to procedural DSOs in RenderMan. The following example is for particles, but we could also provide support for meshes. The planned plugin support would allow the user to specify particles in the Python scene description and look something like this:

ri.PointsProcedural( "myplugin", "float param1", val1, "float param2", val2 ) #python code

And your c++ .so/.dll code may look something like this:

extern "c" {
void myplugin_INIT( void** userData, float param1, float param2 ) {
   //...
}
void myplugin_GETPARTICLE( void** userData, particle_buffer& outParticle ) {
  //set outParticle
}
}

Krakatoa SR planned C library:
Used to interact with Krakatoa without the use of Python. This would be primarily used for writing an actual plugin within a 3d modeling program such as Maya (as apposed to the current scene “exporter” for Maya). It would be somewhat analogous to linking to lib3delight.so directly. In an extremely simple case, this would be a use of the C library to produce a render (although it would also have a way of providing particles without external PRT files):

int main( int, char* ) {
   //...
   WorldBegin();
   PointsFile( "myfile.prt" );
   WorldEnd();
   return 0;
}
5

A C/C++ api to read/write PRT file would be most welcome.

It would be useful for you folks to use that library too so everyone (yourself and your customers) are on the same page and progress together in the Krakatoa ecosystem.

What is the ETA ? I am starting to write a PRT viewer using the PRT reading component from the M2K project ?

I know you folks have many competing requests :slight_smile:

Regards

6

This is currently a little lower on our priority list, but we plan on having it completed for the first release. I have started working on the C library (not the plugin architecture) so that will probably be completed first.

7

No worries.

Just let me know when the C-library is ready for testing.

I will put my Houdini ROP_Krakatoa development on hold for now.

Regards

8

The C/C++ interface to directly input particles will be great, Definitely looking forward to that, in addition this would allow us to load theoretically ANY particle/point data into krakatoa, which would be the best scenario.

I’ve been talking briefly with the thinkbox guys about this already, but I’ve done a little work in the last month in
getting all the formats I can, working in disney’s Partio, This or something akin to this in my opinion is where we need to be headed.
Ultimately we’d love to see one format (like alembic is becoming for geo cache) or at least a library to read all formats to allow one point of entry/exit for particle data into and out of any package including Krakatoa.

my 2 cents…

-johnc
redpawfx