PDA

View Full Version : Dancing edges? dancing lines? flickering lines?



Opusnet
02-14-2008, 10:29 PM
Hi there everyone...

Have not been here for ages. Thus forgotten my previous username and password, so here i am again...

Not sure if this is the best place to ask this, i have this problem with the look on the rendered edges, it got worst during playback on tv.. see attached on 01-04.jpg. During playback, those edges that i boxed out with arrows were actually "dancing", "moving steps", "flickering", really dont know what is it called. Im using Lighwave 8.5 and rendering with FPrime 3, 25frames/sec, 1 frame around 10-20mins to render for SD size. Now a few of my projects are going to HD... i guess i have even more problems! See attached 05_Perfect.jpg, was done by someone else so i cant show them in full, is perfect... no problem on the edges! how did they do it?

Below are some of the steps i have tried,
1) Render them in field, but TV nowsaday are LCD.
2) Render them with motion blur, doesnt help
3) Render them in higher resolutions, then post side shrink down, it did help but arent good enough.
4) Render longer, same results
5) Tried using Lightwave's render with adaptive sampling unchecked... same results and it took much more time to render compare the FPrime because im using Area lights.

Anyone out there faces the same problems? or anyone know how to deal with it.. thanks a lot.

Surrealist.
02-14-2008, 10:56 PM
It looks like basic AA issues to me. Have you tried to render a few frames with the AA kicked up high? Also which camera are you using? The AA is different in 8.5 than in 9.0 but I think we got the perspective camera in 8.5 but with a different AA.

I would not consider field rendering as a solution. I would keep it progressive even in SD.

Opusnet
02-14-2008, 11:01 PM
Im using FPrime 3.0, does the setting on the Lightwave's camera Antialiasing have any impact on it? Im using D1 (Pal Widescreen).

jameswillmott
02-14-2008, 11:19 PM
FPrime's antialiasing has nothing to do with any setting in Lightwave, v9.3 of Lightwave has Oversampling, which lets you increase the radius of the antialiasing samples, setting it to 0.25-0.5 would probably help those issues you're having. LW9.0 renders faster than 8.5 too so you might get enough speed out of it to not worry about FPrime for your rendering if it's not handling antialiasing the way you want. You can grab a demo of 9 to trial it if you want.

Exception
02-14-2008, 11:20 PM
Hey opusnet, read the tutorial about AA in my signature... the issues lies in your base AA being too low to be detected by Adaptive sampling. Easy to resolve. This only applies to LW native negine though, not to Fprime.

Your Fprime issue has to do with HDR values being out of range of AA. Theres not much to do about it except let it cook for longer, or prevent highly exposed values.

, Cheers!

Opusnet
02-14-2008, 11:36 PM
Hi Surrealist, jameswillmott and Exception.

Thanks for the fast reply. Seems like i have to switch back to LW's native render engine.. hmmm... oh my.. is slow. I have not tried 9.3 yet but i do believe that is still much slower than FPrime.

So highly exposed values will result such problem? because is too contrast?

Exception
02-14-2008, 11:40 PM
So highly exposed values will result such problem? because is too contrast?

Yes, the contrast is in the High Dynamic Range. This causes much longer rendering times to resolve in Fprime, or any other endering engine. In the native LW engine you can turn on 'limit Dynamic Range' which will solve these issues. Fprime does not support this.
Although Lw native can be slower than Fprime in some circumstances, when yuo use the right settings, you can actually be MUCH faster as well.

The questions is... do you have objects or lights moving in your scene?
If not, with Lw interpolated FG radiosity and radiosity caching you should be able to render much faster than Fprime.
If you do have moving objects / lights, you're stuck with Fprime, or use Kray's interpolated GI method.

Opusnet
02-15-2008, 12:11 AM
Thanks for explainning Exception,

All of my animations have moving objects, but not so much for animated lights infact not at all. I try not to use radiosity, GI to my animations, mostly normal lightings. My previous attachments, only the living rooms were rendered in radiosity, the rest are normal lightings using Area lights.

