There is an issue with Frost 2.2.2, when we try to mesh as Geometry, PRT coming from Bifrost (MaxFluids).
For meshing, frost expected ID, if bifrost export the ID, ID from Bifrost are in Uint64, but frost only support int32 (krakatoa/tP support the id in Uint64 coming from the export, just frost won’t allow to use them).
The only way to fix it right now, is to rename the ID Channel from bifrost to something else, then use magma flow (required krakatoa), to remap the new ID name to default ID with right arrity
@paul: reading the PRT inside a PRT loader or directly inside Frost ‘load sequence’, return this error :
ERR: BuildMesh (Frost001): get_channel_type_convertor_function() - Conversion of channel “ID” from type uint64 to type int32 is not an allowed conversion.
Krakatoa read the ID fine, just frost do not like that the ID is in Uint64, and those happen only when wanted to use the geometry mode (other meshing mode work fine).
I’m going to loop around with the devs here anyway and see. I’m not sure if we can coerce the data type into a 32bit int or not. Do you know how many particles are in your scene?
it do not matter, you can have a single one (rare with bifrost fluid simulation), or millions, it will give the error, the problem is coming from ‘how’ bifrost cache data (maya like), wich of course is not compatible with 3dsMAX (and probably maya version of thinkbox tool)…
Particles ID is not a problem if you want to mesh it as a fluid (as an implicit shape/blobmesh etc), but is requires to mesh as geometries instances.
Particle ID is stored as Uint64 -> but Frost require the data to be int32
UV is store as a list #(u,v) wich is maya like -> but or magma flow (krakatoa), or frost or anything inside
3dsMAX in fact require a vector 3 data : [u,v,w]…so those both channels are also krakatoa non compatible.
So for me the problem is mainly bifrost do NOT export correct data arrity for those 2 channels (other one are fine)….and if it’s true for 3dsMAX, i suspect the same issue to be true on maya side…