it would be awesome to try out krakatoa properly with some infos… like: how can I render x-particles without assigning them to a group? how to use a fractal (i can load a prt but how can I use a fractal to change it??)? why I don’t see any changes If increase or decrease the subdivisions, or particle for subdivisions in the repopulate parameters? how can I use age, speed, vorticity as shaders? what about al those setting in the krakatoa light, magnitude, channel ecc ecc ? In this way it is impossible to give a feedback, since it seems that nothing it’s not working (for sure I’m doing everything wrong!) I never used before krakatoa, i had a look at the krakatoa my and mx but the documentation seems to be far away from this release… hope in some help, and some great improvements!
Hi!
Thanks for the feedback!
Our original plan was to release the Beta in early January 2014 after working on it for a bit and actually writing initial documentation.
We decided to release it as soon as we had a more or less working build for OSX and Windows for two reasons:
- To give people something to play with over the holidays
- To see how much a user can figure out without documentation (feedback like yours helps us understand which areas are not intuitive enough)
We are working on some preliminary documentation and we will keep on adding to it during the Beta. I am writing the first documents as we speak and hope to publish some of the results on our website by the end of the day (Pacific Time).
I still have not heard back from the X-Particles developers, so I don’t have a copy of their plugin for testing, and have never used it. So I will leave it to Daniel to answer some of your questions if he is reading this post. Same applies to TurbulenceFD.
The Krakatoa Fractal Source does not change incoming particles. KC4D does not provide any objects that modify other objects (yet). All Krakatoa Sources take some existing source object, or in the case of Fractal generate new particles, and pass them to the renderer.
Unfortunately, the implementation of the Krakatoa Fractal Source we received was missing the majority of relevant controls, so you cannot really do much tweaking or even animate the fractal designs over time. Just ignore it for now until we make it usable.
As for Repopulation, I can clearly see a change in the particle count when I change the Subdivision or Particles Per Subdivision values. Are you looking at the Console Log? Can you post simple steps using native C4D tools so I can try to reproduce? (I don’t have any 3rd party plugins yet, as I mentioned already)
Once again, thanks for your feedback!
I will gladly provide a sample scene for X-Particles as well. Check the Demo Post for new infos. Same goes for the basic Repopulation and the like.
Actually the channel infos for age etc are readable by Krakatoa XParticles Source already. Just apply it in the display options of the Emitter.
As for the File Source this coloring feature will soon be available I think;)
Yet I think the plan is to adapt the Cinema 4D bridge to
match KMY/KMX where possible, so on the long run the documentation will converge to a certain agreee.
Thanks for your reply guys!
Right know I think there is a major bug with the repopulation that come with the last release.
I have tried to render a scene with a krakatoa tp source with and without repopulation. the scene contains just 56 paricles, with the repopulation tooks 1 minute and 29 seconds without the render it shows immediately. I tried to use the less particles i could because yesterday for rendering a scene with approx. 5000 particle and repopulation took. 40 minutes. I don’t have the log file cause c4d crashed after stopping a render. by the way I have attached the log file of the last two render with the 56 particles. the settings for repopulation were radius 0.05 subdivision 1 particle for subdivision 1.
Another issue is that when I stop the render c4d crash, and I have to log out to kill all the windows from c4d.
I am pretty those problems were not an issue in the previous release.
I cannot still understand how to use x-paricles source. I just add the x-particle emitter in the emitter tag but no result! I am doing something wrong?
About the fd source I cannot give any feedback, beacause I have the demo version.
The question for the fractal was about where I have to put it to see some changes in the particles.
Btw I doing all the tests using a tp source, and having an x-particle assigned to a group.
I tried to use the TP source shpere from the demo scene file and I am getting the same results.
thanks for your help!
btw I am using a macbookpro mid 2010 2,4 Ghz Intel Core i5 with 8GB of ram with c4d r15, x-particle 2.1
paolone86, please check my updated demo files here:
http://forums.thinkboxsoftware.com/viewtopic.php?f=197&t=10994&p=47990#p47990
Best
Daniel
You might be using it wrong (of course it is my fault because there is no docs on the repopulation).
Repopulation uses an algorithm similar to blobby surfaces (metaballs), minus the actual mesh.
So you take your 56 particles and imagine a large sphere around each one. This is the “Influence Radius” which happens to be the “Fill Radius” of the Repopulation. When the radii touch, they merge like metaballs. Thus, if your scene is in CM, you MUST use a Radius that is proportional to the distance between your particles. if you make a Sphere (100cm radius) and turn it to PRT Volume with a spacing of 40cm, you get 57 particles. Create a Target Light, check “Override Background” in Krakatoa Settings > Global Render Values and render:
Now go to the Setup tab and check “Enable Particle Repopulation”. Enter Fill Radius of 10cm, keep Subdivs at 0 and Per Subdivision at 5. This is clearly too low for a distribution where the distance between particles is 40cm, but we want to see what it looks like:
This created a voxel grid with spacing of 10cm and encoded the influence of the original 57 particles onto it. Then we seeded new particles within the influence regions, taking the color, density etc. of the original particles.
Now let’s increase the number of particles by changing the # of Particles Per Subdivision to 100. Reduce the Final Pass Density Exponent from -1 to -3 to let more light pass through the new particles, otherwise our “blobs” will get too dark. Render 97,495 particles:
As with PRT Volume itself, it is generally recommended to increase the Subdivisions instead as it adds some better anti-aliasing. Increase the Subdivisions from 0 to 2 and render again - this will turn each voxel into 3x3x3 = 27 sub-divisions, each getting potentially 100 particles. But since we are filling only around the original particles, it won’t be that bad, and we get 2,627,871 particles that look like this:
Now let’s try increasing the Fill Radius a bit. Let’s use 25cm which is still not enough to cover the 40cm between the original source particles, but enough for them to overlap a bit (at 20cm radius they would be touching exactly, at 25 you get 10cm overlap). Increase the Final Density Exponent to give it more light-shadow contrast:
Now we could get to a much higher radius of 40cm which should help us recreate something similar to a Sphere. But unlike CSI Miami, we cannot get more detail out of missing detail, so our sphere will be quite rough:
We start noticing some patterns in the random distribution. It is generally better to increase the Subdivs and not the Number Of Particles. Here is 7 Subdivisions, 100 particles per subdiv, creating 39,601,281 particles in 10 seconds, and rendering in 21 more for a total of 31 seconds:
This is getting smoother, but not more detailed - we need more base particles to get a better sphere.
So in the PRT Volume Mesh settings, change the Voxel Spacing to 10cm. Disable Repopulation to see the distribution of 3,959 particles:
If we would render with the original 40cm Fill Radius, this would produce 73,742,253 particles in 18 seconds and total render time of 56 seconds:
Obviously, the right thing to do is to reduce the Fill Radius to about 10cm which was our average particle distance in the base cloud.
NOW YOU HAVE TO REMEMBER! The Subdivisions apply to the Fill Radius. So a Fill Radius reduced 4 times will result in the subdivisions also becoming 4 times smaller, and each getting 100 particles. Even reducing the Subdivs from 7 to 2 would produce 100 million particles! So let’s also reduce the Number Of Particles Per Subdivision from 100 to 10 and Subdivs to 2. Setting the Radius to 10 will still show some grid artifacts because the original particles don’t really constitute a full smooth sphere, but a boxy approximation with 10cm voxel grid size, or 20x20x20 voxel grid with one particle in the center of each voxel. These are 9,968,897 particles:
Using a larger Fill Radius of 20.0 and a higher Subdiv of 4 will smooth out the edges, but of course our cloud will be about 10cm larger than the original sphere. The top is the PRT Volume with Voxel Spacing of 2cm and Subdiv 1, Jittered, 2 particles per region, total of 8,138,288 particles in 11 seconds. The bottom is the Repopulated 4000 particles to 8,525,753 particles in 8 seconds:
I hope this explains the concept, the power and the limitations of the Repopulation feature. When you can generate million particles from the source system, do it as it will give you a lot more detail. If you don’t have a way to produce more particles, use Repopulation wisely and remember that it is in its base a Metaball-like system which ensures all data is distributed from the old to the new particles, and that overlapping influence radii don’t produce density increase…
Expect an actual documentation page based on this post soon.
Rest of the docs are shaping up here:
thinkboxsoftware.com/krakato … -settings/
One more detail that might be surprising. A lot of particles don’t have their own Normals.
PRT Volume particles DO have Normals taken from the surface of the Mesh’s LevelSet produced when voxelizing the source mesh:
I increased the Sphere Segments from 24 to 64 to produce a smoother LevelSet surface - in the previous post you can see the slightly flat segments of the original polygons.
But it would make very little sense to transfer these to the new Repopulated particles the way we transfer Colors, Densities, Velocities etc.
So the Repopulation feature actually takes the LevelSet info produced when encoding the source particles onto the Repopulation grid, and produces NEW Normals from that! Thus, if you take the example of 40cm Voxel Spacing, but with 20cm Repopulation “blobs” slightly touching, each individual blob will get its own correct surface Normals. And Phong Shading works correctly!
thanks a lot guys!!