[Luis Dias]

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.

[Kolgena]

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

[Luis Dias]

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

[Valathil]

So i think i got it finally looks good i think



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.

[chief1983]

Beavis, this is the coolest thing I have ever seen.

[Kolgena]

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.

[Valathil]

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.

[Kolgena]

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)

[Luis Dias]

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

[Luis Dias]

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.

[Valathil]

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.

[G0atmaster]

Could we get a shot of the Ulysses as the beams fire?  See if it reflects well off of that?


Looks freakin sweet, btw!!

[Valathil]

[Valathil]

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

[Kolgena]

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?

[MatthTheGeek]

**** already hits the fan with 20 Karunas, sooooooo...

[Kolgena]

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.

[Valathil]

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

[Kolgena]

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?

[mjn.mixael]

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?