Hi, yeah the screenshots above shows the imported .bin sequence (the one created after the exec of the script).
The odd thing is that my max range value for the velocity is ~3.5 but when I turn on vorticity display the max range value increase to ~600000000 ! Seems strange.
Thanks anyway
The odd thing is that my max range value for the velocity is ~3.5 but when I turn on vorticity display the max range value increase to ~600000000 ! Seems strange.
hmm yea you can change the range in realflow manually or you could load it in krakatoa and use kcm modifier as show in my previous post… (i dont think its possible to calculate maximum vorticity or value of any channel, for that matter, at every frame of the simulation without frying the cpu (you need the wolfram alpha computer for that!) even the krakatoa particle viewer by default returns the channel values for the first 1000 particles (you could increase this value but as you increase it, it will obviously slow down!) another thought just hit me mind, can i get the krakatoa particle viewer to return the maximum magnitude of a channel (like velocity) instead of the maximum value of each component of the vector (i haven’t looked this up yet, maybe there is an option in the viewer… ?)
thanks for help
The reason the PDV defaults to 1000 particles is that the DotNet ListView is slow to update. So we have added an option in a drop-down list to the left of the UPDATE button to show only the stats, thus not populating the top list, just the Min/Max/Average one. It is still not very fast (due to the way MAXScript has to read one particle at a time), so in the future there might be a dedicated MagmaFlow Operator to get such data inside the flow.
As for the Magnitude of Vector values, I added this to the PDV - the patch is attached to this post. Just unzip it, replace the file found in the \Krakatoa\Scripts folder of your installation and you should get a 4th row for each vector representing the Min/Max/Average of the vector’s length.
Hey ! , simple question , do i gain quality if i do a partition of my realflow bins exported to p flow??
2nd question … i trying to make it look rly splashee in terms of visuals, , any suggestions ??
Simple partitioning won’t do anything unless the PFlow contains operators that use a random seed and can modify aspects of the animation like position and speed. We have tutorials in the Krakatoa documentation about how one could partition a Realflow simulation using a high-frequency Noise modifier on top of a PRT Loader to randomize the positions of the particles. RTFM.
Wrong thread, try starting a new one about RealFlow simulations.
Counter-question: what is up with the commas? I have seen several posts today full of , and I am wondering what’s the story is. My advice - learn to write clearly to be taken seriously. Unless you have Parkinson’s, in which case I apologize. Btw, Windows has a feature to filter out strokes from trebling fingers.
thanks for the patch man, and for the YT tutorials too (keep them coming :drool:!) :bowdown:
The reason the PDV defaults to 1000 particles is that the DotNet ListView is slow to update
so in the future there might be a dedicated MagmaFlow Operator to get such data inside the flow.
WOW! That would be cool 
. Does this mean one could actually normalize the velocity per frame (say, normalized Value = velocity of particle / max value of velocity per frame)?
thanks for help!
I am back to Krakatoa as for recent project requirement. I am using it after a long time and I am really enjoying all the changes plus thanks a ton Bobo for posting wonderful videos on youtube.
As I started, I noticed that It’s not using all cpus of my i7 core machine. Is it a bug related to i7?
Also I don’t see anymore (Use all cpus, 2 cpu dialogue in renderer tab)
So recent version 1.6 isn’t multithreaded or Am I missing something?
Thanks,
Regards,
Jigu
1.6. is the most multi-threaded version ever. Drawing particles, lighting particles, matte object processing, all hit all 8 cores on my machines (i7 at home, dual quadcore Xeon in the office).
So there must be something wrong with your machine / installation.
The CPU controls are in the Preferences rollout, accessible via the Krakatoa Menu, from the Main Controls UI and via the icons. It should default to “Use All CPUs (8)”.
What are you doing when you check the CPUs? Some operations like loading particles from disk use only two CPUs, shading and KCMs use all CPUs, but would require a lot of processing to really saturate them all. Saving particles will only load more than one CPU if you are applying complex materials and heavy KCMs, but usually it is I/O bound.
Some aspects of the Voxel rendering could be sped up, but it should hit at least 70% CPU most of the time.
Generating particles in a PRT Volume is currently single-threaded, but it is quite fast nevertheless.
Processing PFlows is single-threaded (outside of Krakatoa), rendering the resulting particles should hit 100% most of the time.
Yes, it shows all CPU usage.
I am using PRT volume (via mesher for pflow) and using voxel mode for rendering. And at rendering, it still uses 15% CPU usage? Is PRT volume limitation at rendering too?
PS : I just noticed when it comes “rendering pass for light” (in voxel mode for PRT volume) CPU usage goes 80% upto and goes down and goes up again. But it happens fast with up and down.
It’s rendering with multiple CPU (I started using Krakatoa again after long time)
I am working on one scene which might requires many PRT volume objects (and all will have high number of particle counts). I have yet tested lighting, shading and rendering on one PRT volume object only.
In the scene, camera is moving and PRT volume is steady. Now due to lots of PRT volume, I am not sure if it will calculate particles for all PRT volume object (and for which isn’t not even in camera?)
If it calculates particles at render time for outside camera particles too, Is it possible to calculate particles which are within camera frustrum? (i.e. like mentalray “Use placeholder for objects” feature)
All PRT volume objects are steady but camera is moving.
Thanks,
Regards,
Jigu
There you go. “Rendering Pass For Light” IS the rendering phase of voxel rendering. If you are using a Filter Radius > 1, it will slow things down since that part of voxel rendering is not well multi-threaded. The processing of the PRT Volume particles before the rendering is mostly single-threaded. The sorting for each light is multi-threaded - that might be the first 80% spike you see.
In short, voxel rendering in 1.6.0 is as slow as it was in 1.5.0. No change there. Particle rendering on the other hand is up to 8 times faster on 8 cores (in the drawing phase, obviously).
Think about this: what will happen to volumetric shading if particles are outside of the camera BUT inside a light’s frustrum? In theory we could do some sort of estimation per object whether its bbox is seen by all lights and the camera, but right now all particles are being loaded into memory regardless. When the rendering is performed though, only particles “seen” by the camera and/or lights will trigger drawing operations. So the loading of particles does not take frustrums into account, the lighting and rendering does.
Thanks for the info.
Then I might go out of ram if I load particles outside camera too. I think I have to make selection to generate PRT volume for particular selection (by camera frustum box)
Hey there, first render of a river test rendered with krak, kinda hard to create this translucent effect of water. I also think it could be better to mix this with a meshed version of the realflow sim.
If you any advices, ideas, etc, do not hesitate 
Cheers
i want to do an animation of a single frame which i partitioned in krakatoa , a camera rotating around the scene , i got the prt loader with the single frame , how do i make the animation though?? is it right to ask that here ?
This is the place
Can you explain what you mean with “animation of a single frame”, since there are several cases that come to mind. Here are some of them:
*You have a single PRT file loaded in a PRT Loader with “Load Single Frame Only” checked. This means that the frame number won’t be appended to the file name of the PRT file and the same particles will load on each frame. All you want to do is animate a camera around, looking at the same static particles over time. In this case, you just keyframe the camera or put it on a Spline Path using a Path Constraint, create at least one light or force Emission and render away.
*A variation of the above method, but much faster, is enabling the PCache for the particles. This will load the particles into memory just once on the first frame, then you can render all frames at a fraction of the time. For example, if the loading of the particles takes 5 seconds and the lighting and rendering takes 5, instead of 10 seconds per frame you will be looking at only 5. If the light source is not moving either, you can also enable the LCache option in the Main Controls rollout and this will eliminate the lighting calculations. Assuming half of the rendering time was spent lighting the particles, you could be down to 1/4 of the original rendering time.
*The above approach also works when rendering on Deadline, but there is a slightly hidden option in the Right-click menu of the large RENDER button that enables it for network rendering. This is tricky though and only recommended for advanced users (assuming you have Deadline installed, of course).
*A completely different way to animate a single PRT file would be to use a Krakatoa Channels Modifier (KCM) that moves the particles in space over time (kind of like PFlow does). There is a tutorial describing this specific case that can be found here:
http://software.primefocusworld.com/software/support/krakatoa/single_frame_constant_motion_animation.php
In this example, the particles perform a linear motion based on the one velocity vector stored in the single PRT file being loaded. If there is no Velocity in the channel, one could generate it via the KCM, too…
If this does not answer your question, please be more specific about what exactly you need help with…
Frost will be a new Thinkbox Software product, so a dedicated CGTalk thread might be needed when it comes along. 
Its development and testing are covered by an NDA, so don’t expect much information in the coming months.
Keep an eye on www.thinkboxsoftware.com for news and stay excited!