Arrrggghhh… sorry. Framebuffer works great, it was my fault. Everytime I forget that maya uses a value range of 0.0 - 255.0 instead of 0.0-1.0. Everything works fine with framebuffer update now.
How can I control the radius per particle? Adding a new channel in the particle stream and calling it “Radius” seems not to be the solution?
Seems that the voxel render method is not working correctly. I get a crash if I implement it into my plugin or in your posted standalone example with adding this line:
krakRenderer.set_rendering_method( krakatoasr::METHOD_VOXEL);If you want to have a look at the current implementation, I have created two small screen captures.
and
I added a simple method to render the vertices of a mesh object as particles.
In my renderings, I cannot see any difference if I set the densityPerParticle to 0.1 or 1234456.0. Is this correct?
edit: Depth Of Field works as well now, it’s really fun working with such a efficient interface 
Just a quick note that Krakatoa does not support point lights in Voxel mode (this is true for both Krakatoa SR and Krakatoa MX). Since the original example was posted with a point light, it could be the cause of the problem…
Indeed, the example works with a directional light. I’ll try this in my plugin.
edit: Tried it, but there seems to be still something strange in my scene. It starts working and I see several passes, but then the rendering crashes. I’ll try to find out what’s the reason.
edit: Found the problem, seems that the voxel renderer doesnt like my depth of field settings.
Please post what the settings were so we can make sure it does not crash with them.
I used these settings:
if( this->renderGlobals->doDof)
{
this->enable_depth_of_field( true );
float fStop = 3.0f;
getFloat(MString("fStop"), camFn, fStop);
float focusDistance = 10.0f;
getFloat(MString("focusDistance"), camFn, focusDistance);
this->set_depth_of_field( fStop, focalLength, focusDistance, this->renderGlobals->mtk_DofParticleSamplingRate );
}
fStop and focusDistance are taken from the real camera but they were very similiar.
I’m not sure what the issue is here without some more info. Is Krakatoa throwing an error? What is the error message you are getting?
To see the error messages from Krakatoa, you have to catch std::exception, which should make debugging easier. For example, when using point lights in voxel mode, you would have gotten this error message:
“Krakatoa does not support point lights in voxel rendering mode. Please disable light: [lightname]”
You can catch and print the errors by using:
try {
krakatoasr::krakatoa_renderer r;
//...some settings for r
r.render();
} catch( std::exception& e ) {
std::cout << e.what() << "\n"; //e.what() contains the error message string
}Well, I already enclosed the renderer with a try/except function, but I didn’t get any output. Maybe it has something to do with the maya environement. I’ll try again and keep you informed.
Just tried the new version of the API and got a few errors.
In the header file there still exists the
set_output_image_file() method what is not valid any more. But the lib has no method like this any more. The new methods you mention,
multi_channel_exr_file_saver fileSaver( "myfile.exr" );
r.set_render_save_callback( &fileSaver );
cannot be fined in the header file. And the headers seem to be very similiar, maybe the new one is still the old one?
haggi
My mistake… I forgot to update the header file in the install package. Thank you for pointing this out.
I have attached the correct header file here. Just replace the header file with this file. Also, I have updated the download in the builds section.
KrakatoaSR.hpp (57.4 KB)
Obviously the Magmaflow UI is way outside of the scope of SR, but if it were possible to just construct the Magmaflow operations in SR using the UI of the host application or of our own design, is that something that we could expect?
Imagine if a KMX user could make a .MagmaScript and then point the python KSR to it. If we wanted something less Maxscript-y, maybe add an alternative export to KMX’s Magmaflow editor? The idea is that anyone could author Magmaflow notation in KMX or anywhere else and know that it would work in ANY Krakatoa implementation that supported loading of Magmaflows via the API.
There’s reasons we want to manage the particlestreams ourselves so we can add our own operators, but I can see a lot of uses for having KSR do all of the manipulations internally if you want to leverage the existing Magmaflow tools.
We have discussed how we would do channel operations in SR (like what is possible in Magma). One way we were thinking was to use “nodes” and “connections” objects just like you would visually use in a UI. The other way we were thinking would be expression based (which is what I prefer personally). Something like this:
//NOTE: THIS IS NOT CURRENTLY IMPLEMENTED IN KRAKATOA SR
//create an expression to covert color channel to grey scale
std::string expression = "Channel('Color').r = Channel('Color').g = Channel('Color').b = ( Channel('Color').r + Channel('Color').g + Channel('Color').b ) / 3";
//add channel mod expression to input particle stream
krakatoasr::add_expression_to_particle_stream( mystream, expression );Alternately, since the user has complete control over the particles being fed into Krakatoa, you could write your own way of feeding in particles capable of “Magma” like things. You’d have to write code to do so though. So, it would be nice to have some easier way of doing it built directly in to the API.
Doing this kind of thing is on the road map, but is not planned for the first release.
HI, I’ve downloaded the latest C++ dll/header and am trying to use it on x64 inside Visual Studio. Currently, the renderer crashes just when I call ‘render’. I doesn’t throw an std::exception since I’m catching it and also have a ‘catchall’.
I feel like it might have something to do with the vc++ compiler version. The software I’m using it with is built against vs2005 (v80 toolset).Is it possible to build a version with v80 an upload the .lib and .dll.
I’m able to use the python version correctly, since I launch it as a separate executable from my tool.
Here’s my code where it crashes:
/* --------- Render the scene ----------*/
try{
krenderer.render();
}
catch(std::exception& ex){
DocPtr->PrintF(ECONID_Log, "CAUGHT EXCEPTION WHEN RENDERING = %s", ex.what());
string errstr = "Unable to render krakatoa scene";
errstr += ex.what();
throw FuException3D(errstr.c_str());
}
catch(...){
DocPtr->PrintF(ECONID_Log, "CAUGHT EXCEPTION WHEN RENDERING ");
throw FuException3D("CAUGHT EXCEPTION WHEN RENDERING ");
}
The FuException3D is caught later in the code. But it never reaches that point. If I comment out the krenderer.render(), all is good (no output ofcourse, but no crash either). All other calls on krenderer seems fine.
Let me know if there’s something else I’m missing out.
thanks
I was thinking more from the standpoint that you already have done the work for the Magmaflow processing, and you can provide a uniform execution of that data. Meaning, someone in 3ds max could have a VecNoise or Curve node and know that if they used the same settings in an SR application, they’d get the exact same results without having to actually make an exactly matching VecNoise or Curve operator.
Of course my logic falls down somewhat when you consider that things like Curve or MeshQuery may be relying on things from the 3ds max SDK. If they are NOT, then we’re in excellent shape. But if they are, then most of the “hard” stuff would have to be re-done anyway. Reimplementing arithmatic, trig, logic, matrix transforms, etc would be pretty easy to do for making your own “Magma like things”. It’s things like the Object and Input nodes that would harder to implement and more likely to require stuff that’s outside of Krakatoa’s domain anyway. Oh well.
The expression string though sounds excellent. I’d actually REALLY like it if we had such a node in Magmaflow. Some operations are really simple to type but would require a pretty complex visual programming setup.
Compiling and rendering in VS2010 was no problem with the new release here.
arun, I’m thinking that using the vc80 toolset shouldn’t be a problem. I will test it here locally to see if it works.
Does this really simple case crash for you using the vc80 toolset:
try {
krakatoasr::krakatoa_renderer r;
r.render();
} catch( std::exception& e ) {
std::cout << e.what() << std::endl;
}Actually I just figured out the reason for the crash. It had nothing to do with compiler version. Sorry about confusion. I was setting the pointers for the saver from a local variable like so:
void set_saver(krakatoasr::krakatoa_renderer& krenderer){
krakatoasr::file_saver fileSaver(outputfile.c_str());
krenderer.set_render_save_callback(&fileSaver);
}
main(){
krakatoasr::krakatoa_renderer krenderer;
set_saver(krenderer);
krenderer.render(); //crash
}I’ve changed this code to use malloced values, which works. Still getting blank images for some reason as output, but I think that’s probably some input being wrong.
I know it was a stupid error, but a boost::shared_ptr version of this API will help get rid of pointer crashes like this a lot for users. Just something to consider for future 
I would like to use shared_ptr, however it was very important to me that the API not have any dependencies (such as Boost). It doesn’t even use anything in the std namespace, or expose any non-primitive data types (this avoids conflicting toolset issues, etc.). As a result, the API is kind of “C”-like.