675x705

will will.png

🧵 Can I unironically ditch the slow ass Cycles for real time UE5 or Unity at this point?

Anonymous No. 889133

https://youtu.be/jhFZF_TiOVE
What's the point of waiting on 1 frame for even a minute, when you can playback shit in realtime not wainting for anything? The realtime light paths are basically look the same now as Cycles or Octane or Corona.
Should I just abandon the old ways?since it's not time efficient?

Anonymous No. 889134

>>889133
ngmi

Anonymous No. 889135

>>889134
explain

Anonymous No. 889145

>>889133
Yes :chad image:

Anonymous No. 889153

>>889133
>since it's not time efficient?
depends on what kind of stuff you do.
Best case scenario, it plays out as you wish, the end consumer doesn't care or even notice that you've done it in a realtime engine.
Worst case scenario: you spent a huge percentage of the time optimizing shit until it looks as good as you wish, time you could have spent otherwise, while your computer (or a cheap renderfarm) is brute-forcing through your renders. And the end result might not even look as good as that of a pathtracer.
Remember: human work-hours are MUCH MORE expensive than electricity.

Anonymous No. 889167

>>889153
Don't you ever check how the render looks like while working on it though? Even just by rendering a small section or in a low resolution, it wastes a lot of time to see results. And you're always partially blind to it because you can never see the final output clearly at all times. Even worse if you're trying to preview vfx. Not trying to shit on it, but idk, it was really hard for me to work on a complex scene with rain with an offline renderer. Results were great ofc, especially VFX was way better than what I could achieve from UE, but I'm still not sure what's worth it more. Both have some pros and cons for me. But UE5 seems promising.

Anonymous No. 889290

>>889133
Absolutely retarded if you think it's the same quality level. You can ditch out eve for those, but all realtime renders look like garbage compared to offline ones, even these fancy new ones. If you don't want your work to look as good as it could, yea you can switch over, but that shouldn't be the regular case

Anonymous No. 889298

>>889167
The problem is that in games you either get "meh" quality or you bake lighting which takes ages.
Cycles is in my experience very fast (2080ti + denoising gets me good looking results in like 3 seconds, unless sss or volumetric effects are used)

Anonymous No. 889301

>The realtime light paths are basically look the same now as Cycles or Octane or Corona.
lmao. i think certain, very limited surfaces can be made to look half decent on UE now (some finished woods, plastics, dry terrain), but most things still look like vidya shit.

that said, i think there's a really big gap in the market for a plugin based near-time renderer. moving things over to unreal is a hassle.
redshift and octane are trying to fill it now with their new 'rt' betas, but i'd like to see more.

Anonymous No. 889309

>>889298
Yes, in games, but we have raytracing and especially Lumen in UE5 now and it is surprisingly good already. It's only gonna get better, UE5 isn't even fully released in a production ready state yet. But I agree about baked lighting, I hate it, even though GPU lightmapper can be pretty fast. Prebake I have even less clear understanding of what the lighting will look like so it's even more painful than just working with small low res images. Cycles is good now, but still it depends a lot on the scene and amount of effects. And I still can't preview how animated effects will render at all if it's not realtime or close to it.

Anonymous No. 889455

>>889309
Any game engine shits the bed when it comes to rendering effects, especially large scale effects.
You want water, rain, dust, smoke, fire etc - you have to put a lot of effort into making it look good and even if you archive a decent amount of quality, its always worse in comparison to a pathtracer, especially if you want to get closeups of any kind of physical interaction of dynamic elements.
Like I said earlier, you spent a lot of time optimizing, time that you could have spent otherwise. With a pathtracer you just sim it and render it. Its mostly brute force, which means the computer does the work and you don't have to hold its hand while its doing it.
Yes, a game engine is 200 times faster than a pathtracer, sometimes 10000 times and the amount of quality you get out of it might be enough in 75% of all cases, but it doesn't matter how good a game engine gets a pathtracer will always maintain its quality advantage since a game engine will always have to use shortcuts that are of a lesser quality, and the advantage in computing power will always accelerate both game engines and pathtracers.
You simply cannot simulate a very complex system with a significant less complex system. Compared with reality, even a pathtracer is several orders of magnitude less complex, but it is closer and it will always be closer.
You as an artist will have to make the call on what to use and which amount of quality is enough. It really depends on what you want to archive.
Same applies to pathtracer renderers. You said Cycles is good now - I disagree. I think its decent, not good if you compare it to Arnold for example. I am doing a lot of pyro sims lately in Houdini and Cycles is decent for far away shots, but it also creates ugly artifacts and renders much slower and you have to build custom shaders, while Arnold looks much better with vanilla shaders out of the box.

Anonymous No. 889479

>>889290
Why can’t we ever accept pros and cons of both systems instead of having a black and white opinion and calling each other retards? Realtime sucks compared to offline in some areas, but the opposite is true as well. Sometimes I do want to finish projects faster and I disagree about the amount of “””optimization””” that a game engine requires. Also, interesting how people usually say you should do vfx in post instead of rendering it in the scene, but they use that as one of the main arguments to shit on realtime renderers because they can’t render good vfx in the scene (which is true).

Anonymous No. 889485

>>889133
A few reasons why.
Like octane, your VRAM bottlenecks your scene. You can't cram more data into the scene than what your GPU can hold.
No VDB support. You have to export spritesheets and make fake 2d volumetrics, or you have to make volumes with the unreal tool which is pathetic compared to Houdini or whatever.
Material editor isn't as powerful as say Arnold's. Not even close. You cant make anything even remotely close to Arnold's dielectrics or randomwalk shaders. Anisotropy is absolute crap, and you don't have all the cool generator nodes you can use to quickly build breakup in less important assets.
Water rendering is bad too. It has a great water surface shader and it's fantastic for games but it has no volumetric interior, for VFX that's pretty damn bad.

I think you're also greatly overestimating unreals performance. Yes it's faster to render, but have you noticed how those demo scenes don't have foliage or terrains or other things? Nanite is amazing at static meshes, but it's not a silver bullet. It doesn't work on animated geometry or foliage or water. What I'm saying is, you may get 10 fps on your rig. Sure that beats blender taking 10 minutes per frame. But, with blender or Maya or Houdini you can work at 60+ fps on the viewport, it's the render that takes time. With unreal, viewport performance can be absolute crap unless you have a monster computer.

You really do need to weigh in a lot of facts. I'm not saying unreal is bad but it had a lot of downsides. All programs and renderers do

Anonymous No. 891190

>>889133
I watch the slap too very nice sir you enjoy?