> Removing the rainbow effect spoils the highly polished aluminium effect on > the b29 and the Lightning F1.
As I said, I don't plan to remove it for good. Quoting myself: " in any case a 2d texture lookup call seems an overkill for a simple 1d color table, so I plan to replace that by a function eventually" I might add 'this will make it quite a bit faster, as it is a very simple function' - so I believe this should be done anyway everywhere the rainbow is used. I am working hard, but don't expect everything to be 100% on the first commit of a new feature. > It is also incompatible with AO effects. Will > this all work with non-nVidia cards/drivers? I believe I've seen screenshots of terrain overlay textures working just fine on ATI cards. Likewise, functions rather than texture lookups work just fine - what counts in the end is a number, the shader doesn't really care if this is calculated or read from texture. The four websites I have studied regarding conditional texture lookups agree that textures can be looked up conditionally on a uniform, not on a varying. Do you see actual reasons for concern, or is this just stabbing in the dark? Not sure why a grain overlay would be incompatible with AO - care to elaborate? My understanding is that we don't have any AO outside of Rembrandt, and a grain would not be intended to carry pre-computed shadows, that's what the base texture is for. > The grain effect you proposed did not gain much if any support from > developers. Do we need to go down this road? No, we don't have to. Like many things, overlay textures and the grain effect are just something I believe have incredible potential. The grain effect on terrain is awesome - without going dds or using huge textures, you can create 15 cm sized terrain resolution everywhere. So, let's give it a few months of testing, see if folks can not use it to good effect - the 5 lines are easily removed from the shader if the potential doesn't materialize. > We are breaking more and more > for minimal gains. I beg to disagree on two counts. First of all, this is a net acceleration. I think currently the ubershader isn't structured well since it unconditionally looks up lots of textures, most of which aren't needed if you use, say, reflection or normal map only - restructuring the shader to not read unused textures and to evaluate as function what can be evaluated as simple function will speed things up. Second, having a technique to achieve 25 times the resolution for 2 times the texture memory isn't a minimal gain. It's visually way more powerful than the rainbow. So we're actually getting more bang for the buck. > Did we ever restore the wake effect on the Carrier > with Atmospheric Light Scattering? Well, we never had it running in the first place, so there can be no talk about restoring it. Someone just has to write it. Presumably that someone will eventually be me, but I have to ask your forgiveness of I priorize things which interest me personally. I mean, it's not like there's something taken away from you... There's two rendering frameworks left in which everything works as you're used to, surely we can afford to have one of three going ahead and trying for a few experimental new features rather than re-doing every effect in the others? Cheers, * Thorsten ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel