Dissolve Effect

#41

I’ll finish the tutorial and post the example.
My main concern is to get a lot of detail in the particles that get dissolved.
Just like in the videos I’ve shown you before.

#42

I understand that. So I am proposing the use of “Random In Cube” mode of the PRT Volume to save out a very large amount of particles with random positions within the PRT Volume’s voxel grid. Then you could reduce the Density multiplier (since you will have a lot of particles occupying the same pixel if the particle count is high enough), and because the initial particle positions will be slightly different, the influence of the forces in PFlow will drive them differently.

Alternatively, you can create a single PRT sequence from the PRT Volume and add a Noise Modifier to the PRT Loader with a very very small Strength along X,Y and Z and a very small scale (around 1.0). When you pick that PRT Loader in the PFlow, the randomization of particle positions will be taken into account by PFlow and you can use the Partitioning functionality to produce any number of sequence that will be slightly different. (just check the PRT Loader Modifiers option in Partitioning rollout to look for that Noise).

The drawback of this approach is that shifting the particles randomly with the Noise modifier will shift the “3D pixels” in 3D space but the colors will stick to them, so if the shift is larger than one pixel of the final image, you might start getting blurring in the rendered image.

On the other hand, when using Random In Cube mode in the PRT Volume and creating one big PRT with all particles, each random position will sample the color of the mapped image correctly. The drawback is that the PFlow would be much slower to process as it would have to run all particles at once.

#43

I’ll start doing this right away.
Talk with you soon Bobo.

#44

Of course! but if you have a sufficient amount of particles the only detail you loose is detail you don’t want anyway. :slight_smile: ie single particle or low density clusters be gone, leaving a detail rich core with some nice feathered edges.

#45

I understand that. So I am proposing the use of “Random In Cube” mode of the PRT Volume to save out a very large amount of particles with random positions within the PRT Volume’s voxel grid. Then you could reduce the Density multiplier (since you will have a lot of particles occupying the same pixel if the particle count is high enough), and because the initial particle positions will be slightly different, the influence of the forces in PFlow will drive them differently.

I’ve decided to follow this direction Bobo.
I placed the number 20 in here. What does this number represents? Millions? Thousands? The render of 40 frames took me 4 hours.
I’m glad I finished it.
I’m still testing some new ways to make the particles fly away. Cause my main interests is to make them create a certain type of “death eaters” smoke trail.
My idea is to reverse it and perhaps try to mix it with FumeFx but thats another conversation.
My main concern at the moment is to achieve the best quality possible and to increase the number of particles to the max I can get. so that’s why I’m asking about what thins value means in the “Random in Cube”.

I talked recently about partition Bobo because my idea was to create the max number of particles possible to achieve that smoke look.
Cheers

#46

The Random In Cube value defines number of PARTICLES per voxel.
See the following topic in the Help:
http://software.primefocusworld.com/software/support/krakatoa/prt_volume_grid_and_random_particle_generation.php

In the first part, the right column shows how a PRT Volume voxelizes the mesh and then places a particle in the middle of each voxel (this is Regular Grid mode with 1 subdivision).

In the case of Random In Cube, when the Number value is 1, one particle is once again placed in each voxel, but it is not in the center but pseudo-randomly distributed inside the voxel. When you increase the Number to 20, 20 particles will be seeded in each voxel.

So the final count depends on the size of the Voxel (which is controlled by the Spacing value) multiplied by the Number value when using Random In Cube.

When using Regular Grid though, the subdivisions increase the number exponentially by the power of 3, so a value of 3 produces 27 particles per voxel, all neatly ordered in a grid of 3x3x3 inside the voxel.

#47

Until what value do you think it’s reasonable to place the spacing, at this moment I’m at 0.5, and the number in the Random in Cube, that is 20?

I’ll probably try to increase it a little bit more.
Thanks Bobo

#48

