• entries
422
1540
• views
489004

# Simple Normal Mapping = Finished

216 views

I've finally made some progress with the code for my "Techniques for Per-Pixel Lighting" chapter. For some reason I was getting almost correct results but not entirely correct.

Turns out that I had made a stupid mistake in my normal-mapping shader, something that's almost embarassing to admit to:

float3 normal = normalize( texNormalMap.Sample( DefaultSampler, v.texcoord ).rgb );

Should actually have been:

float3 normal = normalize( texNormalMap.Sample( DefaultSampler, v.texcoord ).rgb * 2.0f - 1.0f );

Almost as stupid as the time I forgot to specify .rgb and my normalization was working on a 4D instead of 3D vector. That was an odd mistake to track down and fix... [headshake]

In order to write the book so as to rely on as little "non standard" technology as possible I'm using D3DX10ComputeNormalMap() to generate the input data at load-time. Problem is it's either poorly documented or just broken - probably a bit of both.

I've only found one format (DXGI_FORMAT_R8G8B8_UNORM) that works - but you can feed in other formats and get partial/odd results back. Not sure if that means the documentation isn't specific enough, or the function shouldn't have restrictions but has a bug that effectively forces it to...

It also seems that the function AddRef()'s something internally and causes a memory leak. Or, at least it does something to make DXUT choke (the runtimes themselves don't report any leaks).

As it stands I'm a little concerned about writing it into the final book text unless it gets fixed. Thankfully I've got at least a couple of SDK's to hope they fix things [smile]

I also had a run in with state blocks this evening. Part of the video I'm preparing (hopefully have it read for you soon [wink]) starts with a wireframe rendering. So I set up the appropriate code for this, then wonder why wireframe mode never turns itself off.

Yup, FX10 changes things and it doesn't automagically handle states the same as FX9 does [rolleyes]

So I now have to box my rendering code like so:

D3D10_STATE_BLOCK_MASK mask;pTechniqueHandle->ComputeStateBlockMask( &mask );CComPtr< ID3D10StateBlock > pStateBlock;if( SUCCEEDED( D3D10CreateStateBlock( pd3dDevice, &mask, &pStateBlock ) ) ){	if( SUCCEEDED( pStateBlock->Capture( ) ) )	{		// Perform rendering here		pStateBlock->Apply( );	}}
Not exactly difficult, but it's just another "house keeping" chore that is all too easy to forget.

Anyway, the fruit of my labour:

I need to work on some better art-work. Currently It's just a simple N-dot-L output, but I want to put some diffuse texture so that I can prove another point later on...

Mmmmmm normal mapping.

What ever happened to the water demo you were working on a while ago? I was looking forward to seeing what you came up with. Last I remember you had the framework setup with the terrain/water plane.

Also I still say you should splurge and buy a 20" 4:3 LCD AND a 27" widescreen LCD...who cares if you've got to mortgage your left nut...it's worth it trust me [grin].

Take it easy man, keep up the good work.

- Dan

##### Link to comment
Quote:
 Almost as stupid as the time I forgot to specify .rgb and my normalization was working on a 4D instead of 3D vector.

Thanks for disclosing this shameful error. I was making the same mistake and couldn't figure out what went wrong until just now [smile]

##### Link to comment
I bet I could draw that image in MS Paint faster than the RefRast [smile].

Cool stuff, though.

##### Link to comment
Quote:
 What ever happened to the water demo you were working on a while ago?
hmm, what can I say... "there aren't enough hours in the day" springs to mind [smile]

I did want to push that one further, but the opportunity to write for this book came up and I grabbed at it instead.

Quote:
 I still say you should splurge and buy a 20" 4:3 LCD AND a 27" widescreen LCD
I was thinking about this earlier... I'll buy the 20" 4:3 LCD now, and at a later date I'll get a widescreen one that'll allow TV input so it can double up as my cinema/TV screen.

I hope to avoid mortgaging my nuts though.

Quote:
 Thanks for disclosing this shameful error.
[lol] My pleasure!

That 4D normalization thing really stumped me when I first hit it - made absolutely no sense yet the results were obviously wrong [headshake]

Quote:
 I bet I could draw that image in MS Paint faster than the RefRast
The above image is pretty fast via RefRast (~1fps) but when I get on to Relief Mapping it'll be a completely different story. Running ATI's "Parallax Occlusion Mapping" sample via D3D9 and hardware only just breaks 15fps [oh]. I'd be impressed if the RefRast worked at 15 seconds/frame...

Cheers,
Jack

## Create an account or sign in to comment

You need to be a member in order to leave a comment

## Create an account

Sign up for a new account in our community. It's easy!

Register a new account