So the spacing between particles (the spatial density) varies over the animation? If that’s the case, then yes, you are seeing the correct result. The Noise doesn’t know that your particle instances need to occupy more volume. That data is not available, nor could the Noise be told what to do with it. This would be something handled though Box#3 or some other method whereby you could determine the spatial density and density gradient and place the new particles appropriately. But this is sometimes slower than just making more partitions. YMMV.
That’s what I tought.
I’ll write a script in Softimage to tell ICE to change all my seeds and export different .prt that I’ll load and render in Krakatoa.
Hey Bobo, that has reflections?! Sweet, I wondeh what the effect will be on the famous Krakatoa rendering speeds. And how many particles have you got up there?
I imported the Stanford dragon PLY which gave me a mesh with 871,414 polygons.
Krakatoa converted its volume on the fly to 7,473,323 particles - this took around 50 seconds including normals and texture coordinates acquisition. I saved the particles to a single PRT and loaded it into cache, then rendered the turntable. Illuminated by 2 spot lights and performing phong shading with an HDRI environment map as additional light source it took 34 seconds per frame. The density was set to 1/-2 so it produced a slight “SSS” effect (volumetric scattering) as the light penetrated the volume.
Of course, the main reason to do this would be to then let the model fall into 7M dust particles blown by the wind or something like that, but the Stanford page warns the user not to destroy any of the characters (dragon, Buddha etc.) since they are considered sacred by certain cultures…
Apropos render speed - I personally consider Krakatoa 1.1.x rather slow, so we are constantly pushing for more performance. Especially on multi-threaded systems, the next version will be faster - just yesterday we made matte objects handling 70 (seventy) times faster, possibly even more depending on the geometry complexity. But I admit matte objects were the slowest component of the system.
Hah i feel amazed! Extermely cool that krakatoa stuff! I didn’t know it has its own particle-generating tool, and the HDR illumination is great. That’s just getting better and better!
Teaser mode ha? Bring it, madaf***er After i’m done with my current proj, I’d really go into scripting, and do some box3/TP with Krakatoa. I’ve actually seen the voxel renderer at work - fan-tastic. I’m wondering whet would happen if i take a few fume sims, make particles run thorough them and color them fancily with TP or box 3, then render with the voxel renderer. Pretty colors guaranteed! Damn i’m looking forward to that!
rendering straight from fume is pretty kick ar$e. caching PRTs without having to come up with a particle system/fume follow rather then straight from a fume sim is neat too…almost cuts out the middle man…if u can render it u can cache it
although i’m not sure if i was supposed to tell that yet. bobo will go into detail here at a given time.
@Anselm: Fume rendering directly with Krak, that’s mighty!
@Bobo: Furry bunnies?! Really, you do gur with particles, that’s totally off the hook! I can imagine at some point, bobo saying - “I would stipulate that everything whould be rendered with particles, atom-scale if need be. After all, that\s the way God made it, so it can’t be wrong” heh crazy stuff, keep sharing!
This is a philosophical topic, of course, but... Most renderers out there simplify reality because of the nature of solid objects - they either stop at the surface, bounce a ray and assume there is nothing inside, or go inside with the ray and assume the volume is isotropic until the ray leaves the volume. Some of them CAN do volumetric rendering by marching a ray through a volume and can handle anisotropic volumes. So for them, volumetric rendering is a side job. Sub-Surface Scattering in the world of surface rendering is (as Chad Capeland mentioned) faking what would happen under the surface, but there is nothing there.
Krakatoa is exactly the opposite - it was designed to deal with particles and volumetric rendering, so "sub-surface" scattering is its natural thing but there are no surfaces, just volumes. Simulating the bread and butter of other renderers (hard surfaces) is a side job for Krakatoa and is typically used just before blowing the object into particles to reveal it is actually solid. With the upcoming version, we add volumetric rendering of particles as voxels which will have some additional implications, but still Krakatoa remains a niche product and does not claim to be more than a particle renderer. It is meant to deliver passes for compositing to be integrated with the render output of other renderers. It wants to play nice with as many other products as possible (PFlow+Boxes, TP, FumeFX etc.) and enhance their output. It does not try to compete with them, it is an extension toolkit. There is still some lack of integration when it comes to playing nice with reflections, refractions and GI in other renderers, although we have some ideas how to solve that.
But at the end of the day, some of these results you see (hard surfaces, hair and fur etc.) are more like curiosities than actual production features. They are witness to the flexibility of particles in general and volumetric particle rendering in particular, but not something that would REPLACE the other methods. Rendering phenomena containing actual particles (smoke, water droplets, silt, sand etc.) as particles is a good idea though. And it is rather good for pixie dust, Ki blasts and Kame-hame-ha, too. :)
