Community
Arnold General Rendering Forum
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Are there known issues regarding frame-to-frame flickering when using multiple meshlights?

38 REPLIES 38
SOLVED
Reply
Message 1 of 39
Anonymous
1296 Views, 38 Replies

Are there known issues regarding frame-to-frame flickering when using multiple meshlights?

We have an outdoor scene using 50 meshlights (50 unique objects, 50 mesh_lights).

In a 15frm test, 2-3 frames (sometimes more) will show surfaces receiving light from the meshlight objects/lights will be darker. On subsequent renders, which actual frames this occurs on will randomly vary. After trying all sorts of things, we decided to condense all 50 unique objects into 1 object and use just 1 mesh_light. Result: No flickering frames.

Has anybody else noticed this behaviour?

We're using 5.1.0.1. Could this issue have perhaps been fixed in a later version?

Thank you,

38 REPLIES 38
Message 21 of 39
Anonymous
in reply to: madsd

Did you see the attached jpeg above to get a sense of the camera angle/position?

Thank you,

Message 22 of 39
Anonymous
in reply to: thiago.ize

No, on re-render, they will be on different frames.

Message 23 of 39
Anonymous
in reply to: thiago.ize

I'll try to upload the DNxHD 75-frame movie, hopefully it'll be under the upload limit.

Thanks,

Message 24 of 39
thiago.ize
in reply to: thiago.ize

That's good to know! So if we render the .ass file you provided many times you expect that we'll see this flicker? If so, can you confirm that we'll see this flicker even if we don't have the rhDepth shader or wocaa1_envLightPaintCC.exr (can I delete those)?

Have you taken a look at the log warnings? I see:

00:00:00 66MB WARNING | GeoImport1_Arnold5LightRigMesh_mesh1Light: for MIS to work properly, polymesh linked to mesh_light should at least be visible to shadow rays

Have you tried fixing this to see if it helps with the flickering or at least helps with image quality?

Message 25 of 39
Anonymous
in reply to: thiago.ize

The movie is way too big...I'll isolate and upload 2 or 3 EXRs asap..

Thanks,

Message 26 of 39
Anonymous
in reply to: madsd

We've noticed that brightness tends to obscure the issue, so we gamma way down and it helps seeing it.

Message 27 of 39
Anonymous
in reply to: thiago.ize

1) So the LookDev supe and I were discussing...we think it might help to briefly explain our technique just a bit. First let me say we don't use Maya directly for rendering but do include the mtoa share lib and use those nodes when we write assfiles from our Katana-like node based lookdev tool.

That said, using this test object as an example, where we have spheres as light bulbs and maya pipe primitive as a light shade/hood...we have one object that contains 50 bulbs and 50 hoods, right..

(more)

Message 28 of 39
Anonymous
in reply to: thiago.ize

2) When we generate the assfile,...for the default EXR layer, the "color" layer if you will, we generate an arnold polymesh that contains all of these 50 bulbs and hoods.

For the meshlight object, the light-emitting object,..we extract the 50 bulbs into a 2nd polymesh and set the visibility to 0. As you point out, this generates the warning you mention.

We're wondering if the visible bulb is randomly being interacted with by the invisible bulb of the meshlight, if you follow me. There are production reasons for doing things this way.

Message 29 of 39
Anonymous
in reply to: thiago.ize

3) We do things this way as production only has to generate one object (one stream). But we wonder if perhaps this whole issue could be solved by providing the renderer one object of 50 hoods and another object of 50 bulbs, the latter would be used by the meshlight and would be visible (instead of invisible as before).

I hope I'm explaining this properly.

Message 30 of 39
Anonymous
in reply to: thiago.ize

4) Just to add,...we're also noticing that the 'texture_max_memory_MB' parameter of the 'options' node is 2048 and our real scene has a huge amount of textures...so we're also wondering if texture memory swapping could play a role here too, though granted in the test object (assfile) we've upload the test objects aren't texture mapped.

