Home Technical Talk

Pipeshoving + Combining VS Connecting Assets for AAA Game Pipeline?

polycounter lvl 5
Offline / Send Message
Amank679 polycounter lvl 5
Hey Everyone, what are your thoughts Pipeshoving secondary objects into main objects to achieve the final result VS Simply connecting you assets to existing objects? Which is more preferable in terms of performance in-game engine as well as what AAA studios prefer in portfolio pieces?

I know connecting objects will add more topology but I'd like some clarification.

Thanks In Advance!

Replies

  • poopipe
    Options
    Offline / Send Message
    poopipe grand marshal polycounter
    Depends. 
    You usually get a better bake if you connect the geometry. 

    There are situations where intersection can lead to increased render costs, wasted uv space and so on but there are also situations where the extra geometry is an issue. 

    Whatever you do,  have a good reason for it and if it's questioned in an interview you'll have a good answer. 
  • Alex_J
    Options
    Offline / Send Message
    Alex_J grand marshal polycounter
    I've been playing some older games like Morrowind and Mount and Blade recently. You'll notice  in these games that character models have many pieces that, nowaday's, you'd expect to be connected. Like heads just intersected with necks. I believe this is because of a couple reasons: 

    1. switiching out pieces for NPC variety and character customization is more simple this way. 
    2. makes organization more simple as you could just put all head items into a single atlas, all body items into another, and so on. When the project gets big, keeping things organized in a simple way is a major concern. If you don't, you'll lose massive amounts of time searching for shit, and this gets frustrating fast.  
    3. All of this means less time paying expensive artist. It's a trade-off for quality to get more quantity.

    Obviously the trade off is you lose a level of graphical realism as player can see the heads are just plopped onto the necks. 

    I don't think anybody (cutting edge AAA I mean) is doing characters like this these days. Not that I've noticed anyhow. If you are designing something like a machine gun for a first person game, I think most of the hard surface guys will tell you to construct it as it is in real life. As in, connect pieces that are connected. However, if you were making a machine gun for a third person or top down game for NPC's, it may make sense to just make separate pieces and shove them together as that level of detail will never be noticed.

    Overall, I don't think it's as big a concern as it may seem at first. Editing topology is pretty flexible. And, as mentioned, as long as you can show that you've put a good amount of critical thinking into your decisions, that is fine. Maybe you don't have all the best information and you make a poor decision or whatever, but anybody who isn't averse to critical thinking can be trained and taught. What you don't want is to just shut your brain off and follow dogmatic rules and not have the ability to change things up as the situation demands.

  • sprunghunt
    Options
    Offline / Send Message
    sprunghunt polycounter
    something to note is that what matters for memory and performance is vertex count not polygon count. 

    I've posted a quick example to my twitter here:



    On these two models the number of faces is 22 (left) vs 33 (right) and I've welded the cylinder onto the top face of the right hand side. 

    However they're both 25 vertexes. So in memory these are exactly the same. And the performance cost between the two also the same. 
  • poopipe
    Options
    Offline / Send Message
    poopipe grand marshal polycounter
    That's not quite the whole story - memory wise you still have to store the extra tri definitions and that's what actually gets rendered.  The number of verts is relevant for transforms and vertex shaders but faces are relevant to actually drawing the picture on screen - the arrangement of tris is arguably more important than the quantity in this respect. 

    in this instance the higher tricount could well be more efficient in certain situations due to the triangles not overlapping 

    Just as an educated guess, the best thing to do with this model is use the right one for high lod and the left one for low lod - this is based on an assumption that overdraw on the lower tricount model "could" be an issue when it covers larger proportion of the screen . 


    /not a render programmer
  • sprunghunt
    Options
    Offline / Send Message
    sprunghunt polycounter
    poopipe said:
    That's not quite the whole story - memory wise you still have to store the extra tri definitions and that's what actually gets rendered.  The number of verts is relevant for transforms and vertex shaders but faces are relevant to actually drawing the picture on screen - the arrangement of tris is arguably more important than the quantity in this respect. 

    in this instance the higher tricount could well be more efficient in certain situations due to the triangles not overlapping 

    Just as an educated guess, the best thing to do with this model is use the right one for high lod and the left one for low lod - this is based on an assumption that overdraw on the lower tricount model "could" be an issue when it covers larger proportion of the screen . 


    /not a render programmer
    Triangles are usually stored in tri-strips. 

    https://en.wikipedia.org/wiki/Triangle_strip

    This means the list of vertexes has no idea of a 'face' definition. This is why engines tend to split the vertexes where there's a change in normals or UVs. 

    Although the geo I made for this example isn't very tri-strip friendly  :p


  • Mark Dygert
    Options
    Offline / Send Message
    It really depends on the asset and the design of the game.

    If the asset deforms, like a character, most animator/riggers will cut you if you just jam pieces into other pieces, in most cases. There are a lot of cases when it's ok but in general it leads to a lot of clipping issues so it's frowned upon for meshes that deform.

    There are other reasons not to do it...
    If you have a normal map that needs to flow seamlessly across a jam'ed piece, if they don't share a vert it's going to cause a seam.
    Shading could be odd, because there isn't a shared vert. 

    The number of verts it adds probably isn't going to cause a performance hit unless it's on a massive scale.

    With that said, it isn't a hard rule that would means one way is bad and the other is good, just problems and solutions under different scenarios that can make one more ideal over the other.
  • sprunghunt
    Options
    Offline / Send Message
    sprunghunt polycounter
    Oh another reason why you shouldn't do this is because of lightmaps. 

    If you're making environment assets for an engine that uses pre-baked lightmaps like unreal you'll have problems when you have unwelded geo like this. The issue is that the lightmap will not be as high resolution as the texture that's on the asset. This means you'll get bleeding lighting from one side of the object to the other - it'll appear shadowed on one side but you'll see a little bit of light coming underneath the geometry. 

    This will mean you'll need a much higher resolution lightmap than necessary to stop light bleeding. And textures cost more in memory than geometry. 


  • RyanB
    Options
    Offline / Send Message
    Pipeshoving is a great way to create lighting problems.
  • Mark Dygert
    Options
    Offline / Send Message
    Oh yea lightmaps, good call out. Pipeshoving can cause z-fighting issues too, even on pieces that are perpendicular, but that depends on how the engine handles the z buffer, what shaders are applied and what kind of hardware it is running on. Low end hardware and zbuffers that favor performance tend to flicker more.

    https://www.youtube.com/watch?v=BghCtFKLuK0



Sign In or Register to comment.