Archived

This topic is now archived and is closed to further replies.

lens flare effect

This topic is 5798 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

hi all, i am trying to code a lens flare effect. i have a main flare wich moves in the background. after normalizing the main flare vector i use this vector and multiply it by different scalars and put at this position new billboarded flare textures. now my problem is that i dunno how to check if the main flare is covered by geometry. if so i wanna fade the lens flare effect down smoothly. i heared about several different technics to achive this efefct, one is raytracing the other is just reading the z-buffer. but i dont know how to do this and maybe i have not enought mathematical background who knows... so anybody can point me in the right direction. maybe some example code.(btw i use opengl api) best regards trigger

Share this post


Link to post
Share on other sites
If you want to use raytracing, you calculate the ray from the camera to the light source. If it hits your geometry, the lightsource is obscured. There should be tutorials about raytracing somewhere. The problem is the speed...
You may also read the z-buffer. You call a gluProject (I think this is the proper function) of your lightsource position after rendering is finished (glFlush), and then read out the zBuffer at that position. But reading the zBuffer is a no-no. First of all, the programm will stall, as the whole scene needs to be rendered before you can read the zBuffer. And the second problem is that it might not work on some graphics cards. I think that a kyro has no zBuffer at all, and thus it will not work.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
theres another thing you can do too.. read the framebuffer.

transform your "sun" position into screen space..i.e. figure out what pixels, if your sun was visible, would hold. have your sun be a solid color that would be easy to check like white. check the framebuffer, from the previous frame is fine..a frame delay for this type of an effect is more than acceptable, at the location you think the sun should be. if you find your suns color, than draw your lens flare effect.

improvements on this can be a chunk of code that ramps the intensity of the lens flare so it doesnt just "pop" on and off. changes to the effect itself based on the "coverage" of your sun. ie if you know your sun is a 3x3 pixel space object and when you check the framebuffer only the upper left corner pixel is your sun you can do the appropriate thing to your lens flare..

Share this post


Link to post
Share on other sites
I am quite sure that they do it by raytracing. Reading out the frame or backbuffer will not work on some graphics cards (either be incorrect or too slow). How the raytracing is done, depends on the datastructure of your mesh. I think most use a bsp tree for indoor levels and an octtree for outdoor levels to calculate the intersection.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Someone please answer this. Why do people put lens flares in games, especially first person games. If you are supposed to see things from a first person perspective then you would be looking through eyes, not a camera. I have never seen a lensflare in real life, only in movies becuase of the camera lens. What is the point in reproducing this, it is less realistic.

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
If you are supposed to see things from a first person perspective then you would be looking through eyes, not a camera. I have never seen a lensflare in real life, only in movies becuase of the camera lens. What is the point in reproducing this, it is less realistic.

wow, i never thought of that...
hmm... they must just be showing off...

--- krez (krezisback@aol.com)

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by trigger
hmmm,

i still wonder how professionals do it ?)


i am a professional, for midway home entertainment, and weve always just read the framebuffer. _DarkWing_ is correct in that youve got to be careful reading it. performance can tank if you dont do it right.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster

is this before or after you''ve linked the photoshop.lib?

Share this post


Link to post
Share on other sites
quote:

i am a professional, for midway home entertainment, and weve always just read the framebuffer. _DarkWing_ is correct in that youve got to be careful reading it. performance can tank if you dont do it right.


So how is it done correctly?



Moe''s site

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
me telling you exactly how we did it wouldnt do you any good. different engines have different weak points. we know where our
weak points are and we work around them, you need to do the same.
if you get something working and its slow, figure out whats wrong.

Chock: yeah, you could send a ray from the camera to the "suns"
location and do a collision check with the world. this is going to
be very expensive, cause youve got to do poly/ray intersection
tests potentially across your entire world grid. the framebuffer or
z-buffer comparison approaches are definitely your best bet.

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster

is this before or after you''ve linked the photoshop.lib?




l0lz0rz...

Sorry that was just funny sorry for the flaming here :D

Share this post


Link to post
Share on other sites
Yeah.
What are you doing ?
Depending on your purpose, you can either use stright lens flare or you can blur the sun.

Blizzard Worlds of Warcraft has a really great lens flare that look kinda real life.
However, most/alot of the games out there just use a "camera" lens flare regardless of circumstances.

