I have tested out your scene, and it seems to be behaving the way I would expect. I’m not entirely certain what the issue is. Can you provide more information?
One thing to note is: It is not a very good idea to use integer channels for Krakatoa streams. You can do it, but I don’t think it will behave the way you expect.
So, for a “Color” channel, Krakatoa expects values between zero and one. You can go over one if you want, but it would not generally be normal.
So, When you use a uint8 for the color, it will be straight-converted to a float. Therefore, integer values of 0-255 will convert to float values of 0.0 to 255.0, and thus, you will probably completely wash out all the colors. Using exr output images will let you see that a little easier.
In general, you would only ever use float channels in your particle stream. If your input channels are integers, you’d likely want to define the stream as a float, then convert the int values to float during the get_particle function.
I couldn’t get any difference when I changed the ordering of the channels. Is there a way to reproduce what you’re seeing?
That’s unfortunate. Why wouldn’t you convert it 0-255 uint as 0.0-1.0 float? I suspect that would be the expected behaviour for almost anyone. I know we can convert ourselves before passing to Krakatoa, but even so using uint8 vs float16 would save us 50% of the memory used for channels that may not need it (like color, absorption, emission, etc), and saving memory means we can cram more particles into our renders.
I understand issue. It is a technical implementation detail. Our datatype conversion functions are used everywhere (not just Krakatoa), so converting an integer into float in general should not scale from [0 to maxint] into [0.0 to 1.0].
However, it does make logical sense to do it for the case of Color. I might consider having an implicit scaling conversion in KSR to avoid this problem the next time someone uses integer channels.
I tested it here, and it does appear to work for me. What version of the API are you using? There was a “channelop_set_vector” bug that was fixed on the November 14th build, so if you have an earlier one, this function may still be broken.
If you are using the latest version, and the bug is still happening, can you send me a test-scene?
Or you could make it explicit and just have us define which conversion to use per channel. If undefined, use the existing behaviour.
Also, when does this conversion take place? If it’s done early in the pipeline, there’s no real savings from using uint8 values. But if it’s done right before the particle is shaded/splatted, then it could save memory.
EDIT: Actually, what’s the use case for doing the straight conversion? I can’t think of any channel where you’d want a range of 0.0-255.0 clamped float anyway. Why not just do the normalized conversion for all int channels implicitly?
EDIT: Ben pointed out that some channels COULD make sense as a straight conversion, like MatID or ObjID or SmoothingGroup. So if explicit conversion was plausible, that would be best.
Sven, While this seems to be a bug, currently Krakatoa is not designed to support integer channels for Color. You will need to use FLOAT16 for your color channel.
EDIT: I understand this also happens when using FLOAT16 channels. I’ll keep looking.
I try to render maya fluids with krakatoa. To do so I try to place particles in the fluid and get density and color attributes.
My question is:
In the particleStream I define a
krakatoasr::INT64 m_particleCount;
which contains the number of expected particles. But unfortunatly I don’t know the exact number of particles because I’d like to create particles only on places where the density is greather than zero. Is there any way to handle this case or do I simply have to create particles everywhere and set the density to 0.0 if the fluid voxel is empty? This would waste a large amount of memory in some cases.
First off, I totally want to support Maya fluids! I have yet to look at how to do it, but we want to support it eventually.
What you’re asking for is doable. If you are implementing your own stream, just return -1 for the particle count.
From the API:
/**
* Defines how many particles this stream will provide. See example usage.
* @return The number of particles in the stream, or -1 if unknown.
*/
virtual INT64 particle_count() const = 0;
In the “-1” case, Krakatoa will continue to draw particles from the stream until “get_next_particle” returns false.
You can see that I have a cube on the left side. If I render the scene I get this:
Now if I add a screen_offset() I would expect that on the left side everything stays black because all particles are completly covered by the polycube and the image should move a bit to the right side.
What I get is:
As you can see on the very left side, we have an area where we see particles where they should be covered by the box. This is exactly the area of the horizontal screen offset. So it seems that the mesh is not taken into account in this area any more.
Sometimes we’d like to use negative values in colors, e.g. for a nuke lighting pass with the velocity of particles.
It seems that if the values of the colors becore negative, the density is autmatically set to 0.0 what means that these particles disappear from rendering.
We can render negative colors OK here with SR in Fusion. Also works with MX. So a set of particles with color of -6,-.5,-1 but density of 1 returns a very dark blue-green cloud.
The particles aren’t supposed to disappear with negative color. I believe they should appear as negative RGB values in the exr image. The particle’s “Color” channel should never effect the “Density”. Can you give me more information as to what is happening?
HI Conrad,
I tried using the enable_occluded_rgba_render API on the renderer. I passed in a mesh object as a part of the scene and the object occludes some of the particles.
This is gets rendered correctly (i.e. the particles correctly get occluded by the mesh). But when I enable this option I’m expecting the particle to get rendered, but
I don’t see any difference in the output. This happens in a very simple scene.
Am I missing something. Is this feature available in the current build. thanks