So i guess if i wanna continue using FPrime, i have to reduce the highlights.

Exception
02-15-2008, 09:07 AM
I know this isn't what you'd like to hear but my advice would be to continue to use Fprime to preview your scene, and set the scene up so that it renders fast in native LW. Be sure to upgrade to the last version (9.3.1) and to use proper AA and area light quality settings (low area light, adaptive sampling) and so on...

Another way to reduce this effect is to save out to an HDR file and use corona or bloom to blur these bright areas...

But perhaps easiest would be to tone down the specularity of these surfaces. But that is perhaps not what you want.

Lego Maniac
02-15-2008, 10:21 PM
You're not seeing aliasing at all. It's not related to the renderer or the AA settings or the filter.

Your image viewer is just clipping the output image which is too bright to display all the pixels. Those "ugly edges" are just where the clipping starts.

If your pixels have values like 0.8 0.9 1.0 1.1 1.2 1.3, it's a smooth gradient, right? But if you clip the values, you get 0.8 0.9 1.0 1.0 1.0, and that sudden transition looks like an ugly edge right at the point where the pixel saturates. That's because you're not displaying the pixel's proper intensity, it's been chopped off.


Easy answer: render to a high quality format (EXR, probably) and use a high dynamic range viewer. Or just reduce your brightness to get it all in range.

Exception
02-16-2008, 10:41 AM
You're not seeing aliasing at all. It's not related to the renderer or the AA settings or the filter.

