real 3D-geometry vs fake (normal/relief/parallax/POM=parallax-occlusion-mapping/etc)

bootstrap · 2007-04-10T02:59:12

This post was originally a reply to a beginner-forum question that asked whether 3D geometry or texture/normal/parallax/etc mapping consumes more graphics engine horsepower. I post this message here because I suspect that question is not only a beginner question, but worthy of serious thought and discussion by serious experts. Time for some brainstorming (or teeth kicking)! Specifically, I refer to a thought process that I went through when planning, designing and understanding the consequences of POM (parallax occlusion mapping) or any other advanced parallax mapping technique. I will describe this thought process below, but the bottom line is this: it looks to me like it is FASTER to create massively detailed geometry than to "fake it" with techniques like POM/relief-mapping/etc - but nobody seems to have noticed this, probably because the move from the oldie/moldie/slow/little-no-videoRAM days to super-fast/lots-of-video-RAM/super-cool-shaders days was a gradual continuous evolution (albeit in a fast-moving industry). First, consider the POM technique. And to make the thought process concrete, imagine your game applies POM to display the surface of a gigantic spacecraft or better yet, one of the death-stars from the StarWars movies (or BorgCube). As players tie-fighters fly near the death-star, POM is a natural approach to consider to display the wealth of 3D relief detail on the outside surface of the death-star --- as opposed to creating actual 3D geometry for the entire moon-size gizmo! To stress the point slightly, lets say you are flying over the surface of the death-star and looking out the front-window (or either side-window) of your figher craft. What you see is a huge expanse of death-star surface stretching out into the distance. Now, to put this into POM terms, the camera-view-ray is the line between your eyes (in the fighter craft) to every point on the death-star that will be displayed as a pixel on the screen. Well, as you can easily see, most (if not all) of the camera-view-rays intersect the nominal top surface of the death-star at a lowish angle --- say a 20 degree angle at the nearby points you can see, and a less-than 1 degree to 5 degree angle at the further-away points you can see. Now we enter the world of the pixel/fragment shader that displays every pixel on the deathstar with its POM algorithm shader-code. The POM shader begins where the camera-view-ray intersects the nominal surface of the death star, which must be at the level of the highest tip of the highest tower sticking up from the surface of the death-star. The lowest point is the bottom of the lowest groove/passage-way in the death-star (like the pathway Luke flew down to explode the deathstar). So, the POM code takes the low-angle (nearish horizontal) camera-view-ray and checks it against the deathstar height-map and finds the ray far above that location on the death-star. So it adds zero to two pixels to its x and y coordinates (in tangent space) and subtracts something like 1 to 3 from the altitude of the camera-view-ray depending on how shallow/steeply the ray approaches the surface of the death-star. This iteration process repeats - often DOZENS to HUNDREDS of times when the camera-view-ray angle is this low (or only 1~2 times looking straight-down, which will virtually never happen in this scenario, except when you are banking at a steep angle during a steep turn and looking out your side window). At each iteration the code reads the normal-map (from "texture-map" videoRAM) to access the height of the death-star surface at this location. In summary, the POM shader reads videoRAM memory dozens to hundreds of times before the camera-view-ray finally hits something on the death-star surface. The best-case, which will be rare, is when tracing the camera-view-ray into the top of the highest towers projecting upward from the death-star surface. The worst-case, which will be less rare, is when the camera-view-ray passes down the length of one of those grooves/passageways, or where large sections of the death-star surface are flatish and low-level with occassional upward projections. (Which mean, POM while flying over monument valley would be absolutely horrific)! Okay, now consider a death-star created with super-fine detail 3D geometry. In fact, lets assume that every polygon is only 2~4 pixels across (where 2 pixels across means you have one vertex for every single screen pixel!!!). So, what happens in the shader of your game engine now --- with this oldiest and moldiest of techniques == utterly vanilla straightforward 3D geometry? Well, to begin with, we probably start out with only half as many vertices as the POM has pixels to trace. But we instantly lose this entire advantage because we have never-displayed vertices on the backside of every geometric feature on the death-star, as well as vertices on the vertical (and even overhanging) portions of every feature in the death-star. So we must assume we gain nothing here --- we have at least as many vertices in the geometry as the normal/height-maps have pixels (and maybe even a factor of 2+ more!) Ouch. But let us continue a little further and not give up before we fully consider. How much work must the 3D engine do per displayed pixel? The POM scheme had to read dozens of normal/height-map entries per displayed pixel. So far, our scheme has to process 2~4 vertices to account for backsides and all those extra features on the sides of the real 3D geometry. Well, first of all we know the 3D engines find out about backside vertices and z-buffer culled vertices early in the pipeline - they never reach the pixel shader. This is important, but not a huge win --- yet. The huge win we are waiting for is *obvious*, in retrospect. For every displayed (and backsurface and z-buffer culled) pixel the 3D engine only reads 2~5 vertices, and only fully processes through the pixel-shader 1~3 vertices (average == 2). So, while POM performs dozens of cache-missing videoRAM references per pixel displayed, oldie-modie-ancient-technology-3D-geometry only reads TWO vertex structures per displayed pixel, and these are ALREADY PREFECTED AND IN CACHE because they are sequential fetches from the VBO/vertex-buffer. And our oldie-and-moldie technique doesn't even NEED texture-maps (for color) or normal-maps (for normals and heights) because all this is part of every fetched vertex! So which is faster? The answer seems very clear. The oldie-and-moldie-3D-geometry method is!!! How can this be? And why does nobody notice this? When you inspect the gradual progression of developed techniques, the answer seems pretty evident. When they started developing these fancy/tricky "fakes", the video-cards had something like 64KB to 256KB of videoRAM, not 512MB to 1024MB of videoRAM like today --- a difference of *** many thousand times ***. So the tradeoffs were very different. But how about now - with fresh analysis? Well, the answer does not appear obvious, does it? Or if it does, the obvious appears to favor the oldie-moldie-simplistic-3D-geometry approaches. Or does it? This is where everyone jumps in and kicks my teeth in! :-) Before you do so --- which I know you will do with glee and joy --- consider a couple side issues of this analysis. Namely: The sides of every [near-vertical] feature in POM cannot have any visible features - or at best, extremely low-rez vertical streaks. Why? Because the entire side of every vertical feature (a skyscraper building for instance) is represented by zero (or very few) pixels. No way exists to place windows and bricks and other features on the sides of buildings, monument-valley rock-towers, or any other supposedly real physical object in POM/parallax-mapping! But guess what? Every pixel in the full-resolution 3D-geometry approach can be displayed in full resolution. Want windows, archways, anything-else on the sides of your world? No problem - we've already taken the efficiency-hit for having all this full-bore detail - so take advantage of it! Furthermore, just try to fly through an open (or closed) window or tunnel in any POM/parallax pseudo-fake-geometry! Ha ha ha!!! No way, Jose --- even if you could display it, which we saw above that you can't! In real 3D-geometry world, "no problem"! And 3D-geometry world can support underhangs, holes, tunnels, anything whatsoever --- none of which POM/parallax can support. And guess what? We still have unlimited opportunities to *selectively* cheat and fake things in 3D-geometry-land --- whereever doing so does not destroy the reality of the world. For example, if we do have any expanses of moderately flatish walls/streets/etc, we can perfectly well omit vertices in those areas and simply place a conventional texture-map and normal-map over each of these kinds of expanses. Given the many places we can save in these ways, how can we ever find places we are actually ***ahead*** of the game with POM/parallax? The point of this post is, to ask all of you experts out there, to answer the original post given the context I just provided here. Admittedly I have taken the question even further than the original post (into POM/parallax land), but similar questions exist even in polygon-vs-texture land. Today, given every detail of the state of modern 3D engines and shaders and everything else, are we getting closer and closer to the point where we are better off reverting more and more to simple, streamlined, straightforward, hardware-accellerated conventional 3D geometry worlds? I am inclined to think so, and limited tests so far tend to agree).

