BUG: RTX Bucket | Resumable Rendering | High Noise

[S_K_I]

Specs:
4930k o/c @ 4.2ghz liquid cooling
ASUS TUF 3090
Sabertooth X79
Corsair Vengeance 32GB (4x8GB) DDR3 1600 MHz (PC3 12800)
Sabrent 1TB NVME drive

I've discovered a bug when I'm doing high resolution renders with the 3090 in RTX bucket mode. As you can see in the pics included the snow is producing major noise issues when resumable mode is enabled. I've been able to replicate this once or twice after my system crashed or I stopped it. I don't know for sure if it's directly related to resume being on because before I had memory errors such as this:

[GPU light cache] Could not allocate pinned buffer of size 148800000!

I fixed it that issue by dramatically reducing the vraydislplacementmod amount from 3" to 9" in my entire scene, however, even then it's still accessing all 24GB of the VRAM and 32GB of the RAM, and a significant part of the buiding geometry, optix, etc. was being written on the NVME. Secondly, the noise is specific to the snow shader I made based off of your "Creating Snow with VRayStochasticFlakesMtl", all the other materials render completely fine. Earlier this morning did a region render of the snow on the ground with the plants included (also has the same shader) with all of the same settings, only change was resume rendering was disabled. Did another render and happily it came out fine with no noise, so again I'm left to wonder what variable is involved here. As I said before my computer BSOD'd twice last night for RAM reasons alone so it's possible that the bug may be related to the PC failure or the severe lack of memory creating the bug. The event log never produced any errors either.

I'd upload this scene but it's over 500MB and the textures alone are close to the gigabyte range as well so let me know what you need so I can provide more info for you guys.

Thanks.

[nicolas_fuminier]

Hello S_K_I,

Tought one without runing some test on the original scene.
Your render parameter looks fine to me at first.

Look like a VRAM issue for me (or maybe a RAM issue). Can you monitor your VRAM load during a render ? (With the "stats" in the VFB tab, top right corner)
Does your Log tab show any other warning (orange) / errors (red)


I would lower or disable some variable, and try to put solo each sensible parameter who usually make scene crash and see what tests my scene passes and what tests my scene does not pass (they might be more than one problematic parameter, or a duo of parameter not working well together).

First ideas in mind :

• Hide, unhide some objects or group of object
• Overides your maps with a grey basic shader (possible issue : Flakes map problem, SSS problem)
• Remove every displace (you've already tried this one), but is your Vraydisplacement has a good setup ? (Basic one work most of the time, 3D mapping mod, not relative to bbox, 4pixel might be a bit big for a 6K picture start à 6, View dependent)
• Did you try to render with progressive mod instead of bucket or there might be a reason for bucket ?
• Did you try to render the image with brut force instead of Light Cache (more time consuming, more noise but that could help to point out an issue)
• Lights (size, intensity, sampling, did you scale your lights ?) Specialy the top right one "plane light" ?
• Do you have dirt map, curvature map or other procedural map that might load a bit to much RAM or VRAM at computing time ?
• Are your multiples walls are in instance or in copy ? Do they have the same maps or multiple maps ?

It might coming from many other place,
That's just first tought,

Nicolas

[S_K_I]

First ideas in mind :[LIST][*]Hide, unhide some objects or group of object[*]Overides your maps with a grey basic shader (possible issue : Flakes map problem, SSS problem)[*]Remove every displace (you've already tried this one), but is your Vraydisplacement has a good setup ? (Basic one work most of the time, 3D mapping mod, not relative to bbox, 4pixel might be a bit big for a 6K picture start à 6, View dependent)[*]Did you try to render with progressive mod instead of bucket or there might be a reason for bucket ?[*]Did you try to render the image with brut force instead of Light Cache (more time consuming, more noise but that could help to point out an issue)[*]Lights (size, intensity, sampling, did you scale your lights ?) Specialy the top right one "plane light" ?[*]Do you have dirt map, curvature map or other procedural map that might load a bit to much RAM or VRAM at computing time ?[*]Are your multiples walls are in instance or in copy ? Do they have the same maps or multiple maps ?
[/QUOTE]

To some of your points:
1. Did that earlier when I was getting the GPU Light Cache error in the log.
2. Already did that as well. Ruled out some shaders.
3. I set the modifier to "9" for all the displacement mods which was ok because I already had a significant amount of geometry on some of them before adding the mod, allowing me to keep it low.
4. Bucket is simply faster and a lot more efficient on my VRAM. I'm just impatient like that.
5. No, never got around to brute force as I never need it unless for IPR stuff.
6. When you mean scale them, elaborate what you mean, did I scale them with the gizmo or from the modifier settings? Is there a difference?
7. Yea I got dirt maps, procedural maps, up the wazoo. I'll keep that in mind in the future.
8. The front wall is separate from the previous two, both have a displacement mod on them. The outer walls (away from camera view) are a simple box geos for the enclosure, simple maps and no displacement was added there.

I found a temporary solution and that was using the "resumable rendering" vrimg file after the 7 hour mark, created a render region in the areas where the noise is apparent and re-rendered with a unchecking the view calculation phase so it doesn't repixelate the entire scene. All the render elements are intact and consistent with the new renders so for now I'm gonna just gonna finish the render as is and re-evaluate the scene after I'm down so maybe we can get a diagnosis on this for future individuals and for you guys in case this is unknown bug that needs to be fixed. Thanks for your assistanceso far.

[Muhammed_Hamed]

Hey S_K_I

I would love to take a look at your scene, send it over to muhammed.hamed@chaos.com

2 things I recommend, first use progressive image sampler. It is faster and more efficient on GPU memory in the current builds of V-Ray GPU. This will reduce your memory usage by at least 3 GB
Second suggestion is to delete any render elements that you don't need in the scene. The least of render elements, the better

The fact that your machine crashes with BSOD doesn't help, it is best to solve this first. Get Aida64 and stress test your machine, CPU, RAM FPU and cache for some hours until it is stable

And thanks Nikolas like always for your tips, they are helpful as well

Best,
Muhammed

[S_K_I]

Hey Muhammed, the renders have completed for now so it's not a worry for the time being, if and when the issue arises again, I'll be sure to follow up and +1 for the progressive recommendation. To your other question, as I told Nicolas before the files are just way too big to upload. In fact, the snowflakes which I created through TyFlow were in the millions of geos which I eventually converted to a V-Ray proxy. I believe this was giving me most of the VRAM and RAM issues because the proxy itself with all of the individual snowflakes included came out to 3.3GB's and that's what literally ate up all of my memory!!! And that doesn't even include the multiple other proxies, materials, and files. To recreate this problem would be a full weeks job and I don't think you guys have the time for that lol.

Oh and speaking of Tyflow, any experience with that? Was wondering if converting to proxies was the most efficient method or not.

Anyways with that said, since I noticed you responded to my other post to the hardware so I'll follow up there in a bit. Thanks for chiming in

[Muhammed_Hamed]

Thanks for the follow up. I'm glad you got this rendered
I have asked about Tyflow workflow, converting to proxies in your case will help with viewport performance and processing time but not memory/VRAM
I will ask for a more detailed answer

Best,
Muhammed

[S_K_I]

Thanks for the follow up. I'm glad you got this rendered
I have asked about Tyflow workflow, converting to proxies in your case will help with viewport performance and processing time but not memory/VRAM
I will ask for a more detailed answer

Best,
Muhammed

Much appreciated brother, thanks.