AA quality differences

[djembeplay]

Does anyone know why these two scenarios yield different results (scenario B seeming generally superior):

A: I render a short animation in C4D at 2000x2000 without any anti-aliasing. Then, in After Effects, I downsample the image to 1000x1000.

B: I render a short animation in C4D at 1000x1000 using 4x anti-aliasing.


There are advantages to rendering a large file without anti-aliasing... only I couldn't do it on the past project I worked on because things like bumpy reflections would be very noisy and 'hard'. To try to better explain that with an example - I had a lake with small waves. The reflection, without AA, was a bit like colored static due to not having any blending with neighboring pixels.

This I expected, but thought it would be solved by downsampling the resolution to 1/2 x 1/2. I thought this would effectively give me one pixel representing the space where there was once 4, and would thus average them together equaling 4x anti-aliasing.

This did not work as expected, however.... so I must be missing something.

[Raptor365]

You ask the darndest questions.

For one thing, when you downscale to exactly half you blend the 4 pixels giving a weight of 25% to each pixel. If you anitalias a scene you get variable weighting on each of the 4x4 pixels.

A line traveling up a screen at 30 degrees would be weighted differently at each pixel.
If it was unantialiased for example at twice the size, the line would probably paint both pixels on it's sides with equal values or otherwise equal unweighted values or just miss the line completely on one of the sides, depending on the render engine, so blending it all together after that would yield inaccurate results.

Anyways, blending isn't antialiasing but I suppose it could be visually close enough in some cases like in your method.

[Raptor365]

This might show it better.

This is an unaliased line that is moving up the screen slightly to the right.
The black squares represent pixels and the white indexed squares represent
the resulting pixel areas if the picture was scaled to half.

If you scale it to exactly half, each 4 pixel block would get blended together resulting in 50% Green and 50% Red resulting in something similar to the second image which is still an aliased line.

http://i179.photobucket.com/albums/w289/TheRaptor365/misc/AA1.jpg

http://i179.photobucket.com/albums/w289/TheRaptor365/misc/AA2.jpg

And don't forget when you render an AA'd object, it's a mathematical model of an object so in this case a linear line. Antialiasing that mathematical line then would yield a 4x4 subpixel accuracy producing a much better representation.

Thanks for helping me procrastinate on my rigging tasks I'm supposed to be doing.
Rigging, arggg.

[djembeplay]

Hmmm... I see.

I think I'm a little lost on your line example. I read it a few times and am a little fuzzy. What do you mean by '30%'?

// oops - I posted in the same page that was open for a couple hours, so I didn't see your last response. Let me have a look-

[Raptor365]

I meant "...traveling up a screen at 30 degrees".:thumbup:

[djembeplay]

Haha, good luck with the rigging - I'm actually doing the same thing right now. I'm just trying to keep it as clean and simple as possible... otherwise I'll find myself fiddling and tweaking little things for hours at a time. I mean, ya there is always tweaking, but it seems like it increases exponentially if I do something like add unnecessary polygons somewhere.

anywho - back to the line - so your saying that downsampling the resolution of an image to half then the color of every block of 4 will be averaged? Red and green will turn into yellow, for example?


You said aliasing the line would equal a 4x4 subpixel accuracy - is that what 4x anti-aliasing is? Does that mean that there are actually 16 pixels averaged together for each rendered pixel?

//But also, those 16 pixels are not averaged together in a linear fashion like what downsampling / blending would do, right? That is where weighting comes into play? For example, the outermost pixels may affect the overall color and luminance of the rendered pixel by 5%, whereas a more centered pixel would represent maybe 15%? Or am I totally off?

[Raptor365]

..."downsampling the resolution of an image to half then the color of every block of 4 will be averaged?", that's right, if it's exactly half and no other blending/AA is going on.
If it's not exactly half then whatever program your using to do the downsizing may try to weight the pixels but it still wont be correct because it wasn't weighted properly in the first render.
Photoshop uses some algorithm when downsizing to blur and weight the pixels a bit, but again, the source render was wrong.

