Hi all,
is it possible to partition and render BiFrost particles in Krakatoa?
cheers,
Steve
Krakatoa does not currently recognize “bifrostShape” type objects which appear to be generating the particles. Internally, Krakatoa interfaces with “particleShape” and “nParticleShape” type objects. Bifrost does not appear to implement this style of object which is why Krakatoa cannot see the particles.
I am somewhat inexperienced with Bifrost, so this might be impossible, but is there a way to create a particleShape object that is driven by the Bifrost particles? If not, I’ll have to investigate if the bifrostShape object will give us API access to its particles.
We are also hearing rumors of a BIF2PRT converter that might or might not be under development at Autodesk. 
If that happens, you will be able to dump your BiFrost particles to Krakatoa PRT format and render them as usual.
Of course, we would prefer to render directly the native data, but this might require API access that is not there yet. We will keep investigating.
I’m pretty inexperienced with BiFrost too.
Just wanting to know the render options with Krakatoa.
cheers guys.
Hey guys… any updates regarding bifrost and krakatoa? Has any one found a workaround?
Maya 2016 should ship with a PRT converter for bifrost files. However, I have not used Maya 2016 yet, so I have no first hand experience.
It would appear that Autodesk still does not provide an API for us to retrieve Bifrost particles. Additionally, their file format is not open, so we can’t support it directly. However, they have released a conversion tool for PRT files!
It is here:
knowledge.autodesk.com/support/m … 8-htm.html
Well…
Testing the bifrost to PRT conversion. Looks okay at first, ran through the .bif cache files, generated .prt files, slow: 10minutes for 160 frames of not that heavy (~860,000) particles, but so far so good.
Loading PRT file back into maya… comes back in ~10x larger and not at original position. Okay otherwise.
Now the problem: I am slowing down the animation using PRT loader to do what bifrost cannot, animating the playback graph to retime the cache. Looks fine until interpolate subframes is activated. Then it gets messy, jumping in scale and position every frame. Seems like the velocities are messed up coming out of bifrost, probably in the conversion process, which then shows up when interpolating. Too bad since this is critical to the slow motion effect.
It is a shame bifrost is such a closed box and not integrated with the nDynamics or anything else since it seems to have real potential.
PRT 1.1 files contain a metadata record that should provide the scale in meters. It is possible that the converter does not output that correctly, and I have been overruled in my quest to allow the user to specify a custom override in the PRT Loader UI to solve such problems. You can of course solve this by scaling the PRT Loader’s Transforms. Alternatively, you would have to scale the Position and Velocity channels using Magma.
Velocities in PRT files are expected to be in units per second. If you scale the PRT Loader using its Transforms, both the Position and the Velocity should be correctly scaled down. When you change the PRT Loader display to show Velocities as lines, the line drawn in the viewport should be scaled down to units per frame and should point at where the particle is expected to be a frame later. If the velocity is too short, then the channel might have been saves as Units Per Frame which would be wrong, but you could multiply in Magma by the FPS to get it back to the right scale.
However, jumping around could also be caused by incorrect IDs. Interpolate Subframes depends on consistent IDs written to channel spelled with Capital “I” and Capital “D” to find two samples of the particle in two consecutive PRT files, and perform cubic interpolation to move the particle along a smooth curve.
In short, if you could send me at least two PRT files of that sequence, I would gladly look at the data and try to determine what might be wrong with it.
Edit: Looks like Bobo answered this while I was writing my response.
There’s a number of things that could be happening here:
Scale off by 100: I suspect that the bif-to-prt conversion is NOT adding unit metadata to the prt file (this would result in a 100x size difference if they saved from meters, since maya defaults to cm). This could be corrected with the PRTLoader’s transform scale.
Playback graph issue: If it works in default “velocity offset” mode, but fails when “interpolate subframes” is enabled then the likely problem is not the velocity vectors, but the ID channel. The default “velocity offset” just pushes the particle along the velocity vector. The “interpolate subframes” mode takes two frames and matches particles by their IDs, then interpolates the position and channels between the two particles. If the particle IDs are not consistent between frames, they go all wacky.
The easiest way for us to debug this would be for you to provide a short sequence of PRTs (maybe 3 or more frames) that you have exported that demonstrate the problem. We can examine the actual content of the PRT to see what is inside.
The scale thing sounds right. Bifrost considers a unit 1m, no global adjustment. One has to scale the driving attributes like gravity and density to run at different world units.
Is there a way to get a list of PRT/particle attributes and their values in Magma? An info feedback node would be neat to have, some way of reporting values that are passing through the flow for debugging purposes.
The skipping around definitely follows a pattern and the using the velocity to drive a color blend in Magma looks correct until the sub-frame interp is activated.
Do you know if there are command flags/options available for the bif2prt script, anything that might effect this? It is sounding like there may not be a work around. Will take a look at scaling the velocity vectors for now.
Meanwhile i’ll grab some PRT files for you. I can send a couple of .mov files to show what is happening if that helps.
edit: looks like I sent before the attachment went through… resending… maybe. Status bar is not changing. Is there another way to send large files?
We have such tools in Krakatoa MX, but not in Krakatoa MY yet. They are on the Wishlist already, but are harder to implement than in 3ds Max, so no, not at this point.
I sent an Invite for our Box storage to the email associated with the Rebus account on this forum.
You should be able to upload large files to that folder after you accept the invitation…
Got it… sending now, thanks!
Unfortunate that the new additions to Maya (bifrost, xgen) were not more integrated; more open, connectable and scriptable like the standard Maya objects.
Ok, I got the files and looked through the data.
First, the PRT specification Autodesk used is 1.0 instead of 1.1, so it has no metadata whatsoever. This means there is no information about scene scale, coordinate system orientation (Maya Y up vs. Max Z up), bounding box, channel interpretation (which channels should be scaled, which not) etc. I am going to inform the Bifrost developers and see if they can embrace the latest specs - we even provide libraries on GitHub to make it easier for 3rd parties to add correct support for PRTs…
Then, the channels available in the files are
Position, Velocity, Density, Droplet, ExpansionRate, StictionBandwidth, StictionStrength, Vorticity.
[attachment=0]Rebus_PRT_PDV_v001.png[/attachment]
The Position channel produces a bounding box of 262.356 x 30.0 x 311.047 units. Is this supposed to be in Meters?
The Velocity channel appears to be scaled incorrectly. I loaded each PRT in a separate PRT Loader, and visualized the Velocities as lines - they were about 2.54 times shorter than they should be. Once I multiplied by 2.54, the previous frame pointer approximately at the position of the next frame. Since 2.54 is the conversion factor of Inches to Centimeters, I wonder what they were doing with it…
The Density was set to 0.1 for every particle.
The Droplet was mostly 0.0, but not entirely - any particle about to detach from the body would have a non-zero value.
The ExpansionRate, StictionBandwidth, StictionStrength were all 0.0.
The Vorticity was a Float32 value between 3.0 and 100.0 units.
[attachment=2]Rebus_Vel_Unscaled_v001.png[/attachment]
[attachment=1]Rebus_Vel_Scaled_v001.png[/attachment]
No sign of ID anywhere, hence the jumping - the PRT Loader is simply matching the particles by index (order in the file), and thus jumping around violently when Interpolate is on. If you don’t turn it on, you will get relatively plausible retiming, but there will be some hickups when the sampling goes from one file to another.
I will ask the Bifrost developers why there is no ID channel in the converted file, because Bifrost definitely has an ID channel (Naiad had one too).
Fascinating!
The animation is built at around 2cm per unit. So I am playing with gravity and density settings to ‘scale’ the simulation. Don’t think it was effective, using the recommended adjustments to go from meter per unit to cm per unit just blew everything up. So I am going by what looks the best. Director is asking for something that is not physically accurate anyway. So the bounding box is closer to cm/10 I guess, though it seems compressed in Y.
That is interesting that there is an inch to cm conversion. Was naiad built in inches?
So I guess there will be no smoothing of the retimed PRTs. Testing changing the simulation time step in birfrost to get the slomo. Looks okay but gets unstable and any near stopping for a freeze effect is impossible. May wind up going to RealFlow…
Thanks for checking the stuff out.
No, it was in Meters, like any physical simulator should be.
I suspect something happened in the conversion from Bifrost to PRT data, but I am unsure why.