> I'll certainly do what I can to help this one along. However, I'm not > clear how this all ties in with the Rembrandt project. Are we in danger of > having to tear it all down and starting over?
I think it's fairly easy to unify shaders applied to geometry (models + terrain). Currently a Rembrandt shader computes material properties and then delegates the last step to an helper function : gbuffer_encode (https://gitorious.org/fg/fgdata/blobs/master/Shaders/gbuffer-encode.frag) We can imagine that this function (renamed to reflect more generality) could compute the final fragment color from material properties already computed and light source informations when used in the classical renderer. Different BRDF or lighting models are possible because Rembrandt has already the concept of material ID, allowing, for instance, to have water reflecting light differently than other kind of materials. This helper function will be chosen at run time using effect predicates and the link functionality of glsl programs. Sort of DLLs applied to shaders. Regards, -Fred ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
