Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers DBPro Corner / Are DBP lights a bit weak, or do I not know how to use them?

Author
Message
Bursar
16
Years of Service
User Offline
Joined: 17th Sep 2008
Location:
Posted: 14th Oct 2008 00:18
I'm trying to create a muzzle flash from a tank firing. Placing the flash at the end of the barrel is not too much of an issue.

What's currently confusing me is how to display a flash of light when the tank fires.

Code is as follows:

Now that kind of works. A really weedy yellow light shines on the tank. But does the range really have to be 100? By the time I turn the range down so it doesn't affect other nearby objects, the light on the tank disappears. It also casts no glow on the ground plain.

Being new to this, I wouldn't be surprised to learn that I'm mis-understanding something and it would work if I changed my code a bit.

On the otherhand, I wouldn't be too surprised to learn that I need to buy Dark Lights in order to get a decent lighting solution
Sixty Squares
18
Years of Service
User Offline
Joined: 7th Jun 2006
Location: Somewhere in the world
Posted: 14th Oct 2008 04:06 Edited at: 14th Oct 2008 14:34
Quote: "By the time I turn the range down so it doesn't affect other nearby objects, the light on the tank disappears. It also casts no glow on the ground plain."


Okay. I've probably got no idea what I'm talking about, but here goes. You'll probably want to wait for a better response later...

I believe that DBP uses vertex lighting or something, so the light has to be at the very corner of the plain to cast a shine (because the plain is divided up into 4 boxes I believe). A work around for this would be to use a per pixel lighting shader (you may not want to jump into that though), or to make a plain with more quadrants in some sort of modeling program? But then the lighting would be sortof square.

Oh, I think there were new parameters added to the make object plain command. In testing them I found that the plain is divided across and down by the specified numbers (like the MAKE MATRIX command). It is also rotated along the X axis by 90 degrees for no reason.

Make Object Plain Object Number, X Size, Y Size, Across Squares, Down Squares

It doesn't highlight in the editor but it works here. I'm using DBP U6.8:



Bursar
16
Years of Service
User Offline
Joined: 17th Sep 2008
Location:
Posted: 14th Oct 2008 11:58
I'm using 6.9 and the Make Object Plain command throws an error when following your syntax. All 6.9 wants is Object Number, Width, Height.

I get what your saying though, and that would explain why if you create a cube and place a light directly over it, the top of the cube remains white until you rotate the cube and the light can catch one of the corners.
Sixty Squares
18
Years of Service
User Offline
Joined: 7th Jun 2006
Location: Somewhere in the world
Posted: 14th Oct 2008 14:35
Strange... Either that functionality was removed or I've got some sort of plugin .

IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 14th Oct 2008 20:14
You've got MY plug-in

The reason for the different orientation was because the plain was primarily implemented to allow it to have the vertices changes for mimicking terrain. The only other difference is that the DBPro plain has culling disabled, and mine doesn't.

Oh, and yes, you do know what you are talking about regarding the DBPro standard lighting

Bursar
16
Years of Service
User Offline
Joined: 17th Sep 2008
Location:
Posted: 14th Oct 2008 21:03 Edited at: 14th Oct 2008 21:30
That works much better. I've installed Ian's plug-ins allowing me to create a plain that's more divided and I now have a nice glow on the ground.

Thanks

Edit -> ofcourse as a bonus I don't need that function to loop through all the limbs looking for the one with the right name. There's a handy command built in that will do it for me!
Sixty Squares
18
Years of Service
User Offline
Joined: 7th Jun 2006
Location: Somewhere in the world
Posted: 14th Oct 2008 23:40
Quote: "You've got MY plug-in "


Haha go figure. Your plugins do everything I'm starting to think half of the commands in there came with DBPro

Quote: "Oh, and yes, you do know what you are talking about regarding the DBPro standard lighting "


That's good .

I'm glad things are all sorted out.

Quantum Fusion
16
Years of Service
User Offline
Joined: 1st Aug 2008
Location: The Great White North
Posted: 29th Oct 2008 17:26
But couldnt Lee throw in a new command in DBPro to help out with the lighting not being so weak?

Something like:

SET LIGHT INTENSITY LightNum, IntensityValue

Dual-Core Pentium D @ 3.00GHz, 1.0 GB nVidia GeForce 8500 GT, 20" Wide screen LCD @ 10,000:1 Contrast, 4.0 GB DDR2 SDRAM, Triple-boot: 32-bit Windows XP MCE, 64-bit Vista, 64-bit Linux Ubuntu
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 29th Oct 2008 21:41
Quote: "to help out with the lighting not being so weak?"

Didn't Sixty Squares just show that there's nothing wrong with the lighting?

It doesn't need fixing, and certainly not that way - doing it that way would cause all the objects that are lit as you expect to become brighter.

No, the correct fix is to use a reasonable number of vertices.

Sixty Squares
18
Years of Service
User Offline
Joined: 7th Jun 2006
Location: Somewhere in the world
Posted: 29th Oct 2008 22:08
Quote: "Something like:

SET LIGHT INTENSITY LightNum, IntensityValue"


Have a look at FADE OBJECT. If your object has, as IanM already stated, a reasonable number of verticies, then setting a value greater than 100 for Fade Object should do the trick.

calcyman
17
Years of Service
User Offline
Joined: 31st Aug 2007
Location: The Uncertainty Principle
Posted: 31st Oct 2008 22:32
It seems very inelegant to have to create more polygons than necessary, just to increase the intensity of a light; especially since it would slow the processor down.

Furthermore, the light shouldn't be applied per surface, but instead should be applied per screen pixel. Otherwise a single quadrilateral that extends infinitely in every direction (imagine an ocean) will be uniformly lit, when in fact it shouldn't.

Quote: "No, the correct fix is to use a reasonable number of vertices."


You mean an excessive number of vertices. Vertices should only be used to increase the detail, not to make the lights more effective.

The optomist's right, The pessimist's right.
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 1st Nov 2008 23:58
It seems very inelegant to render lighting per-pixel using a shader just to increase intensity of light, especially since it would slow rendering down.

The world of rendering is full of trade-offs, almost none of which are elegant, and all of which are approximations:
Why use poly's when they can only approximate a surface?
Why use normals when they can only give approximate lighting?
Why use gourand shading when it only approximates the lighting?
Why use specular or diffuse when they only approximates the lighting?

Approximation piled upon approximation.
I could go on and list many more things that affect lighting, all of them approximations and inelegant.

The point is that you pick a method that works for you, and use it. If adding a pixel shader works and your frame rate can afford it, use it. If adding vertices works and your frame rate can afford it, use it.

Login to post a reply

Server time is: 2024-11-24 20:02:10
Your offset time is: 2024-11-24 20:02:10