AWS Thinkbox Discussion Forums

Max fluid & prt issue...

Hi, i’m meshing some liquid generated by max fluids (max2018 u3). To be precise, i want to compare workflow speed between the default meshing the liquid does and frost. However when i import the prt sequence into frost its a bizarre scale and location, also i have to flip it (mirror). Now i realise they may not talk to each other perfectly yet :wink: but i would have thought i could still stick the frost gizmo on the origin and it would be positionaly correct.

Anyone else had these issues, or just me?>

thanks

UPDATE: I was slightly wrong. It does work centered to the origin, it was just the scale that was off putting. However i do have to flip it.
UPDATE2: And the scale issue kind of makes sense. I use cms for scene scale and 0.5 meters for the liquid. Frost needed a custom scale of 0.15

Ok, my quick test has an alrming difference:

max fluid meshing = 48 secs
frost = 14.46 mins :open_mouth:

Now i know there is a lot of particles (2.7milion), but that difference is huge. The actual render time is super quick, its the loading that is taking forever.

Hmm, that does not make sense. Max Fluids are supposed to write out PRT v1.1 files, which contain explicit metadata about both the scale and the coordinate system orientation. The actual data is written in Maya Y-up space though.

If you load the PRT in a Krakatoa PRT Loader, does it align and scale correctly (Krakatoa MX has a license-free mode, in case you don’t know, you should be totally using it with Frost. Let me know if you don’t know where to get it from).

Frost is supposed to scale and reorient PRT v1.1 files the exact same way as PRT Loader does. I assume you are running Frost 2.x?
That being said, I have not installed the Product Update in 2018 yet, so I have not tested if it works correctly. I have been in communication with the Autodesk developers though, so I am quite sure they write the data they way they should.

Makes no sense to me. 2.7 million particles should load in about a second from most drives. I took an old Naiad simulation saved as PRTs, found a frame that has 2.7 million particles, and meshed in Frost in 5.5 seconds on a nearly 10 years old i7 workstation… Even with very small radius settings, it shouldn’t ever go above 30 seconds.

Can you send me a file to look at?

Hi Bobo, thanks for replying.

I am using frost version 2.1.0 max 2018u3

If it is written in maya Y-up then i guess that makes sense why i have to mirror.

I have not got the Krak PRT loader, yes please send me a link!

I’ve attached the scene i was using to try the test out.

I agree, i have some old Naiad scenes also that never took this long.
shot_001_03_curve_corridor.zip (255 KB)

I meant a PRT file you already saved so I can just try to load it in Frost and see what happens.

As mentioned, I don’t have the 2018u3 build installed yet, and don’t have the time to actually run the simulation right now. Let me know if you need a place to upload it and I will send you a Box link.

Also check your Private Messages…

While the content of a PRT file saved by the Max Fluids is stored in Maya/Bifrost Y-up coordinates, the Metadata of the v1.1 PRT file format should describe that, as well as the system units scale, and the PRT Loader is supposed to automatically flip the data and scale it. This is how Krakatoa handles data between 3ds Max, Maya, Cinema 4D etc. anyway.

Right, sorry misunderstood. Here’s a frame:

https://we.tl/i4mYx4dI6y

Thanks for the link. After loading in the prt sequence into Krakatoa, it needs to be mirrored in Y to match the original location.

Looking at the flipped axis problem, it turns out the data in the PRT file that Bifrost generated is in Y-up LEFT-handed coordinates, which matches RealFlow for example. But Maya is Y-up RIGHT-handed, and Max is Z-up RIGHT-handed. So the PRT files produced by the Max Fluid are marked in the Metadata as Maya-compliant Y-up Right-handed, but are in fact Left-handed, which requires a rotation about Z at 180 degrees and then a flip of the X axis.

I took a HEX editor and flipped the byte that defines the Metadata from 1 to 3 (Y up RH to Y up LH), and lo and behond, the modified PRT file aligns perfectly with your sim. I have reported this to Autodesk and I hope it will be fixed in the future. After all, it is just a single metadata byte that is off…

Regarding the meshing speed, you had your Frost set to Anisotropic, which is notoriously slow. You should NEVER use that mode unless you really need flat fluids. In Zhu/Bridson mode which everyone uses when meshing fluids with Frost, the time in v2.1 was between 3.5 and 10 seconds depending on the radius. You can tweak the Z/B Blend radius to produce smoother surfaces (with values around 2.5 to 3.0).

In short, if you really need to use Anisotropic, you are out of luck, it will take minutes. This is because each particle has to look up its neighbors to figure out the anisotropy, and closest particles lookups are slow. We had some ideas for a new method that would be faster, but right now just stay away from that mode.

Thanks a lot Bobo, that all makes sense. Now call me a paranoid max user but it looks like they got a maya guy to put bifrost into max!

RE: Anisotropic - Got it. Thanks for the explanation.

cheers.

chris/

You couldn’t be farther from the truth.

The bug is partly my fault. Originally, Bifrost had a PRT v1.0 exporter shipping with Maya. PRT v1.0 did not support Metadata, so the particles would be written in the Maya space and required extra transforms if loaded into Max. I suggested to the Max dev. team they should switch to the PRT v1.1 format and set the Metadata for CoordSys to 1 (assuming incorrectly Bifrost uses Maya’s coordinate system). This happened just days before 2018.3 went out, so I never got to actually test it. Looks like nobody else caught it either.

So apologies from me, on behalf of the Max developers. I will try to stop assuming things…

Forgiven!

you know, you could have blamed Trump and i would have belived you.

Privacy | Site terms | Cookie preferences