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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
17 matches
Mail list logo
