Hi there
In this thread I´ll post all tests I will do with Krakatoa. Thoughts and other Krakatoa related stuff.
Cheers,
Raphael
Some really basic MB and DOF tests.
In this tests I tested Camera DOF (Moving Camera, static Particles)
If you have a scene camera without Krakatoa Cam Tag I didn´t quite figure out where to set the f-stop.
For the tests I used the Cam Tag with f-stop set to override.
The logic for the f-stop goes like this:
*If the camera does not have a Krakatoa Camera Tag, the f-stop value in the Krakatoa Render Settings (under DOF panel) will be used.
*If the camera does have a Krakatoa Camera Tag, but the f-stop override is NOT checked, the (Physical) camera’s f-stop would be used. Unfortunately, that value is grayed out when the renderer is not the Physical one, so it is tricky to access. You would have to switch to Physical renderer, change the f-stop, switch back to Krakatoa.
*If the camera does have a Krakatoa Camera Tag and the f-stop override is checked, that value will be used, overriding both the camera’s own Physical Renderer f-stop and the Krakatoa Render Settings global f-stop.
Hi Bobo,
thanks a lot for your informative post. It really helps me to understand the concept behind the renderer!
Suggestion on Tag Behaviour
It might be more intuitive if the Krakatoa tags would be linked to the related parameters of the objects.
For example in lights. If you have a spot light and change its inner angle in the light tag (with override) it would be great if the light settings would pick up what settings you use in the tag and vise versa.
So if you type in 45° in the Light it would also set 45° in the light Tag.
Also if you set a light to spot other light types in the tag get grayed out. Maybe a good reference would be how it´s handled in Vray. (don´t know if you have ever used Vray for C4D. (If not I can post pictures)
This way you do not have different values all over the place (light different from light tag e.g.) and it´s more intuitive to handle settings (less test rendering to figure out what value is evaluated right now)
Cheers,
Raphael
Well that is happening right now, the tag is just using the objects parameters until you decide to override.
Hi TylerAfx.
yes this is true but thats only a small part of my suggestion.
Won´t you find it less chaotic if values would update on the other side if you enter them in the tag or the override.
Imagine a light source with a light tag. As soon as the tag is put on the light source the main features get overridden.
In that instant you lost your viewport representation of whats happening because your light does not update Shape, Aspect Ratio, Cone Inner Angle, Cone Outer Angel etc.
I have the problem of not knowing what inputs are getting read by Krakatoa if I´m just using a Light or a Camera without Tag.
The C4D Light has a lot of settings and only a few of those are evaluated by Krakatoa.
When I´m putting a Tag on the object i can read all the settings that are available for override so I can assume the settings in the main light that work.
I find that a little counter intuitive (of course if you do not know krakatoa and haven´t learned what settings are used)
You are either stuck with a lot of testrendering to figure out what values of the light / camera etc are taking into account by the renderer or to get a tag and compare the overidable options.
My suggestion was to do it like in Vray:
You need a Tag in order to work with the Object. You can see the tag as “manager” so users know what to do.
That means you set everything you need only in the tag (not the object). But the tag is linked to the object (light, camera etc) and the according values also update in the object (so you see what you do in the viewport)
So you would select your light tpye in the tag and only get the options for this type.
For example if you choose spotlight in the tag only spot light options will be available. Also the C4D light type changes to Spot and you change the inner and outer angle the C4D Light attributes changes too.
In this setup “Override” does not exist because everything is synced between the tag and the light.
In my opinion this way its more intuitive to work.
Cheers,
Raphael
I think there is a misunderstanding on the current usage of Light Tags here 
Originally, the Krakatoa Light Tag as designed by UglyKids was meant to be the only source of Krakatoa Light properties.
In the current Beta build though, EVERY relevant property of the C4D light is already supported by Krakatoa without the need for a Tag.
So the only reason to add a Krakatoa Light Tag to a C4D light is to “layer” a set of overrides and produce a different behavior than in all other renderers. In that case, you probably DON’T want your Tag parameters to match the base parameters anyway…
There are a bunch of parameters that are Krakatoa SR specific and are not used by C4D, but were exposed nevertheless (e.g. Pixar PRMan deep shadows slots and stuff I have never used myself). So you might need a Light Tag if you ever had a deep shadow map to apply that was rendered in Renderman, but otherwise I don’t see a reason to use a Light Tag.
We should probably make the Krakatoa Light Tag behave more like the Krakatoa Camera Tag where every possible parameter has an “override” checkbox and lets you specifically enable the override per parameter as needed. We kind of do this in the Setup tab where Color/Intensity/Decay have a single override checkbox, the Shadows have their own checkbox and the Attenuation does too.
But since Light Tags are now pretty much obsolete because we exposed directly all C4D light properties in Beta 3, I am not sure if that would be worth the effort.
Long story short: Don’t use Light Tags.
Hi Bobo,
thanks for the long answer!
I think I understand what you have planned.
But I also think that you haven´t quite understood my point
What I´m trying to say is that it might be better to create some kind of “mask” for new users like me so they know what sliders do have an effect in the first place.
As a beginner I do not know all the settings Krakatoa offers.
Example:
I open Krakatoa C4D the first time an set up an emitter etc.
Then I create a light object. (Sorry for always picking the light but it seems to provide good examples 
But as I do not know what features of the light are taken into account I am forced to do a test render for every tick box, slider and setting in the light…
(I agree that testrendering will be rather fast because of the speed of Krakatoa. But its not really intuitive)
E.g. I do not know what light types are supported, also I don´t know if fallof or raytraced shadows have an effect on Krakatoa (without looking in the light tag or the manual)
The Point I´m trying to make here is:
There is no way to know which settings of the C4D light object have an effect on Krakatoa. (without looking in the light tag or the manual)
There are more settings in the C4D light then used by Krakatoa. For example the area light with area shadow (which is not supported in Krakatoa to my knowledge) But you can set them as you are using an C4D light. And that might cause confusion!
In my opinion it would be more intuitive if you´d provide a “krakatoa light tag” with all the options lights have inside Krakatoa so beginners like me would not have to guess but could see what´s available and what´s supported right away.
And that also goes for all the other tags provided.
Don´t get me wrong. This is just a suggestion I made to make the work flow a bit more intuitive. If you disagree that´s ok and I totally respect that.
Maybe I am looking on it from an wrong (or a beginners) perspective and there are facts that I do not see or know right now that makes my ideas unusable.
So this is just my 2 cents, if you don´t like them then through them away. I just wanted to mention my thoughts
Cheers,
Raphael
Thank you for your suggestions!
We will try to streamline the workflow, but I won’t accept the excuse of “I have not read the manual” once there is a manual 
Ha ha I´m ok with that. Yes of course it will be more easy if you have a manual to support you 
Here´s a animation test I made yesterday.
Still image from the animation:
Object Emitter with X-Particles.
The Emission is based on moving noise Shaders.
Collision with the emission object enabled (you can see if you watch closely)
I cached the Particles to disc with the Krakatoa PRT saver to avoid the Motion Blur issue (inconstant particle count)
Krakatoa had one light source and an override emission to lighten up shadows. (Spot light with shadow map of 1000px)
Rendered with Motion Blur.
Lighting Pass Density 0.25 Exponent -1
Final Pass Density 1 Exponent -1
Particle count is consistent at about 1.000.000
I hope you like my first little test.
Cheers,
Raphael
Silver_Logo_Krakatoa_01_HQ.mov (5.28 MB)
Very nice sandy look. I will also try the prt saver workflow for my particle bird. I hope that solves the MB problem.
@Thinkbox: Would it be possible to stamp the most important attributes in the rendering? Maybe particle count, repopulation settings, light pass density and final density? That would really help to learn this stuff when we render tests here.
Cheers
Simon
Can you clarify (keep in mind we are learning C4D as we are going along 
).
Is there a built in feature in C4D for stamping info on the final rendered image (like VRay does), or do you want the info stored inside the image file (if it supports metadata), or in an external metadata file (like KMX does?)
EDIT: I looked into the Watermark feature. You can use it as is, and enter the data that you want by hand. I am not sure if we would be able to pass any Krakatoa-specific data to it, but I have logged it as a wish.
Another setup.
I tried to achieve more detail and create a big scale sim.
This sim was done with X-Particles and has 12mio particles at its high point.
This represent some sort of snow avalanche.
I used different turbulence modifiers to create small and large scale detail.
Hope you like it
[attachment=0]Lawine_01_1.mp4[/attachment]
Cheers,
Raphael
cool! can’t wait until partitioning 
is working so you can make this 120 million or 1.2 billion ;-p
cb
Its supported in the newest beta release. But only for C4D Emitters. Can´t wait for X-Particle support!
Here´s another test with a similar setup from today:
[attachment=0]Spawning_Sand_01.mp4[/attachment]
or you can use repopulation to a certain degree…
Here´s another animation I made using Krakatoa.
Krakatoa “only” was responsible for the spars. But it renders so fast that it allows for a lot of iterations!
Cheers,
Raphael