..."You said aliasing the line would equal a 4x4 subpixel accuracy"...
Another oops on my part. I meant a 4 pixel area (subpixel...antialias). In 3D that would have been a 2x2x2 cube which is probably what I was imagining...4x4...a cube and the number 4...cough.:Drogar-Dum(DBG):

///er wait, I was right the first time, it's 4x4, so your right 16, sub pixels, if antialiasing is turned on.
If it's off, there is no sub sampling and you still have the error. So even if you rendered at 4X with no AA the error would still exist albeit less noticable. Sorry for the confusion.

[djembeplay]

Heh, hmm... interesting.

So would downsizing a 16x16 image to 8X8 actually equal rendering an 8x8 image at 2x antialiasing (2x2)?

Hmm... that leads me to wonder if C4D calculates it's AA based on a 2D image, or if it is weighted somehow taking 3D space into account...?

Most importantly - tech theory makes us feel smart :)

[Raptor365]

So would downsizing a 16x16 image to 8X8 actually equal rendering an 8x8 image at 2x antialiasing (2x2)?

No because downsizing is just blending what you already have.
Remember that antialiasing blends together a number of weighted colors.
In the 2x2 example I showed with the pictures, the pairs of vertical green color squares would have been weighted, not solid as they are shown, unaliased.


...C4D calculates it's AA based on a 2D image

//Let me be more accurate.
A ray is sent out from a given screen pixel (Or image pixel/sub-pixel if you like), that interecpts the object in 3 Space, defining where it hit.
Those 3 space (World Space) coords are converted to Object Space and then to the objects Texture Space where the sample is taken from it's texture. Other things inlcude shadows, depth, ect.
That point of hit, when transformed to 2D space with decimal accuracy, also defines the amount of weight to give it.
For example, is this an edge of the object? If so, how far does it extend between this pixel (sample) and the next? Weight accordingly.

Then again it depends on the render engine doesn't it? I mean if they only take samples with no weighting then you get what you get, an approximation of weighting.

//Oh, and just for technical accuracy the yellow color I showed in my pictures had an RGB % value of (100,100,0) whereas it should have been darker (50,50,0) since it would have been 50%R + 50%G.

[djembeplay]

Hmm... I'm still not seeing the full picture.

So if all anti-aliasing is done on a 2D image (i.e. everything has been raytraced based on camera angle, lighting, etc. etc.) then there must be an in-between stage where there exists an aliased image, right?

Then, in that case, what information does C4D have about that image that another program like AE wouldn't... isn't it just an image map at that point?

Orrr... hmm, your saying that all the AA is calculated BEFORE the image is even created. But still, if it works in a 2D space, I'm still stuck on what the difference would be from AA and pixel blending a larger resolution bitmap.

^^ Ah, after reading your edit I think I'm beginning to understand... It's all about the weighting. So if there were no weighting at all, it would be the same as the pixel blending that occurs when down-sizing a large bitmap, right? Weighting actually takes into account certain properties that have to do with the objects location in 3D space, correct?

I'm picturing a square grid in that 3D space. Every square in the grid represents one pixel of my render. Out of each square are beams being shot out perpendicular to the plane. If there is no anti-aliasing, there is only one 'beam' per grid square. If there is 4x anti-aliasing, there are 16 beams per grid square. Each of these beams send back information that is used by a bit of code (the weighting) to calculate the overall averaged luma and chroma of the corresponding grid square...

Am I getting the jist?

So, in short, it's safe to say that internal AA is the only way to fly.

[Raptor365]

Well, while were on the topic and getting deeper into the pit of tech hell...

...the beams don't actualy shoot out perpendicular to the screen/plane/image otherwise there would be no depth, which is percieved as perspective distortion. The beam actually originates outside and center of the screen by some constant value that represents an eye. A ray originates there and intercepts a screen pixel (for purposes of explanation) to define the rays vectors path and then carrys on that path inside the screen to intercept/hit objects in the 3D space.

