Reduction Topology, Triangle Question

jdellinger98

Decided to pause and ask before getting ahead of myself with it. With something like seen in the picture, is this topology good, bad, okay? In the reference there not separated parts which is why it's a single mesh. It's also coming down to a flat surface and I didn't want a bunch of extra polygons wrapping around that weren't being utilized. 

Klunk

seems ok, but it really depends on what it's for I guess.

poopipe

You have geometry in the middle of flat surfaces that doesn't need to be there.
 Otherwise it looks alright to me

GlowingPotato

its ok, but it will bite your ass if you need to make a hi-poly version later.

jdellinger98

poopipe said:

You have geometry in the middle of flat surfaces that doesn't need to be there.
 Otherwise it looks alright to me

Ill keep that in mind, I could always reduce and wanted to get some feedback on this question before proceeding any further. Thanks!

jdellinger98

GlowingPotato said:

its ok, but it will bite your ass if you need to make a hi-poly version later.

I would have to agree with that lol. In that event I would just redo it. The outer arch only took a little over 5mins as it stands to do. Now that I have the sizing down It would take even less time Thanks for everyones input!

another caveman

it's up to you what's good and bad geometry depending what you' re working on

if as few tri as you can is what you aim for I see this you could do ? and disconnect it from the above piece. no one will see maybe push the verts a little bit in so you dont see seams from far or cause shadow glitch

its an example it applies to different spots on your model as @poopipe e said

poopipe

I'd generally advise against that sort of structure unless you really are trying to minimise tricount (eg for a low Lod mesh)  the overlapping geometry can have a bigger effect on frame time than you might think - especially if it covers a lot of screen pixels.  

At a distance the above example would be fine, just not up close

icegodofhungary

poopipe said:

I'd generally advise against that sort of structure unless you really are trying to minimise tricount (eg for a low Lod mesh)  the overlapping geometry can have a bigger effect on frame time than you might think - especially if it covers a lot of screen pixels.  

At a distance the above example would be fine, just not up close

Can you elaborate on this more? When I model, especially windows and doors, I find it easier to break things up sort the way that post was suggesting. I try to stay away from modeling things as one piece because it just seems messier. Is that actually wrong? Let's say you're making a FPS in 2020, should I actually be making windows, doorways, and all that one piece rather than floating door frames or window frames on top of a wall piece? Or are you suggesting something that would be ideal but not completely necessary?

For example here is a wall section with a window that I was working on for a project:

The wall has an opening over which the rounded frame sits but is not one solid piece. Then the smaller frame is also floating, along with the flat sill/table part. Should all this actually be one piece stitched together? The player would be able to walk up to and interact with the window.

poopipe

Basically if you have overlapping triangles at a pixel (technically a 2x2pixel area) the renderer has to consider all of them, which means it has to process that bit of the screen repeatedly


It's not worth worrying about if the number of pixels involved is small or if preventing it means extra work, sacrificing modularity etc. 
It also has to be balanced against introducing subpixel triangles which are worse.

Your example is absolutely fine, as would the OP's example be with some gentle optimisation.

another caveman's example would be ideal for a lod mesh since the triangles are large but you could be looking at  a pretty significant portion of the screen featuring the overlap if this were the top Lod of  an FPS prop.

gnoop

I  heard about the issue ( overlapping tirangles) too    bit wonder does anyone  ever really measured the impact.     After all modern games are having so many overlapping  triangles  with 3d grass, foliage etc.          Another  argument against floating geo usually  is Z-fighting .

Still floating geo makes producing lods  much easier  without messing normals  so I tend to use it a lot lately

poopipe

 Pixel coverage is the issue in this context,  For a lod there will be a lot fewer screen pixels covered so the balance shifts towards  having less triangles.

The problem with measuring the impact of this stuff is that there are no constants - everything is entirely dependent on the content of a given frame. 
Nobody can ever tell you categorically whether what you've made is causing a problem before they've profiled it in the context of a running game. 
Furthermore most games go through a cycle of being GPU bound and then CPU bound and back to GPU bound and so on throughout development so problems shift and it's not uncommon to find out something that was fine months ago is now causing a problem. 

practically speaking the most useful thing any artist can do is make the best looking and most efficient meshes they possibly can. 
Efficiency is key though. Include only what is necessary for the asset to look correct at the distance you view it from

Aionard

First time I hear about the pixel overlap on floating geo, which is good to know. I'd say that You can start with floaties, and if that becomes and issue, you can just boolean the floater in (the frame of the window into the window sill) and quickly have the same effect, albeit your UVs will likely need some work.