I watched just part 2 since it is about Krakatoa, and I must say it is brilliant! You explained all the basics in a simple and very accessible way.
However, I figured I would comment here instead of your YouTube channel to clarify some things:
[size=150]Final Pass Density and Exponent[/size]
- Your explanation was quite wonderful, but I have to point out that the Density value is not in the range from 0.0 to 1.0 as you claimed, but rather from 10^-32 to 10^32. In fact, that is the reason Krakatoa in all its incarnations (3ds Max, Maya, C4D, Stand-Alone) uses this complex notation - in most of those applications, you cannot really enter a value like 0.0000000000000001 - the value field would simply round it down to 0.0! But you can enter 1.0 Exponent -16 and get this value easily. Why would you want to do that? Well, back in 2011 we took a big machine with 256 GB of RAM and rendered 7 billion points to see what would happen. To get a smooth result, we needed to scale down the per-particle Density to 1.0E-9 - entering that value directly wouldn’t have worked. You can see some fragments and a whole blog about the experience here: thinkboxsoftware.com/news/20 … /7bpf.html
- The Final Pass Density is in fact a scene-wide scale value. As you probably know, in Krakatoa every particle can come with its own per-particle Density value. In the case of X-Particles, it happens to be the default 1.0, but you could modify it via a, say, Gradient Tag to change over time, or based on Velocity Magnitude, etc. So if your particles were saved with a very very low per-particle Density channel in the PRT file, and you need to boost the render-time value via the Final Pass Density, you need to be able to scale with values > 1.0. You will notice that the Exponent slider goes from -8 to +8, but the value field itself accepts values from -32 to +32, so you can create values with up to 32 zeros BEHIND the base value! E.g. if you want to enter a million, instead of typing base 1000000 and Exponent 0 (since 10^0=1), you can enter 1 and Exponent 6.
- However, if you are working with rather regular numbers with few decimal positions or zeros, you are free to set Exponent to 0 and enter the value in the left (base) Final Pass Density value. It accepts floating point numbers, so you can enter 0.05 Exponent 0, and it is the same as 5 Exponent -2. But if you try to enter a smaller number, e.g. 0.005, it will be clamped to 0.001 as that is the default precision of the value field.
- You can enter much larger numbers though, so it is allowed to type in 12345.67 in the Final Pass Density and set the Exponent to 0 and that will be the Density value you will get.
- In fact, you can mix the notation, so Final Pass Density 0.05 Exponent -2 is allowed and is the same as 5 Exponent -4
In the end of the day, the Exponent simply shifts the decimal position left and right, but the Final Pass Density itself is a floating point number you can type in manually any way you want, within the limits of the CINEMA 4D (or other 3D application’s) UI limitations.
So why is the final combined value not listed? Well, in Krakatoa MX for 3ds Max it is, because the UI there was implemented in the native scripting language of the application (MAXScript), and it was rather easy to add. We have not done that for Maya yet IIRC, but we could do it easily because that UI is written in MEL. But for CINEMA 4D, the parameters are handled in C++ and the UI is simply getting and setting them via the (rather elegant) UI description files, but I had no idea how to add more advanced display without scripting. I suspect we would have to perform the calculation in C++ and then expose another read-only control to show the value. I will add it to the Wishlist and we can look into it, but I feel that once the user understands how the controls work, it becomes a moot point.
[size=150]Rendering 30 Partitions[/size]
- In your example, you rendered one partition with up to 100K particles in Krakatoa.
- Once you created and loaded 30 partitions, the theory says that you need to reduce the Final Pass Density 30 times to produce an equivalent result.
- In your case, you started with 5.0 Exponent -1 (the default), or 0.5. That divided by 30 would give you 0.01666666(66). It is easy to think of it like this: Let’s divide the 5 by 3 = 1.66666(66), and then shift the Exponent by one digit down, from -1 to -2. This will give you 1.66666 * 10^-2 = 0.016666
[size=150]Rendering Without Explicit Lights[/size]
- Krakatoa C4D is the only implementation that lets you render with the default lights. In all other Krakatoa versions, no lights in the scene result in black particles on black background.
- While it kinda works, I would recommend adding an explicit light source from the SIDE of the cloud so even with bad Density settings, the user would see how the light hits the one side and attenuates through the volume to the other side…
Let me know what you think
Once again, this was probably the first time I watched a video about Krakatoa where I felt the presenter knew what he was talking about! Very impressive!
Thanks so much for your kind words.
I’m really sorry I got some of the detail wrong. Thanks for your detailed explanations though, it all makes perfect sense now - I’ll make sure I clarify and correct all of these points in my next tutorial (I may even re-record this one - I hate things not to be right!).
I’ll also use a scene light in future tutorials, even if it’s a simple scene.
Thanks again for the help Bobo, and for developing such an awesome plugin
I know the feeling.
However, I don’t think rerecording the the whole second part would be necessary - most people would not notice the one detail, and you got the principles right anyway, which was the main point. You could just add a YouTube text overlay on the video with a note, or just explain in the next video as you suggested.
Did you find that X-Particles crashes quite often? It seems that it doesn’t deal well with particle advection. I followed along with your tutorial and even at 300,000 particles my C4D crashed on the 3rd partition.
Not only with your tutorial, but for weeks I’ve been creating stuff with the same technique and always getting random crashes.
I find that it’s a weak spot of X-Particles, you can generate millions when not using particle advection, but it seems to struggle at a few hundred thousand when being driven by particle advection.
We have had clients reporting that X-Particles does crash a lot. I looked into the crash dumps a few times, but I wasn’t able to reproduce it on our end to determine what exactly was happening.
Mostly I was just trying to rule out whether or not Krakatoa was contributing to the crashes. Does this happen even when Krakatoa is not exporting?
Hi. I think it happens when Xparticles runs out of RAM.
How much Ram do you have on your system?
I’ve got 64gb on mine. The partitions I did for the tut render had 1 million particles in total, although at this amount the machine grinds to a halt. Maybe try caching an Xparticles sim and have a look at your system performance to see how much RAM it’s using, and then try and work out what your max particles per scene is for your setup.