> If you want to know the altitude, you need to have the matrix that > transforms > from the current view position/orientation to the earths center. And you > need > to transform from cartesian space into the earth ellipsoid. The best you > can > do is to do this per vertex. And even that is way too much computation > for > that single altitude that you can just set when you set up the geometry. > The most efficient method is probably to set up a 4 vector plane > equation that > represents the sea level altitude horizontal plane in object > coordinates. This > plane needs to be updated when the cloud object moves significantly by > the cpu > code. In the shader you can then compute the distance to the plane in the > usual way. That would give an altitude per vertex which would be even > exact per fragment by correct interpolation. > > If you only need the altitude per cloud, put that scalar value in a > uniform.
That somehow seems way too complicated. We're currently rendering clouds to 45 km, my private hack does 75 km, in my wildest dreams I am speculating about 250 km, cloud altitude is always below 30 km - all these numbers are way smaller than the Earth radius, so a local Cartesian system and the first term of the Taylor expansion in curvature will always be enough to any sane accuracy. I have now a scheme that does seem to do the trick - high stuff and stuff towards the sun glows properly before lower stuff and stuff away from the sun. http://www.flightgear.org/forums/viewtopic.php?f=47&t=14755&start=15#p147240 The idea is: * compute the relative vector between eye position and vertex * get its z-component as altitude difference * pass the eye position altitude as uniform * add eye altitude to relative altitude - this is the uncorrected vertex altitude * use the known distance to correct for curvature to get the actual altitude (it's probably off by a few percent, but who cares?) I have the feeling there should be an even simpler way to do it, but after coordinate-system-crawling for 5 hours yesterday I'm simply not in the mood to try to find out. What derailed me for a while is that the shader doesn't do numerics to high accuracy - the small difference of two individually large numbers doesn't compute very well (I know it's a bad problem), and that screwed things up for a while, and so I thought the scheme itself was flawed, but I think I sorted that out as well. So, thanks for the input to everyone! * Thorsten ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
