Blender’s a fantastic program, but Boy! does it have some difficult-to-deal-with problems…
I have a five second clip I’m trying to render that is mostly static except for about 1/3rd of a second which has a great deal of motion in it. So, I figured I’d render the static parts using OSA 8 and the parts with motion using Motion Blur and then edit them together. It’s a great time-saving idea… in theory. I wrongly figured that they’d end up at least looking similar.
But no; OSA and Motion Blur are very different critters…
Am I doing something wrong, or is OSA really not all that great?
Forgive me if I’m reading this wrong, but it sounds like you’re trying to say that OSA with its special algorithm is better than Motion Blur’s “just” stacking frames, despite the fact that Motion Blur is demonstrably better looking (if far more processor intensive)?
So, short of giving the jitter algorithm itself a tune-up there’s little that can be done about the absolutely breathtaking jaggies still present even at OSA16 (and the colour problems, too, such as the miserable bottom of the orange dome)? Short of just using Motion Blur, that is.
And there has to be more going on with Motion Blur than “just” stacking the same non-oversampled frame over and over. The object in my picture above was not moving at all and it still came out looking nice and smooth, as you can see (JPG encoding errors and 32 vertex UVsphere notwithstanding ).
Haven’t tried it yet, but it doesn’t seem like a good idea: The render time is no-doubt horrendously long, and multiplying the errors in the OSA jitter calculations cannot possibly be a good thing. Is there any practical reason to do this?
Forgive me if I’m reading this wrong, but it sounds like you’re trying to say that OSA with its special algorithm is better than Motion Blur’s “just” stacking frames, despite the fact that Motion Blur is demonstrably better looking (if far more processor intensive)?[/quote]
Not at all, I was just stating factual differences between the two methods.
Having done no personnal test on that subject, I’m not really in a position to state which is the best and why.
And there has to be more going on with Motion Blur than “just” stacking the same non-oversampled frame over and over. The object in my picture above was not moving at all and it still came out looking nice and smooth, as you can see (JPG encoding errors and 32 vertex UVsphere notwithstanding ).p
there’s probably some averaging matrix applying to each pixel mixing it with it’s neighbours, but that’s only an hypothesis.
NOTE: after some very short experiences, it seems like Motion Blur also uses some sort or another of jitter. Maybe the difference between both method would be the mixing algorithm used.
Haven’t tried it yet, but it doesn’t seem like a good idea: The render time is no-doubt horrendously long, and multiplying the errors in the OSA jitter calculations cannot possibly be a good thing. Is there any practical reason to do this?[/quote]
theorically, it multiplies by 16 the power of OSA.
Other than impressionning your 5 year old neighbour, no, I don’t think there’s any practical reason to do that
I suppose I should mention I’m using 2.27 with Unified Render turned off.
Understood now. And thank you.
For the heck of it, I just did some time trials on one frame of my animation. The results:
38 seconds – OSA16
3 min 9 sec – MotionBlur 8/.5
4 min 28 sec – OSA8 MotionBlur .5
OSA16 and MotionBlur 8/.5 are as you see them in the first post. The combo of the both has – as expected – the smooth good looks of the MotionBlur along with the problems of OSA16. It’s quite bizarre.
From looking at your 1st picture, esp in the top left, I can say that your antialaising definately isn’t working properly. Normally with AA oyu get 2, maybe 3 pixals “Blurred”, but looking at that place, it appears that there were none. Maybe there is a problem in the algorithm, or it could be a random bug, but normally AA is very effeicient at what it does.
In your OSA render, it looks like everything were antialiased, exept the top and bottom of the grille (the grey sharp parts)… The rest seems to be correct. Is there something different with the non oversampled parts like material or texture settings? Anyway that seems to be a bug, the problem is how to locate it…
Indeed. To that end, I’ve been doing some testing… First: A description of the object so people can – if they wish, try to recreate the problem. The item in my pictures is basically several cylinders and a UV sphere. It is not meant to be a particular thing; it’s an amalgamation of various parts of my scene that were giving me problems.
-=- The ‘struts’ of the object are groups of three long thin cylinders. They are pure white, set smooth and have autosmooth on. No other modifications from the basic material.
-=- The top and bottom grey rings are wide, flat cylinders that have each had one side shrunk (using scaling of the pixels around the object centre) to give it a beveled look. They are Blender’s default material, just set smooth.
-=- The central grille is the same as the rings, only shaped differently. It is black with Z-Transp and an alpha of .85. A simple crosshatch texture (a loaded image) was applied with Col and Alpha clicked.
-=- The orange ball is a UVsphere, set to an orange colour with Z-Transp and an alpha of .79 (along with various other material settings to give it a vaguely glassy look; high spec and hard, etc).
-=- The background is a world setting (blend clicked off) of pure white.
-=- And there are six lights in the scene, all spots, all pointing at the object. One directly above, one directly in front, one each to the left and right in line with the object, and one each to the left and right at 45 degree angles both in front of and above the object.
There are (at least) two, possibly related, problems under investigation here: [1] The grey rings not aliasing correctly against the backdrop. And [2] The orange dome and grille not aliasing well at all against the grey rings and the white struts.
For the figures below, I have added a blue plane behind the right half of the object to show any potential differences between aliasing against the World backdrop and against an object. All pictures are rendered with an OSA setting of 8.
Figures 1 and 2, below, are rendered with all the lights in the scene turned off. Figure 2 was intended to see if changing the background colour made any difference to the problems. Sadly, it doesn’t.
Interestingly, problem [1] is not present at all in either figure. The rings appear to alias correctly against the backdrops. Part of problem [2], however, is very, very obvious.
Figure 3 has the lights turned on and shows the same problems as before; both [1] and [2] are in evidence.
Problem [1] appears to be only occurring in front of the world backdrop, but if you zoom in, you can see that the same grey ring highly visible on the left is also present where it shouldn’t be in front of the blue plane. On problem [2], we can see that the blue plane is visible through the ‘crack’ caused by the grille’s aliasing error.
After playing around some, I discovered that turning ZTransp off ‘solved’ problem [2] entirely. No crack around the edges of the visible parts of the grille. No jaggies at the bottom of the dome and the grille. Hence Figure 4 – the now-familiar image, but with the ZTransp buttons of the grille and dome set to “off.” Note that they both still have their alphas less than 1, however, and that their colours both fade towards white.
Note also problem [1], still defiantly evident.
The final picture, Figure 5, has the alphas turned all the way up. Problem [2] is gone, as has been noted, leading to the conclusion that aliasing does not appear to work correctly at all with objects that are ZTransp enabled.
Problem [1] still lingers, but it appears from this evidence to have something to do with lighted objects. Perhaps the aliasing algorithm only checks against the base colour of the object and fades it into the background colour (like lowering the alpha if ZTransp isn’t pushed)? Or just cheats and fades things to grey, something that wouldn’t normally be distractingly visible (witness the ring in front of the blue plane), but becomes so with white objects and worlds?
Is there someone I should be bringing this to the attention of? Is there a bug reporting scheme set up for Blender?
Thank you for the info. It’ll be submitted shortly.
I’ve created an example .blend for anyone who wants to play with this problem (so we can see if it’s limited to 2.27, or my OS or computer type… etc). It can be downloaded from http://home.maine.rr.com/meanwhile/osa/osaerror.blend
hmm…intresting…i dunno if this will help, but with my experiences OSA anti-aliases mainly textures…and motion blur ani-aliases mainly edges…you can make a pic or anim. look good with just OSA on…i usually use the highest setting myself…but…if you want to go the extra mile, motion blur combined with OSA brings the overall quality even higher…but motion blur does make render time much slower! thats weird tho…when i use OSA or motion blur on objects with Ztransp. enabled on my system…it seem to work for me…maybe im just too blind to notice it! …
It is by no means certain that it happens on all systems. By all means, please download my .blend and try to reproduce the images presented above and then definitely let us all know what you find (along with what your ssytem is and what version of Blender you’re using).
I have noticed a problem very similar to yours when using a particle system to simulate fog. The fog particles (halos which - obviously - implicitly have Ztransp turned on:) make anything that is behind them look VERY jaggy, as if it had no OSA at all. Example:
from your alls pictures and analises, it looks like it has to do with transperancy…but i came up with some intresting results when i did my own little test…
ok, first here was the original scene with OSA8 inabled…
both problems are evident…
so, i tried to put it on OSA16…
both problems are a little less noticable, but ultimately still odvious…
next i tried using OSA8 + MBlur on 0.5
now after i rendered with motion blur, atleast to me, both problems have seemed to more or less vanish…im sure if you used OSA16 combined with Mblur it would be even more effective…i tried using OSA8 without ztransp. and i came up with about the same aliasing results as the previous picture with ztransp on…
so, it seems there could be a small problem with ztransp. objects rendering correctly, but it could be fixed with OSA+motion blur…but, none the less, it still looks like a minor bug…hope this helped , oh, and by the way my OS is WindowsME, and i used Blender2.27…
You’ve got a broken link on your pic…could you fix that for us? Great work on this…its amazing to see people who don’t even know each other put their heads together to solve a problem this complex…if only it worked in the middle east %|
Thank you for taking the time, TUDBZD69. So, we now have two instance of WinME and 2.27 having the same errors. So, it’s not just my computer.
And Intrr’s point about the halos was interesting to note, too. So, it now seems fairly definite that transparency messes up the OSA algorithm somehow. Here’s hoping someone on the programming end of things will take notice of this. I’ve posted it to Blender Bugs, so we’ll see.
Anyone running earlier versions of Blender or a different system willing to give this a shot?
Ah, and interestingly enough, in your test image (with the grille and the orange glass stuff), the nature of the rendering errors changes when you use the Unified Renderer.
Without it, aliasing appears on horizontal lines. With Unified turned on, the horizontal lines are perfect, but the aliasing occurs on the vertical lines!
).
…
, oh, and by the way my OS is WindowsME, and i used Blender2.27…
