bizarre baking issue seemingly caused by VRAM shortage
Hi,
I've been stuck with this issue for some time now, and I cannot for the life of me find any single cause.
I'm trying to bake this 19 million triangle high-poly mesh:
...onto this much lower poly mesh:
To clarify:
-My mesh is split into 3 UDIMs, all merged at UV0 with respective material names. (1001, 1002, 1003)
-All of my objects are separated because i am too lazy to set up proper naming conventions for my bake groups.
-My model was made in Blender, with cloth assets generated in Marvelous Designer, and my low poly was unwrapped in RizomUV.
-I am using Toolbag 4.03
-I have a 2070 Super with 8 gigs of VRAM, an i9-9900K, and 64 gigs of RAM
-I have confirmed that my GPU timout delay is configured correctly
Ok, so with that in mind, here is the issue:
When I import the high poly model into toolbag 4, it generates these strange artifacts as long as ray tracing is enabled:
This is what it looks like in toolbag 4 without ray tracing enabled
As you can see, the artifacts dont appear as long as ray tracing is disabled. Please note that, despite this problem happening with the high-poly, the low-poly seems to be unaffected.
Ok, now here's where it gets really weird:
If I attempt to bake as long as the shading issue with the high poly persists, marmoset spits out these eldritch horrors/works of modern art:
Immediately after producing what is supposed to be my normal_1001, marmoset just closes. The nature of this crash seems strange, as most of the time, there doesn't appear to be any particularly glaring errors present in the log file. On one occasion I managed to see a large repeating list of "CUDA error 700, an illegal memory access was encountered" but I have since not been able to recreate this error, and new attempts to replicate it have overridden the log file.
Things I have tried:
-I have run 3 different diagnostic programs to detect defects in my VRAM. No problems are present
-GPU benchmarks perform on par with where they should be given my pc specs
-I have tried pretty much every in-app baker setting, I've baked with jpeg, png, psd, I have disabled UDIMs, I've tried changing tangent spaces, etc.
-I have re-installed marmoset software
-I have re-installed my nvidia studio drivers
-If I attempt to bake any piece of my high poly merged with any other piece of my high poly, the issue happens again. I get the same shading artifacts and marmoset spits out randomness. Marmoset will only let me bake single pieces of my mesh.
-I have baked things that are bigger in the past. My previous project's high poly was 30 million triangles with 4 UDIMs and it baked just fine.
-Additionally, I have gone back to those previous projects after discovering this issue and attempted to re-bake. They still work just fine, with the latest GPU drivers and marmoset version. Because of this, it seems that the issue is unique to this model.
If I export just a single part of my high poly model, as well as its respective low poly version, I can bake just that piece alone with no errors. This is true for every piece of my model that I have tried. However, if I take two pieces of the high poly that work in marmoset fine alone, and I join them together, the ray tracing and baking issues persist.
please help or i will implode,
-quat
Replies
" if I take two pieces of the high poly that work in marmoset fine alone, and I join them together, the ray tracing and baking issues persist."
Well, then the next logical step would be to upload a file containing just 2 of these pieces joined together for people to have a look and repro. IMHO nothing else really matters until that one specific aspect is being looked at.
I cant replicate this anymore, this is driving me insane
The single part that I mention in the post that baked correctly is now causing the problem on its own, even though it used to work independently.
After re-importing the same asset a couple of times, the visual artifacts seem to be moving. Sometimes they're very small, and sometimes they're very obvious. That being said, I still can't bake on the part that I was able to before
I got it to crash in such a way that it managed to save the log file properly this time.
And here is the high-poly that caused the problem:
https://www.mediafire.com/file/4i30w2cn0de1ea4/bake_test.obj/file
baked onto this low-poly:
https://www.mediafire.com/file/xudysh2os9m38he/nmg_low_packed_mergedUDIM.obj/file
Well, as a fellow user (but in no way official support of course) there are a few points right off the bat :
• there is really no need to share the whole model. As a matter of fact it would be way more efficient to limit the test to as few parts as possible that exhibit the issue.
• Regarldless, the lowpoly loads up in a very weird way materials-wise. It loads up with 3 materials, assigned in ways that do not make sense. I understand that you mentionned UDIMs and that's probably related, but still, UDIMs or not, why would a piece like the silencer be spread around 3 unrelated IDs ? That just seems like asking for trouble.
And even though I have never worked with UDIMs in production, it would make more sense to me to spread the model over 3 cleanly separated UV sheets logically following the design, so that the asset can work well with both pipelines (UDIM and regular multimaterial).
• The lowpoly seems to have unneeded hard edge splits along smooth cylinder surfaces - there is no justification for that :
• Lastly and more importantly, the lowpoly parts seem to not have any UVs at all, at least in the exported file you provide.
None of the above relate to the potential issues with the highpoly, but still they should be adressed first, since your final asset is the lowpoly + a set a textures and the high is just here to, quite litterally, provide the least important surface details ...