-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mathias Fröhlich wrote:
> On Thursday 30 November 2006 01:36, Tim Moore wrote:
>> Try http://www.bricoworks.com/moore/lightpt3.diff instead. A last-minute
>> typo disabled point sprites.
> This is still faster with point sprites reenabled?
I'm not sure about "faster" but, as far as I can tell, "equivalent." By
the way, it would be very nice to have some more timing information
available than just the frame rate. I don't know if the easiest way to
get there is to move to Producer so we can get its nice rendering stage
statistics, wait for Robert to duplicate that in his new osgViewer
stuff, do it ourselves, or what.

> 
> I do not want to remove the old implementation that was happening completely 
> on the GPU in favour to an CPU based one if we end up slower.
> 
> Anyway, can we keep the old implementation instead of just a plain OpenGL 
> point based one. That means the old one that used triangles that are backface 
> culled and draw points for the front side where two of them are transparent?
> 
I don't mind adding the old implementation back in as an option, except
for the VASI lights, where it really would have no advantage over the
OSG lights. One would lose some features, such as point size scaled by
intensity, fading alpha with distance, and blink sequence animations for
the approach lights.

> Like I stated before in some private mails I would like to have the osg 
> version only as an alternative to the old implementation if it is faster than 
> the GPU/triangle based one. May be not exactly the old implementation but an 
> implementation that does nothing on the CPU but does all lightging decisions 
> on the GPU.
I would like to see some comparisons between the two approaches on a
low-end machine. You may be overestimating the cost of the CPU based
approach and underestimating the costs of triangle approach. As I said
in private email, the old approach uses a fairly exotic rendering path
- -- polygons rendered in point mode with a texture environment -- which
very well may be done on the CPU on a "low-end" machine.

> And as also told before I would like to have an other alternative for the 
> main 
> usage where we still do that light intensity decision - together with more 
> advanced light texturing dependent on fog density, distance and  other neat 
> parameters - on the *GPU*. Just use a vertex shader for the view direction 
> dependence of the light and fragment shaders for more advanced halos. That 
> will require a newer OpenGL implementation and for that I believe we need to 
> keep a lighting version for older boards. Also this all happens in the *GPU*. 
> That has the advantage that it is probably way faster and even if it is about 
> at fast as on the CPU, it does not block CPU cycles that can equally well be 
> spent for more advanced physical models or better AI traffic or whatever we 
> need to do on the CPU.
> So on the longer term I will favour that shader based approach as default as 
> long as the GPU supports it.
Yes, I think that is a great project, but more work than I have time for
right at the moment. It would be good for people to learn about OSG's
support for shading programs *hint*hint* :)

> 
> For that we still need some factory methods that will provide now the old 
> implementation or the osg::LightPoint based one and later when I have the 
> time to merge my tests into simgear the shader based one.
> 
> So we need to he able to decide between implementations based on capabilities 
> of the GPU and settings from the user anyway. Can we set up together such an 
> infrastructure and put the old triangle based approach as other alternative 
> below?
"We?" :) Seriously, I would be happy to look at getting the OpenGL
extensions available from OSG and making that available to fg in an
elegant way, but goes way beyond to scope of light points, so for now
exposing the choice to the user is probably the best way. Automatically
benchmarking the user's machine and putting it into slow /fast
categories would be an interesting project too.

> In the long term I believe that we will reduce that back to two alternatives 
> again. The shader based and one of the low end card capable ones - whichever 
> of the low end card implementation is faster. For that decision we need 
> *both* up again and optimized well ...
I'll add back the old one and do the obvious optimizations.
> 
> I will look at the current patch that weekend.
Cool.

Tim

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFFbp5ReDhWHdXrDRURAl5xAKCqJsKXQ0IL84SwMINO+k822eAnyQCdHjQ0
sDNDGgKV0U9b1rEltT7Pixo=
=bmNW
-----END PGP SIGNATURE-----

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to