Baking Materials with Arnold

[balazsmd]

Dear AutoDesk Community,

I have just watched a interesting video on your channel entitled: "Bake to Texture: Baking Light Maps" and it showed the process to go from Arnold based scene setup and bake to legacy standard (shell) texture. Interesting. I thought the idea of Arnold and its fast GPU renderer would be to eliminate the baking process and use real time raytracing instead but if it speeds up the rendering process still then let's use it! I have a few important questions because mine behaves slightly differently than what i saw. 

1. Does it matter whether you use the CPU or GPU arnold renderer during the baking process? I assume that the generated baked texture should be as noise free as possible so the CPU generally give a less noisy result. Also, the baking process has to be done only once so the longer render times might be ok with CPU.

2. Once the baking is done, does it matter whether I use CPU or GPU for the actual production rendering? I see dramatic improvement already (for CPU going from 10 minutes down to 1 and GPU going from 3 minutes down to 45 seconds!) but want to be sure that I do not violate the properties of the baked material. Would Arnold standard surface materials bake too or only physical materials?

3. what could be the reason why my viewport shows black materials after the baking is done? Also, using channel 2 did not properly assign the baked materials even though I used channel 2 for all objects, so I had to go back using channel 1 which then resulted in proper material assignment. 

4. What exactly am I allowed to do with my scene if I baked to texture all of it afterwards? Can I move and animate objects? Or should I only bake objects that are non-dynamic and do not move at all? Can I introduce new light sources to the scene (even if it comes with some loss of performance), or I will get completely incorrect shadows and reflections with that? Would using the OptiX Denoiser be a problem? 

5. I assume in 3ds max 2021 currently the ideal workflow would be something like this: build the scene with all of its light sources, bake to texture everything, rig and animate the scene, render production (preferably using arnold GPU renderer with good settings and denoising). Am I incorrect in assuming this? 

6. Finally, and this is just cherry on top, I am trying to export my scenes to 3ds max Interactive but not getting the materials to work correctly. This started with me attempting all kinds (physical, arnold, legacy standard etc.) and all I get is just the color diffuse map. No glow, no reflection. And now after this baking process my models transfer to 3ds max interactive but NO materials. Are the shell materials do not transfer? They just show up with question marks. I apologize but I am new to 3ds max interactive so I am certain I have a long learning curve ahead but thought just want to see if I am doing wrong during the export process.  (Quick note: Level send all does not work, it gives a script error message...). If this part belongs to a different forum please ignore. 

Instead of wasting your time, I am uploading my learning file right away. Take a look. Thank you - Blaze

(P.S. Copyright disclosure: My scene features ED209 from the movie RoboCop. All rights belong to MGM Inc. I only use it for educational purposes)

[madsd]

1. Using  the GPU if you have a decent newish GPU over a relative humble CPU, can be many times faster to bake with.

2. If you see something that isnt rendering the same on CPU and GPU, after you have baked it, make a thread on the board here about it and show examples.

But new thread, dont put them into this one.

3. Viewport in HQ mode, is the one you want to use in general when you look at assets and shaders in the viewport, especially if you use pure OSL shaders to drive it.
It sounds like you use an old workflow which could probably be upgraded to fetch all the new tricks Zap etc implemented in recent history, using OSL shaders instead of shell. However it should work I think, so you might not have set the Physical material to show in HQ and viewport is also not in show in HQ mode, I dont know. But we can fix it for you, just need to know what you missed.

4. You can move objects, but dont bake any static lightning into the objects if you are going to move them. reflection maps, roughness, metal, normals, AO, Emission, Albedo, those maps, you can bake out.

Bake to .exr and convert to .tx for huge speed gains the larger the scene gets. Calling the .tx texture directly from disk, mipmapped.

5. Only bake what does not need to be recalculated for each frame in the production render in order to work.
You start by baking out the albedo and a normal map, then relight the baked scene.

6. You need to make sure you export ( bake ) the bitmaps neeed for a PBR model, channels mentioned in 4. Once that is done, your max mission is over, and you make sure that the material in the game editor has the bitmaps loaded to the correct slots, you can do this manually to make sure its working, then try see which part you missed in your current situation.

[balazsmd]

Thank you so much for spending the time on my long message! Looking forward to learning more. 

1. Understood. Will do!

2. Will do!