With antialiasing, the steps between each screen pixel is subdivided which would mean for 2x2 grid you would have 4 total traces for an xy of positions (0,0), (0.5,0)(0,0.5),(0.5,0.5) for a pixel of position 0, or that may be +-0.25 depending on how you attack it, whatever.

It's getting late so I'll pick this conversation back up tomorrow but I wanted to post this...

http://i179.photobucket.com/albums/w289/TheRaptor365/misc/AA4_Weighted.jpg

This is a 10x20 pixel image of a slightly rotated plane I rendered.
The first image has no antialiasing and the second has an AA value of 1x1 min by 1x1 max.

So, here's a question for you, is the apparent blending of the second image due to weighting of the plane's edge only, assuming 1x1 means there is only one ray per pixel being sampled, or does 1x1 mean +- 1 pixel, that is 1 pixel on either side,top and bottom and then a blend used with no weighting?

I'm sure it's due to weighting but I'd need to know what the exact definition of 1x1 is first as defined by C4D.

And I have my own render engine that I could use for examples and explanation but why bother if were talking about C4D here (I ask myself)? Anyways, I'll be back tomorrow, going to watch a movie shortly and hopefully fall asleep, ha.

//oh just one more...
So if all anti-aliasing is done on a 2D image (i.e. everything has been raytraced based on camera angle, lighting, etc. etc.) then there must be an in-between stage where there exists an aliased image, right?

Not really, your thinking the data is stored as pixel data like in an image, but they are stored only as data with a decimal value in a buffer, not an actual image, just numbers only, which still retain the high degree of accuracy, 129.0004253 for example. If an edge of a plane crossed a pixel area in a way that 20% of the pixels area was covered by the cube, then that sampled color of the cube at that location would be given a weight of 20%, not the 100% it would get when not aliased.

Anyways, let me take a break and maybe Anhar will come in here in the meantime and explain it all in 10 words or less. :)

[djembeplay]

Ya, I'm crashing too. Thanks for the explanation. I'll re-read it tomorrow as my thoughts are now pre-occupied with ogling my pillow.

[Raptor365]

Actually I got back up becaaauuuuusse...
...your partly right and I'm partly wrong.

Let's say that you understand the reasoning behind antialiasing lines and edges and weighting those.
And let's say we're rendering an object on the screen that has no edges visible, just all texture.

So, I misguided you about the weighting of textures.
Your right about for a 4x4 antialiasing, you would sample 16 points on the texture resulting in the same thing as if you render non antialiased at 4 times the render size
downsized with averaging, with a 'but..'.

First let me, hopefully, explain why because I forgot something.
If the object is very far away, how do we weight the samples between the rays? We can't take the area between them, collect all of the texture pictures that fall into that
range and average them because there might be thousands and that would take too long.

So a method called Mip Mapping was developed and which C4D uses.
The 16 samples are still taken as you said, point blank single samples, but instead of from one texture, the distance of the ray to the object is taken into account and
selects from a number of pre-blurred textures derived from the original objects texture.
That simulates pre-weighting, although it's not ideal.

Anyways here's a google I did for you that I'm sure covers it better than I can.
http://en.wikipedia.org/wiki/Mipmap

So your right about the sampling part, with a 'but'. And the edge antialising stuff is still applicable.

That was the long road to get here.
So, answering your original question again, the method of rendering at a larger size and then downsizing still will not produce the same image as a properly antialiased one.

This has been a confusing mess, hasn't it?

And lastly, if your rays were perpendicular to the screen, I believe you would end up with a 'Frontal' view render as opposed to a 'Perspective' view. I've never actually done non-perspective views before but that sounds about right.

[djembeplay]

Man, you know your stuff.

I've read through what you wrote a few times carefully and believe I'm catching on.

Here's a question that popped in - you said that if 20% of the edge of a plane was inside a pixel 'cube', it would be represented as 100% in an aliased image (no weighting). At least I think this is what you were saying (I always try to leave room for personal error / misunderstanding).

