Light on Terrain

Started by
10 comments, last by kauna 10 years, 11 months ago

When the player shoot, I want to create a point light on the hit point so I can have something like bullet impact light effect.

Here is the code that I tried:


D3DLIGHT9 light;
light.Type = D3DLIGHT_POINT;
light.Diffuse = D3DXCOLOR(255.0, 255.0, 0.0f, 255.0f);
light.Position = hitPoint;
light.Range = 100.0f;
light.Attenuation0 = 50.0f; 
light.Attenuation1 = 50.0f;  
light.Attenuation2 = 0.0f;    
device->SetLight(2, &light);
device->LightEnable(2, TRUE);
I even set D3DRS_LIGHTING to TRUE before rendering the terrain, but I see that the terrain is not getting affected by the light.
Advertisement
If you're using the terrain shader from your other thread, D3DRS_LIGHTING will not work, since that is fixed function pipeline.

I'm using Pixel Shader for terrain texture splatting, now I want to be able to use D3DLIGHT9 in the light class, how do I do that?

By writing a pixel shader which handles lighting. Though you will find plenty of source if you google around, you will unlikely be able to just plug it into your system: You will have to combine it with your terrain splatting shader. The splatting will (at least) give you the so-called albedo (or diffuse) term for your lighting.

An alternative (which might or might not work with FFP, I don't know) is to just additively blend a light effect after your terrain has been rendered. It probably will not look as good as proper lighting, but could be enough for a short effect.

So that means If I'm using Shaders, I can't use device->SetLight()?

I think that will be a problem, since I'm working on a Game Engine that should handle everything that the game need, that way I can't use a light class, I will have to write pixel shaders for lighting for each game, am I right?

That could make things much harder when it come to mission editor since I will have to write shaders instead of using lighting tools (In the mission editor).

What's your suggestions?

So that means If I'm using Shaders, I can't use device->SetLight()?

Correct.

I think that will be a problem, since I'm working on a Game Engine that should handle everything that the game need, that way I can't use a light class, I will have to write pixel shaders for lighting for each game, am I right?

Nothing hinders you to use the same shaders across different applications, so: no.

That could make things much harder when it come to mission editor since I will have to write shaders instead of using lighting tools (In the mission editor).

It sure would, since you probably want your editor to support everything your engine is capable of. (Though I for one find FFP quite cumbersome compared to shaders).

What's your suggestions?

Seriously: Dump the fixed function pipeline. This was not the first and will not be the last wall you're hitting. FFP might have it's little use for some non-game or 2D apps, but practically every consumer hardware nowadays supports at least shader model 2 (look at the steam or unity hardware survey). You will also find better information (and help) concerning shaders.

Do I have to edit the Pixel Shader file for lighting in every game? I mean how do I position the light according to each game scene?

Another problem is that the shader files are much easier to change than binary files, while in the fixed function, it's much harder to change the binary, so that could be a problem since others can easily modify the scene if I'm relaying on shader files by simply changing the shader files.

Do I have to edit the Pixel Shader file for lighting in every game? I mean how do I position the light according to each game scene?

You can give your shaders any flexibility they need. The first of which usually is the transformations (world, view, projection etc.). For lighting this would be material properties and of course your light position. They are provided through specific API calls (e.g. SetPixelShaderConstantF) or, if using the effect framework, through more convenient functions. They are called shader constants or shader uniforms. If you think of a shader as a function these would be your function parameters (input).

Another problem is that the shader files are much easier to change than binary files, while in the fixed function, it's much harder to change the binary, so that could be a problem since others can easily modify the scene if I'm relaying on shader files by simply changing the shader files.

You could compile your shaders to binary if you're so concerned. Has the advantage that they don't need to be compiled at program start (complex shader need quite some time!).

Then again, someone with enough dedication and knowledge will break anything. Your best protection is through the law.

You don't even need to load them from file. For example use D3DXAssembleShader function, and write shader source directly in your code


std::string shaderSource =
        "ps_1_4\n              " \
        "// Sample textures\n  " \
        "texld r0, t0\n           " \
        "texld r1, t1\n           " \
        "texld r2, t2\n           " \
        "texld r3, t3\n           " \
        "texld r4, t4\n           " \
        "texld r5, t5\n           " \
        "mul r1, r1, r0.x\n       " \
        "lrp r2, r0.y, r2, r1\n" \
        "lrp r3, r0.z, r3, r2\n" \
        "lrp r0, r0.w, r4, r3\n" \
        "mul r0, r5, r0\n      ";

    hr = D3DXAssembleShader(shaderSource.c_str(), shaderSource.size(), NULL, NULL, 0, &source, NULL);

As unbird said there is no point in protecting your shader source.

You could even precompile shader and save "source" (ID3DXBuffer) in your binary file and then on client machine just load with CreatePixel/VertexShader().

Although i have not try that but it should work.

Another problem is that the shader files are much easier to change than binary files, while in the fixed function, it's much harder to change the binary, so that could be a problem since others can easily modify the scene if I'm relaying on shader files by simply changing the shader files.

Well, it looks like you missed the train by, about, ....counting...., a decade.

These days, since you haven't noticed, you don't wow the crowd with some shaders, internet is full of, anyway.

You wow them with a content adhering to a unique art style and that is very expensive to produce.

In short, worrying that someone could "steal" your shaders is least of your worries. If anything, that would be flattering...

VladR My 3rd person action RPG on GreenLight: http://steamcommunity.com/sharedfiles/filedetails/?id=92951596

This topic is closed to new replies.

Advertisement