Announcement

Collapse
No announcement yet.

Shared Space, Z-Fighting, Modeling Standards

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Shared Space, Z-Fighting, Modeling Standards

    Hi guys,

    I just wanted to see other artist/developers opinions on this matter.

    Most of this is because I'm entirely frustrated with a client that I am working with.

    I was hired by a company to fix and optimize some models. The original model was full of co-planer faces, and z-fighting issues galore. It was because the previous modeler had used only planes to design and color the building models instead of creating actual geometry, UVs, and texturing.

    So after I finish fixing all of the problems, here's where the problem lies.

    I tested every object in the engine they had said they were using. (It's Unity by the way, I know this is UDK but this discussion is more about modeling than engine.) All of the models functioned fine. But they come back to us and say that the models are still blinking because there are multiple pieces of geometry "simply hidden" within other geometry. And this is true. I had used multiple objects to create the whole building itself, but made **** sure there were no co-planer faces, and that the other geometry was far enough away from other faces where Z-buffers won't confuse them. The closest I had gotten to co-planer geometry were at the intersections of the objects.

    So the next few emails coming in are criticizing me for not understanding how 3D geometry works, and that all models need to be 1 single mesh with no intersecting geometry

    The last email contents summarized are: "This problem isn't new and is well known within the CG Art community. Newer engines probably handle this better, but we need it this way. It's also better practice for real-time rendering engines"

    I know what Z-fighting is, why, and how it is handled. While I can't completely disagree with what was said, I disagree that it is necessary in this day and age for real-time rendering engines. Z-Buffers have become sophisticated enough to be able to identify which pixel occupies which space unless it is a few pixels from each other, and mine were not.

    So what I'm trying to ask is: As a CG Artist, am I really just out of touch and making my own rules about modeling standards? Or am I correct for understanding that modern game engines aren't that strict and finicky about shared space in geometry? Co-Planer geometry and intersecting geometry are NOT the same thing, and I made **** sure I had no co-planer faces.

    Some feedback guys? Don't be afraid to tell me I'm an idiot.

    #2
    Hard to say without pictures to visualise the issue, etc.

    One thing that does come to mind is that the Z-buffer resolution starts to break down as distance increases. If you have a hidden face a few units behind a front face then it should render fine within a certain range... but as the mesh moves into the distance the depth buffer values of both faces start to converge and there comes a point where float imprecision causes ambiguity between them, and z-fighting occurs.

    This also happens for intersecting planes near the point of intersection.

    If the buffer is 16 bit then it's a lot worse, but that's older hardware. I'm not sure if 16 bit is supported anymore (been awhile since I was in engine dev) as most buffers are 24 bit with an 8 bit stencil.

    Comment


      #3
      So I'm not crazy for thinking that Z-buffers will be able to render fine. I'm sorry I can't provide any visuals, but I promise the geometry is far enough from each other for the Z-Buffer to understand what is where. Imagine a wheel and axle. The wheel is simple a closed cylinder, and the axle is a smaller and longer cylinder pushed through the center. According to the client, even THAT would cause issues. And this is constant, non-dependent on the distance of the camera (as far as I know, because if they're complaining that it blinks from a far distance, that should've be stated. Also, that's just being nitpicky.)

      My frustration stems more from that fact that they are speaking to me like I don't know how to do my job, rather than the Z-Fighting issue itself.

      Comment


        #4
        Z-fighting can differ depending on the 3D engine, like for instance I believe UDK has a larger clipping range than what 3ds Max has which would mean you would get Z-fighting issues at a closer distance. I don't know whether that can be changed in the engine, 3ds Max has the control for the viewport that allows you to adjust the range.

        Something like a cylinder poking through another cylinder should not cause that problem, I do that type of stuff all the time, it's inefficient to make everything modeled together if it doesn't have to be. If they've got that issue I would wonder if they're doing anything weird on their end. I would try downloading Unity and import one of the files and see what's going on. If it's fine in there, send them a screenshot to prove it's an issue on their end.

        In my cases, I've had to have planar objects really close together (like a plane on top of the ground) and was able to change the depth priority, but that only works in a certain situation, something like a cylinder going through another cylinder isn't going to be fixed that way.

        Comment


          #5
          As my far as my knowledge goes about what's going on in their end, is they are using the Unity Engine, but it's modified somehow. I can't see how they could've modified the engine to the point where it breaks the Z-Buffer. I'm using the same version as they are, sans the modifications, and I've tested every model and ran it through every scenario. I'd said multiple times that there is no problem on my end, and that my models shouldn't cause any z-fighting issues because they don't occupy the same Z-Space. Just doesn't seem like they wanna hear it.

          I'm just glad to know I'm not a CG Idiot and am getting frustrated for no reason.

          So to follow up: We know that shared space should be alright (not co-planer geometry), and would be more efficient. What are your opinions on the professional industry standard? I've read that the last system to not be able to support true Z-buffering was the Playstation 1, so I assume everyone has adopted multiple primitives to create assets as a standard at this point.

          Comment


            #6
            Assuming they are using a 24-bit or higher depth buffer mode...
            If they have modified the camera near clipping plane to a smaller value then they are wasting most of the depth buffer precision range.
            This will cause z-fighting to start at closer distances and requires that all models be essentially hollow shells to reduce flickering.

            Comment


              #7
              Even with a very low z-buffer resolution (be it a low bit-depth or wasting the resolution with bad camera settings), the given example (the wheel with an axle) seems very unlikely to produce z-fighting. Just by the description and without a visual example, my guess would be that it's actually a depth sorting problem, caused by the materials being handled as alphablended for some reason.

              Comment


                #8
                Doesn't Z-Buffer handle Depth Sorting? Also, I unfortunately don't have screenshots of the object either.

                Comment


                  #9
                  With depth sorting, I'm referring to Painter's Algorithm, which is still used for alphablended objects (because objects behind them have to be rendered). Having overlapping objects rendered with Painter's Algorithm can lead to problems similar to z-fighting, but in places, where z-fighting is unlikely to occur. And since it is usually only used for alphablended objects, my guess would be, that the materials are messed up (or if they actually are transparent, the objects would have to be broken up to account for that).

                  Comment


                    #10
                    Ah I see! That actually might make sense because the objects do have transparencies. I mean, it's not a complex transparent object mind you. It's only a plane for a window. How do you suppose it's causing issues in their version of the engine, and not in the version I am running?

                    Comment


                      #11
                      Well, if they're using a different version, it might handle transparencies differently (the problem is less common with newer engines, though I'm not sure how they handle it; I just had some basic 3d programming in my studies) and without knowing how the geometry really looks it's hard to make suggestions on how to fix it (if it's the problem at all).
                      But in general, merging everything into one single mesh would be counterproductive in that case (at least for the transparent parts). Always keep transparent objects separated from solid ones (never make a solid object with a tiny bit of transparency, while a transparent object with small solid parts is ok) and keep them "flat". By flat, I mean transparent Objects should not obstruct visible parts of themselves.

                      Comment


                        #12
                        I think if they can't tell the difference between alpha sorting and z-fighting, they've got bigger problems than, alpha sorting or z-fighting.

                        Comment

                        Working...
                        X