In the Channels rollout (or by right-clicking the PCache button, or by looking into the Krakatoa Log window), you can see how many particles were actually generated at render time. The Spacing means nothing without knowing the size and shape of the object. If it is a plane, it depends on the width and length of the plane. Multiply the width*height by the spacing and you will get an idea about the number of voxels in two dimensions. Keep in mind that the PRT Volume might add several voxels thickness because a plane is open and it uses some spacing around the bounding box to solve that. (see the topic http://software.primefocusworld.com/software/support/krakatoa/render_geometry_volumes.php#Filling_Partially_Open_Objects for details)

So it depends on your geometry, the resulting number of particles at render time and your workstation’s RAM, not on what I say is a good number :wink: The Channels rollout has a Memory/Count calculator to help you figure out how many particles could fit in a specific amount of RAM. Once you know the current count, you can add more particles by increasing the number value or changing the Spacing (smaller Spacing values -> more voxels -> more particles).

#49

The Channels rollout has a Memory/Count calculator to help you figure out how many particles could fit in a specific amount of RAM

Where can I find this Bobo?

My main concern at the moment is that because of the values I placed in I can’t get the entire image cause my computer almost crashes. I’m only able to see a small portion. So I’m orienting myself by the plane that has the material of the image. My main concern is because I can’t see the movement the particles after I place the forces to make the dissolve.
The only thing I can do is to do a lower the number of particles and then apply all the forces, right? -and them pass this to the higher version.
I don’t see any other way

My plane is 288 by 512 in generic units.
The image size is 1152 by 2048.
Cheers

#50

In the Krakatoa UI, where else?

My main concern at the moment is that because of the values I placed in I can’t get the entire image cause my computer almost crashes. So I’m orienting myself by the plane that has the material of the image. My main concern is because I can’t see the movement the particles after I place the forces to make the dissolve.
The only thing I can do is to do a lower the number of particles and then apply all the forces, right? -and them pass this to the higher version.
I don’t see any other way

My plane is 288 by 512 in generic units.
The image size is 1152 by 2048.
Cheers

Ok, when I create a plane with those dimensions and set the the Spacing to 0.5, I get 877,775 particles. Multiply that by 20 and you get 17,555,500 or 17.5 Million particles. This requires around 500 MB to render in Krakatoa, unfortunately passing it through Particle Flow will change that since PFlow has quite different (and higher) memory requirements.

You should use the 877,775 particles (1 random in cube) to produce a PRT file sequence and get the right look in PFlow. In fact, you can reduce the Render % in the PRT Loader, set it to Load Every Nth and the PFlow will use only a fraction of the particles. Get the right motion that way.

Once you feel the particle animation is what you want, increase the particle count in the PRT Volume, save a new sequence, load it into the PRT Loader, change the Render % to 100.0 and let PFlow crunch through the millions of particles (this will take a while). If you have enough disk space, dump the PFlow particles to a PRT sequence so you can later re-render any frame without waiting for PFlow to calculate.

#51

Now I get it.
In the rendering section the option was in “Load First N Particles”. I’ve changed that.
I’ve placed the viewport render % to 0,005 and now I can see all the particles still when I mess around the viewport it slows down a bit. My particle count is 17,769,684. I think this is too much. Basically what you recommend is for me to reduce the Rendering percentage and perhaps the % of render also. I’m sorry for being so slow in understanding this but there are some process that I can understand because this isn’t Maya but still I’m getting used to this.

After all the forces applied I’ll save all the action for me to render it without having to worry with PFlow.
I have a lot of disc space hope my 8 Gigas of Ram don’t let me down.
A huge thanks for all this step by step help.
I’ll try to post my results as soon as I can.
Cheers

#52

When the PRT Loader is set to Load Every Nth, it is generally slower because it has to read ALL particles from disk (the PRT file is zipped so it cannot just jump through it, it has to unzip it all), while First N loads only a portion of the file. But because the particles from a PRT Volume are ordered from bottom to top, you would get only a fraction of the plane and not the whole thing.

That’s why I proposed to create a very small (less than 1MP) PRT sequence to play with AND set it to Every Nth in the PRT Loader which is then respected by the Particle Flow (assuming you created the ID channel as explained in the tutorial). Particle Flow grabs the particles from the top of the modifier stack of the PRT Loader and respects the PRT Loader’s render percentage settings, so if you have 877K particles in the file and load 10% in the PRT Loader, the PFlow should also load and show only 87K particles which should be relatively fast to mess with.

Once you like the forces, you switch to a high-count particle file sequence with many millions and go drink coffee (or red wine, being in Portugal ;)) and wait for PFlow to process the final version. Instead of just rendering, you can switch Krakatoa to “Save Particles To File Sequence” once again and dump all the force-influenced particles, their Velocities, Colors, Density etc. to a new PRT sequence. This will allow you to load the resulting simulation in a PRT Loader and apply post-processing of any channels via KCMs, play with the Density multiplier, tweak the Motion Blur settings, reduce the particle count if needed, cull portions of the particles, even DEFORM the particles with deformation modifiers etc. and it should take a couple of seconds to load and render ANY frame because PRTs are history-independent snapshots of the particles (you can jump to frame 100 without pre-calulating 99 frames each time).

#53

Once you like the forces, you switch to a high-count particle file sequence with many millions and go drink coffee (or red wine, being in Portugal )

Vinho do Porto :smiley:

This is my test image, I’ve decided to do a low res version.
I’m starting to render it, to see how the animation behaves.
I like self illumination but I can still use lights to do the job, right?
I’m using 0,5 in the Final Pass Density and in the exponent the value 0.
Perhaps when I increase the particle number I’ll be able to play a little bit more with these settings.
Cheers

I’ve increased the resolution in the rendering section. With 640480 I’ve got this pic, but with 20481152 the image has a lot of dots. Why is that? How could you maintain that correct look in the teapot? Is it because I don’t have enough particles?
Sorry for so many questions Bobo

#54

Yes.

Krakatoa, when rendering in Particle mode, draws each particle as a pixel-sized dot (when the filtering is set to Bi-Linear or Bi-Cubic, it actually covers partially up to 4 pixels in a square (2x2), with Nearest filtering filling exactly one pixel. So if the resolution increases, you will need to provide more particles to cover the whole image. Alternatively, you can render at half the image resolution and resize up in post which will of course result in more blurring.

The other alternative is to render as Voxels. Voxels have a fixed world units size and if there is one particle in each voxel, there will be no gaps between the voxels. The particles that fall into a voxel will all determine what the data in the voxel will be (incl. averaged color, density, velocity etc.). If the voxel size is selected to be close to the pixel size of your final rendering, the results will look very similar to particle rendering (just a lot slower). If you select the voxel size to be several pixels on screen, the resulting rendering will look too pixelated. The Filter Radius can be used to smooth that out, but the result will be blurry.

You can see this page for some examples and discussion of how Voxel rendering works and how it differs from Particle rendering:
http://software.primefocusworld.com/software/support/krakatoa/voxel_rendering_mode.php

So you can either generate even more particles to cover enough pixels as you increase resolution, or render a lower resolution with the current particle count and resize in post, or use voxels. It is the nature of the renderer and you have to tweak the settings to get the look you want - in some movie shots we had used up to 1 billion particles (usually in several passes) to get the look we wanted!

If you have self-illumination (Emission) turned on, the dynamic lighting can be calculated, but it might not appear very pronounced. You will have to play with it to see if it looks good.

Btw, the result looks very promising, esp. taking into account it is mapped on a flat plane… Good job!

#55

Hello Bobo,
I’ve been testing my animation but at the moment theres something that bothers me it’s a certain pattern that the particles create when they are dissolving. I thinks we can see it in the pic above.
How can I fight that? With more or different values in the force warps?
Probably the increase in the number of particles will also help.
Cheers

#56

Nope, particle count just makes the effect even more pronounced.
It is completely dependent on the forces you are applying. What you are getting looks a lot like a very strong turbulent wind (but I could be wrong). Possible tweaks include the overlaying of multiple forces with different values and the addition of a Drag force to slow down the motion of the particles on one or two of the 3 axes to reduce the curvature of the waves you are getting.

But this does not even require the current setup for testing - just use a simple PFlow and play with the same forces to see how they affect a fast particle system as you tweak their values. Once you get a feeling of how the various values change the outcome, apply that knowledge to the real scene. It will be much faster to learn that way.

#57

Couldn’t make it without it Bobo.
I’m really loving PFlow and Krakatoa, especially Krakatoa.
It as been an huge learning experience.
I’ve learned a lot.
I’ll post my results as soon as I can.
Cheers

#58

Hello Bobo,
I’ve been testing around quite a bit.
One of the things that keeps bothering me it’s that xxx pattern.
I would like to change that. What type of forces do you recommend me to use?
Should I keep the wind and work on different settings?

Theres a specific effect I would like to create. I want to maintain that back part of the hair, of the image of the girl above, to keep dissolving. how can I do that? Do I need to maintain the deflector before the end of her hair?

Hope you don’t take me wrong with these new questions.
Thanks

#59

This falls into general PFlow use and since it is not Krakatoa-related, I will let others comment on best practices.

As I said already in this thread, grab a simple particle system (the default teapot example from the Krakatoa intro will do) and layer multiple Wind forces with different scales and strengths plus Drag forces to slow down the particles to prevent them from accelerating too much. Get a feeling of how forces work in PFlow. Then apply the knowledge to the actual scene. There are free 3rd party plugins like Grant Adam’s “BetterWind” that might provide more control, and you could use FumeFX simulations to get more physically-correct effects (in fact I assumed that was what you were doing to start with).

I am trying to provide Krakatoa support here, not PFlow, and I hope you won’t misunderstand that either. :wink:

#60

Yes that’s right.
Sorry for the questions Bobo.
I’m already doing what you told me before.
If I have any more questions related with Krakatoa I’ll post them right here.
Thanks for everything.
Really appreciate all the help.
I’ll post my tests soon.