Interior Mapping demo

I did tests comparing polygonal rooms to Interior Mapped rooms and the performance of my version of Interior Mapping is pretty good, actually. And that was with much more efficient rooms: roofs, ceilings and walls of rooms can be shared between rooms, so the actual geometry required is much less than 8 vertices per room. Still, Interior Mapping absolutely appears to be preferable above actual geometry.
Why could you not use a texture atlas for the polygonal version?
 
You only need a single texture lookup. I think yours needs four.
That is true, but that could also be achieved by using an if-statement and only looking up in the right texture, because the values from the other three textures are ignored anyway. I never got around to trying how much performance would actually be gained by that, though, but I guess you are right that your version is indeed faster because of that. :smile:
Why could you not use a texture atlas for the polygonal version?
Euhm, what are you refering to? I guess I could use one?
 
You say a big part of the speed advantage over the polygonal version is the fact it can be done in a single draw call ... with a texture atlas (with some pixel shader magic to handle the tiling) that advantage would not be there.

In the end I'm doubtful that raycasting inside the pixel shader is going to beat rasterization for something which adds so few polygons, theoretically you are doing more work (assuming efficient occlusion culling). Also you put yourself in the position of needing to add new code for the shading when you use shadow buffers (and anything which needs the correct Z value in the Z-buffer is right out).

The "oh no, scary high polygon counts" is something we need to get away from now it's all unified.
 
Last edited by a moderator:
That is true, but that could also be achieved by using an if-statement and only looking up in the right texture, because the values from the other three textures are ignored anyway. I never got around to trying how much performance would actually be gained by that, though, but I guess you are right that your version is indeed faster because of that.?

The problem with dynamic branching is that you'd need to use the gradient version, which would then add additional cycles to the sampling cost, so the gain may not be too great.

You say a big part of the speed advantage over the polygonal version is the fact it can be done in a single draw call ... with a texture atlas (with some pixel shader magic to handle the tiling) that advantage would not be there.

Don't underestimate the pixel shader magic necessary to make texture atlases work reliably though. Dealing with wrapping and mipmaps on atlases is a major pain in the posterior. It takes more instructions to do that than do the raytracing. In DX10 you could use texture arrays though, which doesn't have the same problems.

In the end I'm doubtful that raycasting inside the pixel shader is going to beat rasterization for something which adds so few polygons, theoretically you are doing more work (assuming efficient occlusion culling). Also you put yourself in the position of needing to add new code for the shading when you use shadow buffers (and anything which needs the correct Z value in the Z-buffer is right out).

If you need to blend windows on top of it you're doing more work with polygons since the interiors are rendered first anyway, and you're culling less.

The "oh no, scary high polygon counts" is something we need to get away from now it's all unified.

Vertex shader work was never much of a concern. It's mostly bandwidth limited anyway. But storage space and trashing the framebuffer with polygon edges are valid concerns. If you're going to render a full city with thousands of buildings it's a different matter than with a few buildings.

Close up it's probably going to be a bit faster to just rasterize with real geometry. In the medium distance LOD interior mapping would likely be the winner, and in the far LOD it's probably enough to just stick to a flat texture and only keep the lights on/off switch.
 
The problem with dynamic branching is that you'd need to use the gradient version, which would then add additional cycles to the sampling cost, so the gain may not be too great.
What do you mean with "the gradient version"? Is that some situation in which dynamic branching has a certain performance?
 
I mean you have to use tex2Dgrad() as opposed to tex2D(). You can't use the regular tex2D() call inside a dynamic branch.
 
Ah, okay, I see that I really have to dig into shader model 3 and 4. I never went beyond shader model 2... :oops:

Does anyone have a link to a serious performance comparison between these two? I always read "it's slower" on these kinds of things, but no one ever seems to have numbers, like "it's x% slower in this and this situation and y% slower in this and this situation." I know, every situation is different, but some interesting numbers can be found nevertheless.

Ow, and as for the windows that are not visible on the inside at the corners, have you thought of a good solution for that? As most buildings are boxes, it should be easy to find whether a wall should have windows. I never tried implementing it, though. For more complex situations, I figured it would be possible to first render the depth and uv of the backfaces into a rendertexture and then look up in that to add the back windows. However, this solution seems to be so costly, that using geometry for the interiors seems better in that case. But again, I never actually implemented it.
 
On R520 tex2Dgrad adds two cycles to the total sampling cost. So if you do a regular bilinear fetch, that means it takes three cycles instead of one, so that's 3x the cost. For trilinear which normally takes two cycles, that'll amount to four cycles, so it's 2x. Trilinear volumetric it becomes 50% extra.

On R600 it's basically the same, with the difference that you can reuse the gradients across texture lookups on the same sampler. So if you're doing a loop with lots of tex2Dgrad calls, if you're using the same gradients for all, you're only taking the two cycle hit on the first fetch.

On G70 I think it's 4x the cost for bilinear and 8x the cost for trilinear. I think it's similar on G80 as well.
 
Thanks for the explanation! That sounds pretty heavy actually, although in an entire shader it is relatively little. This does make your implementation theoretically faster, though. :)
 
I've uploaded a new version of the demo now. Hadn't done any depth sorting, and it turns out it was pretty much drawing back to front in the default position. So a simply sort added, and performance went up 80%. :)
 
Then I'll give it a try as soon as my new Radeon arrives. But I'm having a hard time deciding between the ultra-cheap (~60 Euro) 3850 and the still-cheap but far more powerful HD4850.



Pity. It'd be a really nice thing for GTA-something or Max Payne III ;)

I actually would greatly dislike it. I don't like such things unless I can actually get into the room. If I could do that though I would be very happy.
 
Got a Shader Model 4.1 card so I finally tested it out. Fantastic idea save for one thing. The corner rooms should be the same when looking from either window. As it stands if you look from the left window it will show one room, but looking from the right it will show a whole different room (looks odd). Hopefully you understand what I'm saying since it seems harder to describe it than it should. :smile:
 
So, I picked up Saints Row 4 with my HD7950 and I dare say this game implements this feature, or at least something very close to it.

Any comment Humus? How different or similar is the technique Volition uses? And have these years given us anything in the way of API advancements to make this more efficient on modern hardware? Perhaps the hardware itself has evolved to suit this technique?

I must say it looks very convincing if you don't look too closely. Much, much better than the typical painted texture of 1950s barber shop in every window :)

Screeners (look at the pretty parallax)
http://steamcommunity.com/profiles/76561197980004240/screenshots
 
Last edited by a moderator:
Yes it is. The effect also breaks down if you get too close and look to hard, but when you're jogging by at 70mph it looks good :D
 
Didn't check this on the actual game, but from the screens it seems like just a regular texture that cleverly scrolls left and right to fake some sort of perspective, but without the costlier parallax distortion of Humus' proposition.
AC3 also had something along those lines, yet with much blurrier interiors.
 
^^ I share Milk's perception -- Saints Row 3 actually had this too. There's some distortion effect that makes that texture look as if there's parallax, but it's not perfect.
 
Hmm, interesting. It is still miles better than a static texture.

Oh absolutely, it's a nice effect and this particular implementation is probably cheaper" than the one Humus built. I'd love to see his method used in games like GTA and SR :)
 
Back
Top