So... why would the 20% be upped to 100% instead of a more dominant pixel color, say if the other 80% was a blue background? Why wouldn't that pixel be blue in the aliased image?

Some possibilities I thought of - maybe proximity is taken into account... so even though the edge is only 20%, since it is the closer object it is automatically the 'dominant' color. Also, maybe it IS the dominant color - meaning there isn't any other color that equals more than 20%, so the image uses this as it is the most dominant of all colors at that moment.

Mi wheels are spinnin'. I like talking about this stuff though - it's fun to know the inner workings of our chosen medium.

[Raptor365]

So... why would the 20% be upped to 100% instead of a more dominant pixel color, say if the other 80% was a blue background? Why wouldn't that pixel be blue in the aliased image?

In the case of aliasing:
Just like with the aliased line example, if a line passes through a pixel it gets drawn with 100% of it's color. That's why it looks jaggy.
Same with the plane's edge, if it passes through a pixel that pixel gets the color.
If there is more than one object passing through the pixel, the color of the one that is closest to the camera is used. The dominant color, right.
The reason the green line example turns yellow is because that would happen during downsizing when blending occurs, mixing it with the red background.

In the 20% example, with antialiasing, the pixel would get 20% of the cubes color since the cubes edge occupies 20% of the pixels area, and then that would get mixed with whatever color the remaining area has, the other 80%. And that 80% area may contain another edge of an object so that would get mixed in as well.

I think you've got it.

[Raptor365]

What? No more questions? Cmon man. I was just starting to feel smart here for a second.

//Edited: (the next day) hahahaha, well I guess I can edit the rest of it out now.

Wow, what a night, last night. I got a little carried away waiting for the clock to roll over and officialy make it my 50th year on this planet. The fact that a bird has been flying into my window for the past 2 days in a row, a bad omen, didn't help. But I made it. And I made some weird posts last night but managed not to get banned, apparently, hahaha.

Have a good one. Sorry for the thread jack. Back to work everyone. :beer:

[djembeplay]

Hey Raptor -

Been gone for a few days so I hadn't gotten around to reading / responding til' now.

Happy B-day! It sounds like you had a nice celebration to bring in the dawn of the next decade of your life.

I think I get the general anti-aliasing concept for the most part (I'm sure this is something in it's self that one could devote a lifetime of study to, becoming more and more finite in their knowledge of the subject).

It just so happens I do have another question, lol. Ok, here we go:

Let's say we have an aliased image. In the example we were discussing above, you said that if there are two colors in the space of one pixel, one belonging to a 'closer' object and the other belonging to a 'further' object, the dominant color would be that of the 'closer' object, right?

So, my question is - what happens if, say, the edge of a cube occupies 20% of a given pixel space. The remaining 80% of the pixel space is occupied by another object residing behind the cube. Would the 20% color of the cube still be the dominant color (and the one used for the aliased pixel space) since the cube is the closer object?

[Raptor365]

So, my question is - what happens if, say, the edge of a cube occupies 20% of a given pixel space. The remaining 80% of the pixel space is occupied by another object residing behind the cube. Would the 20% color of the cube still be the dominant color (and the one used for the aliased pixel space) since the cube is the closer object?

Correctamundo.

There is one more detail though. My referring to the 'closest object' isn't tecnically correct.
It's basically the world coordinate on an object, that the ray hits, that's is used to determine which is closer, and the color at that point on the object would get assigned to the pixel, in case of aliasing.

A tree for example would have many branches that occlude each other, although it's still all one object. So just the intercept coords are used to determine which 'hit' is closest.
More specifially the intercept point on a polygon.

And of course with antialiasing, that would be a bit different in that you'd have the weighting taken into account.

//edit: And I suppose if you wanted to take it a step further, those polygons actually get broken down into triangles first for some calculations becase that is the smallest shape possible. Most render engines would allow you to plug in 'triangles' into whatever functions. Otherwise a function would have to break down multisided polys first, then make another call and plug in each triangle into that. hehe, yeah, I like this stuff.

[djembeplay]

