Re: [Flightgear-devel] Color-shifts for textures
Hi Stuart, On Wednesday, January 23, 2013 21:52:49 Stuart Buchanan wrote: The current proposal that Thorsten and myself have been thinking about is that all of this is optional on the quality slider on the rendering dialog. So we absolutely will be supporting both, and users can balance frame-rate against eye-candy, as they do today. Nevertheless, we obviously want to be as efficient as possible, and personally speaking I have insufficient knowledge of modern graphics pipelines to know where the bottlenecks reside. Does that address your concerns? This kind of answer is the one that I expected to get at some point. Generally, I think that the major point in our kind of application gets lost. Think about the type of technology and why we are using this type of technology. We do currently use a rasterizer based approach which is delivered with hardware acceleration by either OpenGl or DirectX. And I think the reason we are doing this is that we reach the speed required for realtime simulations. REally if you are interrested in nice pictures no matter how long it takes, there are really convincing techologies out there. Global lighting integral equations give the most convining and most expensive pictures. Then ray tracing like approaches get more and more interresting as they can deliver great pictures down in the seconds range. At least for inside scenes and with a bunch of gpu's doing compute work. Outside ones are still much more problematic. Then there is that faky rasterizer based approach. That one has a lot of downsides but this is still the only aproach that can deliver pictures at deterministic 60 hz - if the renderer is not being crippled to be slow. At least some of the flightgear users need stable framerates over a not so small amount of screens. These might be genlocked to have a common buffer swap. So, you need some headroom if you do not want a missed frame everery second or so. Really: speed is the only reason not to use something that gives way better pictures by itself. If the priority is too much shifted on pretty pictures then it's better to look at a different project out there. That does not mean that it's impossible to render nice frames with a rasterizer. And there is a lot of technology out there which enables this great faky pictures where you do not recognize that its so faky. But what I saw lately - especially from this finish guy - is noting close there. He is extremely loud, argues with 'works for me' like arguments and does not listen to suggestions that would guide in a better direction. Let's take the uebershader like approach.That's really one of the worst ideas that you can have gpu wise. There are a lot of if's that are impossible to be optimized out since these are runtime configurable by a lot of uniforms. And thats actually the second bad point in this approach. So, just looking at the problem it must be clear that this is a not so good idea. Sure from a softwareengineering point of view having a configurable shader seems good. But for the purpose of having a fast renderer it is not - and remember if you are interrested in nice pictures at any (performance) price use an other technology. For our type of application, speed matters. Then there is the scattering stuff. That's great but I told him may be two years ago how this could be done efficiently. Now he presents something that he tells that needs to be inserted into any shader in any model. So it's just clear that he did not listen to any suggestion at that time. That would be ok if this would be optional in the sense that it does not impact what is there performance wise. But since this is all runtime configured by an uebershader with a lot of uniforms this is not the case. Any additional feature done in this way *does* impact everbody in several ways. Any additional uniform takes time to be set up in the driver. Any code that is in the shader and that cannot be optimized away at *link* time of the shader may take registers which affects the partitioning and the amount of paralell executed threads in the GPU. At least a notable amount of gpu's on the market can get register set limited at that point. Getting back to procedural textures, go on with what you planed. But keep in mind that you should not use resources just because you have a lot left. Think if you really need what you think you need. And if you really (again really) need this resource add it. Also please do not throw away the old style textures just because we have now that hot and spicy new technology. As also mentioned in a private mail to you, I will provide a different renderer sometime in the future where I aim to provide better isolation of this kind of renderer options so that people with very different aims can probably coexist better. Have a nice weekend Mathias -- Master Visual Studio,
Re: [Flightgear-devel] Color-shifts for textures
On 27 Jan 2013, at 16:44, Mathias Fröhlich mathias.froehl...@gmx.net wrote: As also mentioned in a private mail to you, I will provide a different renderer sometime in the future where I aim to provide better isolation of this kind of renderer options so that people with very different aims can probably coexist better. Just to say, supporting the option of different viewer / rasteriser front-ends is by far the best solution here, since there are different requirements for different use-cases and target users. Plenty of people are interested in the kind of effects Thorsten's uber-shader and atmospheric model can provide, but plenty of others care more about a solid 60Hz (or even higher), and still others would prefer a solution that works with the fixed-funtion pipeline. And then there's Rembrandt as yet another rendering configuration. My plan in parallel with / after 2.12 is to work with Mathias' HLA code to make this separation possible, unless of course he beats me to it :) James -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
