ChangeQueue.ApplyMaterialChanges is not called for some assignments

I have recently noticed a ChangeQueue issue (I am on 7.22.22255.5001, 2022-09-12), where assignment of a material fails to cause a call to ApplyMaterialChanges.

Tested with my plugin uninstalled, I have also reproduced this using Raytraced, with the steps being:

  1. open the provided file, the “persp” viewport will be rendering in Raytraced, the “plaster” material is assigned to the plane.
  2. drag material “emission-0” onto the plane, in the “Top” viewport, it will be assigned, and rendering will restart.
  3. drag material “emission-1” onto the plane, in the “Top” viewport, it will be assigned, but the render will not restart.
  4. repeat steps 2 & 3 as you like, the render will not restart.
  5. drag material “plaster” onto the plane, in the “Top” viewport, it will be assigned, and the render will restart.
  6. you may now repeat steps 2-4 again as you like, the render will not restart.

Now, if you change the color of one of the emission materials, it will begin working as expected, which leads me to suspect there is some over-zealous use of hash values, such that the system is considering materials with matching hashes to be equivalent for purposes of rendering, regardless of their actual identity.

That may be fine for some renderers, but in ours, the identity of a material is important, regardless if it has a similar appearance to other materials, since for example, the user may group a set of emitters and control them together, and if I am not notified of new assignments, the groups inside my scene cannot be kept synchronized with the current state of the model, from the user’s point of view.

changequeue-update-issue.3dm (61.3 KB)


I’ll look into this as soon as possible. I’m afk all this week, but as soon as I get back.


1 Like

Hi @jdhill

Sorry it’s taken a while to get back to you. Yes - this is how it was designed in V7 - if a render content (a material) returns a similar RenderHash to the previous one, it is assumed to be the same material.

I’m going to add something in V8 so that you can override this behaviour in your own change queue - basically, instead of calling RenderContent::RenderHash, it will call into a virtual function on your change queue which you can override to do what you want.

That way, you can separate out emission materials without doing the same to other types if you want to.

  • Andy

Thanks Andy, but I see this as a change in behavior – I can’t say in exactly which build it changed, but I only just noticed it when reporting, and have confirmed that V6 does not show the same problem.

That said, checking again now with 7.24.22308.15001, the behavior appears to have changed yet again, where the steps given above no longer produce it, but these similar ones do:

  1. open the provided file
  2. duplicate the red “plaster” material
  3. rendering will not restart when assigning either plaster material
  4. change the color of the duplicate, now assigning either plaster will restart rendering
  5. change the color back, and once again rendering will not restart when assigning either plaster

So for whatever reason, the emission materials are now working as expected, but a newly-duplicated plaster material does not. With my plugin loaded, my own emitter materials behave like the plaster.

I would suggest that regardless of any new render hash override, adding a render content’s name or other instance-specific property to the hash should restore the prior behavior. But if something like that will not be done, then the proposed override does sound like the next best thing.

RH-70565 is fixed in the latest WIP