Ok, more questions arise with more knowledge -

So your saying there are two ways in which a ray determines the closer object, world coords and intercept coords? Why doesn't it always just use intercept coords?

This leads me to another question utilizing an example. Let's say there are two trees. One of the trees has a world coordinate nearer to the point of view than the other. A branch on the nearer tree stretches backward and curls behind a protruding branch belonging to the further tree.

Now you have a case where in whatever pixel space the intersection of the two branches occupy, the 'closer' branch belongs to an object with further world coordinates, and the 'further' branch belongs to an object with closer world coordinates. Would the world coordinates dominate, giving preference to the branch that is further from the POV, or would the intercept coords have some influence somehow?

Also, I don't see the distinction between the processes you describe in your edited paragraph. If a render engine allowed you to plug in 'triangles', wouldn't it still have to break down all multi-sided polys first and convert them to triangles?

[Raptor365]

Well hold on a sec my man :) , I'm giving you things in steps. One thing at a time. :)


So your saying there are two ways in which a ray determines the closer object, world coords and intercept coords? Why doesn't it always just use intercept coords?

No, they are the same. The intercept point is taken in World coords. Same thing.
Whatever space your in that you have to deal with, right? If your camera is in world space and your hit is in world space, it's better to derive the disatnce from those coords. IF you need the texture corrds, then, you have to do the conversions to object space, then texture space, and the UVW's to find out what color occupies that hit.

Yeah, not a big deal, your just over thinking it, I think, haha.


Also, I don't see the distinction between the processes you describe in your edited paragraph. If a render engine allowed you to plug in 'triangles', wouldn't it still have to break down all multi-sided polys first and convert them to triangles?

Yeah, that's what I'm saying. The Root function handles triangles only, but there may be a case where you could have a sub function that allows you to plug in multisided polys, but in the end, your right, that function would have to break down, and 'guess' and triangulate those polys and call the primary function with each of the broken down polys, which would be the triangles.

It just makes it easier for the caller sometimes to say, here, here's the poly, give me the info, and let the sub functions handle it. It's easier to type and handier. But in the end, yeah, it all get's broken down into triangles.

Sorry for the babble. I don't work this out ahead of time, not like a tutorial, it's just off the top of my head. Otherwise it would be more 'tight', hehe. :beer:

[djembeplay]

Hmm, I think you lost me on both accounts there -

So your saying each point has it's own coordinate that the renderer uses? And that would mean that, in the example I gave above, it wouldn't matter that the coordinates of the entire tree is closer to the camera... what matters is that the individual points of the branch are extending behind those of the other, 'furthar' tree?

Also, I'm not sure why you would need texture coordinates or object coordinates for rendering... what would the difference be in using these versus world coords for rendering?

Also - I'm not sure what your saying about the triangulated polys. What is a caller, what is a subfunction, what is a root function, and what is a primary function?

[Raptor365]

Hmm, I think you lost me on both accounts there -


One of the various reasons why I don't teach for a living, hehe.


So your saying each point has it's own coordinate that the renderer uses? And that would mean that, in the example I gave above, it wouldn't matter that the coordinates of the entire tree is closer to the camera... what matters is that the individual points of the branch are extending behind those of the other, 'further' tree?

Right. Briefly...
Yeah. The 3D world space is described as x,y,z coords.
Those are visible in the Coords Manager as you know.
What I was explaining earlier about the cube being the closer object was to explain, using basic shapes, what was happening with antialiasing.


Having got by that...
really what your after is the closest polygon regardless of what object it belongs to, correct.
Objects are ofcourse made up of polygons, so that's what you really intercepting, 'polygons' on the object.


Also, I'm not sure why you would need texture coordinates or object coordinates for rendering... what would the difference be in using these versus world coords for rendering?

Well, really your getting into programming tech stuff, and while I'm not an expert, I'll carry it as far as I can. This stuff isn't required knowledge to use 3D programs, except maybe in explaining your original first post question.

