When I first read Eevee I thought it would be like the game engines so that in Eevee mode the objects would be 100% locked, it would be a mode just for rendering and as such pretty much close to game engines.
However it turned out to be usable in edit mode, thus requiring a lot more resources… but the most important thing that makes everything slow is the lack of:
As far as I can tell, after watching many video snippets on Twitter, that those can be “faked” with geometry nodes.
Kinda is like Blender have no benefits (other than technical complexity and maintenance) to offer them by design out of the box.
So kinda puts the responsibility on the user, provided that someone enter the world of Blender, with a hardcore mindset of scene optimization. If someone has no mindset of optimization will struggle for many years until they come up to the conclusion, that the only way forward, to scaling up the scene complexity, is only through sophisticated node setup.
However still the problem exists, that if you end up with a humongous mesh (8 million vertices etc), it will be impossible to squeeze better performance, either you would have to chunk it into bits either get a behemoth of a GPU.
Why everybody want Eevee will be like UE, but not want UE will be like Blender? UE has not any designing and modeling tools (maybe have a little little bit), because UE is game engine, not a 3D modeling and designing software. If you are not a programmer, you never understand what is difference.
It’s not that everyone wants Eevee to be like UE exactly, so much as they want some of the performance saving features from UE brought to Blender.
Of the three things Rogper mentioned above, LODs and Occlusion Culling would be absolute killer features, simply because they’d allow you to design your scenes without having to micromanage the minutiae quite so much.
This is not possible. Because UE works low level, not high level like Eevee. Yes, Eevee can have some performance fixes, but never will be like UE, and UE never will be like Blender. This is based programming and designing issues.
I’m not a programmer, but I can’t think of a reason why Eevee couldn’t support LODs and Occlusion. It’s all just polling positions and z-depth buffers relative to the camera.
The biggest difference I can see is that UE always treats the viewport position as if it’s through the camera, while in Blender, the camera is the camera, and if your viewport isn’t currently looking through it, then Blender isn’t registering any information from it.
I suppose you know what is LOD. If you know what is, Eevee why need this? And Occlusion. Eevee have occlusion option already. All render engines have Occlusion Culling.
UE works fast, because all vertex and shading datas storing and executing low level.
Think of it like this…
Let’s use a bunch of trees as an example, since trees are what I’ve worked with most over this last year. You place all your high poly objects into the scene, and things are running and rendering a little bit on the chunkity side of things, despite the fact you’re only halfway done. You decide to start cleaning up your scene a bit, replacing some of the trees and shrubs farther away from the camera with lower poly stand-ins. The trees and foliage way off in the background? They can be flat image planes.
So you go through the process of deleting and replacing all the objects that don’t need to have an achingly high polycount. Your scene now runs better, renders faster, and you have more room for play.
…but wouldn’t it be nice if all your tree objects in your library already had LODs attached to them? You wouldn’t have to worry so much about planning ahead, and won’t have to redo anything if you suddenly decide that your scene looks better a little deeper into the forest.
Now UE and Eevee are designed for different use cases. The former is meant to support giant gamespaces, while the latter is primarily about making nice pictures and animations, and building nice objects to be used elsewhere. Eevee doesn’t have to be as efficient as UE does, and doesn’t need things like texture and object streaming, since you’re usually designing to more specific standards in Blender. But still, that doesn’t mean anything that increases performance, lowers ram usage, and generally makes life a little easier, like LODs do, should be ignored.
What will do when continue modeling your mesh? And you need a lot of memory for every LOD model. Only game engines needs LOD, because game engines works with finished models. But Blender is modeling and designing software and main role is these, not realtime rendering. You must choose what you want: Realtime rendering, or modeling and designing. If you want together two of this, then you must give waive somethings.
It depends on your use case. If you’re making a single object, you don’t need LODs. But if you’re making a large scene with a bunch of instanced objects, LODs would be nice.
Ultimately, an LOD’d object will be just as finished as any object you have in your library. If you want to edit it later, you can. When everything is said and done, LODs aren’t some special type of model. They’re just 3 to 5 models that the renderer will swap between depending on it’s distance in meters from the camera.
No, I see you really have not any programming knowledge. Blender use linked objects for this. If you have a lot of same objects, you must use linked objects for performance. And second example, we use real-time rendered background for increase performance. This is trick for the real time rendering but you can only use this for realtime rendering engines, not with 3D modeling programs. Because Blender’s main goal is modeling and designing, not move around scenes in the realtime. This is the main goal of the game engines.
Eevee can support LOD, just use UPBGE version of Blender and there is LOD.
I think the biggest point of contention here is that you’re thinking of LODs as being a trick primarily useful for realtime game engines, while I’m thinking of LODs in the abstract, as heavier data being swapped for lighter data based upon preset parameters.
I’m not going to make a massive 30 sq. mile forest with high objects spread over every single inch of groundspace in Blender. That’s not what it’s designed for. You’d use UE for that. But that doesn’t mean that LODs are useless in Blender, because maximizing performance and lowering RAM usage are equally important in both applications, despite supporting entirely different use cases.
Like I said above, at the very least, it does make some things slightly less of a pain in the ass to deal with.
LOD increases memory, not reduces. For this reason I said you have not any programming info. I now understand you don’t know why we use LOD in the game engines.
Really? Well hell.
Yes, really.
Yup. I looked it up, and sure enough, I found out that everything I believed was a lie.
I’m going to have to reevaluate my entire worldview now.
Maybe you can stop believe, and start knowing.
I’ll just take the liberty of quoting the team from the famous Scatter addon as I feel they know what they’re doing:
"One might assume that the best solution to make the Blender viewport faster is to use game engine-like optimization tricks!
I’m sorry to inform you that this is a common misconception. Distance-based LOD, for example, is one such technology that is highly sought after by Blender users. Implementing such an inconvenient trick doesn’t make much sense in a non-real-time rendering application.
The best, optimal, and simplest approach is to simply display a placeholder (a surrogate object used only for visual representation) in the viewport and render the object in full resolution only during the final rendering. "
(https://sites.google.com/view/scatter5docs/manual/optimization)
On the one hand silly when you get lectured, on the other great when you can finally discard a misconception that limits you and costs a lot of work.
Neither of these things are true. Eevee doesn’t occlusion cull, at least not in the viewport. I can’t exactly do a renderdoc capture of the rendered output, but in a capture of the viewport with only two objects in the scene, a plane and a suzanne, with the plane fully occluding the suzanne, with no bounding box bleed through, I still get a draw call for the suzanne in the renderdoc capture.
And even in game engines occlusion culling isn’t a universal feature. Godot rather famously has only just implemented occlusion culling in 4.0, and even then their implementation only works for static meshes, which are the cheapest thing to render anyway.