I am noticing that, when baking AO, the resulting map looks quite different from what is produced by the render engine if I have AO enabled. For the sake of comparison, I have included 2 screen shots. The first is the results of the AO default settings for the renderer, the second is the result of the baked texture from C4D applied to the object. As you can see the difference is quite large. In the bake object settings, there is only a check box for AO, with the only variables being Supersampling (which is more of an Anti-Aliasing thing) and Pixel Border (which is an overshoot thing as I understand it.)
Is there a step I am missing, or is this simply a shortcoming of the program? Perhaps a different technique is needed? I am wondering if I put AO in the luminance channel of a material and perform a bake texture as opposed to a bake object, if that would make a difference… but then I end up with a baked texture for every object in my scene, which as mentioned in an earlier thread is not ideal.
Looks like a resolution problem to me. Try to render twice (or four times, etc) the size and resize later back. Supersampling would be another step (Edit, another step means: not an alternative!/edit).
As I mentioned, A Color-Checker-texture (attached but a small one) helps to see how well the UV work was done, in terms of Surface-resolution ratio)
Ok, I can play with those settings… Presently the baked AO was done at a resolution of 2048 x 2048 with supersampling upped to 5. Given that the bake at those settings takes close to an hour, and in the course of that hour, I am unable to do any other work, the experiment will have to wait for end of day. I can try this on a smaller test project, but I fear the processing time may still be too high. I’ll report back either way.
Yes, it takes a while, but Supersampling will NOT help, Will.
I suggested over-sampling as main idea. Supersampling will not help a lot, it might refine the result. I guess you will see a dramatic change in quality with an initially larger size, which is then resized later to the smaller target size.
Super-sampling will not help here so much, AFAIK. Dial the Supersampling back to 0 or 1. If you oversample, the Alias artifacts will vanish perhaps completely anyway.
As a side note:
Perhaps you might try as well to use a “Sky-Object” and besides that, you have only the “to be baked” object visible for the render. In Gi Mode, you might get a more natural AO anyway, perhaps even faster.
All the best
Sassi
P.S.: the image was done nearly with the same render-time! I had to upscale the “Super-Sampling” to compare it.
That side note is interesting, and I’d love to try it. I am being pulled in 40 directions right now, so my brain isn’t making the connection on the idea though, could you explain how that works toward making a baked texture?
If you are “under the gun” at the moment, let’s focus on the main target. Set the Supersampling back to 0 and increase the texture size to, e.g, 8192x8192 and perhaps 16 bit for the rendering. (If needed perhaps even to 16K). If the result is a little bit noisy, you might apply a blur of 0.5 pixels to it, while in full size.
Then sample it down in Ps in at least two steps. Downsampling in one step wouldn’t be my advice, it doesn’t lead to the best results. In your case down to 4096x4096 first and use only the “Bicubic (best for smooth gradients)”. Any other option will not help here, it might result in a lower quality. If you have reached your final target size, check the color profile first before you go to 8bit/c! If you do the color profile change later, you might risk to see unnecessary “bandings”.
To the side note:
The GI version is not using AO at all, it uses the light that is calculated on the surface. AO was (AND IS) the “fake” before GI was usable. As it is simple to use and easier to calculate, AO has survived. I personally like it as much as I like “Über-Saturated Tonemapping Images”, hehe. Both look the same to me. A GI solution looks much more correct, if done well.
Interesting. Particularly your discovery that Super Sampling is of no real help. I am running test on the oversampling method now, I’ll let you know how it shakes out.
I do know that AO is the GI fake, but what I was wondering was, how does one go about translating GI settings into an texture map that can be used in another application? I would like to test that option as well to see what provides me the best results.
I was told by the Viz team that they generally prefer 2048 x 2048 as a delivered file, I suppose I can down-sample it that far down. They often even take THAT file and down-sample it again. While the single texture is no big deal, there are usually at last many, many layers of textures, tens or hundreds of thousands of 3D vertices and all manner of stuff in the final scene. In order to ensure that everything can play in realtime, it is crucial to make each asset as compact and easy to process as possible, while still maintaining quality. It is a tightrope dance, to be sure.
Ok, so here are the results. I include 3 images here (or 2 here and one in another post if the limit is 2, I forget offhand.
The first image, for comparison, is the rendered AO.
The second image is the baked AO at 8K as applied to the model automatically post - bake. As you can see, there is quite a difference.
The third image is the baked texture resized (I did shoot for 2048 as that is what has been requested), and the results are not so favorable. I tried both with and without a .5 pixel blur and found there not to be a difference between the 2.
I haven’t given up yet, there must be a way to get a baked AO that more closely resembles it’s rendered cousin.
I stick with it, it is a resolution problem. The 8K texture—would be nice if you have changed it to 4k then 2K before applying, as introduced above. The noise of the 8k looks perfectly like blurred noise in Ps, BTW. C4D is not scaling down in several steps as I suggested, and 2K was your target delivery. So, work always during final tests with the format you have to deliver.
If you render AO from the camera view, you get perhaps a much higher precision than a small 2K texture placed on the whole object, even 8K might be not sufficient for that specific area. It is a simple “texture/surface/render” dependency.
So, let me repeat this:
Have you set up the “Color Checkers”, to KNOW how much resolution you have really on that specific part of the object? Don’t waste more time on it, if you have no knowledge about the need for that area. Let’s put it to the extreme, you could have a 64K or even 128K square texture available, but if the area that you show here uses only 256x256 pixels from it, it will look bad. The translation of the area used by the UV polygons is critical, really critical.
It is important that the texture that you apply to a model is 1.5 larger than what you expect to be seen later on in the camera view. So, if that large white area of you model uses , e.g., 900x900 pixels, you can render it only at 600x600 to gain a similar quality. The pixel density of the surface is always based on the lowest received density from the texture, which must be (again) at least 1.5 times higher, to work). This is for all 3D apps the same and not a C4D thingy. If the resolution wasn’t available in the texture, then it will not magically be there during render time, sorry if I sound repetitive here, I just try to get my point across.
Optimize your UV, or bite the bullet and tell the client that this model can’t be represented with a single texture in a certain quality. Note, that I do not know the whole model, nor have any idea of the UV/texture ratio.
Use the color checker, which I have supplied above, and get clear about how many pixels you have in that area and go from there.
I just wanted to provide an update. I was never able to discern how to correctly deploy the color checker, but using other advice you’ve provided along with a couple of VizRT specific tips from a user at CG Talk, I have been able to reliably produce quality AO bakes out of Cinema. The first revelation came, after talking at some length with the artists in our Realtime department, that it would be fine to get 2 or 3 AO Maps, allowing me to break the bake up into manageable chunks. Then came word from a Cinema / Viz user at CG talk on the best settings for the Bake Object command as they apply to Viz - Super Sampling set to 1 (which equals 4x AA - the same that Viz uses), with a Pixel Border set to 4. I render the bakes at 4K, roundtrip into PS where I apply a 2px blur and down-sample to 2K, and reapply the textures in Cinema for QA. I learned that by setting the OGL in Cinema to Mipmap, AA 4x, and setting my materials to ‘No Scaling’ I am able to see in the editor the exact look the Viz Artists see in their software, saving me some back and forth on the QA.
So, there it is, the ‘secret’ recipe. I wouldn’t have arrived here with out your help, so once again, thank you.
Think of the color checker like a “tape measure”, that you place instead of the texture, and then you can read the “local” size of each part of the texture. The colors are there to make your life easier, if you like to see what part of the texture goes where. Instead of inch or centimeter, the texture measurement is pixel. Each square has the same amount of pixels.
Practically: if a square is very small on the object, you have a high density of pixels there, if the square is large, the square is stretched (thin) and might cause problems, certainly earlier than the small square. Does this help to see the use of it? Let me know.
The Subsampling is kind of weird: (if we say that binary scales are natural, hehe, so here is what the developer have put into the manual about it)
The following sub-pixel ratios apply:
0: 1x1 (no effect)
1: 3x3
2: 5x5
3: 7x7 and so on…
====
To have the same view as the one who receives your work is perfect. In your case it is even more finetuned than the mandatory screen calibration (Brightness/collor, etc) which I hopefully standard by now.
Thanks as well of pointing out the extra millage that you walked here to get the best pipeline experience and with it a more stable workflow: fantastic. Thank you.
