Bevels vs Sharps
null
Hey people, Is there any reason why I shouldn't bevel every sharp edge (instead of making them sharp) as I understand it any where there is a sharp/split edge, those verts are doubled (to the gpu at least), if you bevel the same edges the verts are also doubled, but with bevels you can have UV seams anywhere you want for technically less gpu verts due to UVs having less seams, Yes you will end up with more tris but surely all that matters is vert count?
In the image below they both have the same gpu vert count, in more complex models the beveled one would have less gpu verts because there will be fewer UV islands...
So would it be ok to bevel instead of sharp for all objects in a game?
Please let me know if I have completely misunderstood all of this haha
note: I use Blender > substance painter > UE4
In the image below they both have the same gpu vert count, in more complex models the beveled one would have less gpu verts because there will be fewer UV islands...
So would it be ok to bevel instead of sharp for all objects in a game?
Please let me know if I have completely misunderstood all of this haha
note: I use Blender > substance painter > UE4
Replies
You're correct i your assessment, but in this day and age (mobile platforms excepted) you really don't need to worry about vert count very much.
Whether you bevel an edge or not is a decision you should make based on what you want it to look like and whether having the geometry there adds any value to the object or not.
If geometry performance is a real issue, I would just create LOD's.
You can as well work with custom normals when using bevels and skip high-poly -> normal baking for certain things.
UV unwrapping gets more complicated with bevels.
If you are planning to use Substance or Quixel or anything else you want to feed with a curvature map for masking, you might run into some issues with custom normals.
http://polycount.com/discussion/comment/2567191/#Comment_2567191
Custom normals don't cause any problem but the way curvature and UV seams work together as described above. If you don't use any masks based on curvature you don't have issues, at least I haven't experienced any yet.
https://forum.allegorithmic.com/index.php?topic=21117.new#new
but never really got an answer to.
https://forum.allegorithmic.com/index.php?topic=21117.new#new
Surely if its a curve, its a curve regardless of uv seams?
Im so confused lol
The curvature baking is not wrong, the curvature information is just limited to the face of the bevel.
Look at the model you posted with the curvature map applied, you will see that only the UV shell of the top has contains information around that edge, the "stripes" don't, that is what causes the hard edge.
On the lower edge it is not a problem because there is no seam.
No, not at all.
Vert count isn't all that important because it's a relatively minor cost compared to all the other things.
The most significant cost in a deferred renderer is how many times each pixel gets interfered with. Many things contribute to this cost and it's only indirectly related to how many triangles/verts are in your model. Shader cost (particularly with alpha blending) and post process effects are where you'll see most of your resources eaten up.
WRT your example... Those small triangles you've added become extremely inefficient when they drop to sub pixel size (at a distance) as they can cause groups of pixels to be rendered many more times than they should be while contributing nothing to the appearance of the object. Long thin triangles are the worst case in this regard, especially if they meet at a pole.
You get around this by lodding appropriately and at the correct distance from camera.
I've glossed over the details here but you'll be able to Google up a more in-depth explanation of how geometry and pixels marry up.
http://www.ericchadwick.com/examples/provost/byf2.html
http://www.fragmentbuffer.com/gpu-performance-for-game-artists/
This link is a lot more up to date - I just dug it out now and haven't read it all but it looks pretty solid - the issue I mentioned earlier is called overshading in this article.
My game is very room based, how important would this all be, as when objects are occluded (by lets say a wall) they are no longer being rendered, So what i'm trying to say is can I just go buck wild with bevels because they wont ever be rendered at a distance?
The opposite, i believe. Extremely small triangles tend to be more gpu intensive because of the way pixels/fragments are calculated in batches of 4. i one, or some of those pixels are outside of a triangle, they have to be recalculated.
https://www.g-truc.net/post-0662.html
The fragment/small triangle thing is a matter of efficiency. Any given fragment inevitably stands a chance of being drawn multiple times and that's OK. What you're trying to avoid is doing it for no benefit - Eg, having several triangles taking up less than one pixel on screen.
Drawing an object is always going to use resources - it's efficient when all the resources used contribute directly to it looking awesome.
if your view distances don't change much you're very lucky because you can tell whether your triangles are contributing or not by simply looking at them (they don't change size on screen if you don't move) .
The chances are that if you're building a room sized environment youll be able to bevel away to your heart's content with no ill effect.
I tend to use bevels and make them smooth so that I get a nice edge with limited polycount and better results than a normal map can provide, which we know can be tedious to make smooth. Especialyl at closeups this works good and it can give you a better Lightmap result as the surfacec is actually round by some degree.
If you have the time LOD is a great solution and it can even work in closeups. You can match your UVs so that lower LOD levels work fine with both texture and lightmap. But it works especially well for looping areas so for instance if you got a cubic pillar and you round up the edges and repeat the texture on the x axis. For more complex objects and bevels this may not work properly, but if LOD is only used to reduce triangle count then this can be an option, in the distance UV seams don't matter. But here is an example, the top plate is an issue here.
Yet for my project I keep this in mind but mainly focus on LOD0 for a start. I want to make an interactive demo and once the scene runs bad on low and mid range GPUs I am going to add LOD. Not sure which tools do what but most bevel tools are UV aware nowadays andthis can be a great help, so you actually model and UV your LOD1 first and then bevel the edges. At areas with connected UVs you get the end result directly. Also when you are unsure this is actially a good approach because you can always Bevel, but it is harder to make it unbeveld when it has UVs already.