This took 9 days to render due to the city background.
I realize this is a “night scene” but you really need some more fill lighting so we can actually see the characters
the whole thing is way too dark.
The dialog was pretty cool and interesting, as was the idea/story itself. I also liked the understated animation of the characters.
As @AutoDidact already mentioned, the render needs more light and there is too little contrast. Since most scenes don’t show a lot of details and are sometimes fairly grainy (plus there are some blocking artifacts which are probably due to YouTube compression), I’m not sure why it took 9 days to render this (presumably in Blender)—even if it was 4K: I figure, on average, 2 to 2.5 minutes per frame, which seems a little long for what ends up on the screen.
I sometimes have render times that are longer than that, but then there is usually a ton of details, or transparencies, reflection, refraction, etc. (or they are indoor scenes with lots of light sources). But maybe I should run a few tests with night scenes in a city. Perhaps the render time is reasonable after all…
Yeah. It has to be the icity 1.5 i used in blender to create the city; when i delete the city and its just the guys and fog it renders at 4000 samples in about 20 seconds per frame.
When the city is in the shot, it was rendering between 3 and 4 minutes per frame at 600 to 1200 samples. 60 frames a second.
Im on a 4080 super gpu 16gb vram, and icity 1.5 filled that up. I used the fog to cur down on the distance because i removed some blocks because it was just too intensive.
Its a sad trade off though… icity 1.5 is such a good add on to create the city… im just gonna need more vram or hope blender 4.5 vulkan speeds it up.
Here is a quick night scene with a large urban environment from Daz and a single medium poly Character from, my crowd simulation system for Blender
Only 96 samples in EEVEE legacy for about a 5 second render time.
As animated filmmakers we should all be aware that when a Hollywood production films an “on location” shot in some back alley up here in New york city they definitely do not use the available lighting from the city street lamps etc.
They setup all kinds of ambient reflectors and fill lights so those highly paid actors can have their faces seen on screen.
Now unless there is some stories/plot narrative that requires partially obscuring characters in darkness, we should be doing the same,even if in the “real world” it would naturally be too dark to see peoples faces.
OK. Since I’m not a Blender user, I don’t know Icity 1.5. For city backgrounds, I normally use pre-made models and instanced copies of the square blocks to increase the size of the city (which would not really be noticeable, particularly at night). Perhaps similar ways exist to increase render performance/cut down on VRAM usage with Icity.
The Icity addon is a procedural city generator
https://superhivemarket.com/products/icity
It has the option to reduce the textures from (what is likely) a 4K default, as they also target game developers in their marketing.
for that Dark car chase scene you could ha literally used perhaps two static city blocks from Daz and fliped/turned them for each camera cut and gotten enough “urban variety” in those shot.
Also I have no idea why you are rendering 4000 sample yet still getting horrible artifacts with the vehicle headlights glare.
Oh no no; 4000 is just what i tried without the icity and just the cars, fog and characters… the render city i dropped to 600 for the car driving parts and 1200 for the two guys. Otherwise it wouldve taken a lot longer to render.
I tried another city builder, not as detailed but faster rendering.
This reminded me a lot of some old MovieStorm flicks from long ago. Simple silly setup. Amusing dialog. Fun.
I agree with simplifying the physical setup and improving the lighting. That’s a whole lot of processing for grainy, blocky results.
So I discovered. It does look interesting, especially because it does not seem to be tied to that square grid pattern that other city generators I have seen appear to be. If I were a Blender user, I’d definitely look into that.
I have no basis of reference whether 600, 1200 or 4000 is a lot (the render engine of my choice does not operate with a number of samples fixed in the render settings but rather with a margin of “acceptable error”) but I can tell that, purely in terms of render quality, none of these settings appear to be really working for the scenes in this video while keeping render times manageable.
I’m not familiar with Daz and Daz assets either, but I think the scene setup could have been optimized especially with a dark environment and limited visibility (on occasion, I use render proxies which are more efficient in terms of VRAM usage for static but fairly high poly environments). Perhaps Icity was a bit of overkill for this project.
Cycles will render everything in the scene, even if it’s off screen, just to get accurate light bounces. So you’re basically rendering the entire city every frame, which is pointless, especially as it’s so dark.
Strangely enough I was just watching a video on you tube that covered rendering optimization techniques that could apply here:
Pay particular attention to the Frustum Culling section, I think that might help a lot.
Wow, 9 days is insane… And sorry to say, esp. for this poor quality.
As this all takes place on one environment,
the whole thing with camera switches would have been rendered in Unreal within 10 Minutes…
I don’t use Blender for renders, and I know render takes longer in Blender,
but it seems you definitely need to work on efficiency.
9 days… especially on something that isn’t really necessary to say. I barely could see, it’s like if the city had its power cut. Study night scenes and look to reference images. Lawrence Sher had a great breakdown when he shot Joker somewhere when it come to lighting.
You should probably jump ship with cycles and look to going with a real time engine like Eevee or look to unreal engine. If the city can be exported in fbx, it should be fine to use in unreal engine. Otherwise there’s blueprints that assemble a pretty decent city block in no time.
From there, you should focus your sets from a more focused area. I usually break it down by block, street, or alley. That way, you can emphasize more on set dressing, lighting, blocking, etc with the resources that are allowed.
Hope it helps
Well the OP would be better served learning how to light a night scene in Blender (cycles or EEVEE)
and break those city generated scene into shots for better optimization.
Installing the over 200 gigabyte UE5 editor learning UE5 blue prints and buying all of the Reallusion plugins etc is probably not the best choice for the OP at this point.
Having recently installed UE 5.6 simply to export motion data for use in iClone, I agree. The installation also took several hours and consumed more than 400 GB of storage space on my drive (probably due to the way the drive is set up and the fact that there seem to be numerous small files)
Also, I don’t really see the point in having RT render engines for narrative animations (as opposed to games) that you do as a hobbyist, if it means accepting visual degradation/limitations or having to learn entirely new software (in the case of, for example, UE).
Yes, the 9 days in this case seem a bit long, but if you can leave a machine just chugging along by itself for that time, it is still doable. Unless you try to crank out a ton of animations, the time for the final render is probably not that important compared to the time required to prepare the animation and learn the software in the first place.
What good is a superfast final render time of mere minutes when you had to spend weeks and months learning the software to get there?
9 days to render four minutes of animation
at the quality level shown in his video makes no sense period.
This is not a Blender software capability issue.
It is an issue of knowing proper render sample settings for animation.
Proper night time lighting set ups.
And learning to use the Icity addon with it is lower than 4K default settings
I was not referring to the render quality per se, but just to a machine being tied up rendering for 9 days. Obviously, the relationship between time spent rendering and the quality of the result is out of whack here.
My point was that (provided the render quality is decent), tieing up a machine for a render taking days is not necessarily undoable if the alternative means learning new software (e.g. UE) just to get renders faster (obviously, scene optimization should come first). At this time, I’d rather wait 9 days for one of my machines to finish rendering then learn UE to get a render in a few minutes, but, hey, that’s just me.
Technically I have 5 computers although one netbook/laptop is in storage and the other 17 inch laptop has a touch screen and is basically been repurposed as Drawing tablet.
That leaves my Big dell desktop tower from 2021.
and My older intel Imac ,that is my primary internet device,
and an old HP, all in one ,running Linux Mint where I mostly watch cartoons & animated series.
So obviously I can commit to long render times on the Dell with Vray in C4DR25, Blender cycles or Arnold in Maya and not be at a stand still.
But I agree that even if I had the drive space, I have no interest in installing 400 gigabytes for UE5 and learning that pipeline .
And even if I did I would start fresh with the Metahumans and other game rigged Characters and scene content created & exported directly from Blender not Iclone/CC3.
Hm, not sure where those numbers come from, but 400 GB sounds ridiculous.
The needed space for UE 5.6 is 33 GB, even if you add debugging and all platforms (Android/IOS/Linux/TVOS) it would be about 140 GB,
but these are not needed at all if you want to run UE for cinematics on PC.
I currently have 6 versions installed, UE4 versions about 25 GB, UE5 versions about 35 to 40 GB each…
Sure this takes some time to install, esp. when you don’t have fast internet speed.
Anyway, the OP wants to use Blender, so he will have to learn some basics about efficiency and the different render systems…