Jump to content

  • Log In with Google      Sign In   
  • Create Account


Light on Terrain


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
11 replies to this topic

#1 Medo3337   Members   -  Reputation: 665

Like
0Likes
Like

Posted 01 May 2013 - 07:51 AM

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.

Edited by Medo3337, 01 May 2013 - 08:46 AM.


Sponsor:

#2 unbird   Crossbones+   -  Reputation: 4776

Like
1Likes
Like

Posted 01 May 2013 - 08:05 AM

If you're using the terrain shader from your other thread, D3DRS_LIGHTING will not work, since that is fixed function pipeline.

#3 Medo3337   Members   -  Reputation: 665

Like
0Likes
Like

Posted 01 May 2013 - 08:45 AM

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?



#4 unbird   Crossbones+   -  Reputation: 4776

Like
1Likes
Like

Posted 01 May 2013 - 09:20 AM

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.

Edited by unbird, 01 May 2013 - 09:24 AM.


#5 Medo3337   Members   -  Reputation: 665

Like
0Likes
Like

Posted 01 May 2013 - 09:37 AM

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?



#6 unbird   Crossbones+   -  Reputation: 4776

Like
2Likes
Like

Posted 01 May 2013 - 10:05 AM

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.

#7 Medo3337   Members   -  Reputation: 665

Like
0Likes
Like

Posted 01 May 2013 - 10:53 AM

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.



#8 unbird   Crossbones+   -  Reputation: 4776

Like
2Likes
Like

Posted 01 May 2013 - 11:22 AM

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.

#9 belfegor   Crossbones+   -  Reputation: 2329

Like
3Likes
Like

Posted 01 May 2013 - 11:34 AM

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.


Edited by belfegor, 01 May 2013 - 11:43 AM.


#10 VladR   Members   -  Reputation: 722

Like
2Likes
Like

Posted 01 May 2013 - 12:12 PM

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

 


#11 SuperVGA   Members   -  Reputation: 1118

Like
0Likes
Like

Posted 01 May 2013 - 02:16 PM

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...

On the top of that, you could make the shader source harder to pick out by including them in your source as a string.

You could even obscure the string if you were really paranoid.

 

But you'd be shooting yourself in the foot. - A cracker gets what a cracker wants if it's available on the client at one moment or another.

You would be much better off just ignoring these things and focusing on making a good product. Or you can go all-in on DRM in all its splendor.

 

With regards to

 


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?

 

You can, by assembling the shader source in the code create the uniforms you'll be needing dynamically.

Keep in mind that there's still a limit of how much you can stuff in there.


Edited by SuperVGA, 01 May 2013 - 02:19 PM.


#12 kauna   Crossbones+   -  Reputation: 2142

Like
0Likes
Like

Posted 01 May 2013 - 06:12 PM

You may check here for a shader with similar capabilities as fixed function pipeline.

 

http://www2.ati.com/misc/samples/dx9/FixedFuncShader.pdf

 

Cheers!






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS