I've been busy optimising a scene and I've noticed some interesting behaviour. I've been checking the render logs and I noticed some background textures were being loaded despite not being visible in the designated render area. Even worse, there were multiple calls to its highest resolution mipmap which lead to some high I/O times for something that's not even visible.
I then replaced these textures' nodes in the material editor from the default Bitmap node to the Arnold Image node and there were some noticeable differences. The time to render was cut from 4 minutes to 3 minutes and the I/O time for the affected textures were very considerably shorter. The amount of calls were reduced from several thousands of its highest mipmap to a single call each to the lowest mipmaps.
Textures loaded with the default 3DS max Bitmap node
00:04:07 10570MB | 50 1 854 10.0 25.5s 4096x4096x3.u8 ..\Ceiling_Peak_Beams_Diagonal_BaseColor.tx MIP-UNUSED MIP-COUNT[854,0,0,0,0,0,0,0,0,0,0,0,0] 00:04:07 10570MB | 51 1 2240 26.3 1m 20.4s 4096x4096x3.u8 ..\Ceiling_Peak_Beams_Horizontal_BaseColor.tx MIP-UNUSED MIP-COUNT[2240,0,0,0,0,0,0,0,0,0,0,0,0] 00:04:07 10570MB | 52 1 1996 23.4 ( 1 0.0) 1m 8.6s 4096x4096x3.u8 ..\Ceiling_Peak_Beams_Lattice_BaseColor.tx MIP-UNUSED MIP-COUNT[1996,0,0,0,0,0,0,0,0,0,0,0,0] 00:04:07 10570MB | 53 1 1451 17.0 48.2s 4096x4096x3.u8 ..\Ceiling_Peak_Beams_Vertical_BaseColor.tx MIP-UNUSED MIP-COUNT[1451,0,0,0,0,0,0,0,0,0,0,0,0] 00:04:07 10570MB | 54 1 2185 25.6 ( 1 0.0) 1m 30.9s 4096x4096x3.u8 ..\Ceiling_Peak_Ceiling_BaseColor.tx MIP-UNUSED MIP-COUNT[2185,0,0,0,0,0,0,0,0,0,0,0,0] 00:04:07 10570MB | 55 1 1123 13.2 37.0s 4096x4096x3.u8 ..\Ceiling_Peak_Connectors_BaseColor.tx MIP-UNUSED MIP-COUNT[1123,0,0,0,0,0,0,0,0,0,0,0,0] 00:04:07 10570MB | 56 1 168 2.0 0.1s 2048x2048x3.u8 ..\Ceiling_Peak_Window_BaseColor.tx MIP-UNUSED MIP-COUNT[168,0,0,0,0,0,0,0,0,0,0,0] 00:04:07 10570MB | 57 1 2364 27.7 1m 13.7s 4096x4096x3.u8 ..\Ceiling_Rails_RailHolders_BaseColor.tx MIP-UNUSED MIP-COUNT[2364,0,0,0,0,0,0,0,0,0,0,0,0]
Textures loaded with the Arnold Image node
00:02:47 10072MB | 50 1 7 0.1 0.2s 4096x4096x3.u8 ..\Ceiling_Peak_Beams_Diagonal_BaseColor.tx MIP-COUNT[0,0,0,0,0,0,1,1,1,1,1,1,1] 00:02:47 10072MB | 51 1 6 0.1 0.3s 4096x4096x3.u8 ..\Ceiling_Peak_Beams_Horizontal_BaseColor.tx MIP-COUNT[0,0,0,0,0,0,0,1,1,1,1,1,1] 00:02:47 10072MB | 52 1 6 0.1 0.1s 4096x4096x3.u8 ..\Ceiling_Peak_Beams_Lattice_BaseColor.tx MIP-COUNT[0,0,0,0,0,0,0,1,1,1,1,1,1] 00:02:47 10072MB | 53 1 6 0.1 0.1s 4096x4096x3.u8 ..\Ceiling_Peak_Beams_Vertical_BaseColor.tx MIP-COUNT[0,0,0,0,0,0,0,1,1,1,1,1,1] 00:02:47 10072MB | 54 1 8 0.1 0.1s 4096x4096x3.u8 ..\Ceiling_Peak_Ceiling_BaseColor.tx MIP-COUNT[0,0,0,0,0,1,1,1,1,1,1,1,1] 00:02:47 10072MB | 55 1 7 0.1 0.1s 4096x4096x3.u8 ..\Ceiling_Peak_Connectors_BaseColor.tx MIP-COUNT[0,0,0,0,0,0,1,1,1,1,1,1,1] 00:02:47 10072MB | 56 1 8 0.1 0.0s 2048x2048x3.u8 ..\Ceiling_Peak_Window_BaseColor.tx MIP-COUNT[0,0,0,0,1,1,1,1,1,1,1,1] 00:02:47 10072MB | 57 1 6 0.1 0.0s 4096x4096x3.u8 ..\Ceiling_Rails_RailHolders_BaseColor.tx MIP-COUNT[0,0,0,0,0,0,0,1,1,1,1,1,1]
I'm hoping the render log formatting survives but note the drastically improved I/O time. From a minute and a half down to a tenth of a second. Peak memory cache also decreased 364MB to 213MB
I still need to do tests with a complete render of the scene and compare the logs then as well as creating a different scene and seeing if this behaviour persists, but is this expected when switching from the Bitmap node to the Image node? Should I be using the Image node rather than the Bitmap node to load textures?
Solved! Go to Solution.
Solved by nicola.stefano.jannuzzo. Go to Solution.
Yes, you should always use the Arnold native node, if you plan to stick with Arnold. When we translate Bitmap, we have to add a lot of extra nodes under the hood to support the Bitmap parameters, which heavily affects performances.
Also, we can not set the derivatives correctly depending on the projection type, which in many cases affects the mipmap level lookup.
Please note that only the legacy Bitmap node supports Real-World Map Size, which is a key feature for architectural visualization. Unless there's an Arnold or OSL implementation of Real-World Map Size, the legacy Bitmap node will still be a requirement for a very large segment of the user base. Since Max is being directly marketed to design visualizers, it's in the best interests of all concerned that this issue is resolved. I don't want to rely on the legacy Bitmap node either... it would be great if it could be retired. But a few milliseconds of delay in rendering is not comparable to the many hours of user production time saved by using the native features of the legacy Bitmap node.
Thank you for your explanation and it makes sense. May I ask if this is covered somewhere in the documentation? Note that I am the kind of idiot who skips over the introductory segments so I might have easily overlooked it.
Agree. For me Real-World Scale can be realized very simple. In VrayBitmapMap uses 3ds Max UV rollout, CoronaBitmap has own interface, but with Real-World Size checkbox.
Can't find what you're looking for? Ask the community or share your knowledge.