daltonwatts

Ok, Update: With 3d vraydisplacementmod turned on, during the lightcache calculation phase the Xeons cpu usage doesn't go past the 88-89% mark. On the i7 4770K cpu usage is 100%. That might explain something. Don't know what though

Sorry to hijack this thread. @dtolios Samsung 950 Pro didn't impress me at all. Apart from fast file transfers it is exactly the same as a "regular" ssd. It's due to return in a few days.

I'm almost certain cpu usage and threads are at 100% during lightcache. But i'll check again later today just to be sure. Same file, same settings, same everything Tried also the same scene on Xeon 1230 v2 and lightcache calculates in 22 seconds.

Further update: Vray DEMO 3.40.02 - 3ds Max 2014 Using 3d displacementmod (Edge Length = 2.0) If i only use one cpu (36 threads): Calculating Lightcache: 42 seconds If i use both cpu's (72 threads): Calculating Lightcache: 3 minutes On single socket i7 4770k (8 threads): Calculating Lightcache: 16 seconds Something clearly isn't right here... Same 3ds max version, same vray demo version.

Hi Juraj! Latest version (3.40.02) solves the problem of lightcache being stuck on the scene i mentioned above but it doesn't solve the 3d displacementmod on the other scene. Basically if i turn ON 3D displacementmod on one single carpet, lightcache takes ages to be processed when the same doesn't happen on both single socket workstations. No problems with 2D displacementmod.

As suspected, Corona has absolutely no problems with the same scene... Must talk to Vlado i guess.

Hi guys! I have a scene with around 6M polys. Only one proxy. Vray 3.3.05. 2D displacementmod turned on. It renders fine in 2 simple machines one with Xeon 1230 v2 (16gb RAM) and other i7 4770k (8gb RAM). Tried rendering on my dual Xeon 2696 v3 with 32gb RAM and bang! Lightcache is a complete snail... If i save the lightcache and irradiancemap and load it on the dual Xeon bang! UNHANDLED EXCEPTION: Irradiance map thread and something to do with GlobalIllumMap::buildLightMap. I've had problems with other scenes too especially it not being able to render with 3D displacementmod turned on. So basically this new dual xeon is on standby mode and i'm unable to use it in production... 3700€ later... I've yet to try Corona renderer to see if the problem is vray related or hardware related. Something i'll try to do today.

Well, it seems i found out the problem. Changing edge length from 2.0 to 5.0 and ticking ON both the "use object mtl" and "view dependent" makes light cache resolve in 5 seconds I can also untick both "use object mtl" and "view dependent" with 5.0 in edge length but it will render about 2 times slower. The problem is if i untick "use object mtl" and keep "view dependent" ticked with 2.0. That makes light cache veeeeeery slooooooow. This is all with cache normals and static geometry unticked. Thank you for all of you that took the trouble to reply

Thank you Desmond but i don't think it's a problem with the file or render settings. It's a specific problem with 3d displacement and my Xeon's. It renders just fine on my i7 4770k. If the same file works on a much weaker cpu it should also work on the dual xeon's. I tried everything by now. I'll have to try other older scenes with 3d displacement to see if the problem is the same.

Vray 3.40.02 DEMO has the exact same issues.

Yes, single cpu benchmark in cinebench was something i haven't tried until now: i7 4770k Single - 154 Xeon 2696 v3 Single - 145 It's not a big difference in single thread so this must not be the main cause. It doesn't explain the massive difference in calculating light cache between the 2 cpu's. 17 seconds for i7 4770k and 4 min and 10 sec for the Xeon's. Not to mention the actual bucket rendering was buggy on the Xeon's.

Hi Francisco, thank you for replying. RAM isn't an issue in this scene. It's a small scene (60mb). The 8gb RAM machine translates quicker than the 32gb machine... Vray 3.40.02 DEMO and 3.40.01 DEMO both have the exact same issues as 3.30.05. Cinebench was the first thing i tried with the new workstation. 4398CB. This i7 4770k if i remember correctly gets 620CB. Nothing of this matter happens in Corona. In Corona the i7 4770k renders the scene in 6:31 and the Dual Xeons render in 1:10. No delay in translating or compiling like vray...

Already done that Vince. Turned to 12000, 10000, 8000, same result.

Ok, some more tests done: On i7 4770k | 8gb RAM (onboard VGA) Max 2014 vray 3.30.05 Opens the scene in 24 seconds On Dual Xeon 2696 v3 | 32gb RAM (Quadro K1200) Max 2016 vray 3.30.05 Opens the scene in 54 seconds After this i thought i should revert back to Max 2014 at least to see if opening times would decrease. Results: On Dual Xeon 2696 v3 | 32gb RAM (Quadro K1200) Max 2016 vray 3.30.05 Opens the scene in 45 seconds Not much of an improvement but i guess cpu frequency might play a factor here? Now even more strange: i7 4770k with vraydisplacementmod 3d type enabled resolves lightcache in 17 seconds and renders the scene in 2minutes and 20seconds. With Dual Xeon 2696 v3 with 3d type enabled the lightcache takes 4minutes and 10 seconds to resolve...!!!!!!!! This is with cache normals and static geometery turned OFF. With 2d displacement type i have no problems in resolving light cache. i7 4770k renders the scene in 2:09 and Dual Xeon renders it in 26seconds. One of the Xeon cpu's is an "ES" version. Does it play a factor here when using 3d type?

Ok, if i'm using the 2 cpu's with the environment variable enabled and tick the "cache normals" and "static geometry" on vraydisplacementmod, it takes 2min to compile geometry and 20seconds to render the entire scene. If i remove the environment variable and only use one cpu it only takes 20seconds at compiling geometry and renders the scene in 35seconds. This is using Irradiance map. My old single Xeon renders the scene in 4m55. I seriously don't get this. Does vray do a bad job in managing 72 threads? Corona has no trouble in utilizing all cpu's and renders the same scene in 1min. I must say that i also tried vray versions 3.40.01 and 3.40.02. 3.40.02 crashes max before starting the render. 3.40.01 has the same problem of 3.30.05.