Illumination "sticking" to the object?

Re: Problem solved: HLSL not very intuitive.

Just checked and it seems the inverse transpose of the view matrix isn't exposed as a standard variable in RenderMonkey, though it should be possible to just transpose inv_view_matrix. But simply using the view_matrix should work in most cases too.

 

That's the "view-projection matrix", that is the view and projection matrix concatenated, and often called the mvp matrix.

mvp = projection * view;

transformed vertex is then

tPos = mvp * inPos = projection * view * inPos

so the vertex is first transformed by the view matrix, then by the projection matrix.

 

The variables you see in RenderMonkey are RenderMonkey specific. The app provides those for you. The HLSL itself doesn't defined any variabled (AFAIK anyway).


[/end of posting spree]

 

Re: Problem solved: HLSL not very intuitive.

whenever the transform is ortho-normal, than is.

 

Re: Problem solved: HLSL not very intuitive.

Two points.

First, premultiplied light color and material color is a somewhat common case in the real-time world. ARB_vertex|fragment_program and ARB_vertex|fragment_shader (the OpenGL Shading Language) include builtin state bindings to the light color & material color products. So, maybe a bit more intuitive. (Maybe not.)

Second, the example should be taken more generally. Particularly since the material properties often won't be uniform across a surface anyway.

Even if you don't care about performance, I'm guessing you will care about making your shader fit. With HLSL the shader either fits, or it doesn't fit. If it doesn't fit, it doesn't run. You can break your shader into multiple passes, or you look for ways to squeeze a few instructions off your shader by pre-multiplying some values. Your choice, either (or more likely, both) will make for slightly more awkward shaders, but the tradeoff may be worth it so you can play with far more complex shaders.

You can multiply by a transposed matrix easily:

Code:

// Transform position and normal from object to view
float4 transformedPosition = mul( view_matrix, position );   // float4x4 x float4
float3 transformedNormal   = mul( normal, inv_view_matrix ); // float4 x float4x4, note the transpose

-mr. bill

edit: Fixed HLSL example slightly (OpenGL Shading Language creeped in, sorry)

 

Re: Problem solved: HLSL not very intuitive.

Nah. Cross-product would be "^", dot product would be "." Ooops, wrong shading language again.

-mr. bill

 

Re: Problem solved: HLSL not very intuitive.

You do realize that you rotate your viewpoint only, while the model is fixed in its position and orientation? The camera goes around, not the model.

 

Re: Problem solved: HLSL not very intuitive.

"Wrong" and "right" depends on your intensions. The only rule in graphics is that "if it looks good, then it is good". In some scenes Half-Lambert looks good, so it can be just about right for those. In other scenes you may want something else. Phong and Blinn aren't so much "right" either, it's just approximations too. The softness is just that the backside doesn't become completely black. You get some lighting on the backside of the model too. This way you may not need any ambient. Ambient which is also a very rude approximationg of global illumination, and may be called "wrong", but it does look very good in relation to its very cheap cost.

 

Re: Problem solved: HLSL not very intuitive.

Moving the camera around will change the relative position of the light to the camera, while just rotating the model won't.

 

Re: Problem solved: HLSL not very intuitive.

Of course I don't expect Half-Lambert in movie renders, but for simple scenes like in RenderMonkey it's useful.

"N dot L over 90 degrees" is nothing uncommon though, it's very common, in fact you have it constantly in the scene unless the camera and light is at the same position. Just view the object from behind and you have N dot L < 0, so all blackness.

 

No, I don't mind your coding style at all. And I don't particularly endorse half-Lambert over other lighting models. I'm not suggesting you should start using it. I'm just saying it's not neccesarily useless or "wrong".