3. Yes I followed the only video tutorial I could find which automatically assigned a shell material instead of an OSL. Would love to see one with that newer workflow. Like a walk through of the whole baking process (including the rendering and showing that it actually improves render times. I did set the viewport to show HQ material. I thought I attached the screenshots from my scene but here it is attached again. 

4. definitely need to learn more on how to bake other maps besides albedo. I only did that. And so for moving objects, lights should not be baked into their texture. Got it.

"Bake to .exr and convert to .tx" - this I REALLY WANT TO LEARN! I could not find anything on this! Is there a built in tool or UI based converter to do the conversion of a jpg or tiff texture file to .TX? I feel this would be another massive improvement for rendering. "Calling the .tx texture directly from disk, mipmapped." - I feel this is another silver bullet to my problem, especially for video rendering. 

5. What constitutes a "need to be recalculated" object? Also, I do not need to bake the light source into the baked scene? I can just add lights afterwords? 

6. Here again a tutorial video with a tiny example (like a metal box) would be very helpful. 

[madsd]

3. you only need 1 Physical material to control many baked islands and channels, skipping the multisub material entirely, yet returning identical functionality ( increased flexibility though )

Make a new thread about this. I wont reply to it in this.

4. Download this .bat file and store it in "sendto" folder, then rightclick a random bitmap you have on a model and pick the converter and it makes a .tx out of the image in the scene.

Then in render panel, find the "Use exsisting .tx" it means it skips the file you have loaded in max and just pulls the .tx file directly from disk.

Make sure that the .bat file points to a location where the maketx.exe file is stored.

Loading to first pixel will sometimes be 20-100 times faster in very large scenes.

[balazsmd]

4. Wow, this actually does not work for me. 😞 Not at all. Shocking. I did everything you mentioned below. (see 3 screenshots). The .tx files are nicely created. So the .bat file works. I setup the scene and click "use existing .tx Textures. I made sure that .bat file points to the maketx.exe file location. Makes no difference in rendering speed, in fact my render time went up! I tried using PBR, physical material and standard surface Arnold material! I even flushed the cache. Makes no difference to my performance. 

[madsd]

It will really show if you use a 900mb png file you try to start rendering, and the same with a .tx version on disk.

the .tx pipeline will start rendering virtually instantly, the png will take a lot of time to translate.

Now imagine you had 400 x 900 mb png textures, the impact would be gigantic, its not really measurable when textures are small and few.

[balazsmd]

So why does it not work for me? I did everything and I see no speed increase in rendering. I understand the concept of the method but I do not see the result that is expected.

[madsd · Accepted solution]

It looks like you use a couple of 1k textures.

That is nothing ( very small and few ), and flies very fast to the frame buffer regardless of being .tx or not.

This is like a differential engine, more gains are more clear the larger things becomes.

[balazsmd]

Oh I see. So for these small textures I will not see any gain. 

[domo.spaji]

---

@madsd wrote:

It will really show if you use a 900mb png file you try to start rendering...

---

Where did you get 900mb png files?

That is something like 400 Megapixels - UNCOMPRESSED!

Why PNG, because you can't have uncompressed jpegs?

[madsd]

It was a random example to explain the gearing effect to first pixel, from when you push render till they appear.

It could also be explained differently, 250*  8k or 16k texture tiles, greatly benefit from being loaded via .tx directly and only when the render engine needs to handle texture data, also these .tx files are mipmapped, so there are different resolutions inside the texture file. 

[domo.spaji]

And recommended workflow is what?

Work with that files in Max and Mat. Editor and use optimized for renderer?

That is like making ultra HD models and textures and send them in game engine instead of low-ones. Same logic.

[madsd]

Depends where in the pipeline you operate.

If you shade an asset, you can use any format supported, regular workflow. Once the asset is ready you prepare it for rendering and tells the asset to call the server side .tx file and skip the random format file you are working with.

If you want the fastest possible scalable scenario, you make a 1x1 pixel jpg file called texture.jpg and a .tx file with the original large mipmapped texture called texture.tx and tell Arnold to load the .tx file at render time.

The more maps, materials, 100s 1000s in the scene the more the effect start to show its effect, meaning big shots are fast, way faster than a traditional setup, in terms of scene load times, some can take many minutes, you can load a huge scene and have a render going very fast, many times faster than if you would do oldschool rendering workflow, especially on heavy scenes, and it will only be better the larger you make it. Small scene not so much a difference.