Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Valathil on July 05, 2011, 08:50:18 pm
-
Been working on this for the past day have a look I think its finally working as it should
http://www.youtube.com/watch?v=_Tw9nNcgbU0
-
That's bloody impressive! Good stuff.
-
I like what I see! How did you manage to overcome the light limit?
-
I like what I see! How did you manage to overcome the light limit?
Valathil can correct me if I am wrong, its done with a tube light (that is the entire beam is a light emitter, rather than the (three?) spot lights that we used previously.
-
look nice! :yes:
-
I like what I see! How did you manage to overcome the light limit?
I work on that in a separate patch beams are much closer for me to release.
(that is the entire beam is a light emitter, rather than the (three?) spot lights that we used previously.
Exactly the beam light is a tube light and I could eliminate one useless light spawn. Beams that hit a ship would always spawn 2 lights, I killed the light that would spawn when a collision is detected and handled that with the tube light. So that makes it a little easier for the 8 light limit.
-
Nicely done! It looks way more subtle. and much more realistic - no more green-wash capships :D
-
will this also cast light on objects that the beam passes, like a fighter between capships that are duking it out?
-
i wanted to do that but the light limit precludes me from removing the filter that only applies beam to the ship the beam was meant for. However if i can fix the problems with my light limit patch this should be possible in the future.
oh and new preview:
http://www.youtube.com/watch?v=TWFkbEJVVhk
-
Nicely done! It looks way more subtle. and much more realistic - no more green-wash capships :D
A thousand times this.
i wanted to do that but the light limit precludes me from removing the filter that only applies beam to the ship the beam was meant for. However if i can fix the problems with my light limit patch this should be possible in the future.
oh and new preview:
http://www.youtube.com/watch?v=TWFkbEJVVhk
I know the blue AAA beams already cast light on things that are nearby, but aren't colliding with the beam. Or at least I think so. Not sure if that's useful for you to know though...
-
Keep up the good work Valathil :yes:
Improving the lighting (and adding shadows :p ) is one of the major points of potential improvements for the freespace graphics :nod:
-
I want to see it against a box-shape ship now, like the Orion. The Lucifer is very rounded, I have a feeling it will have a different effect on a ship that's mostly flat surfaces and right angles.
-
The Colossus in the second video is decidedly box-like.
-
I know the blue AAA beams already cast light on things that are nearby, but aren't colliding with the beam. Or at least I think so. Not sure if that's useful for you to know though...
they dont have the filter set cause they are expected to miss often
-
I have to say I'm impressed, and I hope the next version of beam lighting will be this one.
Having said this, I also have to say that I'm slightly disappointed that the light hitting the hull of the ships is not exactly aligned with the beam itself, it seems that the light source is too far away from the hull itself, and the end result seems more like a reflection of a somewhat distant light, rather than the beam's light itself.
When I read your explanation, I thought, "Great, someone made a nice review of id's cheat on QuakeGL's missiles light (spheres)", but after seeing the videos, I see that by "tube" you mean something different.
So could someone explain to me what is geometrically happening within "light tubes"?
EDIT: And perhaps make it a little less "subtle"?
-
The "subtlety" could probably be tweaked by light tags.
I do agree that at point of impact, there needs to be a fair bit more relative luminosity though.
-
I have to say I'm impressed, and I hope the next version of beam lighting will be this one.
Having said this, I also have to say that I'm slightly disappointed that the light hitting the hull of the ships is not exactly aligned with the beam itself, it seems that the light source is too far away from the hull itself, and the end result seems more like a reflection of a somewhat distant light, rather than the beam's light itself.
When I read your explanation, I thought, "Great, someone made a nice review of id's cheat on QuakeGL's missiles light (spheres)", but after seeing the videos, I see that by "tube" you mean something different.
So could someone explain to me what is geometrically happening within "light tubes"?
EDIT: And perhaps make it a little less "subtle"?
well by tube light i mean i take the nearest point on the beam line relative to the current calculating pixel and use that as a lighting direction. the to far away effect that doesnt look right comes from that kinda "faking it" way of doing the calculation. hardware limitations preclude me from a more accurate solution of integrating the light components along the beam (at least i think they do, i could try though would be crazy but worth it if it works).
will this also cast light on objects that the beam passes, like a fighter between capships that are duking it out?
i want to correct myself on that tube lights currently project light onto every target in range except the firing ship ( to save calculations about being "behind" the beam ). a fighter between two capships is currently being lit beautifully in my last test
EDIT: And perhaps make it a little less "subtle"?
im currently tweaking the lighting parameters thats why it isnt released to the public yet
-
Ahhh nice, now I get it.
Soooo, is it so hard to code a fixed-distance from the hull? Since the engine already calculates the intersection between the beam and the hull, could one not calculate the point in the beam where it stands, say, 100m from it?
EDIT: alternatively, could it be possible to calculate the half-distance between the closest pixel on screen and the hull? Even if by "half-distance" one is measuring in actual pixels on-screen (thus not in real distance), the effect could be better. Or 2/3, or 4/5, I mean it could be testable.
-
i want to correct myself on that tube lights currently project light onto every target in range except the firing ship ( to save calculations about being "behind" the beam ).
What does this mean? A ship firing its own beams won't be lit by them? I'm thinking specifically of ships like the Hecate, where a tube light might look nice if it gets closer to some of the projections, or the Orion, when firing off a beam at a very acute angle.
I revisited the video, and I think your method of calculating light intensity based on distance looks pretty good. The washed-out effect only really shows up when there are 2-3 beams active, which makes sense; it's be equivalent to having 2-3 fluorescent lights lined up in the same orientation. You'll get soft light that bleeds together to look more uniform. It probably just needs more intensity to look normal.
Preview vid 2, at 0:12, makes me think that you're on the right track. 0:32? not so much.
-
Very impressive work! ;)
Is the attenuation for the lights hard-coded?
-
Preview vid 2, at 0:12, makes me think that you're on the right track. 0:32? not so much.
This relates to the point of view from which a beam is viewed. If the nearest beam pixel is perpendicular to the point where the beam hits the target, then the effect will be spot on. If, however (and most likely in many circumstances), the beam is skewed (not perpendicular to the targeted face), the nearest beam pixel will light the hull in a spot that is pretty far off the mark from where the burning spot is.
This is why I am asking if one could code a much closer distance between the light and the hull, to diminish this effect to the point where it is meaningless.
-
Right, regarding attenuation and integration:
Is your attenuation 1/r^2, or 1/r? It should be noted that for tube instead of point sources, using your method, attenuation is NOT 1/r^2. but exactly 1/r. (Recall point light is 1/r^2, tube light is 1/r, and planar light has no attenuation)
@ Luis Dais: I'm not sure I follow. Since he says his algorithm picks a pixel, then finds the nearest part of the beam to the pixel's spacial location, then by definition, that pixel is perpendicular to the beam.
Edit: Wait, I think I might know what you mean now. Firstly: as I understand it, there isn't any light spawned at any distance from the ship. If you will, there is one "light" that's pulled from the singular beam for each pixel on the screen. That means that you can't put the light closer to the ship, because there isn't any point light involved. The entire beam behaves as one, long light. The weirdness with the lighting actually kind of looks like too much specular behavior and too little diffuse behavior. The specular highlight would then be camera angle dependent, much like how a mirror works, and would sort of explain what we see at 0:32.
/making **** up >.>
-
Ah ok, I see where I misread his explanation now. Hmm, yeah I see that too much specular and too little diffuse would cause that, but I'm still amazed that he can pull that kind of "infinite line" lighting off from the start! So it's a perfect geometrical solution, and it's very cool stuff. It can even potentially be useful to create shadows.
For instance, if you make a check between the pixel point of the hull involved and the beam, and there's no intersection, then there is full light. If there is, then light = 0. It wouldn't be a perfect solution of course, and it may even create strange screenshots, but they wouldn't be inconsistent per se (no artifacts that I can foresee), and it would be generally just awesome!
Now, back to the specular/diffuse problem, perhaps a more agressive intensity, followed by an agressive attenuation might be the key. Now rigorously speaking, your attenuation numbers are true if the geometry of the beam and the plane are infinite (this is specially important for the plane example, since the beams may be simplified to be "infinite").
-
So i think i got it finally looks good i think
(http://img217.imageshack.us/img217/1210/screen0010w.png) (http://imageshack.us/photo/my-images/217/screen0010w.png/)
Just for explanation for the comments the beam is not infinite it stops at the hit point which was set back about 300 units before. This is now corrected plus intensity tuning. For some unexplained reason fs reduces the intensity of tube lights by about 9/10ths. Intensity can still be controlled by standard lighting command line parameters for those who wish a more "subtle" approach.
-
Beavis, this is the coolest thing I have ever seen (http://www.fortunecity.com/lavendar/douglas/140/bb70.wav).
-
It looks good. I'm not sure why nearly 100% of the light seems to react as specular, though I think that all other lights in FSO are like that anyways. Maybe it's also just the Colossus, which has fairly strong shine maps.
(I spy custom radar icons. Where did they come from?)
While you're at it, do you know if beam charge balls have lights before the beam is fired? If they don't, it might be something to look into.
-
Charging lights with intensity dimming ooooh shiny idea.
It looks good. I'm not sure why nearly 100% of the light seems to react as specular, though I think that all other lights in FSO are like that anyways. Maybe it's also just the Colossus, which has fairly strong shine maps.
This is because the light direction has some problems with the surface normals when the beam is perpendicular to the reflective plane and reduces the diffuse component. Im trying different things for correcting the direction, nothing worked so far ( artifacts sprung up at certain radii from the beam impact point cause of value issues). The problem is ideally to find the closest point on the beam line that is at the same time the vector with the greatest dot product to the reflected camera to pixel vector so a problem of finding the extreme of two values that are interdependent. I dont think there is a purely algebraic approach to this and the only thing I come up with is a brute force or raytracing approach which just isnt cost effective for this small an improvement. Im all ears for ideas though.
-
Ray trace really bad idea.
A hack is to spawn a point light at/near the point of impact. That idea sucks too for using up a light. I know.
I'm not sure I follow what you mean about all the vectors. The way I understand it, your beam lighting model radiates light ONLY orthogonal to a 1D line (only orthogonal because you get pixels to search for the shortest line to the beam, which is by definition a perpendicular line). If you intersect a plane orthonally to this beam, then light will fail to reflect off of it, unless normal maps create a reflective surface that is not parallel to the light. This will look like pitch black, with bright green lines on the normal map. If this is the case, I don't think the best approach to fix this is to find a way to pull a directional light vector that is not perpendicular to the beam, since the light intensity/attenuation will probably get all screwed up. Remember, it should be easy to simulate integrated light along a tube if you force pixels to get light vectors perpendicular to the tube and use (luminance/distance^1=lighting intensity). At least, I was taught that this is analogous to the integrated result for electric fields from a wire. However, as soon as you call light vectors that aren't normal to the beam, you can't use this simplification.
An idea to render the diffuse light is to ignore the position of the camera entirely. Since diffuse reflection is well, diffuse, it should appear almost the same regardless of where you're looking at it from. What happens if you multiply the pixel's diffuse map value to the appropriately attenuated beam light? Assuming that things work okay when the pixel finds a ray of light that is within the plane of the hull since there is no occlusion check, this could work. This seems like it'll require two passes though: one for pure specular highlights that is via what you have now, one for pure diffuse. I don't know if that's consistent with FSO rendering, or any rendering system in general, for that matter.
(I should let you know that I don't know any coding, so therefore don't really know what I'm talking about. My knowledge of the related math extends to first year vector geometry/matrices. I like bull****ting about graphics code only because it's an interest of mine and I hope to learn a bit about the theory behind it when people correct me)
-
I thought that "diffuse reflection" already worked the way you are describing it, at least in FSO and most game engines... I mean it's not specular, which does depend upon the viewer POV.
Your point about the orthogonal plane and the end result is pretty much spot on, I *should* have figured that problem earlier. I'm going to develop a little this small point, which explains a lot the renders that are shown here. It's simple, but hard to explain in words ;). Basically what happens is that the plane where the beam intersects with the hull is *never* really orthogonal to the beam, but at least slightly inclined with a certain angle. And the part of that surface that makes acute angles with the beam *is shown lighted*, while the other half of the plane *does not show lighted*, because those pixels are out of the range of the beam already (there is no perpendicular path to the beam anymore at these points).
This explains the above render, with the parts of the plane where this tube actually intersects with the plane, which is only the upper right part of it (due to the inclination of the plane).
This is at least as I understand it. A quick fix to this problem, if real, would be to extend the light tube some meters to the inside of the hull, so that the plane is completely lit (and not only the parts of the plane where the angle towards the light beam is acute).
-
Is there a possibility of making a fixed angle for the rays, instead of being perpendicular? That could just solve it if it's even possible.
-
(http://img580.imageshack.us/img580/741/diffuse.png) (http://imageshack.us/photo/my-images/580/diffuse.png/)
This is a diagram of the diffuse problem. Directly on the plane where the beam hits all generated light directions that are on the left side of the beam (cause the nearest point is the impact point, the beam stops there) are tangential to the plane. In the specular component this is rectified somewhat by adding the eyedirection which results in a beautiful cone like reflection which is exactly what we want. however the diffuse component as you said is generated by dot(normal,lightdir) which is in this case always zero. One solution would be to move the beam hitpoint away again from the hull which results in a specular blob cause it feels like a point light again. Other solution would be to dynamically move the nearest point back along the beam for the calculation of the diffuse component ONLY. But by how much? Keep in mind that this should handle beams that are parallel to the plane as well where this offset should be nonexistent.
-
Could we get a shot of the Ulysses as the beams fire? See if it reflects well off of that?
Looks freakin sweet, btw!!
-
(http://img834.imageshack.us/img834/3558/screen0019.png) (http://imageshack.us/photo/my-images/834/screen0019.png/)
-
So i now add an additional diffuse component that is dot (normal,-beamdir) which handles the case when the beam is perpendicular to the ship let me know what you think about this
(http://img577.imageshack.us/img577/5066/screen0020.png) (http://imageshack.us/photo/my-images/577/screen0020.png/)
-
I'm guessing we're now looking at the green hue that's underneath the specular highlight? If so, looks good and better than before, though it'd be better illustrated with a vid or a few stop-motion capture frames. I'd like to see how the light responds as the beamdir changes as the slash beam moves.
Btw, how is performance of this light? Will **** hit the fan and systems crash when the game maxes out its light slots on a beam disco show in the midst of 20 Karunas?
-
**** already hits the fan with 20 Karunas, sooooooo...
-
Speak for your self. I can run BP massive battle at 2 fps. No crashing, ever.
But yeah, bad example. What I mean to ask is how this will perform relative to the legacy system of spawning 3 point lights.
-
Concerning performance: I add 2 dot products , around 5 multiplication and about 10 or so additions to the shader. I dont think that its that big of a performance hit. But this will all be have to decide when i release and people get to try it.
And as requested vid:
http://www.youtube.com/watch?v=7YeZauWDKHI
-
Thanks for taking the time to make the video!
1. Holy ****. Looks much better than the screenshots suggested.
2. Love the light spooling effects. However, at 0:39, the light intensity is poorly synchronized to the shrinking plasma ball. There's also some weirdness to the position of the specular highlight there. It's like it's brightest a fair distance to the left of the ball, rather than surrounding the ball. Then again, it actually looks like an artifact resulting from lack of an occlusion check, so I'm not sure if it can be fixed, or if it's worth it to fix it.
3. This is a matter of personal preference, but I think it could do with a stronger diffuse component relative to the specular component. Perhaps going so far as to have diffuse being primary, and the specular for normal map detail and cone shine awesomeness. Are the two numbers tweakable independently by flags?
-
Can't we already control spec with a command flag?
I'm wondering, do we really need to start sub-controlling different spec elements with more command flags?
-
Thanks for taking the time to make the video!
1. Holy ****. Looks much better than the screenshots suggested.
2. Love the light spooling effects. However, at 0:39, the light intensity is poorly synchronized to the shrinking plasma ball. There's also some weirdness to the position of the specular highlight there. It's like it's brightest a fair distance to the left of the ball, rather than surrounding the ball. Then again, it actually looks like an artifact resulting from lack of an occlusion check, so I'm not sure if it can be fixed, or if it's worth it to fix it.
3. This is a matter of personal preference, but I think it could do with a stronger diffuse component relative to the specular component. Perhaps going so far as to have diffuse being primary, and the specular for normal map detail and cone shine awesomeness. Are the two numbers tweakable independently by flags?
1. I know, right?
2. I use the same percentage function as the render_muzzle_glow function. However I do agree that the sprite vanishes before the light is fully spooled down. Could be because of alpha blending of the sprite ill look into it.
And the specular thing is because the muzzle light is moved like 300 units into the beam so the lightdirection is less tangential ( the same problem i had with the beam ^^) i didnt change, was always like that. But if you move it closer you get a very small specular I tried already.
3. Specular component is controllabe by -ogl_spec and -spec_tube like always. Diffuse is not controllable.
-
-spec_tube, yes. But that won't change the relative contributions of diffuse light vs specular light. Yeah, it's a big nitpick, so I throw it out there more as a curious musing than a serious suggestion. Especially since none of the other light sources offer such customization.
Edit: ninja'd. :/
-
Au Contraire Mon Frère. -spec_tube only scales the specular color. It does change the relative contribution. You just cant scale the diffuse color it stays fixed.
-
Er yeah. My bad. I meant that having only that one tag does not allow customization of diffuse light vs specular light and total light intensity at the same time.
My onlie english sucks apparenlty.
-
I could have sworn there was a defuse tag too.
-
Nope. The closest there is is emissive light/ambient light, but that's nondirectional.
-
Concerning performance: I add 2 dot products , around 5 multiplication and about 10 or so additions to the shader. I dont think that its that big of a performance hit. But this will all be have to decide when i release and people get to try it.
And as requested vid:
http://www.youtube.com/watch?v=7YeZauWDKHI
The way the lights slowly fade up whilst the beam is charging looks very wrong imo. I think it should flash on instantly the moment it fires, and fade out as it finishes firing.
It looks sick though.
-
The way the lights slowly fade up whilst the beam is charging looks very wrong imo. I think it should flash on instantly the moment it fires, and fade out as it finishes firing.
It looks sick though.
Thats not representive of the current situation anymore. it now fades up to about 80% then jumps to 100% when the beam turns on try the build it really looks much better then in the video
-
Beam lighting is pretty fantastic. It's interesting that tube-lights need to be around 1 to be realistic, whereas they had to be quite a bit lower before to avoid being overpowering.
Not that that's a bad thing.
-
that's probably because point lights had a 0 constant attenuation which meant that as you went closer to the point light than the light radius the divisor got less than 1 which meant the the light was scaled upward which is BAD
-
Oooh, I see.
I bring it up mainly because most people will want to change their lighting flag if they want to have a look consistent with how it was prior. I've bumped my 0.75 up to 1.5 lol.
I'm not really noticing the jump in intensity that's supposed to happen at beam fire. Is that controlled by spec_tube or spec_static? It could just be that there are too many beams going on at once and I didn't notice something that is actually there.
-
muzzle lights are spec_static
-
Any way to up their own intensity relative to things like explosions, lasers, and stuff? Perhaps something in the shader?
-
nope, point lights are point lights are point lights. you cant expect to control every variable in the game with a cmdline or shadertweak sry