Re: [Flightgear-devel] A plan for a 3.0 release?
On Wednesday 13 June 2012 12:05:42 Renk Thorsten wrote: Now, random vegetation seems to increase vertex count a lot, and this may well be not doable by just taking the code and applying it to the vegetation (it didn't work with clouds either). So it probably needs a dedicated approximation scheme making use of the fact that vegetation is drawn relatively close to the position and not 100 km distant to run at all. Given my framerate when switching on lightfields and random vegetation without lightfield shading, I'm not too optimistic :-( But worth a try. * Thorsten There is a simple solution to that. Move the work in the fragment shader. You won't be scene complexity bound, and you'll also have the correct depth available as: float fragmentDepth = gl_ProjectionMatrix[3].z/(gl_FragCoord.z * -2.0 + 1.0 - gl_ProjectionMatrix[2].z); (Currently, if taking depth info in the vertex shader for the trees, you need to do some ugly hacks to get the right depth, hacks that fail to work most of the times. ) As for performance concerns, yes, fragment operations might be slower than vertex ones for the same complex task, but they are generaly done on a limited amount of fragments that varies only with camera position/orientation and isn't adversely affected by high vertex count scenes. And the trend is for vertex count increase. Regards, Emilian -- 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
Re: [Flightgear-devel] A plan for a 3.0 release?
There is a simple solution to that. Move the work in the fragment shader. You won't be scene complexity bound, and you'll also have the correct depth available as (...) Right... but I need the projection of the vertex position into the sun direction in the horizon plane to compute light - that's the part which doesn't go easily into the fragment shader. Maybe we have enough varying to pass all raw vectors involved right through the vertex shader - then everything can be done in the fragment part? The problem might also be that similar to clouds, tree textures are transparent in places, and so the fragment part may be slower than expected (for clouds, moving too much into the fragment shader gets very slow for that reason). Thanks for the suggestion in any case - plenty of things need to be tried... * Thorsten -- 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
Re: [Flightgear-devel] A plan for a 3.0 release?
On Tuesday 19 June 2012 12:29:34 Renk Thorsten wrote: There is a simple solution to that. Move the work in the fragment shader. You won't be scene complexity bound, and you'll also have the correct depth available as (...) Right... but I need the projection of the vertex position into the sun direction in the horizon plane to compute light - that's the part which doesn't go easily into the fragment shader. Maybe we have enough varying to pass all raw vectors involved right through the vertex shader - then everything can be done in the fragment part? The problem might also be that similar to clouds, tree textures are transparent in places, and so the fragment part may be slower than expected (for clouds, moving too much into the fragment shader gets very slow for that reason). Thanks for the suggestion in any case - plenty of things need to be tried... * Thorsten Just look in the tree shader, there's a line there dropping the fragment if it hits the transparent part, so no there won't be any penalty incurred for the transparent bits in the trees. You can have the position, properly interpolated, in the fragment shader. You already have it in most shaders. And if you don't you just replace the current varying holding the result of your work in the vertex shader with a varying passing the position/ecPosition depending on what you need. Regards, Emilian -- 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
Re: [Flightgear-devel] A plan for a 3.0 release?
Fragment discard isn't anywhere near as free or beneficial as you think it is. It's pretty crippling on a lot of older hardware. -- 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
Re: [Flightgear-devel] A plan for a 3.0 release?
I'd add to this list * lightfields integrating well with other shaders. For example, I know that the random vegetation doesn't work with lightfield shaders, and the fix that Emilian put together to allow the random buildings to work was a workaround rather than a full fix. I think this is probably something you and I will need to work on together to fix. I have that one on my todo list, but my suspicion is that it's going to be a very tough one. The lightfields are rather computation-heavy on the vertex shader side (all the geometry relative to the sun needs to be done) and on my machine scale with vertex count. Now, random vegetation seems to increase vertex count a lot, and this may well be not doable by just taking the code and applying it to the vegetation (it didn't work with clouds either). So it probably needs a dedicated approximation scheme making use of the fact that vegetation is drawn relatively close to the position and not 100 km distant to run at all. Given my framerate when switching on lightfields and random vegetation without lightfield shading, I'm not too optimistic :-( But worth a try. * Thorsten -- 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
[Flightgear-devel] A plan for a 3.0 release?
Torsten's question about what the release number should be got me thinking a bit what I would expect from a 3.0 version, and I thought maybe I can put my outcome for a discussion: I think what makes the difference isn't so much new cool feature, but really a good and intuitive integration of the existing features. Say, in particular I'd like to see for a 3.0 (I'm focusing mainly on my area of expertise...): * lightfields and Rembrandt working together * lightfields properly supported by Basic Weather or even better * a redesign of the weather interfaces, basically going to the unified weather system people have been talking about - some ideas and brainstorming urgently needed! Then some fixes for long-standing, not really critical but annoying bugs * the current rain system still only works for Basic Weather * turbulence should affect YaSim and JSBSim the same way Then maybe some cool, but not so important features to make things complete: * lightning (and thunder?) for thunderstorms * windsocks moving with ground wind rather than wind at aircraft position Ideally, making full use of things we already have to present the best possible scenery * regionalized random building types * dedicated texture packs for the main vegetation zones * exploit the placement mask possibilities fully And then, ship 3.0 with (finally) the next edition of a world scenery release, so we can really present much better visuals! So, personally I'd like 3.0 to be a release that doesn't only have cool features, but also cool features which work basically everywhere and a release that doesn't have the current snags like 'this doesn't work with that, and the GUI is counter-intuitive and so on. Let me be the first to admit that it's much more fun doing my own stuff the way I like and then just merge it in. But if we can find consensus about any plan having to do with integration of new features and making it all work together, then I'm willing to reserve the majority of my coding time for working towards that goal. Would this be something to aim for in a 3.0 release? * Thorsten -- 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
Re: [Flightgear-devel] A plan for a 3.0 release?
On Sun, Jun 10, 2012 at 11:10 AM, Renk Thorsten wrote: Torsten's question about what the release number should be got me thinking a bit what I would expect from a 3.0 version, and I thought maybe I can put my outcome for a discussion: I think what makes the difference isn't so much new cool feature, but really a good and intuitive integration of the existing features. Say, in particular I'd like to see for a 3.0 (I'm focusing mainly on my area of expertise...): * lightfields and Rembrandt working together * lightfields properly supported by Basic Weather I'd add to this list * lightfields integrating well with other shaders. For example, I know that the random vegetation doesn't work with lightfield shaders, and the fix that Emilian put together to allow the random buildings to work was a workaround rather than a full fix. I think this is probably something you and I will need to work on together to fix. * a redesign of the weather interfaces, basically going to the unified weather system people have been talking about - some ideas and brainstorming urgently needed! Agreed. And then, ship 3.0 with (finally) the next edition of a world scenery release, so we can really present much better visuals! So, personally I'd like 3.0 to be a release that doesn't only have cool features, but also cool features which work basically everywhere and a release that doesn't have the current snags like 'this doesn't work with that, and the GUI is counter-intuitive and so on. Let me be the first to admit that it's much more fun doing my own stuff the way I like and then just merge it in. But if we can find consensus about any plan having to do with integration of new features and making it all work together, then I'm willing to reserve the majority of my coding time for working towards that goal. Would this be something to aim for in a 3.0 release? +1 -Stuart -- 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
