Cache? PRT Output?

[Chad]

Are there any plans to add some sort of caching (like PCache or LCache) to SR so that we can load up our PRT’s, lights, camera, matte objects, etc., render, realize the voxel size is too big, modify that option, then re-render without having to load the PRT’s again?

Also, what about saving out PRT’s? Could we load 10 OBJ’s, fill them with points, light the points, and save out a PRT with Position, Density, and Emission?

• Chad

[Bobo]

@Chad

Are there any plans to add some sort of caching (like PCache or LCache) to SR so that we can load up our PRT’s, lights, camera, matte objects, etc., render, realize the voxel size is too big, modify that option, then re-render without having to load the PRT’s again?

I have wished for it. My impression was that the current implementation via the Python interface would not allow for that.
We would have to keep the RENDERER in memory in order to keep the particles in memory.
So the C interface might be a solution here, if the KSR DLL is loaded and the renderer is not released by the program calling it, it could keep PCache and LCache in memory, too.
So it is on the wish list, but is a bit tricky.

@Chad

Also, what about saving out PRT’s? Could we load 10 OBJ’s, fill them with points, light the points, and save out a PRT with Position, Density, and Emission?

We feel this might happen before the end of the week. It is pretty high on the list and shouldn’t be too difficult to implement. Stay tuned.

[Chad]

So what’s the timetable for a C++ renderer? In our application, we’d certainly find that more useful than python. Especially if we don’t need to do the I/O of PRT writing/reading and EXR writing/reading and can just move the data in memory. For the time being, we’re just writing out python as a string from our application, so we’re not really using python for anything.

[cbond]

Chad,

Bobo can speak to specifics after discussing with Conrad/Ian, but it’s high on our list.

chris bond

[Conrad_Wiebe]

@Chad

Are there any plans to add some sort of caching (like PCache or LCache) to SR so that we can load up our PRT’s, lights, camera, matte objects, etc., render, realize the voxel size is too big, modify that option, then re-render without having to load the PRT’s again?

Bobo is correct. once Python exits, the cache is gone. Here is my plan for the Python interface (it is not yet implemented). I will include RenderMan-style ObjectBegin and ObjectEnd calls which you can wrap particles inside, then reference them for future frames (within the same file). The only downside is that once the program execution finishes, this memory is gone. For example, I know this will probably not be of much use to you, but this is how caching would work using the Python interface:

import KrakatoaSR
ri = KrakatoaSR.Ri()

### cache particle set ###
ri.ObjectBegin( "myparticles" )
ri.PointsFile( "myprtfile.prt" )
ri.ObjectEnd()

### frame 0 begin ###
ri.FrameBegin( 0 )
ri.Display( "frame_0000.exr", "file", "rgba" )
ri.WorldBegin()
#...
ri.ObjectInstance( "myparticles" ) # read cache
ri.WorldEnd()
ri.FrameEnd()

### frame 1 begin ###
ri.FrameBegin( 1 )
ri.Display( "frame_0001.exr", "file", "rgba" )
ri.WorldBegin()
#...
ri.ObjectInstance( "myparticles" ) # read cache
ri.WorldEnd()
ri.FrameEnd()

### ...

As Bobo mentioned, we are planning a c-interface .dll/.so that will contain the exact same exposure that the Python interface does. It was discussed a little bit on this thread. If you wanted to write your own application that simply linked to our .dll/.so you could do so. In that case, as long as you don’t unload the .dll/.so, you will have access to saved particles wrapped in ObjectBegin/ObjectEnd calls. We plan on releasing the C interface before the Beta is finished. Would this C interface be very useful for you? If you had a C interface, how would your workflow ideally go?

@Chad

Also, what about saving out PRT’s? Could we load 10 OBJ’s, fill them with points, light the points, and save out a PRT with Position, Density, and Emission?

• Chad

Yes, this is the plan. I plan on having a output type of “particles”. If this is high priority for you, we can also make it a high priority. It would look like this in the python interface:

ri.Display( "image.exr", "file", "rgba" ) #for image output
ri.Display( "particles.prt", "file", "points" ) #for particle output

[Chad]

@Conrad Wiebe

Yes, this is the plan. I plan on having a output type of “particles”. If this is high priority for you, we can also make it a high priority. It would look like this in the python

No, it isn’t, but I can see how this would be very helpful. We often need to reduce channels because of memory limitations, so SR could help us in those tight situations. But we don’t immediately need it now.

[anon58450692]

You can start an interactive Python session so that particles cached via ObjectBegin/ObjectEnd don’t die after the frame finishes rendering. You could tweak stuff and render the frame again without closing the python interpreter. Those cached objects will last as long as the python process, which is no different from any caching system other than writing PRT files.

[Conrad_Wiebe]

Darcy brings up a good point, if you put your “World” definition as a function in separate file, you could run an interactive session and continually tweak/re-import the scene file. Although I haven’t tried any of it, so it may or may not work the way I think, but a little knowledge of Python would let you do a bunch of things.