Community
Arnold for Maya Forum
Rendering with Arnold in Maya using the MtoA plug-in.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Default 3ds max Bitmap node vs Arnold Image node

5 REPLIES 5
SOLVED
Reply
Message 1 of 6
haryo.s
904 Views, 5 Replies

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?

Tags (2)
Labels (2)
5 REPLIES 5
Message 2 of 6

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.

Message 3 of 6
aaronfross
in reply to: haryo.s

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.

Message 4 of 6

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.

Message 5 of 6

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

Message 6 of 6
kulaginb
in reply to: haryo.s

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.

Post to forums  

Autodesk Design & Make Report