question

Haryo Sukmawanto avatar image
Haryo Sukmawanto asked ·

Default 3ds max Bitmap node vs Arnold Image node

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?

imagemipmap
10 |600 characters needed characters left characters exceeded

Up to 5 attachments (including images) can be used with a maximum of 2.0 MiB each and 9.8 MiB total.

Nicola Stefano Jannuzzo avatar image
Nicola Stefano Jannuzzo answered ·

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.

2 comments Share
10 |600 characters needed characters left characters exceeded

Up to 5 attachments (including images) can be used with a maximum of 2.0 MiB each and 9.8 MiB total.

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.

0 Likes 0 · ·

No, it's not. I am the kind of idiot who forgets to document stuff. ;)

0 Likes 0 · ·
Boris Kulagin avatar image
Boris Kulagin answered ·

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.

Share
10 |600 characters needed characters left characters exceeded

Up to 5 attachments (including images) can be used with a maximum of 2.0 MiB each and 9.8 MiB total.

Aaron Ross avatar image
Aaron Ross answered ·

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.

Share
10 |600 characters needed characters left characters exceeded

Up to 5 attachments (including images) can be used with a maximum of 2.0 MiB each and 9.8 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 5 attachments (including images) can be used with a maximum of 2.0 MiB each and 9.8 MiB total.

Welcome to the Arnold Answers community.

This is the place for Arnold renderer users everywhere to ask and answer rendering questions, and share knowledge about using Arnold, Arnold plugins, workflows and developing tools with Arnold.

If you are a new user to Arnold Answers, please first check out our FAQ and User Guide for more information.

When posting questions, please be sure to select the appropriate Space for your Arnold plugin and include the plugin version you are using.

Please include images, scene and log files whenever possible as this helps the community answer your questions.

Instructions for generating full verbosity log files are available for MtoA, MaxtoA, C4DtoA, HtoA, KtoA, and Kick.

If you are looking for Arnold Documentation and Support please visit the Arnold Support site.

To try Arnold please visit the Arnold Trial page.

Bottom No panel present for this section.