Rendering hair over the network creates visible blocks

[mzeilfelder]

We are currently trying to render carpets using the hair-shape. As hair can't seem to have multiple colors we did instead create one hair-shape per color. So to have multi-color carpets we do for example quantize texture-colors first to reduce them to 16 colors and then create 16 single-color hair-shapes which are all in the same place.

When rendering on a single processor this does actually work rather well:

The problem is when we render it on our server using network nodes. The result is that the render block-size then becomes visible, like this: (this one uses the default 32x32 blocks-size, but we also tried other blocks-sizes and they always show).

When using just a single hair shape it also works over the network:

The Mitsuba version we use is 0.5.0 (the official release from https://www.mitsuba-renderer.org/). Unfortunately I failed to compile current git version (see thread "Compiler Error with vs2017"), so I can't test if anything has changed there since then.

The following zip contains the scene which fails rendering over network: bugreport_hairs_multidiffuse.zip (note it has 2 xml's - the newscen_outside.xml is the scene itself while 15_render_0_1.xml is to also have the exact same camera as we used).

For comparison here is the zip which has only a single hair-shape and works: bugreport_hairs_diffuse.zip

Any feedback or ideas would be welcome!

[marwik15]

My result

i7 870 Win10 + 2x xeon L5520 Win8.1

[mzeilfelder]

@marwik15: Thanks for testing. Are you using Mitsuba 0.5 or git version? And which block-size did you use? (because on top it also looks like one block might be darker, but only if you used a larger blocksize than 32x32)

[marwik15]

@mzeilfelder Sorry for late reply and lack of details. I used mitsuba 0.5.0 from official website. Rendered from 15_render_0_1.xml file without any chages using GUI (32x32). I also failed running git version (basicly every mitsuba binary just won't start like other Qt applications in my case - not fully comfirmed/tested)

using 128x128 block size (same configuration as above)

Last time I forggot to add this : "Sorry for bad English" ;) Have nice day

[marwik15]

My curiosity wins so I render this separately and got two different results (both 64x64). Even 870's render is different from first attempt. I'll check this in school when possible using exactly idential hardware and OS. Image saved by : File > export image (.png)

i7-870 2x L5520

[mzeilfelder]

Thanks for the other tests. I had already wondered in your first screenshot why it was so much brighter than mine. Anyone got an idea what could be causing this?

[marwik15]

I also tried on 5x i7 7700 (win10, 128x128) Even worse result

[mzeilfelder]

I also experimented some more by reducing the number of involved hair files. Never happened so far when I only used a single one, but could reduce it to 4 involved files (p.e. hair4-hair7 in bugreport_hairs_multidiffuse).

[merlinND]

create 16 single-color hair-shapes which are all in the same place.

From what you described, as well as the experiments posted in this thread, here is a hypothesis that could explain the issue:

When intersecting the hair shapes, different machines may consistently hit different hair instances. If you render on a single machine, or with few overlapping shapes, the issue doesn't show up. But on different machines and with 1+ overlapping shapes, blocks assigned to different machines will lead to consistently different results.

Could that explain it? Either way, intersecting overlapping shapes probably has undefined behavior.

[mzeilfelder]

Sorry for not answering before. I can't tell if this explains it, but sounds strange as a lot of scenes have overlapping and intersecting shapes and I haven't noticed this problem in other scenes before. Basically to test it I suppose I have to write first some code which gives me the exact same geometry without using the hair-shape.

[merlinND]

Hi @mzeilfelder,

I believe that rendering many shapes that have the exact same vertex locations on different machines has undefined behavior. (Shapes that intersect but do not overlap should be okay, the issue is with resolving collision order when several primitives have the same location). Feel free to reopen the issue if you are able to reproduce the issue with a simple case :)

[mzeilfelder]

They shouldn't have the same vertex locations. There's several hair-shapes to allow for different colors. But never 2 hair on the same place. I calculated all hair-positions first - and then did split them by color into the different shapes.