I noticed on some recent exterior renders that Vray was taking much longer to render than I would have expected (on the order of 4-5 times longer than I’d expect). To make a long story short it was due to the presence of wparallax planes in the scene. Backing this up, it seems like while rendering the windows or anything that might reflect a window (e.g., leaves are SLOOOW) knocks the cpu usage down to 20% in task manager. If I removed or hid the planes everything rendered nice and fast at 100%. The wparallax planes weren’t a huge portion of the scene (no giant windows or windows most of the frame). I’m in contact with Art at wParallax to see if there’s some issue but I realize the OSL code isn’t unique/original to wparallax. He suggested posting it here to see if any one has any insight or similar issues. My email to him is below that explains it a bit more in depth…
Thank you for the quick reply. I’m not sure what’s going on either. To answer your initial questions, no I’m not using any type of multlimap or multi-sub material and no I don’t have double faces. The old OSL code actually seems to be a bit faster in my testing, but usually just by several seconds over 2-3 minutes of rendering. It seems to get slowed down in every scene I try it in so I’ve boiled it down to just a plain scene with 25 identical planes with one textured applied which I’ve attached. In the scene, the first two material map slots have the old (1st) and new (2nd) OSL shaders in them if you want to compare (I think they are set up the same just with the newer code).
Some additional info:
-to clarify, I’m running 3ds max 2020.3.7 on Windows 10. I’ve got a few other plugins running but nothing that I think should affect this: railclone, forestpack, rpmanager, bercon maps, colocorrect, to name a few.
-the slowdown is quite dramatic in the test scene for me. I’ve got a Threadripper 3970x with 32 cores/64threads and 64gb ram and I get times of around 2:30 (150 seconds) at 1920x1440 with VRay 6 Hotfix 3 (just regular CPU mode). The same scene but with a standard map in the illumination slot (for example I used the same “wP_Retail_v1…exr” from the sample scene) finishes in about 3 seconds (10 seconds if I use progressive rather than buckets which is somewhat inefficient in this case).
-if I switch it over to VRay GPU 6 Hotfix 3, it finishes in 3.8 seconds using both the old and new OSL shader using a GTX 3070 and the CUDA engine (3.9 sec using RTX). Even if I switch the CUDA engine over to using the CPU (3970x) only I get a time of 8 seconds.
…
I’ve recently updated to VRay 6 from Next so I thought that might be the problem but I tried reverting back to next and the problem persisted.
I’ve been using wparallax for a while now (I think shortly after it was released) and don’t recall similar behavior previously) which is why I tried reverting back to Next. As I said though, no change. Maybe I just didn’t notice the slowdowns before though since I don’t really watch the task manager that much.
I realize it’s not a good idea to directly compare VRay CPU to VRay GPU directly but it seems like something is getting messed up on the CPU side since the results are so drastic. I’ve attached the scene if anyone wants to try it out. You don’t need the right EXR, any bitmap will do. I’ve also tried recreating the material using the VRayOSLTex map but haven’t been able to get that to function as expected.
Is anyone having similar problems using wparallax? Any ideas what might be causing this? wParallax_Troubleshooting.zip (1.12 MB)
Hi thanks for posting. You’ve sent only a 3ds Max file without a single asset. I am afraid I will need all assets used in your scene in order to troubleshoot. If you wish you can use our support contact form as well.
With all the slowdown fuzz that is surrounding the Threadripper CPUs lately, I’m wondering if it’s because of these specific CPUs. I can’t test it because I also have threadrippers. I wonder what the outcome will be.
The scene is just one repeated plane with a wparallax map in place (all of the other maps are just from the material editor slots and aren’t used). I didn’t want to repost the large exr but the problem occurs with any map plugged into the OSL filename so it’s not really necessary. I think I’ve got it diagnosed and fixed though-see below.
I’ve determined that the problem is the 3.7 security update to Max 2020 I installed about a month ago. Since I went from stock 2020 straight to the 3.7 Security update I’m not sure at exactly what point this issue started though since all of the updates are cumulative. (i.e., it could be from 3.4). To figure this out, on a different server (a 72 core Xeon) I loaded up a brand new virtual machine with windows 10, installed 2020 and Vray 6 then rendered the test scene (no other plugins). It rendered just fine at about 10 seconds. I then updated Max 2020 to the 3.7 security update and rerendered… it took over 3 minutes. With this confirmation in mind, I then uninstalled max 2020 from my main machine, reinstalled all of the plugins, etc. and got a time of 3 seconds (10 in Progressive)!! Back to normal.
I’m not on subscription so I can’t update max to 2023 other than the trial so I’m stuck with that. What’s weird is that the stock version of 2023 doesn’t exhibit this behavior and I would have assumed any “fixes” from the 3.7 security update would be included in 2023. Obviously it’s something Autodesk either noticed and fixed or messed up in the 3.7 update.
I saw these years ago while they were being talked about. I am glad to see that they are now real. I am sorry about the slowdown; I am going to check them out anyway
I’ve never used them for full view fake interiors like they show on their website. Not that you couldn’t, the resolution and quality are mostly there. I use them almost exclusively to add just a bit of random interest behind the glass of windows and break it up a bit. I can easily take a repeated plane with random ids and have instant activity. I just make sure the planes are about the right size for the floors and place them behind all of the windows. Occasionally you’ll see a returning wall and the proper perspective on them goes a long way imo. If anyone really peeked at what was happening in these rooms they’d notice thing aren’t quite right though. No one does though.
Relink finds them all. I can see them in the martial editor. I’ll play around with in more when I get time. Their help does say V-Ray is slow to process.
The “slow” processing I think is only on the file open. I’ve never really noticed anything other than a few seconds so I’m not sure what your issue is.
On the larger issue, I’ve updated Max 2020 to 2020.3 (Update 3) and the OSL texture seems to work OK with no delays so I’m going to leave it there.
