[size=200]Welcome to the Krakatoa SR Beta Discussion![/size]
Please use this forum to comment on existing features, suggest new features, discuss workflows or simply ask questions.
To report bugs, please post in the dedicated Krakatoa SR Bug Reports forum:
[size=150]Krakatoa Overview[/size] Krakatoa SR is a stand-alone renderer available for the Linux and Windows operating systems.
Krakatoa SR is implemented as a Python module and uses a PY file as a scene description language. For details on the scene format, please see the the documentation thread,
Krakatoa SR currently provides two reference exporters - one is implemented in MEL script for Maya, the other is part of the Krakatoa MX package for 3ds Max. More reference exporters (mainly in Python) are planned for the near future to illustrate the support for other 3D applications like Houdini and Softimage. Krakatoa SR as product does NOT include the exporter part, it is purely a renderer with a Python-based, Renderman-style interface. You are encouraged to explore and develop your own exporter implementations to support these and more 3D applications.
Krakatoa SR supports the reading of Thinkbox PRT files, Realflow Particle BIN files and Comma-Separated Values CSV files. Free PRT exporters are available for Maya, 3ds Max, Softimage, Houdini and Naiad. RealFlow 2012 also includes saving to PRT as an option.
Krakatoa SR supports OBJ files as geometry interchange format to define matte objects and particle volumes. Make sure the OBJ export is available in your 3D application (for example, in Maya you have to make sure the OBJexport plugin is Loader and AutoLoading on startup for the reference Krakatoa SR exporter script to work correctly).
For a Work In Progress Feature List, please see this thread.
Provide a reference reader implementation so you can implement your own viewers.
Provide a Python particle stream library so you can read data from a PRT file and do whatever you want with it. Same for saving. We have such interfaces for MAXScript for example and have implemented the Particle Data Viewer in 3ds Max using just that.
Provide a stand-alone viewer. We have a prototype in Windows (the viewer I used in the Maya demo video to show the rendered image can also show PRT and various other volume and mesh formats)
Provide a built-in loader object (like the PRT Loader in 3ds Max) for various platforms, e.g. Maya, Softimage, Houdini
Provide even more integrated solutions like a PRT Loader operator in Houdini (the free “HDK” PRT saver can also load particles, but we don’t like that implementation very much)
At the moment, I am prototyping some tools to render points out of Houdini via an animated series of geo/bgeo
So option (3) [stand-alone viewer] sounds most useful and if written as a Qt or PyQt app would be more portable across the platform for which Krakatoa SR 2.0 will be produced.
My use case would be to view the geo/bgeo using gplay and firing up your stand-alone view to compare, this is especially useful when dealing with coordinate system differences between host application and rendering software.
Hello everyone!! I noticed that one of the main problems is that the particles are dependent on the scale (units) may be somehow solve the problem of scaling, because voxels are different sizes for objects? (Maya)
Krakatoa is a Volumetric Renderer. So volumes mean a lot, and the scale of the spatial subdivisions obviously too.
We advise to think in real-world units when working with volumes, and avoid going below 1.0 system unit where rounding errors could start accumulating.
When a particle is rendered as a point or a voxel, its Density channel affects the Density of the volume (represented as a screen pixel or as a voxel).
If you have a cubic unit and you put 1 particle with density of 1.0 in it, you will get a Density of 1.0. If you put 10 particles in it with Density of 1.0 each, you will accumulate a Density of 10.0. If you scale the scene differently so that a voxel is not 1.0 cubic unit anymore but 10.0^3, if only one particle with Density of 1.0 falls in that volume, its influence will be 1000 times less. So you either have to create 1000 times more particles, or increase the Global Density multiplier (Final Pass Density + Exponent). Typically, you would change the Exponent by +3 so a single particle with a per-particle Density value of 1.0 would contribute 1000 times more.
In the Krakatoa MX implementation, there are a bunch of ways to control the actual particle Density channel per object and per particle including Magma modifiers, the Object Visibility track, the Material’s Opacity track and so on. I don’t think any of these are currently supported in Maya. I am not sure what the PRT exporter for Maya writes as Density, but I suspect it is 1.0. Unless it actually accesses per-particle channels and reads transparency data. We should look at ways to control the per-particle Density at object and particle level in Maya since that’s the ticket to controlling the final look.
Currently it is not possible to have different voxel size within the same scene when rendering in Voxel mode, but PRT Volume objects can create more or less particles since their Spacing (which is in fact a Voxel size, too) can be manipulated independently. Also, you can subdivide the voxels as often as you want and put 1 or more particles in each subdivision. For example, if you have a cube with size of 10.0 units converted to PRT Volume with default Spacing of 1.0, there will be 10x10x10 voxels with one particle in each, or 1000 particles. If you change the Subdivisions to 1, each voxel will be split once into 2x2x2 sub-voxels and each will get 1 particle, thus producing 8 times more particles, or 8000. If Jitter is enabled and you set Jittered Particles Per Voxel to 10, you will get 80000 particles from the same geometry.
If the renderer’s Voxel size is approximately equal to the size of the PRT Volume spacing, multiple particles from the PRT Volume would fall in the same voxel. If the Subdivisions and Particles Per Voxel are enabled and increased, one would have to reduce the renderer’s Voxel size to capture more detail.