Krakatoa SR Python Scene Description Format

[size=200]Krakatoa SR Python Scene Description Format[/size]

Started: 2011/10/10
Edited: 2012/12/05
WORK IN PROGRESS

The following document describes the current implementation of the KrakatoaSR scene format.
It is Work In Progress and will be updated often as features are added and modified.

import KrakatoaSR

Imports the KrakatoaSR module.
This line is mandatory.

ri = KrakatoaSR.Ri()

Creates a Render Interface instance.
This line is mandatory. The variable can have an arbitrary name, but this documentation assumes the name “ri”.

[size=150]Render Options[/size]
The following are all currently supported parameters.
They are all optional parameters unless explicitly specified otherwise.
Their defaults match the factory defaults of Krakatoa MX.

ri.Option( "render", "BackgroundColor", (0,0,0) )

Defines the background color as an RGB value where components are in the range from 0.0 and 1.0.
When not specified, defaults to black (0,0,0)

ri.Option( "render", "DensityPerParticle", 5, "DensityExponent", -1 )

Defines the Density Per Particle value and the Density Exponent value. This is a scale applied to the Density of all particles to be rendered. By default, it affects both the Lighting Pass and the Final Pass drawing of particles, unless the “LightingDensityPerParticle” option is also provided (see further below).
The two values together comprise the final value, for example 5.0 and -1 produce a value of 5.0*10^-1= 0.5. Increasing or decreasing the Exponent only lets you modify the Density Per Particle value by an order of magnitude, e.g. 5.0 and -2 produces 0.05, 5.0 and -6 produces 0.000005, 5 and 2 produces 500.0 and so on.

ri.Option( "render", "LightingDensityPerParticle", 5, "LightingDensityExponent", -1 )  

Defines the Lighting Pass Density Per Particle value and the Lighting Pass Density Exponent value.
If this option is not set, the “DensityPerParticle” and “DensityExponent” values will be used for the Lighting Pass, too.
For details on specifying the value using the two properties, see the previous paragraph.

ri.Option( "render", "UseEmissionColor", False )

When specified and set to True, allows the particles to emit light according to their Emission channel.
When not specified or set to False, the particles will only scatter incoming color from lights but won’t emit light on their own.
Note that in the current version of Krakatoa, the Emission does not illuminate neighbor particles yet.

ri.Option( "render", "EmissionStrength", 1, "EmissionStrengthExponent", 0 )   

Controls the Emission Strength when “UseEmissionColor” is set to True.
If not set, the “DensityPerParticle” property will be used instead.

ri.Option( "render", "RenderingMethod", "particle" )  

Controls the rendering method used by Krakatoa to convert the particle data to final pixels in the output image.
Supported options are “particle” and “voxel”.

ri.Option( "render", "VoxelSize", 0.5 )

Defines the Voxel Size in system units used when the “RenderingMethod” is set to “voxel”.
Lower values produce more detailed results at cost of performance.

ri.Option( "render", "VoxelFilterRadius", 1 )

Defines the Voxel Filter Radius in number of neighbor voxels to filter over.
Higher values produce smoother filtering at cost of performance.

ri.Option( "render", "AttenuationLookupFilter", "Bicubic" )

Defines the pixel filter when drawing the attenuation map.
Possible values are “Nearest”, “Bilinear”, “Bicubic” (default), and “Bilinear#” (where # is an integer value representing the radius of the filter).

ri.Option( "render", "DrawPointFilter", "Bilinear" )

Defines the pixel filter when drawing the final image.
Possible values are “Nearest”, “Bilinear” (default) and “Bicubic”.

ri.Option( "render", "AdditiveMode", False )

Forces Additive rendering with no Alpha by setting internally the Emission Color to the Scatter Color and the Scatter and Absorption colors to black (0,0,0).

ri.Option( "render", "MotionBlurParticleSegments", 2 )

When specified and the parameter is greater than 1, produces particle motion blur using the given number of samples.
When not specified or set to 1, produces a single pass (no Motion Blur effect).

