Jump to content

  • Log In with Google      Sign In   
  • Create Account


BlueHabu

Member Since 28 Feb 2005
Offline Last Active Private

Topics I've Started

New compile trouble with perv working lighting effect file

16 August 2009 - 11:14 AM

I have been using this lighting model for years to run a small program that run a visual simulation for a network project I am working on. I took it almost verbatim out of the my book by Frank Luna on using D3D 9.0. I understand it is copyrighted but I am only using the code for academic uses. I have not rebuilt the program in over a year but I tried this week with the latest march 09 SDK and for the life of me I can get this fx file to load. The error is "Lighting.fx(87,8): error x4579: NaN and infinity literals not allowed by shader model ID3DXEffectCompiler: Compilation Failed" I am no graphics guru but I just cannot see the error. As a "quick fix" i have float t = 0.0. thanks for taken a look and any sugesstions
//=============================================================================
// PhongDirLtTex.fx by Frank Luna © 2004 All Rights Reserved.
//
// Phong directional light & texture.
//=============================================================================

struct Material
{
	float4 ambient;
	float4 diffuse;
	float4 spec;
	float  specPower;
};

struct DirLight
{
	float4 ambient;
	float4 diffuse;
	float4 spec;
    float3 DirW; 
};

uniform extern float4x4 gWorld;
uniform extern float4x4 gWorldInvTrans;
uniform extern float4x4 gWVP;
uniform extern Material gMaterial;
uniform extern DirLight gLight;
uniform extern float3   gEyePosW;
uniform extern texture  gTexture;

sampler TexS = sampler_state
{
	Texture = <gTexture>;
	MinFilter = Anisotropic;
	MagFilter = LINEAR;
	MipFilter = LINEAR;
	MaxAnisotropy = 4;
	AddressU  = WRAP;
    AddressV  = WRAP;
};
 
struct OutputVS
{
    float4 posH    : POSITION0;
    float3 normalW : TEXCOORD0;
    float3 toEyeW  : TEXCOORD1;
    float2 tex0    : TEXCOORD2;
};

OutputVS PhongLightingVS(float3 posL : POSITION0, float3 normalL : NORMAL0, float2 tex0: TEXCOORD0)
{
  // Zero out our output.
	OutputVS outVS = (OutputVS)0;
	
	// Transform normal to world space.
	outVS.normalW = mul(float4(normalL, 0.0f), gWorldInvTrans).xyz;
	
	// Transform vertex position to world space.
	float3 posW  = mul(float4(posL, 1.0f), gWorld).xyz;
	
	// Compute the unit vector from the vertex to the eye.
	outVS.toEyeW = gEyePosW - posW;
	
	// Transform to homogeneous clip space.
	outVS.posH = mul(float4(posL, 1.0f), gWVP);
	
	// Pass on texture coordinates to be interpolated in rasterization.
	outVS.tex0 = tex0;

	// Done--return the output.
  return outVS;
}

float4 PhongLightingPS(float3 normalW : TEXCOORD0, float3 toEyeW  : TEXCOORD1, float2 tex0 : TEXCOORD2) : COLOR
{
	// Interpolated normals can become unnormal--so normalize.
	normalW = normalize(normalW);
	toEyeW  = normalize(toEyeW);
	
	// Light vector is opposite the direction of the light.
	float3 lightVecW = -gLight.DirW;
	
	// Compute the reflection vector.
	float3 r = reflect(-lightVecW, normalW);
	
	// Determine how much (if any) specular light makes it into the eye.
	float t  = pow(max(dot(r, toEyeW), 0.0f), gMaterial.specPower);
	
	// Determine the diffuse light intensity that strikes the vertex.
	float s = max(dot(lightVecW, normalW), 0.0f);
	
	// Compute the ambient, diffuse and specular terms separatly. 
	float3 spec = t*(gMaterial.spec*gLight.spec).rgb;
	float3 diffuse = s*(gMaterial.diffuse*gLight.diffuse).rgb;
	float3 ambient = gMaterial.ambient*gLight.ambient;
	
	// Get the texture color.
	float4 texColor = tex2D(TexS, tex0);
	
	// Combine the color from lighting with the texture color.
	float3 color = (ambient + diffuse)*texColor.rgb + spec;
		
	// Sum all the terms together and copy over the diffuse alpha.
   return float4(color, gMaterial.diffuse.a*texColor.a);
}


