[Humus]

I've published a new demo showing off the Interior Mapping technique, which basically is a pixel shader based technique for adding interiors to buildings. The buildings are still rendered as simple boxes. Rooms are represented as a cubemap and I'm using cubemap arrays in DX10.1 to select between different room layouts to avoid repeativeness.



I was going to say "download at the usual place", but hey, it's not at the usual place, because my site has moved.
It's now at www.humus.name, but is otherwise the same site as before.

[CarstenS]

So, 10.1-CM-arrays means no-go for Geforce-user?

But judging from the screenshot it looks like it could make large downtown sceneries much more believable. Any ideas if there are games going to be using it?

[fellix]

What would be the performance hit rendering those cube-maps in DX10.0?

For the report - it runs flawlessly for me (4870), just had to update the DX with June's Redistributable.

[Humus]

Originally Posted by CarstenS

So, 10.1-CM-arrays means no-go for Geforce-user?

Yeah.

Originally Posted by CarstenS

But judging from the screenshot it looks like it could make large downtown sceneries much more believable. Any ideas if there are games going to be using it?

Haven't heard of any.

Originally Posted by fellix

What would be the performance hit rendering those cube-maps in DX10.0?

I'm not rendering to any cubemaps. The cubemaps are static. It's just the room walls, floor and ceiling stored in the faces of the cubemap. The option for DX10.0 would be to rotate the walls for the same room. That would give you 4 out of the 8 permutations I have now, but be more expensive, a bunch of ALU instructions extra. Should look good enough though.

Best would be if you had enough artwork for several different room types. If I had more time or were better at Photoshop I would have done that. That's not an option you have with DX10.0 though with this technique, unless you use several samplers and dynamic branching to select.

[CarstenS]

Originally Posted by Humus

Yeah.

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.

Originally Posted by Humus

Haven't heard of any.

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

[willardjuice]

Originally Posted by Humus

It's now at www.humus.name, but is otherwise the same site as before.

Perhaps you should update your sig.

I'm sure it's an awesome demo, must remember to try it when I get hardware that can run it.

[Humus]

Originally Posted by willardjuice

Perhaps you should update your sig.

Done. Thanks for reminding me.

[NRP]

Nevermind

[Panajev2001a]

Originally Posted by Humus

I've published a new demo showing off the Interior Mapping technique, which basically is a pixel shader based technique for adding interiors to buildings. The buildings are still rendered as simple boxes. Rooms are represented as a cubemap and I'm using cubemap arrays in DX10.1 to select between different room layouts to avoid repeativeness.



I was going to say "download at the usual place", but hey, it's not at the usual place, because my site has moved.
It's now at www.humus.name, but is otherwise the same site as before.

It is a great demo, but I feel it breaks down with rooms on the corners which have two windows... nothing on the programming side, just an artistic consideration... kinda funny imagining where the virtual diagonal wall obstructing the light is .
In that picture (easier to spot when you look at the large version of it in your web page) you can spot this minor issue quite a bit (second building on the right).

[Johnny_Physics]

Originally Posted by CarstenS

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

Something very similar, but as fancy, was used in Crackdown on Xbox360, really nice touch and a great use of making shaders give more to the game than the more obvious effects you'd expect. Since I have a GeForce and can't run this demo I will take my revenge by posting a Crackdown-picture

Couldn't find a good picture and my memory is fuzzy so that might be one of the few normal windows pictured, so my nVengeance is tepid at best, but it was most noticable at night with dimmed lights behind curtains and such...

Link to bigger:
http://xbox360media.ign.com/xbox360/...2110819256.jpg


Great effect though, I hope to see the more advanced type like Humus' demo in something soon, it's a clever use of available resources.

[Humus]

Originally Posted by Panajev2001a

It is a great demo, but I feel it breaks down with rooms on the corners which have two windows... nothing on the programming side, just an artistic consideration... kinda funny imagining where the virtual diagonal wall obstructing the light is .
In that picture (easier to spot when you look at the large version of it in your web page) you can spot this minor issue quite a bit (second building on the right).

True. I did consider that, but found it not to be too disturbing. Artists would probably disagree though. It could be fixed though. In this demo I'm using math to basically randomize it. You could use low res textures instead. For a real game that's probably what you want to do anyway to let artists tweak the look. That way you could make sure rooms align across corners and you don't get any issues with light being turned off on one side of the corner and lit on the other side.

Originally Posted by Johnny_Physics

Something very similar, but as fancy, was used in Crackdown on Xbox360, really nice touch and a great use of making shaders give more to the game than the more obvious effects you'd expect.

Yep. I really liked the idea when I heard of it. Lots of games have just plain window textures with nothing inside, or just a flat image. Getting some depth to the interiors really does improve things a lot.

[Sc4freak]

