By default, the EXR tile size of the Krakatoa pass output will be managed automatically.
When VRay is in Bucket mode,
[list][*]KVRY now expects the tile size to be either equal to the bucket size, or equal to the Output Resolution.
KVRY will allocate memory based on the number of render threads and passes to be rendered (for example each motion blur pass stores a separate EXR), and the fraction of available memory specified in the Export Options rollout.
If the full frames cannot fit in memory, the tile size will be set to the Bucket size. If all Buckets cannot fit into memory, the tiles will be loaded dynamically, potentially causing less buckets to be rendered in parallel.
[/:m]
[]When VRay is in Progressive mode, KVRY will set the Tile size to the Output Resolution. If the Tiles cannot fit into the specified fraction of available memory, the rendering will fail and a suggestion will be logged to increase the memory or switch to Bucket mode.[/*:m][/list:u]
Basic Render Elements Support
Several VRay Render Elements will now include the Krakatoa information, including
[list]
[*]VrayAlpha
VrayGlobalIllumination
VrayNormals
VrayRawGlobalIllumination
VrayRawReflection
VrayRawRefraction
VrayRawShadow
VrayReflections
VrayRefraction
VraySelfIllumination - a bug in the KMX Emission Render Element was also fixed to correctly respect the Emission Strength or Density scaling
VrayShadows
VraySpecular
VrayUnclampedColor
[/:m]
[]The following Render Element kinda works, but needs improvements:
VrayZDepth - you need to uncheck the Invert option for it to render correctly. Also it seems not to output where particles are against background (as opposed to other geometry).
[/:m]
[]The following Render Elements are planned to be supported, but do not work yet:
VrayDiffuseFilter - should output the Color channel of the particles, does nothing right now
VrayLighting
VrayRawLighting
VrayVelocity
[/*:m][/list:u]
Fail On Missing License
KVRY will now fail if no valid krakatoa-render license could be acquired. In the past, it would fail silently, and VRay.exe would still render the scene minus the particles.
KVRY Exporter UI
Added a new rollout to define the default Shadow Resolution, Step, Spacing and Exponential/Linear mode when no Krakatoa Shadows generator is found in the light.
[size=150]KVRY Bug Fixes[/size]
Fixed a crash with more than a single light source.
Fixed lights which were ignoring the Multiplier value in the Krakatoa pass
Fixed lights which were ignoring the Decay settings in the Krakatoa pass. However, note that the Decay in Krakatoa does not match 3ds Max/VRay at the moment if the Start range is different than 1.0, this should be addressed in the next build.
When Reflections in particles are enabled but Use Emission is unchecked, the renderer will not perform the reflection calculations anymore.
Fixed the failure to detect V-Ray NFR as the current renderer (same as the patch posted for Beta 2)
[size=150]New KMX Features[/size]
Added a new Stack Data Explorer script to the Krakatoa Menu. It shows the data flow of a single particle’s value through the modifier stack of 3ds Max, e.g. Base Object, Modifiers, Magma, Transforms, WSMs, Material and will show the final value on top of the stack, visualizing how a particle value is affected by these stages.
Added the ability to reorder exposed controls in Magma (same as Stoke MX 2.3).
Fixed a slowdown in Magma Editor when working with hundreds of nodes which was caused by slow file I/O creating the Undo records. Should be at least an order of magnitude faster when selecting, creating, editing etc. nodes in large flows.
An updated exporter script forcing UTF8 encoding to all exported text files has been posted.
See this thread for details and for the download if you experience the same problem: forums.thinkboxsoftware.com/vie … 28&t=15133
Only one license should be acquired when rendering (John Rand, please check with the previous license file!).
VRayLights and any other unsupported lights will be skipped.
Light Decay (Inverse, InverseSquare) will be calculated by Krakatoa VRY to match V-Ray’s.
Spot and Direct lights set to Rectangular shape and with Aspect other than 1.0 will now have the shadow scaled correctly (in previous builds the shadow was stretched).
ZDepth Render Element with Inverse on will produce correct results. However note that a Normal Render Element must also be added for the ZDepth to work, otherwise no particles will be rendered in it. This is a known limitation we will try to fix later.
You must replace the DLL in the respective VRay RT installation folder, for example for 2017, it would be normally in
C:\Program Files\Chaos Group\V-Ray\RT for 3ds Max 2017 for x64\bin\plugins
You need to close 3ds Max as the file could be locked during vrscene export, and you will also need Admin. rights to modify files in a Program Files folder.
I am posting this in place of a full installer to get you going immediately. vray_KrakatoaVRY_20170206.zip (4.49 MB)
The attached DLL should fix the animation sequence rendering which was broken in the previous build.
To install,
You must replace the DLL in the respective VRay RT installation folder, for example for 2017, it would be normally in
C:\Program Files\Chaos Group\V-Ray\RT for 3ds Max 2017 for x64\bin\plugins
You need to close 3ds Max as the file could be locked during vrscene export.
You will also need Admin. rights to modify files in a Program Files folder.
No. But it might be a good idea to send a screenshot or a video showing what you are seeing.
The bug we fixed looked like this here: Submission worked ok, rendering of the first frame in the sequence was ok, then all following frames failed to render the Krakatoa pass and somehow composited the frame 0 on all frames, resulting in a static particle view with moving VRay environment.
I suspect your problem is something else, but “not having luck” is not enough of a problem description to understand what you are seeing.
This is the latest build of the Krakatoa VRY DLL with fixed environment/background integration.
Please replace the existing DLL as instructed in previous posts in this thread… vray_KrakatoaVRY_20170224.zip (4.48 MB)
Yet another update to both the Krakatoa VRY exporter script and the Krakatoa VRY plugin. vray_KrakatoaVRY_20170302.zip (4.52 MB)
To install, copy the DLL into the Plugins folder of the VRay RT installation for your 3ds Max version (see earlier posts in this thread). Copy the MS file to the Krakatoa MX\Scripts\ folder. You will need to set corresponding permissions to your files to overwrite them.
Lots of changes here:
Added a wait option to the DLL when a PRT file is missing. The exporter currently sets the wait time to 1 minute, and a new attempt is performed every 10 seconds until the PRT file appears or the minute has expired. The wait time is currently hard-coded and not exposed to the UI, but due to other changes is probably not as necessary as before anyway.
Added some new logic to the export of unchanging PRT objects: If a PRT object produces the same particles over time within the export sequence, later frames will not reexport the PRT file, but will simply copy the previously exported file. This results in much faster export of, say, PRT Volumes from a static mesh. The planned solution to this is actually something more similar to XMesh header files to allow the reuse of frames without duplication on disk. So this is just a temporary measure.
Fixed the hashing of PRT objects with a changing source object. In previous versions, a PRT Volume made from a deforming mesh (say, an EMesh with a Bend modifier) did not detect the animation of the underlying mesh and produced the same hash on all frames, thus ignoring the deformation.
Added a PRT cleanup pass when exporting an animation. In previous versions, if you exported a PRT sequence and it was preserved on disk from a previous render attempt, if you launched a new iteration and the export was slower than the rendering, at some point the renderer could encounter a previous PRT file that has not been updated yet, thus rendering potentially incorrect particles. In the new fixed version, after saving the first frame’s PRT and starting the rendering, but before saving the rest of the frames, a pass will be performed over all objects and any PRT files that have a mismatching hash checksum will be deleted first. This way, any pre-cached and valid PRTs will remain on disk and can be rendered, but any changed particle files will be deleted and cause the renderer to wait for the next export (see the first item on this list above!) This ensures every frame will always contain the latest particles.
Added a function to check the type and name of the current viewport. It will be reported in the beginning of the export. Also, if the type is not Perspective, Camera or Light (which means it is any Ortho view), the Krakatoa rendering is likely to render incorrectly, so the rendering will be prevented and an error will be printed to the log. This is supposed to work with both Locked and Unlocked render views. It should hopefully prevent accidental renders of incorrect viewports.
Added a 2 seconds timeout between clicks on the Export/Cancel button. This way, if you multi-click too quickly on the Cancel button (and it can take a while before it registers when exporting large PRT files), there is no danger of accidentally starting another export.
