Below you will find two images. The first shows 3 million particles loaded one of 5 particle partitions. The second shows all 5 particle partitions, about 15 million particles.
The second one has the “influence” density reduced by a factor of 5, to compensate for the increased “spacial” density.
Notice two things, one that the lighting is very much changed, and also that the graininess of the particles is not reduced. Is this normal?
EDIT: The color is set with script vector, the density is set to No Density Scaling, I’m controling the desity spacially.
I’d suggest rendering each partition individually, and doing image comparisons between them. If something went wrong in terms of randomizing seeds, they will look the same, and rendering them together won’t reduce the noise. If they all have different grain patterns, putting them together should reduce the graininess.
The factor of 5 should be right for maintaining the same lighting. Some other factors, like the size of the attenuation buffer’s map (it uses the shadow map buffer size), can affect it too. Using a really high resolution map will let more light bleed through because there are gaps between the particles drawn on the buffer.
-Mark
I’d be interested to hear what baseline strategies people are using to reduce graininess in rendered Krakatoa passes.
Currently every single batch of comments coming back from our senior compositor contains the fatal phrase “Still too much graininess”.
- I’ve tried raising motion blur as high as 32 passes
- I’ve rendered massively oversized passes, then scaled them down
- I’ve spent entire days tweaking and balancing Lighting Pass Density, Final Pass Density and shadow map density
Obviously most people are getting good results … so what are your magic settings?
Well… there may be a problem with how the particles converge on a solution that may prevent renders from ever not being grainy. I need to do some more testing on this front.
The problem I saw was that I could never get the particles to render smooth, no matter how many particles I added, as if the render saw a limited number of particles in a pixel and stopped at that point. Might be different now? The shadows were definately compounding the issue. Check to see if it’s the particles on the shadows that is the problem.
Or it might be that the particles themselves, for whatever reason weren’t totally random. That’s why I was asking before about the precision in the PRT files (according to Bobo, it’s 32 bit per component, so it’s unlikely that that is the problem).
I can make some controlled experiments, I just haven’t had time to yet, as I’ve been doing production work.
As to my current setup, I’m adding depth of field to compensate when possible, and the rest I’m fixing in the comp. A mix of different filters and such.
>- I've tried raising motion
>blur as high as 32 passes
Doesn't help unless you jitter the camera.
>- I've rendered massively
>oversized passes, then scaled
>them down
Doesn't help because the number of particles per pixel is reduced, so you lose density. It's weird, but if you make a ball o particles and place it 100 units from the camera, it looks solid, but move it 1 unit from the camera and you can barely see it. Unintuitive, but perfectly normal. Raster is just weird like that. Maybe post 1.0 we will get variable sized splats.
>- I've spent entire days
>tweaking and balancing
>Lighting Pass Density, Final
>Pass Density and shadow map
>density
Actually, that's not a bad plan. Before we had shadow density control, it was much harder to refine the softness of the object.
Unfortunately, loading the particles and processing the lighting takes a long time, so there's very little you can do to optimize it.
If we had the ability to do a region render where say... Only particles within a box defined by 2 point3's were used, maybe then we could more effectively tweak the look? It's just painful when every test render takes 20 minutes and there's no obvious way to speed things along if you are adjusting the number of particles loaded.
- Chad
One easy thing that seems to remove graininess is to reduce your shadow sizes to silly small. Like 20.
It’s inaccurate, but very pleasing to the eye.
The top one is 28 million particles, with shadow map size of 1024.
The next is shadow map size of 10. Notice lack of grain.
The next is shadow map 30. More grain, but more accurate shadowing.
Last one is 2.8 million particles, or 10% of the original. Shadow map = 10. Here you see the lack of particles causeing grain because they don’t smooth together nicely and fill the volume.
Hey Chad,
Very Interesting experiment images there!! One question though - the shadow/light balance is very consistent between each of the images. Did you have to do any tweaking of densities to achieve that, or was it not affected when you changed the shadow map size?
When I tried tweaking the shadow maps to a smaller size here, the particle cloud lit up like a Christmas tree…
No, all I changed was the shadow map size, except in the last one, I changed the PRT load percentage.
Otherwise all settings the same.
The shadow WAS set to a density of .7 on all images though. Even that is high for me. Most of my shadow densities are in the .3-.5 range. I just happened to need this bone model to be very opaque, so I used this density. I do soft tissue with much more translucency.
- Chad
I’ve been doing some tests with static particles and lights and a moving camera.
The grain is “ok” on any single frame, but when the camera moves slowly, the shimmering of the grain is terrible. I’m not sure if it is a bug or not, but even with VERY high densities (~million particles per pixel?) I see the problem.
- Chad
Chad,
Can you get us a max scene or PRT file that we can work with?
I’m going to try a simple test to confirm. Sending 350 million particles won’t make my IT department happy.
- Chad
I’m going to try a simple test to confirm. Sending 350 million particles
won’t make my IT department happy.<<
Even if it took a week to burn and mail a CD or DVD, it would give us
something to work with before we release the software. We’d like to work
with one of your datasets because they are created a bit differently than
ours from Pflow, TP, or Flood.