Hello, I hope everyone is doing well. I have not been able to get a successful bake without errors in a Layer project when using a file containing cage meshes. The target .fbx file contains 11 meshes with the suffix “_low” and a polycount of 5,638 tris, along with 11 corresponding cage meshes inside the same file with the suffix “_cage”. The source mesh has 11 meshes with the suffix “_high” and 12.9 million tris total, but I also tried a 6.9 million decimated version, both having the same result when baking via the “By Mesh Name” targeting mode.
To me, it appears as if the cage meshes, which are sitting directly on top of their corresponding low-poly counterparts, are being baked as separate meshes rather than being utilized as cage meshes.
Please let me know if this is a possible bug or if I am just doing something wrong with the setup
Thank you, @Pixby ! I am sending you a Google Drive link to the .fbx files via PM.
Disclaimer: I’m aware that the window frames would need further “exploding” to achieve a “technically” error-free bake in the normal map, but “visually” it still bakes error-free in Blender (since errors occur only at non-visible geometry intersections).
I have been able to reproduce the baking errors when using the cage meshes, however when removing them I’m able to get a much cleaner bake. (Aside from some overlapping UVs on the “Main” material ). I will bring this up internally so that we can further investigate the cage mesh behavior.
Thanks again for reaching out and I’ll provide more information once it becomes available!
I’ve fixed those UVs and updated the link accordingly, in case you still need the files for internal testing. Baking without any cage meshes produces a much better result than I thought it would, so I’m happy I can at least move forward with the project. Thank you again for all your help and your sharp eye!
Awesome @TheFifthSardonyx that looks great! So glad we were able to help and that you can continue with your project. You’re very welcome! I’d love to see the finished result someday!
Due to cage baking not functioning at present, I ended up setting the “Outwards Ray Length” to 2.5% to accommodate the inward sloping walls, and protected the fine details of the window frames from bake errors by fully exploding the mesh. I was very pleased with the results and with the abilities of InstaMAT.
One thing I noticed during the process was that Layering projects seem to be GPU bound. During baking, I was able to select “CPU” as the baking engine, which was great for my older GTX 970 4GB, since the source mesh was very high-poly and attempting to bake on the GPU would result in InstaMAT crashing.
While adding material and paint layers in a Layering project, I was able to work in 2048 x 2048 16 bpp almost until the project end, however, I did eventually have switch to 1024 x 1024 16 bpp, as attempting to load one of the three active materials (the roof material) would push the GPU memory usage over 63% and cause InstaMAT to immediately crash.
I have 32 GB of RAM on my pc, and I don’t know if it would be possible or not, but I think it would be awesome if InstaMAT either fell back on system RAM once a GPU RAM threshold was reached, or just allowed the user to switch the rendering engine to CPU during a Layering or Element Graph project (I should note I already have the “Preview Quality” set to “Low”, which certainly helps a lot, but it doesn’t take many layers to max out those 4 GB on the GPU at 2048 resolution).
Thanks so much for listening to this feedback, and again, I really thank you for such an amazing program!
Thanks for sharing the final result @TheFifthSardonyx! It looks great!
By the way, we have an InstaMAT > Showcase category here on the forum if you’d like to share your work and any workflows you’d like to share when using InstaMAT.
Regarding InstaMAT’s memory management, InstaMAT does fall back to system RAM when the GPU RAM limit has been reached. It’s possible though that the driver for the older GPU does not support his. In this case it is up to the GPU to be able to support this functionality.
Congratulations on finishing the project and thanks again for sharing!
That’s great to hear that InstaMAT does support system RAM fallback. I had been using GeForce Game Ready Driver 536.23, which was released in June of last year. Supposedly the “CUDA - Sysmem Fallback Policy” feature was released with driver 536.40, and driver 546.01 and above featured the option to enable/disable it. I’ve just updated the driver to version 555.99 which was released on June 4, 2024 and enabled the Sysmem fallback feature for InstaMAT.
Unfortunately, it still results in an immediate crash when attempting to load the third Active Material. In Windows task manager, GPU RAM usage does not appear to rise above 3.5 GB of 4 GB, but “Utilization” does jump to 100% just before the crash. Either my GPU does not properly support the fallback feature, or some other issue is causing the crash, but the little GPU utilization bar in InstaMAT grows quite large and turns yellow just before the application crashes. For now, I guess I’ll have to just down-res to 1024 if I happen to run into this on another project.
). I will bring this up internally so that we can further investigate the cage mesh behavior.
You’re very welcome! I’d love to see the finished result someday!
