I’m testing the PRT Loader with some older Realflow sims that I have. The RF .bin sequence imports and the channels seem to be reading which is all great, however the scale is far too small. The PRT Loader seems to be 10 times smaller (guestimation!).
Here are two screen shots without moving the camera, one loading with RF and one loading with PRT Loader. Note the RF Particle Importer is set to use scale of 1. The PRT particles are tiny.
this actually a feature as the prt source tries to mimic the scale your Realflow Scene was simulated in to work properly in conjunction with Cinem4D.
the scaling parameter in the RealFlow plugin needs to be set to 0.01 to match in this case;)
Fluid Simulators tend to use SI units (Meter/Kilogram/Second). So RF BIN files would usually be in Meters.
Assuming your C4D scene is in CM, you should have to scale up 100 times, which explains the 0.01 factor Daniel proposed.
Thanks guys, I’m still unsure of the correct workflow here. I don’t want to reduce the RF Importer I want the PRT Loader to match the RF particles. I understand it is by design but unsure of the correct procedure.
To test, I created a simple scene in C4D with some geo. using default settings (project scale 1cm)
Exported SD to RF (scene scale 1).
Created a particle sim (all realflow scale prefs at 1.000)
Imported the particles into the original scene using RF Importer (scale set to 1).
The RF particles match the geometry perfectly.
With the PRT Loader it is 100 times smaller, so how do I match the PRT Loader scale to my existing C4D Geometry? Are you saying I should be working with project scale at 1 metre?
I think the PRT Loader would benefit from a scale option for those times when some one passes you an existing animated C4D scene, if the PRT Loader didn’t match the existing scale then we could scale the imported particles, or am I getting this all wrong!?
Thanks
Tim
The PRT 1.1 format includes a scale metadata component. Unfortunately, RealFlow does not export PRTs in that format yet (AFAIK), and BIN files don’t contain such data eather.
Both Krakatoa MY and MX v2.3 would export using the PRT 1.1 specification.
The BIN behavior could be a bug though, because a BIN file containing a cube of particles with side length of 1 meter should load as 100x100x100 centimeters. If it does not, it is a bug - the PRT Loader should assume a RF simulation BIN file is in meters and scale appropriately.
I tested the general PRT Loader behavior using Krakatoa MX v2.3 and KC4D Beta 5 (both Beta 4 and 5 support PRT 1.1 I/O).
*In Max, I set the System Units to 1 Generic Unit = 1 Centimeter.
*I created a Geosphere with Radius of 100 cm and converted it to a PRT Volume with spacing of 4 cm.
*I saved the resulting particles to disk as a PRT file.
*I loaded that file in C4D using a default PRT Loader without any adjustments.
*Then I created a default C4D Sphere that also happens to have a Radius of 100 cm.
RESULT: My PRT Loader particles matched the C4D Sphere.
*I went back to Max, changed the System Units to 1 GU = 1 Meter and Reset the scene.
*I recreated the same setup, but this time my Sphere had only 1 meter (1 unit!) Radius, so I had to set the PRT Volume’s spacing to 0.04 to produce the same number of particles.
*I saved another file (which had about the same size) and loaded that in my C4D scene which was still set to Centimeters.
RESULT: My PRT Loader’s particles still matched the C4D sphere because the PRT Loader found a scale factor inside the PRT file and scaled it up 100 times to be 100 units in radius instead of only 1.
Also note that in Max, the Z axis is the up axis and the Max PRT Volume fills up the volume from bottom to top along it. When I loaded in C4D and increased the view percentage from 10 to 100%, the Sphere once again filled up bottom to top because the PRT Loader automatically converted the Max Z-up to the C4D Y-up coordinate system.
I will perform some tests with BIN files to see if the KC4D PRT Loader handles them correctly.
That being said, you can freely SCALE a PRT Loader - just go to its Coord. tab and enter a Scale factor, e.g. 100.0, and the particle cloud should come in 100 times larger. The scaling will correctly apply to the Velocity vectors, too.
Thanks for your reply Bobo, it is good to know we can scale the PRT Loader and maintain the correct velocity data.
I’ll do some more tests between RF2013 & C4D and let you know what I come up with.
Thanks
Tim
There is your error, if you want to work flawlessly with Cinema 4D to RealFlow you have to set thr geometry scale in RealFlow to 0.01 in the preferences and axis setup to YZX btw 
Really? I’ve worked flawlessly with Realflow & C4D on many projects. Anyway… I tried what you said and it isn’t possible, the geometry scale won’t go any lower that 0.1 (RF 2013).
I tried Bobo suggestion of making a cube and filling it with particles. I tried using project units of metres in C4D, display units as metres, to check the scale issue with C4D, I created my default cube with metres as the project unit (cube = 200m), then I closed this and merged with a scene using cm as project units (cube = 200cm), the merged cube came in 100 times larger (correct result).
However in all my tests between RF and C4D, the PRT loader was always 100x smaller than the geometry and the RF imported particles, I tried saving .bin and .prt from RF. I guess we have to wait for RF to support the scaling metadata in PRT and until then the only solution was to scale the PRT Loader 100x in the C4D coordinates manager.
To add to this, I tried using the repopulate tag on the cube of particles, at the default settings the new particles were spread too far and looked like a bunch of noise (didn’t maintain the cube shape), I reduced the fill radius to 0.05 and then it seemed to work better, so I’m guessing that we have to recalculate the value in the fill radius as it isn’t accounting for the scale up of the PRT Loader? Although that would suggest using 0.01 for fill radius and that value seemed too low as I had clumping around each existing particle. So my question, does the repopulate take PRT Loader scale into consideration?
Thanks
Tim
No, all object-space operations (including all Tags like Repopulate) occur before transforms.
I will log the RF BIN scale issue as a bug.
You can set the geometry scale inside the RealFlow preferences to 0.01. If typing isnt working in RF2013 due to a bug you can paste the value in via notepad.
But to simply test this, try making a cube that has 10cm edge size and fill it with particles in RealFlow. Resolution 1 means 1 particle per litre, so you might want to increase that and eventually see the particles amount in the 10cm sized cube will always resemble the resolution value.
I don’t know what kind of projects you been working on in RealFlow but keeping the realistic scene scale in mind is crucial to yield physical plausible results. The default grid inside RealFlow is in meters btw.
So I assume the prt loader works properly by scaling the the particles you created honoring the internal meta data. I always set the scale in the RealFlow particle loader to 0.01 to match the geometry I worked with in Cinema 4D. Actually the scaling option in the plugin was my request;)
hi Tim,
"Created a particle sim (all realflow scale prefs at 1.000) " is wrong, i can second that what TylerFx says.
RF<->C4D workflow has ever since been affected by a scaling factor of 100, which means in RF you have set your Global Scene Scale in the Prefs to 0.01.
Then it should work fine.
hth
fuat
Thanks Daniel & Fuat.
