AWS Thinkbox Discussion Forums

skip particles for meshing

Hi,

at the moment I’m playing with my 30 day Naiad license :smiley: and did a quick test of a waterfall. I ran the sim a few days ago and wrote EMP files. Now, I converted them to PRT and loaded them inside Max 2012 with a PRT Loader. I tried to mesh the particles with Frost but I think my machine at home doesn’t handle the meshing process of 1.2 mil particles very well. Waited around 30 minutes for the Frost object to be updated and then cancelled the rendering. My actual question is if there is a possibility to skip particles for rendering like you can skip them in the viewport (à la “Every Nth Particle”) because I think I could mesh with much less particles and still get an acceptable result for the shader development. I think I already tried to set the PRT Loader to render only a small number but Frost wanted to have all of them :unamused: but maybe I did something wrong there. Thanks in advance!

Take care,
Dziga

Okay, my bad. I found the check box under meshing quality :blush:

There is no reason I can think of for Frost not to be able to mesh 1.2 million particles in less than a minute. How is the behavior of the counter in the bottom of the 3ds Max UI? Does it count to over 90% and then lock up, or does it count very slowly? What meshing mode do you use? How is your memory usage in Task Manager? How much memory do you have?

Some other things to keep in mind: Naiad outputs in Meters. Depending on your 3ds Max settings, you might have to do some scaling of the PRT Loader or pick the PRT file in Frost directly and select the right File Units to produce a reasonable sized cloud to mesh. Start with “Union Of Spheres” and make sure the Particle Size is set to a meaningful value. In general, Frost is supposed to use only around 500MB while processing the mesh, but if the Particle Size is too small, it is possible that the final mesh could be multi-million polygons and Max could choke on it if it does not have enough memory. Also note that Anisotropic meshing is significantly slower than all other modes.

I have here Naiad sims with 50+ million particles and they mesh in under a minute with 8 cores and 12 GB of RAM. I am very interested to find out why your 1.2 MP do not mesh correctly (read: fast)! :slight_smile:

AAH I am reading fast :smiley:

Well, I meshed 1% of the particles in the viewport with Anisotropic °ᴥ° and this was quite fast. Only, when I press F9 for a quick render the render popup hangs at “Updating Object(Frost)” (or similar, I am not at home right now to get the exact wording) and I don’t get info on the progress at the bottom at all so it might crash even before starting to mesh. I work on an i7 2600K with 32GB memory, so this shouldn’t be a problem here. Also, the task manager shows 100% CPU usage and the memory load stays at around 8GB with my scene, it doesn’t load more into RAM. After some time the CPU load sinks to 70% and then increases again to 100% as if it tries a new run.
I noticed the small scaling when importing the PRTs and just scaled it up manually until I had a good size of the cache and rotated it 90 degrees on the x axis. I remember using a fairly small particle size because I thought I want small splashes to be of a radius of about 3cm.

Gonna go home now and try your Union of Spheres method first and check for the message at render again. Thank you Bobo! Hear you soon.

Take care,
Dziga

So, I got the scene open right now and one thing somehow instantly hit me in my head…my problem could very likely be caused by Vrays memory limit that was set to 400mb. Normally, that’s one of the first things I adjust setting up my scene but I forgot it this time. I’m going to give it a chance now if it can update the frost object for rendering with a limit of 16GB. I’ll keep you updated :smiley:
When changing the method to union of spheres my size of 0,02m seems still to be too large so I might scale the loader again.

Update:

It took 12mins now to render the mesh with anisotropic. I guess that’s a reasonable rendertime for my quadcore. Maybe it’s a Vray issue that I don’t see any progress percentage at the bottom? It only shows “Updating Object (Frost003)…”. I’m gonna test it with the default scanline renderer and mental ray next.

Update#2:

8 secs with Union of Spheres (:
Another question: I want to color the mesh by velocity like in the tutorial of yours. I assigned a VrayMtl to the Frost mesh with a Vertex Color node connected to the Diffuse slot. Vertex Color map channel and Frost velocity map channel are identical and the Frost mesh shows my color by velocity like my particles but it renders the default vertex color colors (RGB). Did I forget anythin? I see in your tutorial you piped the velocity that was saved to map channel 3 in the Frost object back onto the particles but I actually just want to render my mesh as it’s displayed in the viewport, same color as the particles. That’s easy, isn’t it?^^

Are you using a Magma modifier to produce the Color channel? I am not sure which tutorial you reference, but I assume it is the one about RealFlow+Frost+Krakatoa.

The general idea is:
*Take the Magnitude of the Velocity, Divide by a scaling factor to bring it in the range from 0.0 to 1.0, then feed that into the 3rd slot of a Blend operator and blend two color InputValues, then output as Color channel.
*Enable Vertex Color display of the Frost and you should see the colors in the viewport.
*Assign the material with a Vertex Color channel set to Channel 0 to Frost and it should render exactly what you see in the viewport.

Do NOT enable the “Velocity To Mapping Channel N” option in Frost, since you are not interested in that. It is useful if you want to pass the velocity to a PRT Volume via a mapping channel. It should not break anything, but you are not interested in this data.

As for Anisotropic meshing, it has to search neighboring particles, and the more you have, the slower it gets. That’s why Union Of Spheres is the default, it gives you a vague idea about the particle sizes. It looks ugly, but is very fast to tweak. :slight_smile:

Yeah, I use a Magma modifier with almost the same flow. So, I wrongly specified another channel than 0 in the vertex color map and I don’t need the checkbox in Frost, i see. I’m doing a render right now to test my lighting setup and after that I will test your workflow. I moved forward to Zhu/Bridson :smiley:. This seems to be a proper compromise concerning mesh quality and speed. Typing these lines the rendering finished. Doesn’t look too bad:

UPDATE:

No matter what I try I can’t get a Magma modifier to work. I had one flow all the time that worked perfectly and right now it shows only black particles. Even when I assign a new Magma modifier, set the output to color and connect a vector input as color blue, the particles stay black in the viewport and render. Lights are still set. I restarted Max but this didn’t help either. I didn’t touch the PRT loader while working on the mesh so I really don’t know what’s up :confused:

Quite possibly you have assigned a VRay material to the PRT Loader by accident. Since Krakatoa does not know how to deal with it, it might be producing a Diffuse color of 0,0,0, thus overriding the Color channel coming up the stack (Magma is evaluated in object space BEFORE the Node Transforms and Material Assignment). To see if this is the case, just check the “Ignore Material” checkbox in the PRT Loader - if the viewport becomes colorful again, you have an unwanted material assignment. There is NO such checkbox for rendering though, but you can fix it by removing the material from the PRT Loader. In older Max versions, you would just drop None material on it, but now with the new Slate ME and picker, you must use MAXScript and say

$.material=undefined

The alternative fix is to switch your Magma to output to Mapping2 or higher, and use Vertex Color Map on the same channel.

Thanks, that worked perfectly. Too bad I need to get to work now and can’t try the Frost shading (:

I did exactly what you said and finally it worked :smiley:
I wish I had created the vorticity channel in Naiad…but maybe it’s better that I didn’t because I really need to spend some time on two short film shots now and stop playing around ;D
Thanks for all you effort.

Kind regards,
Dziga

Privacy | Site terms | Cookie preferences