Dear Mathias, > But what I saw lately - especially from this finish guy - is noting close > there.
I continue to have a name (which is Thorsten), that name doesn't actually sound very Finnish, and that would be because I am actually German (I do live in Finland). There's no need to pretend you can suddenly talk over my head and I'm not on this list, or pretend that you just forgot my name because I'm so unimportant :-) Disagreements are no justification for rudeness. > He is extremely loud, argues with 'works for me' like arguments > and does not listen to suggestions that would guide in a better direction. It's pretty difficult to be 'loud' in an email, wouldn't you think? You argue also with 'works for me' type arguments - you just assume your needs and requirements somehow trump mine. Why would that be the case? I've stated a few times just when I start listening to suggestions - when they make any sense and there's convincing evidence that the suggestion really leads into a better direction. > Let's take the uebershader like approach.That's really one of the worst > idea that you can have gpu wise. Indeed (I could probably come up with worse ones though...). But we can all see where dedicated non-configurable terrain shader for every landclass got us - at some point we had two different fog models, so some terrain types could be seen twice as far as others, two different snow models with hard contrasts between pixel color snow and texture overlay snow... Here's how this looks: http://www.phy.duke.edu/~trenk/pics/textures.jpg Clearly, GPU optimization isn't everything, and maintainability, ease of use for the graphical artists and coherence are issues in practice for some of us. In the end, this is about delivering a working framework within the FG environment, not an idealized proof of concept. We don't have an infinite number of maintainers, we have a limited coherence within the developers, so it's much easier to lament that things aren't done in an optimal way than to make them optimal. > If the priority is too much shifted on pretty pictures then it's better > to look at a different project out there. Face it, Mathias - I'm part of this project, and I have the right to bring my own ideas in, regardless if you like them or not. I'm not just here to execute your plans for FG. > 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. You did no such thing, Mathias. You gave a completely incomprehensible, highly technical sermon here which I tried to figure out for an hour googling every third word or so and then gave up. You did not answer any follow-up questions, usually you just appear here, throw technical comments in and then disappear again. If you really want any of your comments to be taken into account, you should perhaps consider making some effort to make yourself understood and take the time to explain things. It's great to be knowledgeable, but that's only part of it - the ability to explain what you know in easy words to others is a very important other part. I promise I'll listen if you really want to try to explain and answer questions. > 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. You mean to say a shader which isn't even compiled takes away performance? (A non-functional shader doesn't throw a compile error unless it is actually switched on in the GUI, so they don't seem to be compiled up-front just in case). That doesn't smell like a problem of the shader design if for real, it smells like a problem of the framework. > 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. Sure, I admit - my secret plan was to turn FG into a raytracing engine and make everyone else miserable - you found me out :-) Isn't that a bit of a red herring? I can't recall anyone planning to use resources just because we have them. I do recall explaining that it's a balance between what resources to use - but since you forgot my name, you probably also forgot my arguments. I am usually very reluctant to use more uniforms or varyings and try to minimize their use - you'd see this if you compare my shaders with others in the repository. I may make many mistakes, but just burning resources for the sake of it isn't one of them. Best, * Thorsten ------------------------------------------------------------------------------ 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
