Multi/Sub-Objects material slow in IPR

[hien_tongduc]

Hi!
So the issue is that we have a workflow that heavily based on Multi/Sub-Objects (multimat) material.
Normally a 20-30 MatIDs an objects is pretty normal
Sometime the object may not have all of those ID but still using the same multimat and respect the IDs
The issue appear when I have a multimat around 30 and when I use IPR to do the look dev any change the the material in the multimat seem to make the engine load the whole multimat instead of just the one I'm tweaking.
This can be by-passed by disconnect the said material from the multimat and assign it back for the look dev, then plug it back in. (while the multimat still present in the IPR without the said material)
With this the IPR run as fast as it can.
So is there a way or this is what is has tobe?
Can this be a request, wishlist?

[yavor.rubenov]

Hello,

Generally reloading all the materials should be very fast as V-Ray clones the materials and textures but doesn't need to reload any resources. Are you seeing some slowdowns and can you give some more details ?

Best regards,
Yavor

[hien_tongduc]

Well it only slow down if the material (A) plug into a multimat (B) and the multimat (B) is assign on the object.
the slow down depend on the number and complexity of the multimat (B)
If the material (A) alone assign to the object, the IPR run pretty normal.
So I assume that the issue is within the link between the multimat and Vray IPR.

[yavor.rubenov]

Can you share a scene or some video showing the slowdown ?

[hien_tongduc]

https://drive.google.com/file/d/1XLg...ew?usp=sharing

Heres a Gdrive link to the video that quite demonstrate it

[yavor.rubenov]

Hm you are using the Max Bitmap loaders - can you try to convert all of them to VRayBitmap to see if there's any difference ? (There's a command for this in the quad menu).

[hien_tongduc]

Wow, It does fix it.
Thanks a lot.
Now I have to rewrite most of my custom script

[^Lele^]

As a general note, you should always try and use our version of any of the max nodes, when available.
We cannot touch the Max code, for obvious reasons, but we pour a lot of effort into the tech we can indeed influence: our own.
I've had the same with both multimaterials and composite maps, in the past, and even without IPR, simply opening the mateditor (and then in rendering.).
Moving away from max bitmap loaders *always* righted the wrongs.

[hien_tongduc]

As a general note, you should always try and use our version of any of the max nodes, when available.
We cannot touch the Max code, for obvious reasons, but we pour a lot of effort into the tech we can indeed influence: our own.
I've had the same with both multimaterials and composite maps, in the past, and even without IPR, simply opening the mateditor (and then in rendering.).
Moving away from max bitmap loaders *always* righted the wrongs.

Thanks
I've just pickup the pacing from a very old workflow so everything need a refresh
Talk about the composite map, yes that one is a mess to, too slow yet its still has it strength

[^Lele^]

It's *very* quick if you convert the textures to tiled .TX. (same quad menu command, or manually with makeTX.exe in the bin folder.)
That's also for multi-sub, and in general all the texture-heavy work.
Give it a try, see if it makes your workflow better.

[hien_tongduc]

It's *very* quick if you convert the textures to tiled .TX. (same quad menu command, or manually with makeTX.exe in the bin folder.)
That's also for multi-sub, and in general all the texture-heavy work.
Give it a try, see if it makes your workflow better.

Yeah, heard of it since the Arnold era.
I believe that it has mipmap process already baked in so it will load and render faster.
Thing is I need to build a workflow that is fool proof, minimize the technical knowledge so that the employees can pick at any level.
Its not an easy job but I think the speed trade off can compensate the effort.

[^Lele^]

It likely requires a "publishing" step, from a department/task to the next.
F.e., a texture artist can work however they please, so long as when they are done with their work "push the button" to convert their final assets to .Tx, and publish those.
It loses some flexibility (due to the added step) but it also makes the process safer from accidental edits (as they'd need another publish/conversion done.).

Both the speed, the quality and the memory usage of the results will be much improved, however.

[hien_tongduc]

It likely requires a "publishing" step, from a department/task to the next.
F.e., a texture artist can work however they please, so long as when they are done with their work "push the button" to convert their final assets to .Tx, and publish those.
It loses some flexibility (due to the added step) but it also makes the process safer from accidental edits (as they'd need another publish/conversion done.).

Both the speed, the quality and the memory usage of the results will be much improved, however.

Thanks man
Not all studios have a dedicated texture artist (it is some what per studio preferences), but it clearly can be applied to a template, ready to used asset which usually take up 70% of the projects.
Great tips BTW, never could have though about it if some one didn't mention it.

[^Lele^]

Eh yes, i was making a generic example from my past history as Pipeline and LnR TD.
Automation has generally been the key to proper adoption: if it's a complex task to achieve, it only burdens artists more, and under pressure is quickly discarded.
I *hate* repetitive, mindless tasks to be done manually (funnily enough, half my production history was precisely that. ^^), and i make "buttons" for myself all the time.
I can't ever rely on me doing things right when tired, but i can trust a procedure that way.

[hien_tongduc]

Hah I still have some tool from 2012 just because they do what I told them to and packed in a small box rather than pages of buttons