Vray Imap DR-Bucket compression

[trixian]

Great to hear. To emphasize, some compression or whatever you had going is fine, but it sometimes got so bad that i looked like faulty buckets.
Sorry about not making the test file for the issue I had at home over VPN. Been a bit busy.

[savio alvares]

Hi Sir,
Is this issue solved......
I am also getting some what this kind of a problem
Please could some one help me....
This happens only when I use my render slaves systems...
Thanks alot

[glorybound]

I get those often, without warning, on random projects. It can go on for a long time, and then stop, as fast as it started. I tried restarting, rebooting.., but nothing seems to work, but it'll stop by itself.

[savio alvares]

I get those often, without warning, on random projects. It can go on for a long time, and then stop, as fast as it started. I tried restarting, rebooting.., but nothing seems to work, but it'll stop by itself.

Sir Thanks
done all.....
downloaded the latest built again and installed but same issues still there.
So for the moment just doing individual rendering.
Thanks

[savio alvares]

Does anyone of us have a solution.....

[trixian]

AFAIK Savio, You are having a different problem. This thread is about addressing the issue of slaves' bucked feedback during irradiance map calculation being compressed to save network bandwidth, and some of us pointing out that the compression sometimes is so heavy that it looksl like the slaves are missing maps, while in reality they aren't, and the final result looks ok. This is mainly a problem because many of us have a habit of relying on watching the imap calculate to visually debug, or quality-assure our renderings (not the best way probably, but I must admit, not seeing the imap makes me jittery and nervous and maybe slightly paranoid when closing in on a deadline).

You seem to be having the classic real problem of render nodes not reading in hdri's etc. or generally calculating things differently (different versions of software, different cpu types bla.bla), resulting in mismatching buckets in your final rendering. This could be from several reasons, all of witch I'm not sure of.

To clarify, these are the result of the rendering above where the buckets seem to be wrong.
All fine in the end, but worrisome while rendering.

[savio alvares]

AFAIK Savio, You are having a different problem. This thread is about addressing the issue of slaves' bucked feedback during irradiance map calculation being compressed to save network bandwidth, and some of us pointing out that the compression sometimes is so heavy that it looksl like the slaves are missing maps, while in reality they aren't, and the final result looks ok. This is mainly a problem because many of us have a habit of relying on watching the imap calculate to visually debug, or quality-assure our renderings (not the best way probably, but I must admit, not seeing the imap makes me jittery and nervous and maybe slightly paranoid when closing in on a deadline).

You seem to be having the classic real problem of render nodes not reading in hdri's etc. or generally calculating things differently (different versions of software, different cpu types bla.bla), resulting in mismatching buckets in your final rendering. This could be from several reasons, all of witch I'm not sure of.

To clarify, these are the result of the rendering above where the buckets seem to be wrong.
All fine in the end, but worrisome while rendering.
[ATTACH=CONFIG]14781[/ATTACH][ATTACH=CONFIG]14782[/ATTACH][ATTACH=CONFIG]14783[/ATTACH]

Thanks Sir......
V-ray support to mailed me with points to check.....
and I got to know that a map was linked with the max file even thought it is not applied in the max file anymore....
once I delinked the missing bitmap using "Relink Bitmaps" by Colin Senner.........
Thanks a lot to all......saved my day......

Will be reply to v-ray support team of what I found to what was causing the problem for me....
Thanks alot