Questioning my LOD workflow
polycounter lvl 5
So when doing a model I always have the # 1 rule in mind with LODs, which is divide in half. Each level is half of the previous. And lately I've been questioning my workflow because optimization is important to me, and the way I see it there are two ways of looking at this.
A ) For the highest poly, just leave all those edgeloops, unless they are an obnoxious waste of polys. It ultimately isn't worth it to be going in and tying up quads into triangles just to reduce the amount of edgeloops and save a few polys here and there. it's also easier for LODs cause you can just go in and delete edgeloops and it's done.
B ) No, you should only use the amount of polygons you need, cut what you can, a lot of triangles are fine. LODs don't matter that much cause programs can practically do those automatically anyways.
I'm not really sure which is the better way, I know in the past B is probably the better option, but with modern engines nowadays I'm not so sure. Hopefully this question makes sense
A ) For the highest poly, just leave all those edgeloops, unless they are an obnoxious waste of polys. It ultimately isn't worth it to be going in and tying up quads into triangles just to reduce the amount of edgeloops and save a few polys here and there. it's also easier for LODs cause you can just go in and delete edgeloops and it's done.
B ) No, you should only use the amount of polygons you need, cut what you can, a lot of triangles are fine. LODs don't matter that much cause programs can practically do those automatically anyways.
I'm not really sure which is the better way, I know in the past B is probably the better option, but with modern engines nowadays I'm not so sure. Hopefully this question makes sense
Replies
Leaving a handful of edges in there is fine, any automated LOD solution will make quick work of them anyway.
I wouldn't worry too much about LODs unless it's a VR game and you're really super focused on counting every tri.
I think it's a waste of time to make them by hand. If you're using an decent engine that can handle it for you, or if you use a slightly more robust solution like simplygon or InstaLOD then making LODs is pretty much a non-task.
This is what I've learnt over the years ..
You should be aiming to LOD everything to a box.
Because your lowest LOD is a box it's easy to make by hand.
Because you're LODding to a box you need to set up your UVs accordingly.
Because you've set up your UVs to support aggressive LODs, your intermediate LODs look better.
Because your intermediate LODs look better, you can bring them in earlier.
Also, automated solutions will do a much better job if theyre given UVs that support aggressive LODs
Basically, make your lowest LOD by hand & UV it. Then UV your highest to fit that basic layout.
Oh.
Your point A) ..
No, just no... The idea is to reduce drawn geometry, not hit an arbitrary percentage target - especially if its a target reached from an inefficient starting point.
poopipe said: If it's a box, why would you bother doing it by hand? Any LOD solution can pound your geometry into the basic form. I do see what you mean about the UVs; I try to consider how well the UVs will match on the midrange LOD... But at the same time, at some point it ceases to matter. Law of diminishing returns and all that.
I will grant the box is an unattainable goal in a lot of cases but it is the ideal bottom LOD.
WRT pounding an object into a basic form.
I've tested various LOD generation tools (I even built one of my own) and found they all share the same weaknesses in terms of identifying what could be a simple geometric primitive in terms of silhouette.
Imagine a gatling gun for example, a human would see all the barrels together as a single cylinder when LODding, Simplygon would not and therefore isn't capable of generating the really efficient low LODs.
It'll do a fine job up to the point where you need to start changing the physical makeup of the object but after that you end up with garbage - obviously you can remesh but you lose UVs and have to either attempt to reconstruct them or accept the cost of another texture set.
I get what you're saying about diminishing returns. it's definitely something to consider but I'd argue that you more than make up for the little extra effort by not having to panic hack optimisations in later when it becomes apparent you can't hit frame rate.
Also, if you're doing props, you can plan ahead - bake small geometry parts on the underlying objects so you can just delete them at the next lod, or leave a small plane and bake a high-tri count object on it, with the finished textures.