Nono, that's not quite true...
although what you say is the cause, AA cannote resolve this transition due to the level of brightness difference (contrast) between the bright an darker areas.
Viewing it in an HDr viewer (which lw's native image viewer FP is) will allow you to lower the contrast but that'll change the entire image, not resolve this effect locally.
For AA to properly resolve this it needs to spread and create a larger transition zone. That can be done in Fprime but only by cooking for a very long time, and in extreme cases not at all.

Rendering to LDR solves this, and as said before, reducing the brightness of those edges too.

Lego Maniac
02-16-2008, 03:46 PM
More AA won't help, it is already smoothly AAed, you just can't SEE it because of the clipped intensity. If you don't want to change the entire scene brightness you could apply a post filter to roll off high intensity pixels more smoothly than a clip like image viewer uses. This is awkward because it can cause color shifts, but so does clipping.

Another workaround is to reduce the brightness of the surfs that are too bright.

Exception
02-16-2008, 04:26 PM
More AA won't help, it is already smoothly AAed, you just can't SEE it because of the clipped intensity.

If the AA band is widened you can for sure AA out of range pixels, within limits. It just needs a larger transition zone. Fprime keeps resampling these areas, and if they're not far out of range they will AA smooth eventually. for instance Michell AA filter has a wider band than the standard classic filter and is better able to handle these areas.


Another workaround is to reduce the brightness of the surfs that are too bright.

Yeah, we've suggested that a few times.

Solutions are:

- If not out of range for AA to solve: let cook longer
- Render with 'Limit dynamic range' on in LW
- Use Corona / bloom to blur these areas
- Reduce specularity or diffuse brightness (depends on material)
- Use a tone mapper (will affect the rest of the image too) (or 'local adaptation' HDR mode in Photoshop, but I don't like that one)

My preferred one is to use corona. I usually use "better bloom", you can get it on flay.

Opusnet
02-17-2008, 10:59 PM
sorry guys, im not around over the weekends.

Thanks Exception, Lego Maniac, jameswillmott and Surrealist and for all the helps.

I will try all the solutions that you all brought up, first step i will upgrade to 9.3.1 first! :)

Captain Obvious
02-18-2008, 01:52 AM
One way to deal with "superwhite" pixels in FPrime is to render to lower quality at double resolution, in a low dynamic range format. So instead of quality 20 at 1000 pixels wide, you render to quality 5 at 2000 pixels wide and then scale it down in Photoshop or something such. The general quality will be roughly the same, and the render time as well, but problematic aliasing issues will typically be reduced as well.

It's not a perfect solution, but it works quite well.

Exception
02-18-2008, 09:21 PM
It's not a perfect solution, but it works quite well.

Yes!
That is indeed a good one...

Captain Obvious
02-19-2008, 06:08 AM
One way to deal with "superwhite" pixels in FPrime is to render to lower quality at double resolution, in a low dynamic range format. So instead of quality 20 at 1000 pixels wide, you render to quality 5 at 2000 pixels wide and then scale it down in Photoshop or something such. The general quality will be roughly the same, and the render time as well, but problematic aliasing issues will typically be reduced as well.

It's not a perfect solution, but it works quite well.
Just to clarify this technique:

In FPrime, everything's treated as HDR, regardless of the output format. That means that if you have a pixel made up of 9 anti-aliasing samples, 8 black and one that's 900 % "white," the pixel output will be the average of that, which is 100 % "white."

If you were to render at 3 x the resolution, you'd end up with 9 pixels with 1 AA sample each. Suppose one of those pixels has a value of 900 %, and the rest are black -- same as before. If we now output to a low dynamic range format and scale it down, this will be trunkated at 100 % and the average value of the nine pixels will be 11 % instead.

This is effectively the same as ticking the "limit dynamic range" option in Lightwave.

Exception
02-19-2008, 07:41 AM
This is effectively the same as ticking the "limit dynamic range" option in Lightwave.

It also works when rendering to HDR and rescaling it in PS (or VirtualDub) after you have performed operations that require HDR... and then having it saved to low dynamic range. So apply bloom, do some curve adjustments, Virtual Darkroom etc. This means you can have the advantage of both. In the end it needs to become LDR anyway for animation.

In fact I've been rendering like that in Kray for the last week for a long animation. A bright window was messing up the AA, so I halved the AA and doubled the resolution... it works well.

Captain Obvious
02-19-2008, 10:19 AM
You can also use the not-yet-in-the-GUI command limitdr 1;. That will limit the dynamic range to "white." However, since it's a scalar instead of a boolean, you can actually do limitdr 2.5; or something such. That will limit the dynamic range to 250 %, so you retain some dynamic range and you get rid of a certain degree of burnout.

Exception
02-19-2008, 11:39 AM
You can also use the not-yet-in-the-GUI command limitdr 1;. That will limit the dynamic range to "white." However, since it's a scalar instead of a boolean, you can actually do limitdr 2.5; or something such. That will limit the dynamic range to 250 %, so you retain some dynamic range and you get rid of a certain degree of burnout.

Yeah I'm aware of that, but you do not want to limit HDR if you're using bloom or Virtual darkroom.. that's really not a good idea.
although ldr at a higher than 100% range offers interesting possibilities (and troubleshooting)...

silverlw
02-20-2008, 04:15 AM
you may also use the more prefered limitdr -1; wich will try to apply adaptive dynamic compression depending on the lightsituation. I always use that.

Opusnet
02-22-2008, 01:26 AM
Yo guys,

Ive tried using 9.3.1 on the same scene, look what i got. See attachment. :(
The one on the left was rendered using the Classic camera, where else the one on the right was using Perspective/Real lens camera. They moved the polygons! or is it my settings? Im still new to 9.3.1. Thought it will solve my flickering problems, but it surprised me with another one! help

Exception
02-22-2008, 10:25 AM
It's a bit hard to see what' going on there.. can you share the scene?

Opusnet
02-25-2008, 10:52 PM
Hi Exception,

Attached are the scenes and object.

I saved 3 types of scenes, the difference are the types of camera used.

1) Classic Camera: No problem
2) Perspective Camera: Poly error
3) Real Lens Camera: Poly error

The perspective and Real Lens camera have more settings on the Antialiasing than the Classic ones, so thought of using them.

Regards.

jameswillmott
02-25-2008, 11:05 PM
Non planar polygons? Perspective camera doesn't like them...

Opusnet
02-26-2008, 01:03 AM
very weird, there are actually many non-planar polys in the object (the one that wasnt minimised till that small piece that i attached), but only this "H" is showing error. :(