To answer your question though, your basic calculations begin in world space, where objects and you camera are.
You ask a question: "Are they in the cone of vision"? Yes, okay bounce a beam off the object in question , does it hit within a rough area? Yes? Okay, test again, does it hit a polygon on that object? Yes, okay, where does it hit? Remember those coords, and for the sake of discussion, calculate and remember the distance to where it hit.

Continue testing all other objects, once done, decide which polygon was the closest.

So now we know which poly is closest and given that we know which object we hit, we know the texture that belongs to it. That point on the poly that the ray hit has a color. What is the color?

The only way to know that is to look up what the texture's name is that was assigned to that portion of the object.
But your texture is, say, a 256 X 256 picture with Cubic Projection assigned to the model.
So, nowwww, you have to do further calculations to determine how it is mapped onto the model, which brings you to having to convert to Object Space...ect..to figure out the point on the texture that matches the point on the polygon.

Its a step by step thing, ask a yes/no question and stop or continue breaking down the problem as you go.

I can talk about this for years man. I hope some of it is making sense though, hehe. If any other programmers would like to jump in, man, do it.

[Anhar Miah]

Raptor you rock!

I'm totally new on the 3D ray programming arena, but as far as I know, to follow on from Raptor, the world space co-ords need to be eventually converted to 2d screen co-ordinates (perspective mapping, this is 2d rasterazation...), methods such as back face culling and LOD are used to cut down the amount of computation needed (why render what you never see?)

Of course there are many many different algorithms out there, I think render man(tm) uses a different approach (REYES as opposed to ray tracing) which in a nutshell dynamically sub divides regions (eg curved surfaces) into micro polygons (sub pixel accuracy), and also uses procedural shades (as opposed to texture look up tables)

http://en.wikipedia.org/wiki/Reyes_rendering *

* ps that technology is probably quite old school now, but still good to know I think


Anhar

[Raptor365]

Anhar, good to see you man. Yeah, I'm still a fan of that old school Frog Engine code. The old school software method. Do it all with the math approach. The best way to understand it all.

Ol John Carmack, hehe. He could crush me with his baby toe. I was just thinking about him before I came back here. He was my inspiration when I started programming.

Yeah, if anyone wants to continue talking gaming code, for something to do even, I still have tons to talk about. Collision detection was always a pain. Structs, Carmack had some cool ideas with his approaches. Rendering code is cool. I can post any of mine if anyone wants, all software rendering. It's not the modern way now but cool if your into math at all.

Anyways...better go.:)
Cheers. :beer:

[Anhar Miah]

Raptor man, funny that you mendtion game code, but I was not able to sleep last night because I was trying to figure out how I would write 'Pong' in x86 Assembly,

I know in any High Level Language this would be kinda trivial-ish (you still need to have some 2d physics + path prediction if your playing against CPU + col detection)

oh Man int 13h VGA mode eek.. *

* inline C++ assembly example

http://www.delorie.com/djgpp/doc/ug/graphics/vga.html

[Raptor365]

hehe, that's going back. Been ages since I played with mode 13h on my 486 PC.
I think I still have many of the old register calls, like for the mouse and keys if you need them.

You could write the Pong code in standard c++ using the dos calls just to handle the interface but I guess that defeats the challenge of doing it all in x86.

Oh yeah, wasn't there a trick to run the dos program in a Windows window, then you could include windows.h and get the big memory allocations and other functions?
Otherwise your stuck with 64K memory max are you not? I was forever running out of memory. Pong might be okay though.

Sounds like a fun challenge. I'm glad 'your' doing it, haha. Let us know how it progresses if you proceed with it.

[djembeplay]

Thanks for the explanation Raptor - that cleared things up nicely.

Thanks for the input as well Anhar.

Well... you guys are out of my league :). I hope this isn't standard to know this stuff in conjunction with being a 3D artist... I mean, you guys know it so well because you happen to be into the programming side of things, right?

[Raptor365]

It isn't stuff you would need to know. I picked up some things while playing with game programming as a hobby before getting into this end of 3D, so it helped a bit.