ri.Option( "render", "MotionBlurJitterParticles", False )

When specified and set to True, enables the random jitter of particle positions along the velocity vector.
When not specified or set to False, each particle sample will be drawn at the same offset along the velocity vector according to the sub-frame interval being evaluated.

ri.Option( "render", "MatteRendererRayDivisions", 1 )

Originally, the option controlled the number of rays to shoot at the particle to determine its visibility when partially occluded. Since the switch to a rasterizer, this value controls mainly the the resolution scale factor of the depth map using for the Matte. Thus a value of 2 produces 2x2 pixels in the depth map corresponding to a single particle. A raytrace method is still available in Krakatoa for matting using Spherical cameras, but this is a special case and currently not used in Krakatoa SR.

ri.Option( "render", "SaveMultipleLayers", False )

This option should control the splitting of the final image output into a foreground and background layer.
It is not hooked up in Krakatoa SR yet (as of Beta 1).

ri.Option( "geometry", "GeometryVisibleToLights", True )

Specifies whether or not the matte geometry defined within the same scope as this is option will be visible to the lights. If it is set to false, the geometry will not cast shadows on scene particles.

ri.Option( "geometry", "GeometryVisibleToCamera", True )

Specifies whether or not the matte geometry defined within the same scope as this is option will be visible to the camera. If it is set to false, the particles will not be occluded by the geometry.

ri.DepthOfField( 2.0, 0.708661417, 100.0 )

When specified, a Depth Of Field camera effect will be calculated by spreading multiple samples of each particle in the circle of confusion. When not specified, no Depth Of Field will be calculated for the camera.
The first argument is the f-stop value
The second argument is the focal length in system units.
The third argument is the focal distance in system units.

ri.Option( "render", "DepthOfFieldSampleRate", 0.1 )

This property controls the quality of the Depth Of Field effect. It determines the number of samples to draw per particle. The higher the number, the higher the sample rate and the effect’s quality at cost of render time. The default is 0.1.

ri.Clipping( newClipping, farClipping )

Specifies the near and far clipping planes for the camera.

ri.Option( "render", "DeepMatteLoadingPath", "holdout_matte_input.dtex" )

This call specifies the DTEX or DSM holdout matte render. The holdout matte is a deep image rendered using a geometry renderer (such as RenderMan or 3Delight) from the perspective of the camera. Importing a holdout matte render, in combination with importing deep shadow maps for each light, can be used in place of importing mesh geometry. To load a DTEX file, the user will need to specify a path to a file loading library (see “SetDtexLibraryPath” ).

ri.ChannelOperation( "Set", ChannelNameString, ChannelValue )
ri.ChannelOperation( "Multiply", ChannelNameString, FloatValue )
ri.ChannelOperation( "Copy", DestinationChannelNameString, SourceChannelNameString )

The above are the three basic ChannelOperation type that allows the user to modify the input particles. These calls are scope-dependent so normally the user would place these prior to adding particles within AttributeBegin and AttributeEnd calls. These are useful for overriding values, modifying existing values, and copying/renaming channels.

ri.FrameBegin( 1 )

Sets the beginning of the current frame.
The argument specifies the frame to render.
It must be paired with a ri.FrameEnd() at the end of the time context.

ri.Format( 640, 480, 1 )

Set up the rendered image resolution and pixel aspect ratio.

ri.Display( "render_output.jpg", "file", "rgba" )  

Defines the output file name and type of the main rbga image pass.
“rbg” is also accepted and is the same as “rgba”, except for setting the alpha of all pixels to 1.0.

ri.Display( "+normal_pass.exr", "file", "N" ) 

Specifies a normal pass.
Normal passes output an RGB image with normals ranging from -1 to 1 (not 0 to 1 like max krakatoa). it’s done this way because that’s how renderman does it.
Currently the “Filtering” option that is in 3dsmax is hard-coded to TRUE in SR. this could be changed if need be.
NOTE: the “+” is needed in the filename after subsequent calls to ri.Display or else it will override the previous ri.Display calls (as per the renderman spec).

