Interior Mapping demo

[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]

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

Yeah.

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.

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]

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.

Haven't heard of any.

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

 

[willardjuice]

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]

Perhaps you should update your sig.

Done. Thanks for reminding me.

 

[NRP]

Nevermind

 

[Panajev2001a]

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]

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/image/article/747/747365/crackdown-20061122110819256.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]

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.

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]

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]

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?

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]

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]

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]

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]

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]

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.