> 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 incomprehe
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 l
On 28 Jan 2013, at 10:41, Emilian Huminiuc 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
> bino
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 l
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
> featur
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 thin
> 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: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 amoun
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 27 Jan 2013, at 16:44, Mathias Fröhlich 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 coe
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
> I see applications that care for stable 60 hz. If you get for one frame
> 59 hz they have too much jitter and look for an other renderer.
>
> What I really do not like is that people purely push in the direction
> they just like more.
Beats me when this has ever been a problem. My first co
Hi Mathias,
Stepping in here just in case some context is getting lost in
translation :).
On Wed, Jan 23, 2013 at 8:50 PM, Mathias Fröhlich wrote:
> What I really do not like is that people purely push in the direction they
> just like more. If you work sensibly, you can support both. If you want
On Sunday, January 20, 2013 19:17:18 Renk Thorsten wrote:
> > Well, if you ask in that way, then the question is:
> > Do we need 10 different flavours of rock?
>
> If we want to look a scene roughly as it would in the location, the answer
> is yes - volcanic rock on Hawaii looks very different fro
> Well, if you ask in that way, then the question is:
> Do we need 10 different flavours of rock?
If we want to look a scene roughly as it would in the location, the answer is
yes - volcanic rock on Hawaii looks very different from Alpine rock in France.
Rock in Iran looks very different again.
On Sunday, January 20, 2013 14:44:17 Renk Thorsten wrote:
> > Yes. Any uniform needs to be handled by the driver. And any of them
> > takes cpu
> > cycles to load. I think having lots of them is one factor that accounts
> > for
> > the long draw times I see here. Looking at profiles the function
>
> Yes. Any uniform needs to be handled by the driver. And any of them
> takes cpu
> cycles to load. I think having lots of them is one factor that accounts
> for
> the long draw times I see here. Looking at profiles the function
> collecting
> them and putting it into a buffer for use in the
On Thursday, January 17, 2013 16:31:57 Renk Thorsten wrote:
> > For example here on an nvidia 8800GT with 313.09 linux driver I have:
> >
> > MAX_VERTEX_UNIFORM_COMPONENTS 4096
> > MAX_FRAGMENT_UNIFORM_COMPONENTS 2048
>
> Nevertheless, that would make 50 seem a rather harmless number. Especially
On 17 Jan 2013, at 16:31, Renk Thorsten wrote:
> Nevertheless, that would make 50 seem a rather harmless number. Especially
> when I'm going to assume that no one with a much older card will be able to
> run a shader with 6 overlay textures in anything resembling a usable
> framerate anyway.
> For example here on an nvidia 8800GT with 313.09 linux driver I have:
>
> MAX_VERTEX_UNIFORM_COMPONENTS 4096
> MAX_FRAGMENT_UNIFORM_COMPONENTS 2048
Nevertheless, that would make 50 seem a rather harmless number. Especially when
I'm going to assume that no one with a much older card will be able
Also see here for uniforms:
https://www.opengl.org/wiki/Uniform_(GLSL)
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with L
On Thursday, January 17, 2013 13:16:03 Renk Thorsten wrote:
> I've recently come across the idea of using one generic sand or rock texture
> and selecting the particular hue desired by multiplying every pixel value
> with an (rgb) vector - so rather than two different-colored sands, we'd
> just sto
I've recently come across the idea of using one generic sand or rock texture
and selecting the particular hue desired by multiplying every pixel value with
an (rgb) vector - so rather than two different-colored sands, we'd just store
one texture and three numbers on disk (and potentially in GPU
23 matches
Mail list logo
