Channels reserved for Krakatoa (or future SR products?)

Is there (or can there be) a list of channels used by KSR? We’d like to know so we don’t start using those channels for our own tools but in a different way.

We know about the shader ones, and there are the common ones like Emission, Absorption, etc., but is there a comprehensive (enumerated even?) list with descriptions and ranges that we can reference?

This would also apply to other SR products, too, if those channels are known.

Yeah I second that. I would love know exactly which channels the krakatoa renderer will actually use so I know what channels to pass in from ICE. I don’t see this in the documentation anywhere.

[code]Name, Arity, Notes
“Position”, 3, Provides the world-space position of the particle. Always allocated.
“Color”, 3, Defines the scatter color of the particle. Always allocated.
“Density”, 1, Defines the density contribution of the particle to a unit cubic volume. Always allocated.
“Emission”, 3, Defines the incandescence (self-illumination) color of the particle. Allocated if Use Emission is on.
“Absorption”, 3, Defines the absorption of the particle. Allocated if Use Absorption in on.
“Lighting”, 3, Internal, accumulates the direct particle illumination. Allocated unless lighting is turned off or Force Additive Mode is on.
“Velocity”, 3, Provides the speed of the particle for Motion Blur interpolation. Allocated only if MBlur is on.
“MBlurTime”, 1, Provides the particle time. Allocated only if MBlur AND Jittered MBlur are on.

“Normal”, 3, Defines the normal vector of the particle. Allocated if Phong Surface shading is requested.
“Tangent”, 3, Defines the tangent vector of the particle. Allocated if Marschner Hair shading is requested.
“SpecularPower”, 1, Optional per-particle Specular Power value that can be used when in Phong Surface shading mode.
“SpecularLevel”, 1, Optional per-particle Specular Level value that can be used when in Phong Surface shading mode.

“Eccentricity”, 1, Optional per-particle Eccentricity value that can be used when in H-G or Schlick shading mode.

Optional per-particle values that can be used when in Marschner Hair shading mode:
“SpecularGlossiness”, 1,
“SpecularShift”, 1
“Specular2Level”, 1
“Specular2Glossiness”, 1
“Specular2Shift”, 1
“GlintLevel”, 1
“GlintSize”, 1
“GlintGlossiness”, 1
“DiffuseLevel”, 1[/code]

Thank you. Is there a place where we can always find an up to date list, or should we just make this post (or a new topic with just the list) sticky?

Is MBlurTime internal? The corollary of that, is it possible to input Lighting (since it’s additive)?

Are there any channels that we should otherwise reserve (by convention) that aren’t used by the actual rendering process? I’m thinking ID or Age or whatnot. Things that we might want to respect for the sake of interchange, so that 3ds max writes a PRT file that has matching channels to one written from Houdini so that we can render both PRT’s together in Fusion?

That was just a quick extraction from the KMX list I used for UI update purposes. I wrote the notes myself, so they are probably not very complete, but the list itself should be good.
I suspect Conrad will add a better list to the docs in the near future…

It is. Krakatoa uses it to keep track of the sub-frame sampling of the particle. So it gets allocated when you enable Jittered mode, but it is populated internally.
I believe you cannot input Lighting, but I could be wrong. That’s why we implemented the baking of lighting via Emission in KMX. But I will let the developers answer that in detail. It is possible that you can, but you shouldn’t :wink:

The KMX UI lists a whole bunch of other channels that are not directly used by the renderer. We also map most Maya channels to Krakatoa channels in KMY, so covering all Max, Maya, Houdini. ICE etc. channels would be a huge effort. You can see the Max-related ones in the Channels rollout of KMX - they include all mapping channels, various channels that can be requested by render elements and so on.

In the C++ api docs, the shaders reference the eccentricity channel as being called: “Eccentricity”. Given your post above it should be “PhaseEccentricity” correct? Might want to update the C++ docs if that is the case.

-James

Thanks, we will have to figure out which one is correct first :slight_smile:

I’m not suggesting we do all of the possible channels, especially since with SR we can how have any application utilizing it’s own channels. For example, we don’t really care about how MXSFloat gets used in XSI (though maybe some curious XSI user might like to know what the MXSFloat channel in the PRT’s they imported are from).

I’m just thinking that if there’s anything currently common between KMX and KMY we should respect that and collectively define anything else. I’m thinking that now is the time, as no one has locked down on a convention yet, to agree among the developers here as to what we should expect for interchange. It would seem to me that we should agree on really common stuff, like what we call UVW mapping channels. Considering that 99.99% of existing PRT files were generated in KMX, there’s an incentive to use those channel names whenever applicable. From the UI side though, the host application can present more appropriate names for the channels. Like if we stuck with “TextureCoord” and “Mapping2” then I could, in Fusion, read in a PRT written from XSI and put a texture on the particles, even though neither Fusion nor XSI use the terms “TextureCoord” or “Mapping2” internally or in their UI’s.

As KMX DOES use “Eccentricity” (range [-1,1] I think), if we’re already confusing that with “PhaseEccentricity” already, now is probably the time to back up a bit and reconsider. :wink:

KMX does use “Eccentricity”.
It was a bug in the KMX UI code which listed it as PhaseEccentricity in the Channels rollout. I am fixing the bug, and have updated the list above to reflect that.

Privacy | Site terms | Cookie preferences