Re: [Flightgear-devel] Color-shifts for textures
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,
Re: [Flightgear-devel] Color-shifts for textures
On Monday 28 January 2013 08:02:14 Renk Thorsten wrote:
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).
No, I think what he meant is that (without me ever even seeing shader code)
something like:
if (enable_light_scattering) {
a = b + c;
}
compromises performance, even if light_scattering is disabled because the
compiler would assign registers to this code (the a = b + c), even though it
will never be executed. These registers could be used to more efficiently
execute the code that actually runs.
Stefan
signature.asc
Description: This is a digitally signed message part.
--
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
Re: [Flightgear-devel] Color-shifts for textures
No, I think what he meant is that (without me ever even seeing shader
code)
something like:
if (enable_light_scattering) {
a = b + c;
}
compromises performance, even if light_scattering is disabled because the
compiler would assign registers to this code (the a = b + c), even
though it
will never be executed. These registers could be used to more efficiently
execute the code that actually runs.
Well, yes, that I know - this is why the performance/quality steps in the
framework utilize mostly different shaders rather than one shader with
if-statements.
But we were talking about *optional* usage of the framework making things worse
for everyone else, and none of the shaders concerned are even compiled unless
they're switched on.
* 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
Re: [Flightgear-devel] Color-shifts for textures
On Monday 28 January 2013 08:46:02 Renk Thorsten wrote: Well, yes, that I know - this is why the performance/quality steps in the framework utilize mostly different shaders rather than one shader with if-statements. But we were talking about *optional* usage of the framework making things worse for everyone else, and none of the shaders concerned are even compiled unless they're switched on. Sounds to me like this discussion could use some more concrete examples to make sure all involved understand the things said and talk about the same. Mathias, could you please give examples of the code you were talking about? Stefan signature.asc Description: This is a digitally signed message part. -- 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
Re: [Flightgear-devel] Color-shifts for textures
Ah, now I understand what Mathias is after: 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. This paragraph has nothing to do with what is actually happening. 1) The 'ubershader' for _models_ (model-combined-deferred.eff and ubershader.vert/frag) has not been introduced by myself but by Frederic Bouvier and Gijs de Rooy with major additions and revisions by Emilian Huminiuc and Vivian Meazza 2011 (says so in the shader code). That shader requires to insert generate tags into each model which uses normal maps. The shader is optional, i.e. it is not compiled if model shader quality is set to zero. It is configured by a lot of uniforms (really a lot more than I ever used for terrain). My own contribution with regard to this shader is just to change the light and fog functions, I did not otherwise alter its design. However, since there's lightmap, reflection map, normal map and dirt map, there are potentially 15 different combinations of dedicated shaders which are not configured by uniforms, it seems to me there may be a maintenance issue to consider and it makes sense to do it that way. I did not come up with the need to modify each model, that is a property of the original shader. Mathias, you picked the wrong audience. 2) The terrain 'ubershader' (terrain-haze-detailed.vert/frag and terrain-haze-ultra.vert/frag) is my own work. These are two quality levels of procedural *terrain* texturing with terrain-haze.vert/frag being the 'bare' light scattering framework without any terrain effects, just modifying light and fog. This shader is very different from the model ubershader and does *not* require any insertion or modification of any model. All of these shaders are only compiled if the respective quality level is actually used and atmosperic light scattering is actually checked. 3) terrain-haze-detailed.vert/frag still has if-clauses linked to quality level in - however the plan (made on this list) is to take them out as I recognize it doesn't help for performance. This has largely been done in terrain-haze-ultra.vert/frag already. It would have been 5 minutes effort for Mathias to take a look into our effect files to see how all this is actually implemented and to realize that none of the shaders being discussed here is compiled unless this is asked for by the user. But it would appear his criticism is not based on any understanding of the situation, but just on his interpretation of bits and pieces of messages out of context. So, I will disregard it as unfounded. Mathias, please next time have a look at what you are against before you start writing. Thanks, * 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
Re: [Flightgear-devel] Color-shifts for textures
On Monday, January 28, 2013 09:27:53 Renk Thorsten wrote: Ah, now I understand what Mathias is after: 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. This paragraph has nothing to do with what is actually happening. 1) The 'ubershader' for _models_ (model-combined-deferred.eff and ubershader.vert/frag) has not been introduced by myself but by Frederic Bouvier and Gijs de Rooy with major additions and revisions by Emilian Huminiuc and Vivian Meazza 2011 (says so in the shader code). That shader requires to insert generate tags into each model which uses normal maps. The shader is optional, i.e. it is not compiled if model shader quality is set to zero. It is configured by a lot of uniforms (really a lot more than I ever used for terrain). My own contribution with regard to this shader is just to change the light and fog functions, I did not otherwise alter its design. However, since there's lightmap, reflection map, normal map and dirt map, there are potentially 15 different combinations of dedicated shaders which are not configured by uniforms, it seems to me there may be a maintenance issue to consider and it makes sense to do it that way. I did not come up with the need to modify each model, that is a property of the original shader. Mathias, you picked the wrong audience. Just to set things straight, models don't need to be modified. The local effect inheriting from model-combined*.eff needs to have those, and this is a workaround to Flightgear not handling graciously untextured models fed to the binormal/tangent generator (by this I mean FlightGear simply segfaults). and this requirement has been in the associated documentation for a year and two full releases Regards, Emilian -- 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
Re: [Flightgear-devel] Color-shifts for textures
On 28 Jan 2013, at 10:41, Emilian Huminiuc emili...@gmail.com wrote: Just to set things straight, models don't need to be modified. The local effect inheriting from model-combined*.eff needs to have those, and this is a workaround to Flightgear not handling graciously untextured models fed to the binormal/tangent generator (by this I mean FlightGear simply segfaults). and this requirement has been in the associated documentation for a year and two full releases Uh, wouldn't it be simpler to fix the segfault? :) It's the first I heard of 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
[Flightgear-devel] Default shader level for 2.10
Heads up: After some discussion / observation, I am going to change the default shader level for 2.10 (and probably next) to '1' instead of '3' '3' is causing folks with underpowered hardware to die, and not realise there's a setting they can tweak. I'd rather we make the default setting pessimistic, since the GUI option is now simple and clear than to Stuart's work. Please don't suggest fancy systems where we look at the GL driver/vendor strings and guess a default shader level, I want a low-risk change for the release branches :) Comments / objections? Regards, 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
Re: [Flightgear-devel] Default shader level for 2.10
After some discussion / observation, I am going to change the default shader level for 2.10 (and probably next) to '1' instead of '3' (...) Comments / objections? Complete agreement, after looking at the Intel and Mac problems in the forum, I was about to suggest the same thing. * 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
Re: [Flightgear-devel] Default shader level for 2.10
Agreed, though I think the GUI is Gijs' work rather than mine. -Stuart -- 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
[Flightgear-devel] Ati viewport bug
http://code.google.com/p/flightgear-bugs/issues/detail?id=385 Is about a problem with the viewport behaving very oddly, in certain Ati catalyst drivers. A kind person has worked out a hack, which fixes the issue, or at least avoids it. It add an empty, pre-render camera to the scene, which I assume forces some state which otherwise gets skipped in the Ati drivers. If anyone has any strong opinions about applying the hack to the 2.10 release branch, let me know. I'm currently undecided - it *is* a hack, but it fixes a real and long-standing bug, and the cost to everyone else should be zero. Regards, 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
Re: [Flightgear-devel] Ati viewport bug
Any chance to wrap this into something like
if( true == getprop(/sim/use-ati-hack) ) {
addTheEmptyPrerenderCamera();
} else {
doNothing();
}
Am 28.01.2013 18:56, schrieb James Turner:
http://code.google.com/p/flightgear-bugs/issues/detail?id=385
Is about a problem with the viewport behaving very oddly, in certain Ati
catalyst drivers.
A kind person has worked out a hack, which fixes the issue, or at least
avoids it. It add an empty, pre-render camera to the scene, which I assume
forces some state which otherwise gets skipped in the Ati drivers.
If anyone has any strong opinions about applying the hack to the 2.10 release
branch, let me know. I'm currently undecided - it *is* a hack, but it fixes a
real and long-standing bug, and the cost to everyone else should be zero.
Regards,
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
--
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
Re: [Flightgear-devel] Ati viewport bug
On 28 Jan 2013, at 19:09, Torsten Dreyer tors...@t3r.de wrote:
Any chance to wrap this into something like
if( true == getprop(/sim/use-ati-hack) ) {
addTheEmptyPrerenderCamera();
} else {
doNothing();
}
Yes of course, that's probably wise.
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
Re: [Flightgear-devel] Ati viewport bug
On 28 Jan 2013, at 19:09, Torsten Dreyer wrote:
Any chance to wrap this into something like
if( true == getprop(/sim/use-ati-hack) ) {
addTheEmptyPrerenderCamera();
} else {
doNothing();
}
On Mon, Jan 28, 2013 at 4:42 PM, James Turner wrote:
Yes of course, that's probably wise.
This does mean that the default behavior is still broke for the people we
are trying to help with this, but it at least offers a fix for anyone who's
willing to ask (or hunt through the email archives.)
Curt.
--
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
--
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
Re: [Flightgear-devel] Ati viewport bug
On 28 Jan 2013, at 22:52, Curtis Olson curtol...@flightgear.org wrote: On Mon, Jan 28, 2013 at 4:42 PM, James Turner wrote: Yes of course, that's probably wise. This does mean that the default behavior is still broke for the people we are trying to help with this, but it at least offers a fix for anyone who's willing to ask (or hunt through the email archives.) Curt. Right - my impression is the hack is zero-impact for non-affected people, so making it on by default is a possibility, but I really don't have a handle on how widespread the bug is - the forums and IRC aren't full of people screaming about it, but equally it has been mentioned several times. I'm going to add the code, bracketed by a property test, and default it to off on the release branch, and to 'on' in 'next', **temporarily**. If anyone running next sees any issues due to the code, they can report them and we will get some data-points about if it's truly zero-impact for 'everyone else' without jeopardising the stability of the release code. And flipping the default property value on the release branch (even for a 2.10.1) will still be an option. 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
Re: [Flightgear-devel] Color-shifts for textures
On Monday, January 28, 2013 09:27:53 Renk Thorsten wrote: Ah, now I understand what Mathias is after: 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. This paragraph has nothing to do with what is actually happening. 1) The 'ubershader' for _models_ (model-combined-deferred.eff and ubershader.vert/frag) has not been introduced by myself but by Frederic Bouvier and Gijs de Rooy with major additions and revisions by Emilian Huminiuc and Vivian Meazza 2011 (says so in the shader code). That shader requires to insert generate tags into each model which uses normal maps. The shader is optional, i.e. it is not compiled if model shader quality is set to zero. It is configured by a lot of uniforms (really a lot more than I ever used for terrain). My own contribution with regard to this shader is just to change the light and fog functions, I did not otherwise alter its design. However, since there's lightmap, reflection map, normal map and dirt map, there are potentially 15 different combinations of dedicated shaders which are not configured by uniforms, it seems to me there may be a maintenance issue to consider and it makes sense to do it that way. I did not come up with the need to modify each model, that is a property of the original shader. Mathias, you picked the wrong audience. 2) The terrain 'ubershader' (terrain-haze-detailed.vert/frag and terrain-haze-ultra.vert/frag) is my own work. These are two quality levels of procedural *terrain* texturing with terrain-haze.vert/frag being the 'bare' light scattering framework without any terrain effects, just modifying light and fog. This shader is very different from the model ubershader and does *not* require any insertion or modification of any model. All of these shaders are only compiled if the respective quality level is actually used and atmosperic light scattering is actually checked. 3) terrain-haze-detailed.vert/frag still has if-clauses linked to quality level in - however the plan (made on this list) is to take them out as I recognize it doesn't help for performance. This has largely been done in terrain-haze-ultra.vert/frag already. It would have been 5 minutes effort for Mathias to take a look into our effect files to see how all this is actually implemented and to realize that none of the shaders being discussed here is compiled unless this is asked for by the user. But it would appear his criticism is not based on any understanding of the situation, but just on his interpretation of bits and pieces of messages out of context. So, I will disregard it as unfounded. Mathias, please next time have a look at what you are against before you start writing. Thanks, You may be right that I did not pick the exactly right person for every line of code. But I also did not get the completely wrong one as you never cared for the state of the art even if being pointed to. If you think that you are right just by being the last one in the mail thread than you are actually very wrong. That just does mean that you have probably the most sloppy job so that you can write more mail than others. I am after technically superior stuff not after fighting for that. Mathias -- 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
Re: [Flightgear-devel] Color-shifts for textures
You may be right that I did not pick the exactly right person for every line of code. But I also did not get the completely wrong one as you never cared for the state of the art even if being pointed to. Quoting myself: 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. Sums it about up. If you think that you are right just by being the last one in the mail thread than you are actually very wrong. That just does mean that you have probably the most sloppy job so that you can write more mail than others. I am right because the problem you refer to (i.e. users selecting a low quality level still being affected by performance overhead) doesn't exist in realityfor terrain because we compile a new shader for every quality level. Rather than admitting that and going on from there or taking into account any of the other arguments made, you turn this into a 'but you aren't right in any case' type of argument and rant about my 'sloppy job'? Is this really an adult conversation? I am after technically superior stuff not after fighting for that. I'm all for that, but you just being for it doesn't change anything for what I do - you need to transmit the information you undoubtedly have to me in a way that I understand, and you need to read and understand what I say in return. Without communication, no transfer of information and without you understanding what the question is and me understanding how the technically superior solution works, no progress. As simple as that. Cheers, * 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
