I tried loading PRT files from RF 2013. It seems they come in with the Z and Y axes flipped. (I wonder if this is because my RF is set to Y up.)
Any thoughts on this? What is the simplest way to flip them correctly?
Thanks.
Switching RF to Z up didn’t seem to help either. I guess I just have to rotate my PRT Loader.
This is nothing new.
Loading BIN files from any version of RealFlow should flip the axes correctly. But we haven’t tested RealFlow 2013 yet.
The next version of Krakatoa will support PRT 1.1 file format which will contain information about the coordinate system and scale of the source application. Unfortunately, RF 2013 came out before we could finalize the new PRT specification, so for now PRT files from RealFlow will require some rotation and scaling.
RealFlow uses a Y-up, left-handed coordinate system, so simply rotating the PRT Loader does not solve the problem.
Max uses Z-up, right-handed coordinate system, Maya uses Y up, right-handed. So all three use different coordinate systems. Yay!
The correct transforms to turn a PRT Loader with RF PRT files into the same coordinates as a PRT Loader with RF BIN files are:
*Rotate the PRT Loader with the PRTs at -90 about X
*Scale the PRT Loader at -100.0 along Y
The equivalent in MAXScript is:
$.transform = (matrix3 [1,0,0] [0,0,1] [0,1,0] [0,0,0])Hope this helps.
Thanks, Bobo. That is exactly what I ended up doing. Forgot the scale at first and was trying to figure out why I could not get the same shot I had in RF 
Then I figured it out and flipped it.
Is it fastest to do that to the PRT Loaders or to the Frost? I have 6 loaders… I wonder if a single transform of the Frost would be faster than 6 transforms of the loaders.
Thanks again!
In theory, transforming the Frost should be slightly faster, because the particles would be loaded directly into it. With PRT Loaders, the particles are loaded once into the Loader, and then again into Frost, thus also using more memory. But I don’t think you would be able to actually notice the difference.
I personally prefer using PRT Loaders because you get all the benefits of independent count controls, Magma modifiers on the stacks, independent channels and materials and so on. Flexibility is usually more important than a few milliseconds…
I totally hear you on the flexibility of using PRTLoaders. In fact, I pretty much require the magma modifier as I am using it to generate vertex based masks for a VRayBlendMtl and custom vertex colors to feed into the Fog parameter of the base material (VRayBlendMtl does not blend the Fog color (which is the color that adds density inside a transparent surface, not fog like environment fog… dumb name on VRay’s part if you ask me). It just uses the fog color from the base mtl.).
I was referring to transforming the Frost even with using PRTLoaders. Rather than loading the particles into Frost directly, and rather than transforming 6 (in my case) PRTLoaders. However, this remove the ability to toggle the particles off and on in place as a faster stand in to Frost.
When Frost is loading particles from scene objects like PRT Loaders and other particle sources, it does NOT apply its own transforms. So each particle is in fact transformed only once. This means that you can place the Frost icon anywhere.
When Frost is loading files directly, its own transforms are applied to the files. So the placement of the Frost icon matters.
But in both cases, the transforms are performed only once per particle, so there should be no difference in performance.
As I mentioned, the main difference is in the memory allocation - PRT Loaders have their own memory cache, and Frost has to load them in its own memory, so you end up with two sets of particle data in memory. That’s where any potential difference would come from, esp. if loading 100 million particles
Ah, OK. I must have been confusing Frost with Stoke, which,if I recall, can transform input particles…
BTW, What would be the MOST memory efficient setup for loading high-density particles in PRTLaoders, applying some Magma modifier stuff (including using selection and delete to chop off areas outside my field of view), and then using Frost?
I have some Frost meshes that eat up a LOT of RAM, and then when I tweak the VRay BSP for performance as well that eats up a few more gigs. This is fine on RAM-laden workstations, but some of our render farm machines have smaller amounts of RAM. Short of buying more RAM (which I have already upgraded four of the nodes, and about to do another four) I am trying to determine the MOST memory efficient settings, assuming I need Magma modifiers (and thus have to use the PRT Loaders).
I have already reduced the Frost Resolution to as low as is acceptable, and reduced the Vertex Refinement as low as I can as well. I also set the radius as high as I can get away with.
Do any of the viewport settings matter when using BackBurner? Should I be turning off the viewport display for BackBurner rendering?
Thanks.
Possibly the best approach would be to resave the transformed and Magma-modified particles to disk and load them directly in an untransformed Frost (placed at the world origin). This will waste twice the amount of disk space and require some time to bake all particles to new PRTs, but you will have half the memory usage for particle data as you can get rid of the PRT Loaders completely.
This is of course only possible if you are happy with your Magma results and don’t intend to tweak them often.
Vertex Refinement does not affect the amount of geometry, just the placement of the vertices relatively to the isosurface. So it produces finer meshes, but not more vertices. Keep it at default (10 or so). It is lowered for viewport because of performance concerns (which were proven wrong anyway, it is fast), and not because it affects the geometry complexity.
No, viewport settings do not matter at render time on BB or Deadline. They are meant for your interactive display in the viewports in workstation mode.
Another alternative would be to cache the Frost using XMesh, or VRay Proxies. This way, no particles will be loaded at render time, only the pure mesh. In the case of VRay Proxies, VRay will load on demand only the portions of the mesh it actually needs.
Wow. Some really great info, thanks.
How much memory do the particles take up? I turned off all the channels I did not need in RF (in the prt export).
To bake out the magma modifiers I would need the full version of Krakatoa, right?
When rendering is there a chance to purge the memory used by the particles after the Frost mesh has been created? This would free up some memory for the BSP tree. IN general does Max load hidden objects? Or only when some other plugin requests them?
I am trying a VRay proxy now. That looks like it might be a really good solution. My preliminary test worked well. Though it looks like the viewport resolution is what is exported.
Speaking of viewport resolution what are the rules with PRTLoaders and viewport resolution with Frost? I have set the viewport resolution to 100% on the loaders otherwise I get weird results. (Even when doing every Nth by id. But by weird they are probably correct for the fewer particles… just not useful for me as a preview…) When it renders will it use the render time settings when Frost requests the particles form the PRTLoader?
Thanks again.
Depends on the channels. 32 bit Vector channels are typically 12 bytes per particle. ID channel might be 4 or 8 bytes. Assuming you have 32 bit channels for Position, Velocity and ID, you would have 28 bytes. 1 million particles would then be 28,000,000 bytes, or 26.7 MB. That is not much.
If you read on, you will see it probably doesn’t matter anyway…
Wrong, it works with in license-free mode.
I talked to the developers and it turns out that the PRT Loader will most probably NOT use any memory at render time in VRay, it will stream the particles to the Frost object. The duplicated memory consumption applies to the viewports since the PRT Loader has a dedicated viewport cache to speed up redraws. Thus, baking the particles for direct Frost loading would be a waste of time and resources.
Max does not load hidden objects for rendering unless another object depends on that data. So if you hide the PRT Loaders, Frost will still request the particles to be loaded and evaluated so it can use them.
Frost can use either the viewport particles, or the render particles. When you start rendering, Max switches to a special mode which causes all objects and modifiers that are aware of viewport/render modes to evaluate correspondingly. Both Frost and PRT Loaders respect these modes, so by default the viewports will use the viewport settings of the PRT Loader, and the viewport meshing settings of Frost. But you can check the option in Frost to “Use Render Particles” in the Viewport, so your mesh will show the same particles as the renderer would use (typically 100%). This would be useful for Proxy generation. Make sure you set the viewport settings to match the render settings regarding Resolution.
When you send the scene to render, Frost will generally use its own Render Settings, and the PRT Loader’s Render Settings. Frost has the option to “Render using Viewport Settings” for the cases where you like what you see in the viewport and are too lazy to copy all parameters into their Render counterparts. But the particles will always be taken from the Render state of the PRT Loaders at render time.
Again, great stuff.
I was able to optimize my magma modifiers, which helped a lot. I had my vertex maps set to 32bit float. I set them to 16bit half-float. (not sure if that actually affects what is stored in RAM) I also stuffed the values into three different channels of two maps rather than six different maps. I used TextureCoords as one of the maps, wondering if that one was allocated regardless. Basically I was wasting a lot of memory and size in the VRay proxy files. I got he VRay files form ~470 megs per frame to ~130 megs per frame with this change. So it is definitely saving the maps top the proxy (if it didn’t my surfacing would not work right).
When I first set up the magma modifiers I used the mantra “make it work, then make it fast” from CS class… I knew I was wasting space using a separate vector(3 channel) map for each single channel map I needed. But it was cleaner to look at. My combining them I saved a lot, though. It also seems to have reduced memory usage and time during Frost generation, though I did not specifically measure.
And way cool that I can output the particles in license free mode. You do that from Krakatoa? Or is there some other way to save them out?
Yes, although you probably don’t have to do that at this point.
Basically, you open Krakatoa UI, switch it from render mode to “Save Particles To File Sequence” mode, specify an output path, make sure the desired channels are selected for saving, enable only PRT Loaders source option, unhide the PRT Loader you want to bake and hit the SAVE PARTICLES button (make sure the right time range is selected). This way, you can combine multiple PRT Loaders into one PRT file, resave PRTs with the Magma and other modifiers baked, create proxy PRT sequences with less particles (just use Every Nth) etc.
Remember that the saving is always in world space, so if you want to preserve the original positions, you might have to uncheck the “Use Transforms” option of the PRT Loaders to make them appear aligned to the world origin. But if you want to bake in the Transforms, you can do that too. When you load the resulting pre-transformed files, you have to put the Loader or Frost at 0,0,0 to avoid applying further transforms…
We have discussed creating dedicated tools for resaving particles, but since Krakatoa can do it already the way I described, it has always been pushed back. We’d rather add things that it cannot do yet