ri.Display( "+zdepth_pass.exr", "file", "z" )

Specify z-depth pass.

ri.Display( "+velocity_pass.exr", "file", "Velocity" )

Specify a Velocity pass.
NOTE that in Renderman, we don’t have a framerate, so the values that come out of this are in UNITS per SECOND (not units per frame like in Krakatoa MX)

ri.Display( "+output_particles.prt", "file", "points", "LightParticles", True )

Adds a PRT file output. This saves out all the transformed and combined particles after processing to a PRT file. If “LightParticles” is set to True, then it will also compute all the lighting for the particles and include that channel in the output PRT data. The particles will also be in sorted order based on distance to the viewing plane. “LightParticles” is true by default.

ri.Shutter( -0.00833333, 0.00833333 )

Shutter begin and end time offset in seconds.
The above values represent 180 degree shutter at 30 fps.

ri.Projection( "perspective", "fov", 90 )  

Set the Projection type to either “perspective” or “orthographic”, and the Field Of View in degrees.
After ri.Projection, the current transform is reset to the identity, and you can work in camera space. prior to this, we were in screen space. Note that only x and y translations (film offset) are allowed in screen-space.

ri.Transform( 1,0,0,0,  0,1,0,0,  0,0,-1,0,  0,0,0,1 )

Specify the camera to world transformation matrix.
Krakatoa SR uses the same left-handed world coordinate system as Renderman - when the camera to world transform is the identity matrix, you are looking down the positive Z axis. In Maya and 3ds Max on the other hand, when the camera to world transform is the identity matrix, you are looking down the negative Z axis. To export a camera from Maya or 3ds Max, get the inverse of the camera transform and output it with the Z axis flipped.
In 3ds Max, this amounts to

local theTM =  getViewTM()
theTM *= matrix3 [1,0,0] [0,1,0] [0,0,-1] [0,0,0]

In Maya, you can use

float $theTM[] = eval ("getAttr " + $transform + ".worldInverseMatrix"); fprint $fileId ("ri.Transform(\n\t"+$theTM[0]+","+$theTM[1]+","+(-$theTM[2])+","+$theTM[3]+",\n\t"+$theTM[4]+","+$theTM[5]+","+(-$theTM[6])+","+$theTM[7]+",\n\t"+$theTM[8]+","+$theTM[9]+","+(-$theTM[10])+","+$theTM[11]+",\n\t"+$theTM[12]+","+$theTM[13]+","+(-$theTM[14])+","+$theTM[15]+"\n)\n");
where $transform is the Transform node of the camera.

ri.MotionBegin(
	-0.00833333,
	-0.00648148,
	-0.00462963,
	-0.00277778,
	-0.000925926,
	0.000925926,
	0.00277778,
	0.00462963,
	0.00648148,
	0.00833333 )
ri.Transform( 1,0,0,0,  0,1,0,0,  0,0,1,0,  0,0,0,1 )
ri.Transform( 1,0,0,0,  0,1,0,0,  0,0,1,0,  0,0,0,1 )
ri.Transform( 1,0,0,0,  0,1,0,0,  0,0,1,0,  0,0,0,1 )
ri.Transform( 1,0,0,0,  0,1,0,0,  0,0,1,0,  0,0,0,1 )
ri.Transform( 1,0,0,0,  0,1,0,0,  0,0,1,0,  0,0,0,1 )
ri.Transform( 1,0,0,0,  0,1,0,0,  0,0,1,0,  0,0,0,1 )
ri.Transform( 1,0,0,0,  0,1,0,0,  0,0,1,0,  0,0,0,1 )
ri.Transform( 1,0,0,0,  0,1,0,0,  0,0,1,0,  0,0,0,1 )
ri.Transform( 1,0,0,0,  0,1,0,0,  0,0,1,0,  0,0,0,1 )
ri.Transform( 1,0,0,0,  0,1,0,0,  0,0,1,0,  0,0,0,1 )
ri.MotionEnd()