Graphics and GPU Programming Programming

Started by bootstrap April 08, 2007 09:13 AM

13 comments, last by wyrzy 17 years ago

l0calh05t

1,829

April 09, 2007 12:45 PM

Quote:Original post by lc_overlord
Quote:Original post by Fingers_
Part of the "problem" is the process of creating and storing 3D geometry vs. a heightmap for the parallax shader. Textures are very convenient in comparison to 3D models. If the entire world were to be modeled in sub-inch density polygon mesh it'd obviously take a lot more time to create than just using tiled textures on less dense geometry.

One would think so, but it really does not take that much longer, most artists actually do a ultra high res version first(for normal maps) and from that create a low res one, this lowres version takes about the same time to make no matter if it is 15000 or 500 polygons.

Yeah, especially with "Sculpting"-type modeling becoming increasingly popular (zBrush, Mudbox, the newest version of Blender and XSI as well, though not 100% sure about the last one) high-resolution meshes have become *very* easy to make. Heh, even *I* can make 'em, and I'm no (visual) artist by a long shot:

lc_overlord

436

April 09, 2007 01:00 PM

Yes, but it's also true for other non sculpting softwares like lightwave, it's pretty easy for a professional artist to create millions of polygons by hand in just a day or two.
And when it comes to the low res approximation mesh it gets easier to get a good fit the more polygons you use and therefore it takes less time to make than if you use a lower res mesh.

