[Dark RevenantX]

Oh, that can be faked in all sorts of ways.  What manner of accuracy/realism would you want to go for?  The quick and dirty ways look pretty good and are comparatively cheaper (for example, you give the shader a preset texture with the camera flare textures and a HDR map (or if you want to get fancy, a Z buffer as well), then use a lookup to the other side of the HDRmap/depthmap to see where to reveal/transform the texture and/or draw flare bits) but the really accurate ways are worse than (and definitely related to) Bokeh calculations on DOF.

I assumed you wanted something else because the pilot's POV is usually an eyeball, not a camera lens.  Anyway the method I showed you doesn't only use points as flare sources; there are examples of entire stained glass windows or a close-up candle flame showing larger, shaped, complex flares.  The primary input to the shader would be a full RGB texture.

[Valathil]

im partial to seperating cockpit view lensflares and external camera flares and use two different algorithms so youll actually see a difference

[Dark RevenantX]

All you'd really have to do is change the shape of the eyeball filters used in the shader and change up some of the math, and add some way to offset the various steps in space so you can see them telescoping out rather than overlapping.  If you can write the shader in the 2nd paper (it's based on the 1st paper) you can then modify it for camera lenses.

This is probably the best solution I can think of.  I'm not an expert but I have programmed graphics engines before, so I probably have a better idea than most on this forum.

[Valathil]

I would wish for a pure screenspace effect no additional geometry needed.

[Dark RevenantX]

You have to supply some sort of static filters to the shader to use for the camera/eyeball effects to create their shapes and properties.  What I meant between having different filters for eyeball and camera is basically just having two shaders that a SEXP can switch between, one that simulates an eye and another that simulates a camera.  I don't think the papers I posted require anything beyond some precomputed (read: STATIC) eyeball/camera data and a HDR texture (containing the bright stuff like beams) to make the effect.  The whole shader could be made with two parameters if you were so inclined.

However, like the Bokeh effect, you may find that taking load off of the shader and passing it more to the CPU (i.e. rendering sprites the old fashioned way) actually improves performance.  The fastest implementation of the Bokeh DOF is to use a shader for the gaussian blur and then overlay polygonal sprites on bright points.  It's much faster than a per-pixel convolution overtop the entire scene, which a completely-GPU-bound Bokeh effect would need.



You could render to a float target to begin with and not have a separate HDR map at all; just render the beam at a luminosity higher than everything else in the scene.  However I have no idea how the renderer is set up, only that you recently changed it to be unified under a G-buffer.

[Valathil]

First draft of glowpoint.tbl https://docs.google.com/document/d/1Q736btTmHytE9FAPsV_QkZ_8WJk7vIbIt_zvGiiKYnA/edit

[Dragon]

Those are per-bank overrides, what about types? I don't see any value for overriding the glowpoint type either. Also, what $Name: is for?

[Valathil]

$Name is for identification of the preset so you can assign it to banks in the ship.tbl.
Is Type Override really needed? I never saw anybody use Type 1 glowpoints but i guess it could be added for completion sake.

[Dragon]

So, does this means you're not going to use glowpoint types afterall? I wanted to be able to assign the presets in POF using that value. That's the unused value in POF data I've been talking about all the time. In fact, this syntax would more or less work for a type definition, just add an option to replace $Name with $Type, or maybe even use them together for a multipurpose preset. The priority order would go: POF data -> Type Definition -> Override. In short, you're able to assign presets in a model as well as in a table, but the table would override the POF data.

The point is to allow a modder to make model glowpoints act more or less consistently across multiple mods, as long as they follow some common layout of glowpoints.tbl (as with most things, a glowpoints.tbl from mediavps will most likely become such a "convention").

Also, would that be possible not to remove the old, model-based syntax? The reason is pretty much the same as above (well, that, and it seems that BP added this syntax to every single glowpoint bank on every ship bigger than a bomber, making changing them back a bit of a chore ).

[The E]

Also, would that be possible not to remove the old, model-based syntax? The reason is pretty much the same as above (well, that, and it seems that BP added this syntax to every single glowpoint bank on every ship bigger than a bomber, making changing them back a bit of a chore ).

What has been committed in can be reverted out. I vote for a complete removal of the old way.

[mjn.mixael]

Also, would that be possible not to remove the old, model-based syntax? The reason is pretty much the same as above (well, that, and it seems that BP added this syntax to every single glowpoint bank on every ship bigger than a bomber, making changing them back a bit of a chore ).

What has been committed in can be reverted out. I vote for a complete removal of the old way.

Agreed. The proposed table looks good to me.

[Axem]

I hate to seem like I'm trying to wiggle in a feature request, but while we're talking about glowpoints, with all of these changes, can we also have glowpoints be able to fade in and out as they turn on and off instead of being completely binary?

If that's a feature for another day, then so be it.

[chief1983]

I hate to seem like I'm trying to wiggle in a feature request, but while we're talking about glowpoints, with all of these changes, can we also have glowpoints be able to fade in and out as they turn on and off instead of being completely binary?

If that's a feature for another day, then so be it.

Dang, now I'm picturing one of those creepy radio tower red fading lights in the fog.  Could do some really atmospheric stuff with fading glowpoints.

[mjn.mixael]

Oh yes... I'd love this for the HTL Comm Node.

[jr2]

You're supposed to be alone in the nebula and then the glowpoints of some massive warship slowly fade in.  It doesn't show up on sensors, and your ship can't see it on sensors either. You are ordered to investigate.  Right as it seems you may be able to obtain visual confirmation, the lights snap off. 

[Kobrar44]

Also, would that be possible not to remove the old, model-based syntax? The reason is pretty much the same as above (well, that, and it seems that BP added this syntax to every single glowpoint bank on every ship bigger than a bomber, making changing them back a bit of a chore ).

Model-based syntax was never committed so I don't think there is any reason for maintaining it.

[MatthTheGeek]

I did the BP glowpoints, and I am ok with moving everything to the new syntax.

[Valathil]

http://youtu.be/-jWk3MxQJv4?hd=1

PROGRESS!!!

[Luis Dias]

Any chance glowpoints can cast shadows? That video is all sorts of awesome, but at times it feels not as light, but as a paint of green invading (and leaving) the mesh.

[Valathil]

1. The green wasn't the best color to demonstrate with.
2. Shadows are a possibility tho it might have too big of a performance impact.
3. Before anyone asks: Volumetric light cones will not be done. By me.