Difference between elements and objects in rendering for games

saparkhid

Hi, Please take a look at picture below, I want to know that which one is better to be used.

if look at the picture, you will see that I have represented two models which are same at final output. The left (cube 1) is a completely one element which has been created by inset and extrude commands. but the right cube (cube 2) is one object but with 2 elements (2 cubes which are intersected in each other).

Note : objects consist of vertices,edges,faces and elements. both 3D models above are one object but the right cube is one object with two elements, not two objects which are grouped together.

For rendering performance (regardless of cubes, think bigger meshes), which one has more impact ? do they cost same in rendering pipe-line ?

What is your opinion about grouping objects (such as parenting two cubes so at output we have two cubes which one is parent another)? I think it costs more because renderer should render every object. As far as I depicted in figure, I think cube2 will be rendered same as the time when objects are grouped together in hierarchy order.

gnoop

Normally you model things like 1  but sometimes version 2 is also ok considering the cubes do not intersect each other but rather small one without back face  is floating on surface of big one with tiny gap. 

Intersecting shapes makes co called "Z-fighting" in games .   Not only perfectly co-planar  things but even such cubes starting from intersecting line and  further the distance from  camera stronger z -fighting may become.     

Nevertheless  version 2  still could  actually  be pretty efficient  especially if smaller cube from your example  is a small detail like button etc on a bigger surface.  At distant LODs you just switch that small floating detail off and keep it baked into big one normal map.

You should also consider  that your examples looks like having "hard edges"  i.e split vertex on sharp corners.   In that case renderer would actually calculate such a vertex two times . So every hard edge is doubling vertex count along such edge.   Uv seams do same too.   

It's because of so called "tri-stripping"  (when a renderer calculates only one single vertex for every new triangle)  is not working across hard edges and uv seams .   So in fact your version 1 object is already have its sides as separate things for game render unless you would "smooth" / unite normals in corners.  

Grouping objects is another thing .    Game renderers doesn't like  gazillion of small separate objects.       It crates so called sorting bottleneck.  Ideally every "object" should be no less than   1500 vertexes.    So you could attach small neighboring objects to each other. But too big (in game units scale)  object makes another issues.    With occlusion culling for example.  

Object grouping sometimes is used as "LOD" technique  for distant lods.

You should also consider not only how much efficient your geometry is for a renderer but how much extra time and puzzles it creates for you.  You could spent forever optimizing things with zero actual  frame rate increase .  It's a special  task  to find actual bottlenecks , It might be not where you initially think .  So not overthink the modeling.  Everything in games is a trade off and compromise.