BTW, I have done a digital photo of the sun; if anyone wants a copy, email me. its pretty interesting.

Bugle4d

Share this post


Link to post
Share on other sites
To whoever asked, lensflares are included in a game to simulate brightness. With standard techniques, there is usually a "maximum brightness" you can achieve on the screen, ie. bright white. This is not as bright as the sun (obviously).

If you simulate a lens flare, the eye is tricked into thinking the sun is brighter than it actually is.

I don''t know for certain but I think Medal of Honour uses a "haze out" system, whereby the image overall gets whited out as you look at the sun, which is more realistic than a lens flare.

Either way, both methods are simply trying to fool the eye.

cheers,

Share this post


Link to post
Share on other sites
The problem I am having with my flare effect is testing if the sun (or light source) itself is on the screen. I need to figure out how to convert the 3d world space coordinate of the sun into a 2d screen space. If anyone could help me out with this, feel free to post at:
http://www.gamedev.net/community/forums/topic.asp?topic_id=74303

Moe''s Site

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
1)transform the position into the cameras frame of reference..
this entails mutipling the position you want to check by the
cameras matrix.

2)take the resultant vector..which is now relative to the camera..
and multiply it by your projection matrix. the resultant vector
is now screen relative.

3)divide the elements of the vector by the w component of the
vector (which can be invisioned as the z-depth, but from the
screens point of view, not the cameras.)
you should now have a 0 to 1 screen relative position in the
x and y portions of the vector at the end of 3.

Share this post


Link to post
Share on other sites
ok,

i got this 3d space to 2d screen coordinat thingie done. now i just need to find a good way to fade the lensflare effect smoothly up/down when the lightsource aka mainflare disapears.. maybe the professionals under us can help with their experience

best regeards
trigger

Edited by - trigger on January 30, 2002 2:41:30 PM

Share this post


Link to post
Share on other sites
quote:
Original post by freshya

If you simulate a lens flare, the eye is tricked into thinking the sun is brighter than it actually is.




Um.... I don''t know about that. Lens flares are just that, lens flares, they occur because of imperfections in the lens.

Fade out is what tricks the eye (brain really) into thinking that you are looking directly at a bright light source.

D.V.

Carpe Diem

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
its simple really..

have your lens flare effect be a state machine.

so the first frame that your sun is "visible" your
lensflare code is actually running through its "fade in"
state. so if your in the "fade in" state and the sun
disappears you drop into the "fade out" state. if
your sun is visible when the "fade in" is complete you drop into
the "lens flare on" state. etc.etc.


Share this post


Link to post
Share on other sites
quote:

Um.... I don''t know about that. Lens flares are just that, lens flares, they occur because of imperfections in the lens.



When the eye sees a lens flare, your brain says "gee, that looks like every photo I''ve ever seen of a bright light. Therefore, it probably is a bright light."

Share this post


Link to post
Share on other sites
In DX8 there is a way to render a primitive, and get returned if any z-buffer tests were returning true.
Its not supported by many cards, but it support is there, use it.
I dont know if there is an opengl-extension which does the same.

If you can query the card by direct support, do it.
It you cant, just use the raytracing.

1) Octree speeds things up extremely
2) if octree node isnt empty, use bounding-sphere to determine visibility
3) if bounding sphere hits ray, do the plane-tests

** if you want to fire more than one ray, to determine "how much" of the light is visible (-> fade the flare in and out at object edges) you can use a "shadow-cache".
just remember the surface that gave the last successful shadow, and test this one first.

** you dont need to know the exact location of the intersection, you just need to know if it is "before the light" or "behind the light". that should be faster to calculate.

** one second-last thing on "dont query the z-buffer without explicit support": there are cards out there that dont use a z-buffer or w-buffer for the whole scene. by reading the z-buffer you force them to generate a z-buffer for the entire screen(!) which is usually very slow. kyro/kyroII are good examples for this.

** one last thing on this: DX8 only supports one (!) lockable (and therefor readable) z-buffer format, ???D16_LOCKABLE, and SDK says this one can be very slow on some hardware. further youre limited to 16bit depth-buffer.


--- foobar
We push more polygons before breakfast than most people do in a day

Share this post


Link to post
Share on other sites