Perhaps I'm missing something, but wouldn't this require far more processing power than just having real geometry for the room? A box for a room would be an extra 8 vertices - but you need many more pixel shader instructions for interior mapping. I imagine this would only yield a performance benefit if you had a lot of buildings with many windows, and they were all very far away (so they don't cover many pixels).

Although I guess it would save time for artists.

[Albuquerque]

Originally Posted by Sc4freak

Perhaps I'm missing something, but wouldn't this require far more processing power than just having real geometry for the room? A box for a room would be an extra 8 vertices - but you need many more pixel shader instructions for interior mapping. I imagine this would only yield a performance benefit if you had a lot of buildings with many windows, and they were all very far away (so they don't cover many pixels).

Although I guess it would save time for artists.

Not really. With "real" geometry, think of all the Z-work involved, especially if there are lots of buildings. A big huge single box is much easier to z-test versus (potentially) many hundreds of individual rooms. And then you'll have translucency and reflection calculations with the glass on the windows versus how much of the room behind it is visible.

The extra shader instructions are trivial compared to the rest...

[Humus]

The shader is 15 ALU instructions on RV670 / RV770. Half of that are things you would need in the geometry case too anyway if you want the same visual quality, like the lighting. Computing the cube texture coordinate is 7 ALU. Also, using real geometry you'll have to separate it into two passes, one for the interior and then another pass blending the exterior on top of it. This is inefficient since you won't get much help from z-rejection because the interior must be rendered first.

[Oogst]

Originally Posted by Humus

I've published a new demo showing off the Interior Mapping technique, which basically is a pixel shader based technique for adding interiors to buildings. The buildings are still rendered as simple boxes. Rooms are represented as a cubemap and I'm using cubemap arrays in DX10.1 to select between different room layouts to avoid repeativeness.



I was going to say "download at the usual place", but hey, it's not at the usual place, because my site has moved.
It's now at www.humus.name, but is otherwise the same site as before.

Ah, that is a pretty interesting variation to my original Interior Mapping technique! It is cool to see other people experimenting with other approaches!

I cannot run your demo, though: I have an Nvidia DX10 card. It is a pitty that your technique requires DX10.1: this makes it much less applicable. Because my own technique runs well in shader model 2, it can be used on the XBox 360 and the Playstation 3, which is a great benefit. Your technique does seem to be a lot cheaper per pixel, though, which is nice.

I am wondering to what extent your demo is pespectively correct, because a cubemap only takes into account ray direction and not ray origin. Can you explain how you handle that?

Originally Posted by Sc4freak

Perhaps I'm missing something, but wouldn't this require far more processing power than just having real geometry for the room? A box for a room would be an extra 8 vertices - but you need many more pixel shader instructions for interior mapping. I imagine this would only yield a performance benefit if you had a lot of buildings with many windows, and they were all very far away (so they don't cover many pixels).

Although I guess it would save time for artists.

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.

My full paper (published at Computer Graphics International 2008) with the performance comparison can be found here.

[Humus]

Originally Posted by Oogst

I am wondering to what extent your demo is pespectively correct, because a cubemap only takes into account ray direction and not ray origin. Can you explain how you handle that?

It's perfectly perspective correct. I don't use the direction ray directly, instead I compute the intersection point of the ray with the room. If you start with interpolated position X I compute the intersection Y.

+----------------Y----+
|               /     |
|              /      |
|             /       |
|            /        |
|           /         |
|          /          |
|         /           |
|        /            |
|       /             |
+======X==============+

The final code after my optimizations is perhaps not so intuitive at what exactly it does:

float2 f = frac(In.texCoord);

 // Entrance position into the room
float4 pos = float4(f * float2(2.0, -2.0) - float2(1.0, -1.0), -1.0, cubeIndex);

// Compute position where the ray intersects the cube
float3 id = 1.0 / In.dir;
float3 k = abs(id) - pos * id;
float kMin = min(min(k.x, k.y), k.z);
pos.xyz += kMin * In.dir;

But basically I just compute the smallest interpolation factor (k) required to hit a wall in x, y or z and use that.

[Oogst]

Originally Posted by Humus

It's perfectly perspective correct. I don't use the direction ray directly, instead I compute the intersection point of the ray with the room. If you start with interpolated position X I compute the intersection Y.

+----------------Y----+
|               /     |
|              /      |
|             /       |
|            /        |
|           /         |
|          /          |
|         /           |
|        /            |
|       /             |
+======X==============+

The final code after my optimizations is perhaps not so intuitive at what exactly it does:

float2 f = frac(In.texCoord);

 // Entrance position into the room
float4 pos = float4(f * float2(2.0, -2.0) - float2(1.0, -1.0), -1.0, cubeIndex);

// Compute position where the ray intersects the cube
float3 id = 1.0 / In.dir;
float3 k = abs(id) - pos * id;
float kMin = min(min(k.x, k.y), k.z);
pos.xyz += kMin * In.dir;

But basically I just compute the smallest interpolation factor (k) required to hit a wall in x, y or z and use that.

Ah, okay, that is clear, but doesn't that make your technique hardly any more efficient than my version? What is the benefit of using a cubemap in this case?

[willardjuice]

Originally Posted by Oogst

Ah, okay, that is clear, but doesn't that make your technique hardly any more efficient than my version? What is the benefit of using a cubemap in this case?

I don't think Humus ever said his version is the best. He often makes demo's just to show people "hey look what's possible!" not "hey my way is the best and everyone else fails".

[Oogst]

Originally Posted by willardjuice

I don't think Humus ever said his version is the best. He often makes demo's just to show people "hey look what's possible!" not "hey my way is the best and everyone else fails".

That his technique would be better was actually my own conclusion when I did not yet understand how this technique works.

[Humus]

Originally Posted by Oogst

Ah, okay, that is clear, but doesn't that make your technique hardly any more efficient than my version? What is the benefit of using a cubemap in this case?

You only need a single texture lookup. I think yours needs four.

[MfA]

Originally Posted by Oogst

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?

[Oogst]

Originally Posted by Humus

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.

Originally Posted by MfA

Why could you not use a texture atlas for the polygonal version?

Euhm, what are you refering to? I guess I could use one?

[MfA]

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.

[Humus]

Originally Posted by Oogst

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.

Originally Posted by MfA

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.

Originally Posted by MfA

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.

Originally Posted by MfA

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.

[Oogst]

Originally Posted by Humus

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?