www.flashbang.se | www.thegeekstate.com | nehe.gamedev.net | glAux fix for lesson 6 | [twitter]thegeekstate[/twitter]

l0calh05t

1,829

April 09, 2007 01:38 PM

I agree. I was just pointing out that it has become extremely easy, and fast.

Defrag

175

April 09, 2007 11:51 PM

It's not as easy to constantly work with & re-use high detail meshes. Most of these techniques are general purpose -- you can use the textures & shaders on arbitrary geometry and it will 'just work'. Workflow is becoming just as important as performance.

To give you an example: If I'm building a level and I want a bumpy floor, it's far, far easier to just apply a texture to the floor compared to manually placing multiple high resolution tiling meshes. The bigger the mesh the less flexible it becomes. A specialised floor mesh for one room won't necessarily work for another, so you often have to break it down into multiple 'snappable' tiles to keep the re-usability high, anyway (which makes it more fiddly & less unique). It can be the difference between manipulating one polygon versus scores of high poly meshes. If the room changes (say the gameplay requires tweaking) then the mesh(es) have to change with it and that's more work & hassle. If your bumpy floor is generated using a technique like POM, it'll likely be more flexible to work with.

IMO you use what works for a given situation. Sometimes there's no replacement for the real thing, whereas other times it's far more convenient to use other techniques.

wyrzy

430

April 10, 2007 02:59 AM

Quote:Original post by Defrag
To give you an example: If I'm building a level and I want a bumpy floor, it's far, far easier to just apply a texture to the floor compared to manually placing multiple high resolution tiling meshes.

Hmm, I don't think the discussion of "how easy is it" to create a texture vs a highly detailed poly mesh is too relevant. If you want to tessalate some triangles based on a texture map, there's plenty of free software to do this.

Regarding the poster's original question, "is it better to use actual vertex data vs image-space techniques", of course the answer is "it depends" (as others have already mentioned).

I was going to write up some comments here, but I think the DX 10.1 slides from gdc 2007 http://msdn2.microsoft.com/en-us/xna/aa937787.aspx explain what I was going to say even better. The talk about on-demand tessaltion and subdivision, done on either GPU or CPU is really the direction I think graphics is ending (computations split between CPU and GPU now that CPUs are becoming more parallel and GPUs are becoming more general).

real 3D-geometry vs fake (normal/relief/parallax/POM=parallax-occlusion-mapping/etc)

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

real 3D-geometry vs fake (normal/relief/parallax/POM=parallax-occlusion-mapping/etc)

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines