AWS Thinkbox Discussion Forums

Questions/Suggestions for C++ API

Krakatoa Stand-alone Renderer Krakatoa SR C++ API
#1

I’m getting started integrating Krakatoa SR into Softimage and I have run into a few small issues with the current API.

  • I don’t see any way to capture the logging output and that leaves the users blind certain types of information. It also makes debugging hard since I can’t see whats going on. This is my biggest hurdle by far. There should be a callback interface for log messages so I can capture and redirect log messages to the Softimage console.
  • It would be nice to add in a render crop so I can support Quick/Region renders without having to render the whole frame anyways.
  • More detailed progressive output (buckets/fragments as threads finish etc). Right now the api only supports a full frame buffer refresh at time

Thanks,

-James

#2

I think the assumption for the C++ API is that you would be writing your own console messages tailored to your application needs. That’s what we’re doing with our Fusion plugin. We provide customized console logging as well as progress messages inside the renderer control panel.

The window or region rendering can be handled by your application directly. Just make a smaller image and transform your camera. It would be nice if we could supply or own projection matrix directly, though. Yet while it would be nice to specify a window directly, since the gathering of the particles and sorting and lighting and resorting and such has to be done each time anyway, there is very little to be saved by having a window. There is currently no caching in SR, and the splatting is pretty fast.

Krakatoa doesn’t do bucket rendering, but instead does a painter’s algorithm on depth sorted bins to different buffers. Since these buffers are done in parallel, you wouldn’t see progress unless you had a larger number of bins than active threads. Even then, you’d only get depth slices and they might not be in order. That said, we have requested access to those intermediate bins and buffers in the API because they would be useful for depth compositing.

#3

The problem I have with the console messages is that once rendering starts (renderer.render()), I have no insight into the process or feedback besides the progress_logger_interface (which doesn’t give much information except for the stage). In the examples, there is quite a bit of useful information printed to the console for even the basic examples which were all printed out from inside krakatoa (not by the client code). I think it would helpful for everyone to have api access to this information just like the log that is accessible from inside the 3dsmax integration. Even just the simple memory usage output can be very useful.

I realize I can modify the camera to transform to match the cropped view, it would just be nice to support the crop directly with a simple api call for usability. At the very least, its less memory wasted in the frame buffer (albeit not much).

-James

#4

I agree about the ease of use for the window, but as long as your render buffer is the window size, there’s no difference in memory usage.

#5

Yeah I was just saying the the crop in general will save a little bit in frame buffer memory vs a full frame render (even if it didn’t do anything for speed). However, in my testing the crop has been quite a bit faster on simple scenes and the cancel reacts quicker on the smaller frames which is important for the Quick/Region render tool in Softimage which can try to launch and stop and render quickly over and over as the user adjusts the crop box. So for my softimage integration, the crop is defiantly worth the effort.

-James

#6

Ah, I understand what you mean. Currently the output goes to the system’s standard out. That may be ignored within your application. Does your application have a way of capturing standard out?
I think the best solution is for me to add a new “message logging” interface to the API. it will be like the “progress logging” interface, but for debug output. It would default to writing to standard out, but you could direct it to a file, or use a custom handler function. Thank you for the suggestion. I will try to add that for the next release.

This is something we could add to the API if it would be useful. It would be a convenience function that would modify the camera resolution and film offsets.

As Chad mentioned, the renderer does not render in buckets. It’s output is several steps of semi-completed frames. Some scene setups work better than others to provide nice looking progress updates. I can look into how we might improve on the progressive output.

Also, thank you Chad for providing very good information!

#7

Yes, but offer two ways to do output it.
The most obvious (to me) is to just output a smaller image. So if the window goes from 100,100 to 200,150 you make your output image 100x50. But the other nice option is to actually use the EXR format’s “data window” so that the output buffer’s display window is the same size, there’s just fewer live pixels.

I was wondering when someone was going to inform you of this forum. :slight_smile:

#8

I’m currently integrating with Softimage and I don’t have any way to capture stdout generically from a C++ plugin. Even if I could, I imagine I might get other non-krakatoa output along with it. I would really love to have a message logging interface so I re-direct this output back to the softimage console or custom log for the user (just like the 3dsmax log).

A couple other quick notes:

krakatoasr::shader_schlick::use_phane_eccentricity_channel
should be
krakatoasr::shader_schlick::use_phase_eccentricity_channel
just a typo.

I’m also having an issue with the phong shader. All the other shaders work fine for me, but the phong shader is generating an all black output even with default parameters in scenes where all the other shaders produce correct output. Has anyone else had this issue?

#9

Haven’t tested it yet but do you have the Normal channel appended?

#10

Ah thanks for the suggestion. Turns out Softimage’s ICE was optimizing away my Normal channel since it wasn’t directly affecting the display of particles, so the normal channel was not getting pushed into krakatoa.

Thanks,

-James

#11

This is an excellent idea that I overlooked. I am working on a logging interface. It will be in the next release. It looks like this:

class logging_interface {
public:
	virtual ~logging_interface();
	virtual void write_log_line( const char* line, logging_level_t level ) = 0;
};
void set_global_logging_level( logging_level_t level );
void set_global_logging_interface( logging_interface* logger );

And you would be able to implement your own write_log_line function that would get all the logging messages sent to it. Does that sounds good?

All fixed! Thanks for pointing that out. I probably needed more coffee when I was writing that file :slight_smile:

#12

Perfect, that is exactly what I was looking for.

Thanks!

#13

Hi James,
In the latest build, I incorporated a few of your requests.

  • The user can now capture all log messages via a logging interface.
  • I changed the typo in “use_phane_eccentricity_channel”.

Thanks for the feedback!

See: viewtopic.php?f=166&t=9473

#14

Thanks! that is exactly what I was looking for.

-James

Privacy | Site terms | Cookie preferences