Thank you very much,

Message 31 of 39
thiago.ize
in reply to: Anonymous

That's unlikely to be causing issues.

Message 32 of 39
thiago.ize
in reply to: Anonymous

Yes, I think it's worth trying since that is what Arnold is expecting. Usually if Arnold gives a warning it's worth addressing.

For testing purposes, try and simplify as much as possible. Get rid of all AOVs, cryptomatte, rhDepth, MtoaAovWriteColor, etc. Instead of multiple shaders attached to the mesh, use only one shader. The meshlight mesh has at least shadow visibility. Don't use overlapping meshes. If you have a simple setup and it's still flickering, that's a great repro to pass to us for debugging. If it works, then start adding back complexity until it flickers, and report that to us.

Message 33 of 39
Anonymous
in reply to: Anonymous

Hi again Thiago,

Apologies, I've been pulled away on other work, but we've not yet resolved this. Will update this thread as soon as possible.

Thank you,

Message 34 of 39
Suppybird.kingdom
in reply to: Anonymous

Please update it to solver it. Every Arnold problem need to be fixed perfectly. In the case users need 50 or 500 mesh lights and each mesh light is animation point object, this cannot be replace by spot light or any other kind for this.

Message 35 of 39
Anonymous
in reply to: thiago.ize

Hi Thiago, just a quick sanity check question 😉

Regarding the polymesh assigned to the 'mesh' parameter of a mesh_light...If this polymesh's 'shader' parameter points to a standard_surface who basic Kd,Ks,etc parameters are texture/color-mapped, how does Arnold handle that? I assume the 'color' parameter of the mesh_light will determine the color of the light emitted, but will the color-mapped polymesh render normally? i.e., as color-mapped? What if bump or displacement is used on the polymesh? i.e., would that affect the mesh_light?

Thank you very much,

Message 36 of 39
Anonymous
in reply to: Suppybird.kingdom

We're now testing with 5.4.0.0 and getting same results.

Thank you,

Message 37 of 39
thiago.ize
in reply to: Anonymous

The assigned shader to the mesh geo is not used for lighting, what’s used is mesh_light.color. Bump is part of the shader, so it won't be used for lighting, but displacement will because that happens on the geometry itself.

Message 38 of 39
Anonymous
in reply to: Anonymous

Apologies for the late follow-up on this...

So we've been able to verify that the issue we were seeing was a result of our methodology and not a symptom of a bug in the arnold renderer.

Briefly, the issue has its root in the polymesh's maximum of 255 allowed materials/shader assignments. We use an in-house lookdev tool (like Katana) to generate assfiles. In the assfile there exists a geomStream procedural block (instead of the polymesh block) that points to our C++ plugin that creates the polymesh block at evaluation (procedural_force_expand) by kick at rendertime. One advantage of this is that the size of the assfile is greatly reduced.

We did not notice that upon evaluation, due to our model having greater than 255 mtls, the geomStream plugin was creating *two* polymesh blocks in the assfile. So meshlights whose 'mesh' param was pointed to the first block actually needed to be linked to the second. This phenomenon was random so it was difficult to determine this and the model was huge, complicating efforts because using a smaller test model (less than 255 mtls) doesn't expose the issue.


As an aside...fixing this was further complicated because the mesh param requires linking to an existing polymesh node but in our case that polymesh node doesn't exist yet as .it's made later at rendertime. It would be nice if this linking could be done by 'string' instead.

Thank you all for helping us working thru this...

Message 39 of 39
thiago.ize
in reply to: Anonymous

Glad you solved your issue! Can you mark your answer as the correct answer so we can close this question?

I've made an internal core ticket for adding string referencing to our API. We'll take a look at it, but there's some tricky edge cases involved with this approach, so no promises on when or if we'd be able to do it.

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Technology Administrators


Autodesk Design & Make Report