technique LightingTech
{
    pass P0
    {
        // Specify the vertex and pixel shader associated with this pass.
        vertexShader = compile vs_2_0 PhongLightingVS();
        pixelShader  = compile ps_2_0 PhongLightingPS();
    }
}


Managed Vrs Native Heap Speed Comparison

17 August 2006 - 05:55 PM

I have created two projects, one is native C++ the other is managed C++/CLI. Both programs create 1GB of data ,write zeros to it one byte at a time, then add 1 to each byte then delete the buffer. I was going to add a timer but did not want to clutter the code if i could tell which is faster by the seat of my pants (which i can). I figured I would put this out there and see what others thought. http://dev.bluehabu.com/Downloads/Allocate.zip What I am wondering about is if there is a small optimization that can be done to the C++/CLI code to make it faster. Now I know I can make the C++ code faster using asm tricks but that is not the point. I was looking at seeing if similar code ran slower or faster depending on being managed or unmanaged. For me the managed code seems noticeably slower but instead of starting yet another C#/C++ holy war I thought I would put these projects here and have people try it out and see which is faster. FYI: Project Allocate2 is native Allocate3 is managed. If you modify the buffer size to something larger let me know what you get it up to. I had an exception thrown if it was too big in Allocate3. My Important Machine Stats AMD 4600 X2 AM2 Nvidia 590 Chipset 2GB of 4-4-4-12 Corsair DDR2-800 Compiler is VC8 My motivation is to see the performance costs of managed code relative to C++. I have been working on a graphics engine for about 6 months now and before I get to far I wanted to see what kind of performance I could get with managed code in terms of using large portions of system memory. Thanks for all that take a look at my crappy code. Project files are included for VS2005

Do I have to many libraries

10 May 2006 - 11:09 AM

First let me describe my current "game engine". HabuTimers - A timers library HabuSS - OpenAL sound system and is dependent on HabuTimers HabuInput - DirectInput library and is dependent on HabuTimers HabuCompress - Compression Library HabuEncrypt - Encryption Library HabuSocket - Generic Network Library and is dependent on HabuCompress, HabuEncrypt and HabuTimers HabuMPN - Multiplayer library that is dependent on HabuSocket HabuGL - DirectX 9 only graphics library and is dependent on HabuTimers Is that going over board with the number of libraries. It works great in my opinion. It was nice when I was working on bug in my timers code and i only had to fix it in one place and was done after a recompile and few tests. The reason I ask is I got into a discussion with a guy doing the game logic for our little project and he said there are to many libs. What to you think? I was just getting ready to add HabuSecurity for anti cheat code and HabuMT for threads/thread pools.

Rain on a Windshield/Window

24 October 2005 - 07:54 AM

I am working on a Racing Sim but as a project for a grad class i am thinking of trying to do rain on windshield (then hopefully use the experience to add it to our sim -- I am an app programmer not a graphics guru) For now the windshield would be stationary (no motion effects like wind and lateral forces). Right now my plan is to have a texture on the windshield that I generate procedurally to simulate the location of the rain drops. (If anyone sees a problem with this approach let me know) Since I am limited to OGL 1.1 (school requirement) and I have never touched GLSL doing a pixel shader is out. I have seen threads about creating rain using particle systems but thats not my goal. I want to simulate water on glass and with the camera is sitting in a "dry" environment. My question is this. How could i get the the effect of the light refracting through the water on the glass to look believable? Does not have to be photo realistic, i am just looking for good approach at this point. If going with a pixel shader is the only way then maybe i can get permission to use 0GL 2.0. Thanks Edit: SPelLinG [Edited by - BlueHabu on October 24, 2005 3:45:10 PM]

Check My Graphic Engine Arch

07 September 2005 - 03:56 AM

Here is what I got 1. Vextex Class with postion data 2. Polygon Class with Vertex* array (Derived Strip, Quadrangle, and Triangle Classes) 3. Mesh Class with Polygon* array, 4. Object Class with Mesh* array 5. Scene Class (Singleton) with Object* array 6. Base Class context and window control I do have a Light Class and a Camera class encapsulated in Object and Scene respectively This seems logical to me but this is my first graphic engine. I have experince with large scale OO projects but to design a OO scheme you need to have some clue on what the design goal is. All I know is I want a cross platform graphic engine. Been playing around with OGL for a couple of months now and this is the best i can come up with. Does any one see any major problems with this design in terms of high poly, semi good performance 3D graphics engine? Sorry I am not a big UMLer.

PARTNERS