The_Lightmapper
The_Lightmapper copied to clipboard
Naxela
Suggestions: progress bar / time indicator
I'm currently experimenting with setups to get some nice quality without the builds taking too long (such as splitting walls into multiple pieces and giving each a material, but also higher res textures and different cycles settings). However, most of the time I have no clue how long it will last. Would be nice to know if will take approximately 10 minutes, 3 hours, 2 days etc. So a "xx minutes remaining" would be very nice, even with a big error margin some indication would be very helpful
Hi,
I have been experimenting with such as function, although I only recently got into the GUI coding thing. I'm not sure it's possible to have a fully realtime ETA timer thing, but I think a progress bar should be possible in the future. - Otherwise, if you don't mind some error margin, I could probably make some very rudimentary render time calculator, probably something like object * material * resolution although it's going to vary a lot, depending on if the object is outside, inside, reflections, etc.
The very rudimentary option is already a nice improvement, just having some indication at all helps a lot. Thanks!
I'll see if I can get it implemented sometime soon, in the meantime in case you haven't noticed it yet - If you turn on verbose in the settings, you can see the progress and which object it's currently baking in the console as it progresses:
Ah that already helps a bit yeah, thanks. Looks like most time is currently in prepping and denoising though, not even the baking. If you can put that into the rudimentary progress indicator that'd be great. I guess for a more accurate indicator later on you could try to measure time taken for specific tasks during a bake and then extrapolate them for future tasks so the indication gradually becomes better for a certain machine/configuration.
It sound strange that most of the time isn't spent on the baking itself, which might provide some clue to the other issue with the long render times, as baking should in most cases be 70-90% of the entire building time, although smart unwrapping is python based in version 2.83 LTS, whereas it's been ported to C in 2.90+ providing a substantial speed-up if your meshes are complex.
The time spent denoising does get quite substantial if your textures exceeds 1K and with 4K and 8K textures, I think that could be one of the bigger areas where your time is spent. I think the only way this gets better is as the denoising models get's trained better (by each gradual OIDN release), alternatively Optix is GPU based and slightly faster although I find the results aren't as good.
Anyway, I have worked on some averaged time estimation in the console in the latest commit, which does seem to provide a decent guess for remaining time:
I'll try the latest version next time, curious how accurate the progress is, thanks for the fast implementation! I am running 2.83, so I'll upgrade soon. Then again, unwrapping is not really the problem for me since I usually do that myself ahead of baking. Denoising definitely was taking up a lot of time though. I'll try to screenrecord a bake next time so you can see what's taking most of the time.
I baked just now with the latest version and recorded the entire bake. The textures are divided as follows:
- walls 4096
- doors + arch 1024
- floor 2048
- ceiling 2048
- lamps 256
It seems to also take a while before it actually starts baking and the remaining time goes up after the first texture. I hope this is of any help!
https://user-images.githubusercontent.com/9960351/108036767-f07aef00-7038-11eb-8a1c-e7ac2a93ca2e.mp4
Hi, there seems to be 3 areas that can be improved somewhat in terms of performance.
First, there seems to be some time spent on UV preparation which shouldn't be necessary as it says the UV is already found and prepared. I'll have to look into that, as it seems like a bug.
The actual baking itself seems to be reasonable enough time wise, the resolutions taken into consideration. Depending on your scene, you might be able to improve it slightly by splitting it into submodules (say 2 walls with 2K rather than 1 with 4K), but that's only if it's not a problem with seams.
Next there's the denoising. I notice that you're using the integrated denoising solution, which not only is slower but also seems of lower quality than native OIDN denoising and somewhat slower than Optix based denoising (although Optix can be disregarded as an option on Linux).
Glad to have found a bug at last, hopefully you'll be able to find it. If I can help debugging let me know!
I tried splitting the wall into parts but did get problems with seams. I might have to later on though when I build out the full maze and 8k resolution won't be enough anymore. We'll see I guess.
The denoising is a dumb mistake on my part, I had changed it to OIDN before but forgot to fix that when switching to blender 2.91. So thanks for noticing that.