Hello everyone!
I’d like to ask if this is legit.
Or am I just producing a miserable pile of polygon trash?
I can imagine it could cause collider / physics problems.
Many thanks for any feedback,
Greetings,
Shu
overlapping polygons are known to cause shading lighting, flickering, sorting, collision issues,
you don’t have to make all meshes full of grids but just make sure your polys are as square as possible, avoid “spikes”.
try to keep 4 and 3 sided polys only otherwise your DCC will “fill” an Ngon with hidden edges you won’t see and probably will have to tweak.
My understanding is that overlapping polys will cause z-fighting(look it up if you don’t know what it is). That is a big no-no. Intersecting geometry(instead of having everything closed) should be fine on modern game engines, as long as you don’t see the backside without double sided shaders(which can cause other problems anyway).
Optimization is like many things. It isn’t generally a bad thing, rather a good thing, but anything in excess turns into a bad thing. Modern game engines in general(with exceptions, especially on mobile), including Unity, are generally good at processing lots of polys. The idea is to have as many polys as you need, in as few draw calls as possible. If going mobile, you have to watch the fill rate more too.
So, optimize where possible, but don’t sacrifice quality for it. And don’t do it so much that you are just wasting time. Pre-mature optimization is the root of all evil some say. It means to optimize where you need, and don’t waste time where you don’t. So, in my opinion, I might optimize out that grid of polys you have(then I might not even do that if it is all one model and material, as depending on the platform it could be a waste of time), but for sure I wouldn’t mess with trying to have overlapping polys to save a bit few of them. That is where the diminishing returns come in.
Thank you very much for your answers!
I see. I tried to import some overlapping polygons yesterday and indeed, I didn’t even need to test collision to see this is wrong. This is probably because of the z-fighting:
(I looked it up! Very informative!)
What I don’t understand there: Aren’t polygon decals coplanar to their surface, too? Or are those placed just a little bit above the surface?
I do use some considerably stretched polygons. So far, this worked without any problems, though. But with that being said, I do use only tris and quads. I make sure to not use any ngons at all.
With “4 and 3 sided polys”, do you mean tris and quads only? Or do you mean different edges shouldn’t overlap?
Because so far, I have only had problems with coplanar polygons.
If there was a vertex or an edge running inside of a polygon, I couldn’t see any problems in Unity.
Also, I had no problems with differently sized edges overlapping, nor did vertex overlapping cause any harm (so far).
Isn’t Unity just going to cull those backfaces? I don’t use any special shaders for backface shading, so shouldn’t I be fine with backfaces that could be “seen” ( / not seen )?
I do work on a mobile game right now. So that’s why I am trying to optimize as much as possible. Right now, I got one of the levels down from about 45 000 polys (triangulated) to 3 300 polys (triangulated). For some texturing purposes, though, I will need to go up a bit again. With trying to target the iPhone 4s at the lowest end, I don’t really know if that’s appropriate, but I will see. Occlusion culling should help there, too.
Concerning the fill rate, I don’t really know what I could optimize there. Maybe I should read some more about that.
This makes perfect sense. I’m probably doing this wrong. I should be optimizing less and test it sooner.
The only thing is that I don’t really want to test it on devices too often because of the long build times I have.
Well, I can answer a few more for you there.
Decals can work different ways to avoid issues. One would indeed be to place said decal slightly above the surface. Another would be to use a certain method to draw decals for sure after other geometry. Playing with the depth test settings would get the results needed to get decals working, as you can draw something for example without writing to the depth buffer, while still checking the value that is currently there(look up z-buffer and depth test for more info on this). In any case, this is all handled by Unity internally so we shouldn’t have to mess with it.
About the N-gons, upon export, and/or upon import into Unity, all N-gons will get converted into triangles. It is better to have control over this yourself, rather than let the export/import code do it for you, as the results aren’t guaranteed. In the case of static geometry it isn’t as important because…well, because things aren’t moving. But for anything animated, depending on the final verts’ positions, and what verts are weighted to what bones, animations could get messed up, hence the recommendation to avoid N-gons in the final version of your models.
Edges…edges should overlap as needed, and they generally do it quite often. Example, a simple cube. A good cube will have to have hard edges, as far as the normals are concerned. So, it would be rendered as 6 separate quads, with each vert of each quad having the normal equally pointed in the same direction(actually, each of those ends up as 2 tris). This means that since the verts and quads are rendering with different normals, though they are the same edges/verts, they actually get duplicated internally. This is also why you get different amounts of geometry as Unity renders then compared to how much Blender says you have.
If you aren’t using any special shaders, then yes, the back faces get culled. On the other hand, if you had a need for this, you would probably know more about it, and therefore know what you are doing. In general, you don’t want double sided polys, rather two separate polys for two different sides, like a really thinly scaled cube would give you.
About mobile and fill rate, I recommend indeed you investigate. Fill rate refers to filling actual screen pixels. It is typical to fill the whole screen, but it is a waste to fill it, then render something else on top, filling it again, and worse, hiding what you previously rendered in the frame. This involves checking the depth buffer, which was filled with the depths of those pixels you already rendered. In the case of mobile devices, the performance in this regard is much less than PCs for whatever reason, while performance of other things is closer to PC. So what you want to optimize for this if you are indeed fill rate bound, is to not do anything covering the whole screen where possible. A single mesh for the level is probably fine, especially if it is only a few thousand tris in the end.
1 Like
Thank you very much for your detailed answer! Most of this makes perfect sense now! The only thing I’m still unsure about is the fill rate, but as you said, I will have to take a closer look at that. Then I will probably understand that part, too!
Yeah, fill rate is weird like that. For example(maybe not exactly, but to give an idea), 2 full screen quads take more time to render than some higher number of small quads, maybe 20 of them, I don’t know. It depends on the device, shaders, and quad sizes, that is how it is. It also has to do with the speed of the video RAM, if it is even dedicated VRAM. PCs don’t have this problem near as much apparently.
1 Like