Defines a motion block for camera motion blur.
The numbers within the MotionBegin call represent shutter times.
The subsequent transformation calls within the motion block are samples at the corresponding shutter time.
For example, if you have 10 shutter times specified in the MotionBegin, you would need 10 calls to a transformation function (such as Transform, Rotate, Identity) within the block.
This example split into 10 even parts from shutter begin to shutter end. It can be split into any ways, but 10 is a reasonable number to use for cameras because internally Krakatoa uses 10 motion samples for the camera (in Krakatoa MX and SR).
This is implemented exactly as the Renderman specification, so look at the Renderman spec document for details.

ri.WorldBegin()

We start the description of the world.
It must be paired with a matching ri.WorldEnd() at the end of the world context which triggers the rendering.
After ri.WorldBegin(), the current transform is reset to the identity, and you can work in world space. prior to this, we were in camera space.

ri.AttributeBegin()
ri.Transform( 0,0,-1,0,  0,1,0,0,  1,0,0,0,  50,0,0,1 )
ri.LightSource( lightTypeString, lightNameString, [optionalParameterNameString, optionalParameterValue], ... )
ri.AttributeEnd()
ri.Illuminate( lightNameString, True )

“ri.LightSource” Defines a light source, and “ri.Illuminate” turns the light ON (lights default to OFF).
The AttributeBegin() and AttributeEnd() calls define a scope in which the light’s parameters are set, including the transformation matrix.

  • lightTypeString: Specifies the light type. Supported type strings are: “directlight”, “spotlight”, and “pointlight”.
  • lightNameString: The user-defined name given to the light.
  • optionalParameterNameString, optionalParameterValue pairs: Parameters for the specific light. The following are valid parameters, including their default values:
    [list]
    [*]“Flux”, (12.5,12.5,12.5)
  • “DecayExponent”, 0
  • “ShadowsEnabled”, True
  • “ShadowDensity”, 1.0
  • “ShadowMapWidth”, 512
  • “UseNearAttenuation”, False
  • “UseFarAttenuation”, False
  • “NearAttenuationStart”, 0.0
  • “NearAttenuationEnd”, 40.0
  • “FarAttenuationStart”, 80.0
  • “FarAttenuationEnd”, 200.0
  • “LightShape”, “round” #Valid options are “round” or “square”. Only applicable to direct and spot lights.
  • “LightAspect”, 1.0 #Only applicable to direct and spot lights.
  • “InnerRadius”, 43.0 #Only applicable to direct lights.
  • “OuterRadius”, 45.0 #Only applicable to direct lights.
  • “InnerConeAngle”, 43.0 #Only applicable to spot lights.
  • “OuterConeAngle”, 45.0 #Only applicable to spot lights.
  • “AttenuationMapSavePath”, “attenuation_output_image.exr”
  • “AttenuationMapDepthSamples”, 1
  • “AttenuationMapSampleSpacing”, 1.0
  • “AttenuationMapExponentialSpacing”, False
  • “AttenMapLoadingPath”, “deep_shadow_map_input_image.dtex” #valid only for direct and spot lights.
  • “AttenMapLoadingPathNX”, “deep_shadow_map_input_image_-x.dtex” #valid only for point lights.
  • “AttenMapLoadingPathNY”, “deep_shadow_map_input_image_-y.dtex” #valid only for point lights.
  • “AttenMapLoadingPathNZ”, “deep_shadow_map_input_image_-z.dtex” #valid only for point lights.
  • “AttenMapLoadingPathPX”, “deep_shadow_map_input_image_+x.dtex” #valid only for point lights.
  • “AttenMapLoadingPathPY”, “deep_shadow_map_input_image_+y.dtex” #valid only for point lights.
  • “AttenMapLoadingPathPZ”, “deep_shadow_map_input_image_+z.dtex” #valid only for point lights.
    [/*:m][/list:u]
    Only the first two parameters are required, the rest are optional (they will be assigned default values if not specified).

[size=150]Shading (Phase Function) [/size]

Krakatoa SR currently supports 6 built-in Phase Functions.
All parameters except the first one (shader name) are optional.
You should only make one call to “Surface”.

ri.Surface( "Isotropic" )

Enables Isotropic shading - light is scattered equally in all directions regardless of light, camera and particle orientations.

ri.Surface( "Phong Surface", "SpecularLevel", 100, "AllocateSpecularLevel", False, "SpecularPower", 10, "AllocateSpecularPower", False )
Enables Phong Surface shading - light is scattered differently according to the angle between the light source, the camera viewing direction and the X axis of the particle’s transformation matrix. A Normal channel is required for this function to produce usable results. If no Normal channel exists, the Normal will default to 0,0,0 and no Phong Shading will be produced.
The “SpecularLevel” parameter defines the scaling value of the cosine value and defaults to 100.0.
The “SpecularPower” parameter defines the power of the cosine value and defaults to 10.
The “AllocateSpecularLevel” and “AllocateSpecularPower” parameters both default to False. When set to True, the respective channels will be allocated in memory to allow per-particle control of the Phong Shading.

ri.Surface( "Henyey-Greenstein", "PhaseEccentricity", 0, "AllocatePhaseEccentricty", False )
Enables Henyey-Greenstein shading - light is scattered differently according to the angle between the light source and the camera viewing direction.
The “PhaseEccentricity” parameter controls the amount of the effect. The default value of 0 produces isotropic scattering.
The “AllocatePhaseEccentricity” parameter defaults to False. When true, a “PhaseEccentricity” channel will be allocated and will be used to control the effect per-particle (assuming valid channel data is provided).

ri.Surface( "Schlick", "PhaseEccentricity", 0, "AllocatePhaseEccentricty", False )
Enables Schlick shading - light is scattered differently according to the angle between the light source and the camera viewing direction.
The “PhaseEccentricity” parameter controls the amount of the effect. The default value of 0 produces isotropic scattering.
The “AllocatePhaseEccentricity” parameter defaults to False. When true, a “PhaseEccentricity” channel will be allocated and will be used to control the effect per-particle (assuming valid channel data is provided).

ri.Surface( "Kajiya-Kay Hair", "SpecularLevel", 100, "AllocateSpecularLevel", False, "SpecularPower", 10, "AllocateSpecularPower", False )

ri.Surface( "Marschner Hair", "SpecularGlossinessVarying", False, "SpecularGlossiness", 300, "SpecularLevelVarying", False, "SpecularLevel", 25, "SpecularShiftVarying", False, "SpecularShift", 0.1, "Specular2GlossinessVarying", False, "Specular2Glossiness", 30, "Specular2LevelVarying", False, "Specular2Level", 90, "Specular2ShiftVarying", False, "Specular2Shift", -0.1, "GlintLevelVarying", False, "GlintLevel", 400, "GlintSizeVarying", False, "GlintSize", 0.5, "GlintGlossinessVarying", False, "GlintGlossiness", 10, "DiffuseLevelVarying", False, "DiffuseLevel", 0 )

[size=150]Particle Sources[/size]

[code]ri.AttributeBegin()

set particle transform. particle transformation can be taken directly from the prt loader’s node transformation

for particle transformation motion blur, only two motion segments are ever needed (although more are accepted), since krakatoa uses linear motion for particles.

ri.MotionBegin( -0.00833333, 0.00833333 )
ri.Transform( 1,0,0,0, 0,1,0,0, 0,0,1,0, 0,0,0,1 )
ri.Transform( 1,0,0,0, 0,1,0,0, 0,0,1,0, 10,0,0,1 )
ri.MotionEnd()
ri.PointsFile( “teapot.prt” )
ri.AttributeEnd()[/code]
This adds an ordinary PRT file. In the example above, transformation motion blur will be applied to the particles.

# Add a time-extrapolated PRT file based on a file sequence. Useful for playback graphs: ri.AttributeBegin() ri.PointsFileSequence( "teapot_sequence_####.prt", 30, 0.25, 1, True ) ri.AttributeEnd()
Krakatoa SR has special handling for loading particle data from a PRT file sequence at non-integer times. This option was added to ease retiming of PRT sequences.
PointsFileSequence has 5 parameters. They are as follows:
-Parameter 1: The filename sequence with #### or a number to indicate the frame number.
-Parameter 2: Frames per second that the PRT sequence was saved out at.
-Parameter 3: The time (in frames) that we wish to load the particles at. When this is a non-integer number, the particle positions will be extrapolated from the nearest frame in the sequence to the requested time.
-Parameter 4: The time (in frames) derivative. This can be viewed as how much did “Parameter 3” change from the current frame to the next frame. When using a playback graph, this can be computed as: playbackGraph.at_time( currentFrame + 1) - playbackGraph.at_time( currentFrame ).
-Parameter 5: “ErrorOnMissingFrame” if the a file does not exist within +/- 0.5 of the requested time it is considered an error. If this is set to False, it will only treat this as a warning.

[code]# to add splines:
ri.AttributeBegin()

these are some optional parameters that can be taken directly from the PRT Hair modifier

ri.Option( “curves”, “WorldSpacing”, 0.1 )
#ri.Option( “curves”, “PixelSpacing”, 0.5 ) # if this is not set, the WorldSpacing will be used instead
ri.CurvesFile( “hair.bin” ) # can be exported from 3ds Max with FranticParticles.SaveHairFile() .
ri.AttributeEnd()
[/code]
Adds a curves file. The curves file is a PRT file with a special channel format. The particles represent spline knots and each particle has an integer “SplineID” and “KnotID” which determines which spline it belongs to.

ri.AttributeBegin() ri.Option( "pointsvolume", "VoxelSpacing", 1.0 ) ri.Option( "pointsvolume", "VoxelSubdivisions", 0 ) ri.Option( "pointsvolume", "StartShell", 0.0 ) #leave these two "shell" values out if no shell, they default to 0 and infinity ri.Option( "pointsvolume", "ShellThickness", 999999999999.9 ) ri.Option( "pointsvolume", "Jitter", True ) #the following are used when "Jitter" is True ri.Option( "pointsvolume", "JitteredParticlesPerVoxel", 1 ) ri.Option( "pointsvolume", "RandomSeed", 42 ) ri.Option( "pointsvolume", "NumDistinctRandomValues", 1024 ) ri.Option( "pointsvolume", "WellDistributedJittering", False ) ri.PointsVolume( "mesh.obj" ) ri.AttributeEnd()
Adds a volume of particles from a mesh. Particles are filled inside the provided mesh. Note that PointsVolume can be called with either a OBJ mesh file or PRT particle file. Using it with a particle file is described below.

ri.AttributeBegin()
ri.PointsFileMultiplication( particleFilename, fillRadius, fillRadiusSubdivs, numParticlesPerSubdiv, densityFalloffStart )
ri.AttributeEnd()

This function takes an existing particle file and it will multiply the number of by filling particles within a radius around the original particle set. It is good for creating lots of particles out of a sparse set.
particleFilename (string) - The original PRT file particles to be “multiplied”.
fillRadius (float) - The radius around each particle to seed new particles.
fillRadiusSubdivs (integer) - The number of seeding subdivisions. Increasing this number will exponentially increase output particle count.
numParticlesPerSubdiv (integer) - The number of particles placed in each subdivision. Increasing this number will linearly increase output particle count.
densityFalloffStart (float) - A value between zero and one that defines the start (between the center and outer radius) of the linear falloff of density. zero being no falloff, one being a linear falloff from the center of the original particle to the outer radius.

ri.AttributeBegin()
ri.FractalPoints( 100000, 12345, 3, 2,

	"AffineTMPosition[0]", (-0.702887,0.802872,-0.395041),
	"AffineTMRotation[0]", (-0.152201, -0.377874, -0.014728, 0.913143),
	"AffineTMScale[0]", (0.807977,0.862501,0.449737),
	"AffineTMSkew[0]", (-0.0177443, -0.0609199, 0.958894, 0.27658),
	"AffineTMSkewAngle[0]", 41.8781,
	"AffineTMWeight[0]", 1.0,
	
	"AffineTMPosition[1]", (-0.473298,-0.693778,0.607502),
	"AffineTMRotation[1]", (-0.494065, -0.774437, 0.246846, 0.308569),
	"AffineTMScale[1]", (0.236419,0.887255,0.84798),
	"AffineTMSkew[1]", (0.015009, -0.429525, -0.292998, 0.85407),
	"AffineTMSkewAngle[1]", 4.50486,
	"AffineTMWeight[1]", 1.0,
	
	"AffineTMPosition[2]", (-0.33963,0.475914,-0.541475),
	"AffineTMRotation[2]", (0.056105, -0.0193157, 0.0833546, 0.994752),
	"AffineTMScale[2]", (0.964409,0.240352,0.644357),
	"AffineTMSkew[2]", (-0.32818, 0.599076, 0.646832, -0.339137),
	"AffineTMSkewAngle[2]", 22.7612,
	"AffineTMWeight[2]", 1.0,
	
	"ColorGradientPosition[0]", 0.0,
	"ColorGradientValue[0]", (1,0,0),

	"ColorGradientPosition[1]", 0.25,
	"ColorGradientValue[1]", (1,1,0),
)
ri.AttributeEnd()

“FractalPoints” provides a way of generating particles in fractal patterns. The first parameter defines how many particles to generate. The second parameter defines a random seed. The third parameter defines how many “Affine Transformation Matrices” will be used to generate the fractals. The fourth parameter defines how many color values will be used to color the particles. The rest of the parameters control the Affine Transformation matrices and the color gradients. They are optional. If they are not defined, they will be randomly generated based on the “seed” parameter.

Affine Transformations:
The fractals are based on two or more “affine transformation matrices” which generate the fractal patterns. Affine TMs are either user defined, or randomly generated. The number of affine TMs is defined by the third parameter. The user can define the TMs with five parameters: Position, Rotation, Scale, Skew, and SkewAngle. Also included is a Weight parameter which controls the overall influence of the TM. See the above example for how to define Affine TM data.

Color Gradients:
The particles get a “Color” and “Emission” channel. Both channels contain the same data, and are generated based on user input. The number of colors used is defined by the fourth parameter. The user can define the color graidents using two parameters: Position and Value. Value is a color value and Position is a number between zero and one that defines where along the gradient that color sits. Normally the user would define a color at the zero position and the one position which would provide a smooth gradient between those two colors. See the above example for how to define color gradient values.

ri.AttributeBegin() ri.MeshFile( "mattebox_mesh.obj" ) ri.AttributeEnd()
Adds a matte mesh.

ri.WorldEnd()

This call concludes the world definition and triggers a render.
It should be paired with a matching ri.WorldBegin() call.

ri.FrameEnd()

This call ends the definition of the current frame.

[size=150]Performance Options[/size]

ri.SetNumberOfThreads( numThreads )

Allows the user to manually define the number of threads Krakatoa is allowed to use. It defaults to the number of logical CPU cores. Passing in -1 will also set this value to the number of logical CPU cores.

[size=150]Global Options[/size]

KrakatoaSR.SetLoggingLevel( "debug" )

Sets the console output logging level of Krakatoa SR. Valid inputs are (in order of verbosity): “none”, “errors”, “warnings”, “progress”, “stats”, and “debug”.

KrakatoaSR.SetDtexLibraryPath( "C:/Program Files/Pixar/RenderManProServer-16.4/lib/libprman.dll" )

In order to load DTEX or DSM files for deep shadow maps or holdout mattes, Krakatoa must use a DTEX loading library DLL. For example, RenderMan’s libprman.dll, or 3Delight’s 3Delight.dll. This call sets the location of that DLL.

Hi,

Are there plans to have a C/C++ interface to the Scene Description Language.

I see a lot of similarity with RenderMan too.

Regards

Are these the complete specs? Meaning, can we use this in lieu of a header? Does this mean that there is no camera projection other than perspective and orthographic? Or that the attenuation filters do not include bilinear 8?

  • Chad

Is the FOV specified as horizontal? Can we specify the film back and fit too?

I have modified the specs a little. They should be quite close to complete at this point, although we will keep adding to them.
FOV is specified as horizontal FOV when the x resolution is less than the y resolution, and FOV is interpreted as a vertical FOV when y resolution is less than the x resolution. It’s a little strange, but I am following what RenderMan does.
Currently the two projection modes supported are “Perspective” and “Orthographic”. We could likely expand that to others.
Attenuation filter does in fact support bilinear 8. I have updated the docs above. You can use it by passing in “Bilinear8” as a string to that option.
I am unsure about specifying the film back. I have followed what Krakatoa MX does for the most part. Bobo might have a better idea of how to answer this question.

In the Maya exporter, I had to deal with the FilmFit because otherwise the results were, of course, wrong.
You can take a look at that code.
In the case of the Krakatoa MX exporter to KSR, there is nothing like that since the Max camera has no concept of film fit or film back. Unless I am wrong.

You’re right. In 3ds max when you change the render output size, the camera frustrum changes. But other applications don’t do that, they treat the camera and render separately. We’ll look at the Maya exporter. Thanks.

  • Chad

Btw, I just finished exposing the Bilinear Filters in KMX as SPINNERS for both Shadows and Final Image!
So instead of having the filter hard-coded to 1,2,4,8, you can dial in any value.
Will do the same in the Maya exporter next.
You can already do that in KSR if you edit the PY file.

Here is an example of the filters used for Final Pass Rendering:

Can that filter size change based on the particle density or position?

We discussed it yesterday and are considering to expose it IN THE FUTURE as a particle property (channel), so you would be able to use anything to control it using Magma (in KMX, and in KSR when that comes). It just won’t be in v2.0.0.

It would be nice if the AttenuationLookupFilter was an attribute of the LightSource.

Will log that as a wish, makes sense.

Hello,
I’m also very interested in the camera options regarding the film back inside of maya. Since this ist our main 3d package for our stereoscopic projects. So we need to get the correct settings for the film back (*.horizontalFilmOffset, *.preScale) to match the main renderings with the sets and characters. Is there an update for these attributes?
Kind regards

Wouldn’t those just be transformations to the camera? Krakatoa SR should be able to handle that just fine now. What do you do when you need to export the camera for any other use, like say as an FBX?

Or are they transformations to the image output? If that’s the case, I guess it needs to be determined how much Krakatoa SR should be responsible for things like cropping and resizing.

My camera transformation is fine, but this is not regarding the film back. At the moment I use the mel scirpt to export from maya to KSR, but I think it’s better to write my own exporter with pymel. We don’t use FBX to export camera data, so I can’t say if the film back is correct inside the FBX. In fact you are right, I can do these transformation to the image output. But therefore I have to render more pixel and crop afterwards (in nuke). So it would be nice if KSR could handle the film back shift, so only required pixel data are processed.

Rendering an arbitrary window/ROI in the image should be supported, yes. Right now we specify the .Format( width, height, aspect ), but adding a render window inside that would be helpful for “render region” type renders as well. If you output an EXR, then it could be written out as the data window.

We plan on improving support for Maya cameras. i don’t believe it should be an issue to properly support their film back setting directly in the exporter, I will take a look.

Hi,

Are there plans to allow custom Python extension e.g. for injecting geometry/particles into a scene ?

i.e. something similar to RenderMan procedural

Regards

We weren’t planning on doing that though Python. However, we do have a mostly-functional C++ API which would allow you to import particles and meshes to Krakatoa (without the need for intermediate files). I’ll post a build of it once I clean it up a bit.

Thanks Conrad. Very much looking forward to it.

Regards