I might frame the email and give it to him for christmas 
Yup, that would do it, nothing like a constant reminder.
1 Like
Hey guys, just wanted to give everyone a heads up. One of the Blender devs made some changes a couple of days ago that broke the file output node in the daily builds. This caused an error about not being able to delete a socket on a built in node, and the render would fail to initialise.
I reported it last night to the Blender devs, and they fixed it within a few minutes, so you wonāt be able to use Turbo Tools with the couple of daily builds released in that short period of time.
Just thought I should mention it in case anyone runs into it 
Great. I wish you can get rid of the cache file. Its kind of nasty thing, vanish sometimes, or if rendering large scale, the cache is always reloaded before and after rendering. Maybe something broken, but even then then the tool should be able to handle that.
You can just disable the animation option in the Turbo Tools Compositor Panel. This will make sure the cache is never loaded back in. Be careful though, if you have it disabled during rendering, non of the cache will be generated, and youāll lose all of the below feature Turbo Tools comes with.
The cache is never reloaded before rendering, in fact the cache nodes are completely removed before rendering. After the full frame range has finished rendering, the cache file is then brought back in. This isnāt a bug, itās what makes all of the Turbo Comp features possible:
Caching parts of a branch - for example in your comp tree you might have a branch with several expensive nodes, that in combination take 10 seconds to evaluate. If you then want to add an rgb curve node or something similar at some point in the tree after those nodes, then every time you tweak a parameter, youāll have to wait 10 seconds to see the result. The standard caching mechanism is only possible because of the render layer cache availablility.
Updating the compositor - The render layer cache system is needed to automatically load the correct rendered frame when changing the frame. The render layer node only stores one frame, and itās lost when updating the compositor from python.
resaving file output nodes - This has been begged for over the years. The ability to resave file output nodes without needing to re-render the scene. For example you might decide you didnāt like the result of your compositor tree as it was during rendering. In the past youād need to re-render the entire 3d scene. With Turbo Comp it doesnāt matter, because all of the render layer cache is generated directly from the render layer node before the compositor tree takes an effect. So the cache allows you to make unlimited changes without ever needing to re-render.
publishing - You can only publish because the render layer cache files exist. Without them youād need to manually create your own exr files and bring them in as an image sequence, and then move all the wires from the render layer node to the image sequence. Even worse youād need to do this for every single render layer node in the scene. A massive job if you have lots of viewlayers and multiple scene, particularly if you have a lot of passes in each that you need to rewire!
You see, the render layer node doesnāt keep reference to all of the rendered frames, so without the cache Turbo Tools generates during rendering, you lose all of the render frames from memory. This means again, youād have to manually bring in your exrs and replace all of the render layer nodes with them. I mean you could have two scenes set up, one for rendering and one for compositing, but again, that requires manual setup, whereas this is all automatic to reduce workload.
I could remove all of the above features. It would definitely speed up development, but I think theyāre too useful for people not compositing in external applications. Having an option to turn off caching altogether, and only keeping turbo render may be possible, but it would be a ton of work for the sake of not waiting a couple of seconds at the end of each completed animation render for the node tree to load in a few EXR files and recalculate the tree.
If ever you find the cache fails to load after publishing or rendering, you just need to press ctrl z a couple of times to put it back to the correct state and then click refresh all to load the newly rendered cache. This is actually an issue with Blender failing to execute queued python commands after changing threads. In version 3.0.5 of Turbo Tools Iāve added extra checks and attempts to resolve without intervention, this was possible thanks to Blender 3.3 upwards exposing additional API parameters. So Iād recommend upgrading to Blender 3.3 or above and getting turbo 3.0.5 to reduce the chance of that happening. It may still happen occasionally, but in later version Iāve added a pop up message to notify the user that they need to press ctrl z a couple of times, this avoids any issues with future operations. Itās just a minor unavoidable annoyance that should be extremely rare now.
Currently working on the next Major release of Turbo Tools (V4). This ones going to be groundbreaking if all goes to plan, the biggest rendering speed improvement yet.
Hereās a sneak peak. Both rendered at 8 seconds per frame (including Turbo Render denoising!), no temporal stabilisation used at all. The new feature coming in V4 will probably make stabilisation unnecessary.
The quality is much lower on the V3 version because to get the render time down to the 8 seconds per frame achieved with V4, I had to dramatically reduce the sample preset and the denoise preset. To get V3 to render to the same quality would take around 4 to 10 times longer. This is pretty amazing, because Turbo Render is already speeding renders up by between 5x and 40x (120x if texture quality is considered) compared to the denoisers in Blenderās render panel. The worst case scenario in V4 is going to be 25x to 160x faster for client quality quality results (480x for scenes where the other denoisers canāt avoid losing textures).
Hardware
gtx 1070
i7 7700k
Turbo Tools V3
download the v3 version
Turbo Tools V4
download the v4 video for comparison
Guess Iāll be the one to ask the obvious question.
8 seconds per frame render time is pretty amazing but at the end of the day, even tho V4 is better, the artifacting/shimmering on the highlights at the corner of the bench top and even in the reflection of the dice still isnāt good enough for anything but a personal test preview.
Hence, what I would love to see the most (and maybe this is only something to be done once you have all the code sorted out), is a time comparison of basically a perfect video animation (so no visual errors) between a standard Blender 3.3.1 Cycles render and Turbo Tools V4 and even V3 if you want.
For me, at the end of the day, my real interest isnāt in how super fast you can get an OK-ish render or how fast one version is compared to another. It totally comes down to, here are two final production quality renders, yes they look the same (or maybe one even looks better, as in texture details, etc). But result A in default Blender takes 3mins per frame to render, while Result B using Turbo Tools V4 does it in 25 seconds, both using a GTX 1070 GPU.
3 Likes
Yes, thatās a great idea, Iāll do that. The only problem though is that the speed gain is different for all scenes. Basically, the longer a frame takes without turbo render, the bigger the speed gain. For example in Turbo V3, a 10 hour still frame render is often reduced to around 7 minutes, whereas a frame that only takes 10 mins without turbo render will only be reduced to around 1 to 2 minutes for production quality.
The V4 update (based on tests so far) will give a further 4 to 5 x speedup on whatever the previous speed gains were for any particular scene.
That seems fair enough. So with that in mind, I have another suggestion, tho it may be a little more work or tricky to sort out.
If you can create and/or source a few test āproductionā scenes, something like a character animation, an indoor still archvis, some sort of VFX smoke/fire/explosion shot.
So a range of scenes and images that covers most of the general usage for Blender with render times that in standard Blender are reasonable without being insanely long and then use them again and again as a basis for testing and showing what Turbo Tools can do for the same quality as default Blender just faster.
A mix of both stills and animation would be ideal, as for some (like myself) my main interest is in animation without rendering/de-noising artifacts.
For a source animation scene, I can think of at least one easy example you could use and it would make a great production test and speed difference. Grab a 3-5s shot from the new Blender Studio film, Project Heist.
As for the others, maybe you could reach out to some of your customers and see if someone will give you a sample scene or two you can use.
I just think nothing sells a product like real word examples and direct quality comparisons and I can tell you right now, I would so love to see the render time/quality comparison of a Project Heist shot. But that may just be me.
Anyway, just a thought, Iām sure sales are going just fine either way, NASA kinda confirms that.
2 Likes
Thanks dude. Theyāre great ideas. I have done some videos with the various test scenes such as the classroom and barbershop:
Barbershop: https://youtu.be/03nxESgQmFk
Classroom: https://youtu.be/Fj6VCCSfgn0
Volume scene with cc0 vdb available so you can follow along : https://youtu.be/YW2WGot3CBs
Iāll definitely start doing more animation showcases in V4 as well, now that itās so much faster with the development version of V4. Project Heist sounds like a great plan too.
Iām somewhat familiar with the Classroom scene, as I used it for my own speed benchmarks when I recently upgraded from a 1070 Ti to a 3080 Ti (I even made a video about it all, but wonāt pollute your thread with a shameless plug).
Still, as you say, when the render time gets shorter, the advantage really starts to shrink. Once you throw a modern GPU with OptiX at it the classroom scene is almost done in a blink of an eye.
Iāve not had a look at the Barbershop scene tho in sometime or tried it with the 3080 Ti, so when I get a chance, Iāll check out your video and try a few tests to see what quality and speed are like.
I have data limits on my Internet connection and some of those Volume scenes are pretty big, but when I can, Iāll give that a go as well, since my curiosity has been sparked.
1 Like
Awesome, someone in the comments tried the barbershop with the 3080 and 4090 (persistent data enabled to so that only actual render time is considered):
pasted from a bit higher up: š Turbo Tools V4 - including TURBO RENDER for MUCH FASTER Cycles renders! - #393 by Michael_Campbell
Hello, I love Turbo Render and the publish animation feature! it was working wonderful until yesterday. The first time I used publish animation it worked great but now I made a Full Copy of a scene in the same project to make a different animation and now Iām getting the "āNoneTypeā object has no attribute ānameā error. I already tried the solution you provided in the gumroad post and it didnāt work sadly :(.
My compositor only had the cache node connected to Composite node and Viewer node before rendering the animation. Iām using blender 3.3.1. If you have another solution let me know please, thanks in advance!!
Hi, when you duplicate a scene, the cache will no longer be able to load because the cache is loaded based on the current scene name and viewlayer name. As the new scene has a different scene name thereāll be no cache for it in other words.
To fix the problem, in the scene that is giving you this error, select the render layer node (not the cache node), then click cache/uncache to automatically move the wires back to the render layer node and delete the cache node. Then click refresh all. Youāll get a message saying you need to re-render because thereās no cache for the current scene/viewlayer combo.
After this point youāll need to re-render to generate cache for the new scene.
If itās happening in the same scene you rendered in, then that would indicate an issue, in which case, do the same as above for the current scene. If the error persists after that, then it may be that an older version of the addon didnāt uninstall correctly when you upgraded, in which case remove all instances of turbo tools, or turbo boost (itās old name), make a note of their folder locations first, and then close blender. Go to those folder locations and manually delete the turbo tools/boost folders. Re-open blender, and then re-install from the zip file.
If you still have issues, then delete all geometry from the scene, clear ophan data until the list is empty to get rid of all packed textures etc, upload it someplace, and send me the link to the customer support email address shown on the receipt, and Iāll take a look at the file (itāll be tomorrow now, as Iām just about to clamber off to bed).
I think youāre missing the point here. I think what Michael is trying to impress is how decent the quality can be at even a measly 8 seconds per frame. By shooting a much higher sample value, the results should get progressively better. The point I think is that imagine a 3 minute render looking as good as a 3 hour one!
1 Like
I already tried a quick test and that 01:25 tracks with what I got. So a worse case would be using Turbo Render on ultra settings, which likely results in even better textures while being 3 times faster. So thatās pretty impressive.
Yeah, I get that, but my point is that as good as it is for 8s, all that artifacting still makes it basically unusable. No doubt default Blender at 8s would be even more rubbish.
To my mind what matters more is comparing final production quality results where sometimes it can take an extra 30-40% of the render time just to clean up that last 5% of artifacting.
Now sure, Turbo Tools will still do it faster, but is it a direct linear scale or does the speed up amount decrease when trying to get a clean render output, especially for animation.
1 Like
The texture quality is practically flawless even at the very lowest samples setting of ācrapā The areas where youāll see improvement with more samples are shadows and lighting.
Hereās a good demonstration of that:
Preserving Textures is actually a 10 year old trick, where you denoise the GI pass and the multiply it with the color pass. I use that technic to denoise all my animation, long before using Cycles.
However, denosing quality on still frames has largely improved over the years. Anyhow, it also need to write out more complex layered EXR images with all channels needed. Which will lead to the need of customize outputs, to animation, so you donāt need to handle Terabytes of data.
The downpoint of denosing is, that most normal and bump mapping will be vanish, also small details in models are a problem. I often texture these details, as textures do not need to be denoised. Another area with problems is transparency.
On interior renderings of animation I had to go up to 2048 samples to get exactable results, that I still had to denoise a bit in compositing. On animations its tricky to say, its useful. Some scenes almost works perfect and fast, others are flickering despite denoising and you may get the same result with classic compositing denoising, based on frame interpolation.
After a few projects, I see a clear win situation, with some exceptions, where the results could not match the quality I have had before.
Another Test of the V4 features Iām currently experimenting with.
This 4k image was achieved in 22.92 seconds on a gtx1070! I still have a lot of testing and tweaking to do to make sure itās viable in all scenarios, but itās looking very promising. A bit wobbly because of the ultra low samples, but Iām just concentrating on speed at the moment.
The result of more tweaks with the upcoming Turbo Tools V4 code. This is 4k in 30 seconds this time. Still not perfect, but considering this scene takes 16 hours to render 4k without turbo render/denoising, Iām pretty happy:
This is actually a 16x speedup over the already blistering results Turbo Tools V3 manages! This will be classed as low quality settings, but should still have very little temporal flicker even without running the stabiliser.
1 Like