Re: [Flightgear-devel] Weather

2012-11-12 Thread Renk Thorsten
Could this weather properties be shared trough network somehow ? No idea, I'm not into MP at all, so I know next to nothing about how easy or difficult it is to transmit anything more. Sorry this dumb questions, I just had the intention to show flightgear weather on a external map/radar

Re: [Flightgear-devel] Weather

2012-11-12 Thread Renk Thorsten
But if this thunderstorm looks exactly the same from different angles is not that important in case there IS a thunderstorm probably. Sharing the center position, pressure, movement, winds and probably cloud density over network is sufficient, in case this data could be shared in metar-like

Re: [Flightgear-devel] 3d clouds on multi-display systems (was Re: FSWeekend 2012...)

2012-11-11 Thread Renk Thorsten
I think that's just a side-effect of having so many pixels covered by (multiple) quads with alpha. I'm not sure there's much we can do about that, unless we somehow start dropping sprites. I'll have a think - 3D cloud perf has always been a big challenge. Based on my own experiments, I

Re: [Flightgear-devel] Moonlight reloaded

2012-11-11 Thread Renk Thorsten
I suspect the difference in light intensity (dynamic range) doesn't fit in an 8-bit 3-component color. It sure doesn't, but I think you're thinking way too complex. We don't want to render physical light intensity, we want to render perceived light intensity, and there the Weber Fechner law

Re: [Flightgear-devel] Moonlight reloaded

2012-11-11 Thread Renk Thorsten
You need to do High Dynamic Range rendering to accurately capture these differences and the eye's ability to adapt to them. Basically, you do all the rendering in floating point and at the end convert the values to RGB colors with a mapping operator. We don't do that yet. I'm currently

Re: [Flightgear-devel] Weather

2012-11-11 Thread Renk Thorsten
Flightgear has a nice (local and global) weather implementation AFAIK. Are there some ideas (or solutions) how to map custom or shared weather values in a (internal or external) weather radar ? Someone was working on that, and we got to the point that Advanced Weather writes thunderstorm info

Re: [Flightgear-devel] Moonlight reloaded

2012-11-10 Thread Renk Thorsten
If you need any information about the moon's position and/or phase, just let me know. It should be trivial to extract these values from the ephemeris code. Thanks, that was what I was hoping for :-) It depends a bit on if Fred wants to do anything with the moon - my scheme would be fine

[Flightgear-devel] Moonlight reloaded

2012-11-09 Thread Renk Thorsten
I was toying with this for a while, but now I have a reasonably cheap solution to render moonlight effects: http://www.flightgear.org/forums/viewtopic.php?f=47t=14755start=195#p170250 Now, all I need is the info about the current moon phase and if the moon is above the horizon which is

Re: [Flightgear-devel] Moonlight reloaded

2012-11-09 Thread Renk Thorsten
Interesting, looks good. So effectively it glows... Not really - unlike glowing stuff, it is actually obscured by cloud cover for instance. * Thorsten -- Everyone hates slow websites. So do we. Make your web apps

Re: [Flightgear-devel] FSWeekend 2012...

2012-11-08 Thread Renk Thorsten
Thanks for the responses, I think I understand the issue much better. The eye catcher is not the gem, but things you see, and notice, from a distance, like a huge flag with free writen on it. I guess it'd just be a matter of setting things up. Sure, on a laptop things tend to get lost. But

Re: [Flightgear-devel] FSWeekend 2012...

2012-11-07 Thread Renk Thorsten
Hi Durk, Please note that I never said that we didn't *have* any major new features. The major difference between previous years and this year was that we didn't have *obvious* eye catchers. Every feature you mention is really a great improvement, but they are not sufficiently salient

Re: [Flightgear-devel] FSWeekend 2012...

2012-11-06 Thread Renk Thorsten
presenting something drastically new every year. But this year the new essence seemed to be missing somewhat. I didn't really feel that we had any major innovations to show (with the notable exception of project rembrandt, which ran well on Alexis' machine). With our multiscreen

Re: [Flightgear-devel] Cloud layer performance

2012-11-06 Thread Renk Thorsten
So I know clouds write a z-buffer, and I know terrain reads a z-buffer - they just don't seem to use the same z-buffer. In which case the whole scheme doesn't work as advertized. Does that make any sense? Is there anything special about clouds? Seems I can't figure that one out on my

[Flightgear-devel] Cloud layer performance

2012-10-24 Thread Renk Thorsten
I've managed to get a test implementation for the idea of filling the depth buffer early by clouds by inserting tracers into some of the cloud calls. The tracers are in essence just opaque white sheets marked with a top shade factor of 0.0 (black - no real cloud can ever have that low a

Re: [Flightgear-devel] Texturing - some opinions please

2012-10-24 Thread Renk Thorsten
I see no reason to include multiple options of the same texture if one could do just fine. It's just a matter of removing them from the xml file (or comment hem out). I take the lack of other responses as silent agreement and will proceed as I see fit then. I also noticed you effectively

Re: [Flightgear-devel] Cloud layer performance

2012-10-24 Thread Renk Thorsten
I haven't really been following this thread closely... are the tracers basically occludes? Are they completely opaque? Yes, they're completely opaque. That's tracer.frag - if it gets a white gl_Color from the vertex shader, it's a real cloud and the fragment is dropped, if it gets any other

Re: [Flightgear-devel] Cloud layer performance

2012-10-24 Thread Renk Thorsten
I realize that I'm confused about whether you are working on Stuart's clouds in C++ or clouds in Nasal. They're the same now - there's an interface to generate a cloud from Nasal which is what I'm using, whereas Basic Weather uses and xml format for layer declaration, but for rendering

Re: [Flightgear-devel] Cloud layer performance

2012-10-24 Thread Renk Thorsten
If I understand correctly, you have only one model of the cloud, which has a bunch of sprites and a few tracer polygons. I don't know if this is practical in the current system, but I'm saying that it would be better to draw only the tracers in the tracer pass and the sprites in the real pass

[Flightgear-devel] Texturing - some opinions please

2012-10-19 Thread Renk Thorsten
I have two questions to which I'd like to gather a few opinions: 1) Emilian pointed out here http://www.flightgear.org/forums/viewtopic.php?f=68t=17114hilit=procedural+texturingstart=30#p165312 that terrain textures are a fair share of memory consumption and concluded that we shouldn't use

Re: [Flightgear-devel] Shader optimization

2012-10-18 Thread Renk Thorsten
Speaking of which - it'd be nice to have local north as well defined direction as well - that would allow for things like the snowline being higher on south slopes ... In the Northern hemisphere ;-) Quite so - but once you have a north-pointing vector, the rest is trivial because you can

Re: [Flightgear-devel] Shader optimization

2012-10-18 Thread Renk Thorsten
Btw, in terrasync terrain you can safely use gl_Vertex.z as altitude. There are some issues with that one, but only in custom terrain generated after 2009, which you're not interested in supporting anyway. FYI, I fixed the snowline problem for custom terrain half a year ago by passing camera

Re: [Flightgear-devel] Shader optimization

2012-10-18 Thread Renk Thorsten
Hint... I already knew that In which case I'm puzzled by your remark that I wouldn't be interested in supporting custom scenery anyway when you know that I've cooked up a scheme which does just that. But maybe I'm simply too tired. * Thorsten

Re: [Flightgear-devel] Shader optimization

2012-10-18 Thread Renk Thorsten
Maybe it would be better next time to ping some more people and notify them about problems in the scenery toolchain. Emilian did it (http://code.google.com/p/flightgear-bugs/issues/detail?id=888) and we fixed the bug, which means that your additional calculations are unnecessary now for

Re: [Flightgear-devel] Shader optimization

2012-10-18 Thread Renk Thorsten
And the matrix transform is for free...? Oh, I forgot, a useless matrix transform is ok to be run on milions of vertices, but one that actualy has a use, and runs on tens or maybe hundreds at most, is killing performance A uniform float doesn't have a matrix transform. I thought you'd

Re: [Flightgear-devel] Shader optimization

2012-10-18 Thread Renk Thorsten
I'm talking about the ep ... which is done for each vertex, everytime ... and the relevance of that observation to the ongoing discussion is...? It's needed among other things to construct a sun/horizon coordinate system for the lighting computations, so the ep has to be computed

Re: [Flightgear-devel] Shader optimization

2012-10-17 Thread Renk Thorsten
Even the oldest hardware that supports OpenGL programmable shaders implements vector operations, and a vector multiply-add has, as far as I know, the same cost as a scalar operation. On the other hand, the shader compiler might be able to combine multiple scalar interpolations into vector

Re: [Flightgear-devel] Shader optimization

2012-10-16 Thread Renk Thorsten
One can assume that a vec4 varying is no more expensive than a vec3. (...) I'm not sure it's useful to think of each component of a varying vector as a varying i.e., three vec3 varying values use up three varying slots, and so do 3 float varying values I dunno... Just counting the number

[Flightgear-devel] Shader optimization

2012-10-15 Thread Renk Thorsten
I thought it might be a good idea to write up a few things I've tried recently and not seen in widespread use - so that either others know about them as well or I can find out what the pitfalls are. Basically this is about reducing the number of varyings, which is desirable for at least two

Re: [Flightgear-devel] New materials.xml elements to control object/tree density depending on slope angle

2012-10-11 Thread Renk Thorsten
and it works particularly well with some of the angle-dependent rock shaders. Indeed it does - Yosemite valley from above (not bad for default scenery...): http://users.jyu.fi/~trenk/pics/tree_slopes.jpg * Thorsten

Re: [Flightgear-devel] New materials.xml elements to control object/tree density depending on slope angle

2012-10-11 Thread Renk Thorsten
Do you have some other local modifications (materials / texture set) in this screenshot? But it's not a part of the world I have explored, maybe I'm simply ignorant of our textures in such places. I think this is all classified as EvergreenForest (or at least some forest...), and the

Re: [Flightgear-devel] In-sim selection of materials.xml file - what to call DDS?

2012-10-10 Thread Renk Thorsten
The reason I didn't just label it material definitions was that I don't think that a new user is going to understand what that means, while the concept of different textures should be familiar to people who have some background in graphics, or gaming. I'd go for something like 'terrain

Re: [Flightgear-devel] New materials.xml elements to control object/tree density depending on slope angle

2012-10-10 Thread Renk Thorsten
Hi Stuart, played around with this a bit yesterday... *very* nice feature! The default values look about right to me from a typical temperate latitudes viewpoint, and using much smaller values gives a quite nice effect possibly suitable for more northerly latitudes. I agree that the

[Flightgear-devel] Useful feedback and the other thing (was: Merge request #181)

2012-10-08 Thread Renk Thorsten
Hi Emilian, Understood... I will refrain from any further tests/opinions on this topic then. Please accept my apologies, and disregard any of the issues I've raised. Everything's working smooth, and looks better than IRL... it's just my imagination playing tricks, better get my eyes checked

Re: [Flightgear-devel] Merge request #181

2012-10-07 Thread Renk Thorsten
I've had a look at this in Scotland, where it is a bit too bright based on my own experience, so I'd like to leave this change so it only applies to South America. Obviously I could do the opposite and make some specific materials for Scotland (hmmm, good idea :) I wanted to have a look at

Re: [Flightgear-devel] Merge request #181

2012-10-07 Thread Renk Thorsten
First I get this when opening the shader settings dialog: Nasal runtime error: non-objects have no members at $FG_ROOT/Nasal/props.nas, line 181 called from: __dlg:shaders-lightfield, line 32 and the slider is off to the right, and can't be of much use. Assuming that this is the shader

Re: [Flightgear-devel] Merge request #181

2012-10-06 Thread Renk Thorsten
I'm taking a look at this merge request. One thing I don't quite understand from doing a code read is the chance to the overall Grasscover to use the tundra-hawaii-green texture, on line 1909 of regions/materials.xml. Can I check this is intentional? This is intentional - I'm trying to

Re: [Flightgear-devel] New materials.xml elements to control object/tree density depending on slope angle

2012-10-06 Thread Renk Thorsten
Nice - looking forward to it! (and before anyone asks, I'm not planning to reduce tree density on shaded slopes...) We wouldn't really want that - shaded slopes in my experience do not grow less trees, they just grow different tree species... :-) I wonder if we could trick the shader into

Re: [Flightgear-devel] New materials.xml elements to control object/tree density depending on slope angle

2012-10-06 Thread Renk Thorsten
I've sometimes wondered if we could have much greater variety of 'trees', to place scrub (cactus in Central America, bramble in Scotland) in areas where full trees don't make sense. I guess wi the regional materials that ought to be much easier? Yes, it's quite straightforward -

Re: [Flightgear-devel] Nav-cache

2012-10-04 Thread Renk Thorsten
I wonder how we deal with this with the next release- I'm sure a whole lot more users will complain about the stuck while launching FGFS. By printing a message like 'Building database during first startup' on the screen? By including the binary nav data with the release? Doesn't look like a

Re: [Flightgear-devel] Depth buffers, render bins and passes

2012-10-04 Thread Renk Thorsten
You know that rendering a transparent object twice alter its transparency. Of course, you can avoid to render it in the color buffer using write mask in one pass. What I do with the trees is render just the opaque bits early on as white with essentially no light and fog computations to

Re: [Flightgear-devel] Depth buffers, render bins and passes

2012-10-04 Thread Renk Thorsten
I am pretty confident (and hope to test, but it sounds like you might beat me to it) that for either the classical (non-Rembrandt) render, doing a depth-write *only* pass of the entire scene will be a net win. (Again assuming the fragment shader is the bottleneck). Since this will

Re: [Flightgear-devel] Depth buffers, render bins and passes

2012-10-03 Thread Renk Thorsten
To summarize, all objects having a pass of render bin -1 are rendered before any object having a render bin 1. If an object have two passes, it is rendered twice, once with the objects of the same render bin than the first pass, once with the objects of the same render bin than the second

[Flightgear-devel] Advanced Weather broken

2012-10-02 Thread Renk Thorsten
It seems some change during the last weeks broke parts of Advanced Weather in at least two places (I had no problems under any conditions until my update yesterday, now I can reproduce both issues consistently on both master and my devel branch). The more serious problem is that under some

[Flightgear-devel] No more software rendering?

2012-10-01 Thread Renk Thorsten
I'm trying to catch up with recent developments, and I've pulled and compiled an up-to-date snapshot today. One thing I stumbled across by accident is that we seem to have lost the ability to do software rendering as a fallback. If I start today's Flightgear binary without access to the GPU

[Flightgear-devel] Depth buffers, render bins and passes

2012-10-01 Thread Renk Thorsten
I'm trying to understand why clouds can obscure hills and hills can obscure clouds properly. My individual bits of knowledge are: * clouds are drawn from outside in, because they are in a depth sorted bin, and this is why clouds obscure other clouds properly. * hills are not drawn from

Re: [Flightgear-devel] fgdata trouble

2012-09-24 Thread Renk Thorsten
So you are calling for git monkeys that take care of the tedious process of getting changes into the tree? If it is as critical to do this right as you say, everyone might be better off if only people who know what they're doing handle commits and every other commit goes through them,

[Flightgear-devel] Some ideas for better performance

2012-09-19 Thread Renk Thorsten
Hi All, unfortunately, due to personal reasons, I won't have much coding time for the rest of the year, which means that I probably won't have a chance to do some things I sort of promised to do (make more shaders work in the atmospheric light scattering framework, help making atmospheric

Re: [Flightgear-devel] license

2012-09-06 Thread Renk Thorsten
There remains this strange discrepancy between what people are outraged about and what could potentially stand in court. Wah. They're immoral scammers by any examination. They're suckering people into not only buying free software, but public domain materials as well! I think the truth

Re: [Flightgear-devel] license

2012-09-05 Thread Renk Thorsten
Hence I would use the same license to keep off scammers. (...) Anything but code should be possible to license similar to GPL, but not allowing any commmercial use. My two cents: First of all, define your use of 'scammer' here. From Wikipedia, I get A confidence trick is also known as a con

Re: [Flightgear-devel] license

2012-09-05 Thread Renk Thorsten
FlightProSim does not defraud its customers as far as I am aware. According to reports on this very list (hint) and elsewhere they don't comply with the money-back guarantee they advertize. Well, since there's always small-print (which I don't know) I would leave that to the courts to

Re: [Flightgear-devel] license

2012-09-05 Thread Renk Thorsten
We haven't been able to pin them down on a specific technical violation of the gpl, but that doesn't mean they are legitimate, honorable, and ethical. They're immoral scammers, plain and simple. It galls me to speak up for FlightProSim, but such statements are, as far as I am concerned, not

Re: [Flightgear-devel] FW: Compute ground elevation dynamically for STG format

2012-08-30 Thread Renk Thorsten
Computing constant values at runtime is bad design and we should not do that. No matter if we notice a significant increase in load time now or not. The ground elevation at a specific point is well known at scenery generation time and that is where the vertical position of an object has to be

Re: [Flightgear-devel] Running Nasal at simulation rate

2012-08-30 Thread Renk Thorsten
I know, some people on the forum would like to eventually replace fgfs(.exe) with nasal(.exe), because apparently everything is just better (tm) when implemented in Nasal (core = bad, nasal = good). But I really think this is a completely wrong direction - and harming the project. Could we

[Flightgear-devel] Rendering passes confusion - again

2012-08-11 Thread Renk Thorsten
I still haven't given up on the idea of 'masking' the terrain pixel shading by the cockpit, since even a very simple mask easily makes the system 50% faster for me. Lauri has kindly given me some instructions on how to use the stencil buffer - so the idea was to start by filling the stencil

Re: [Flightgear-devel] git help request

2012-08-09 Thread Renk Thorsten
The typical fix is to edit the conflicting files and git add them the run git rebase --continue. But these files don't exist so I can't edit them, git add fails, git rm also fails since they don't exist. If the files no longer exist, I think one solution is to tell the system to skip the

[Flightgear-devel] Memory issues

2012-08-09 Thread Renk Thorsten
Of late, I have increasingly been running into some segfaults which seem to have to do with peak memory usage (I don't think memory leaks are a major issue for what I've been seeing, since some segfauls happened quite early on, and especially when I try pushing my limits of graphical goodies).

Re: [Flightgear-devel] Procedural texturing merge request

2012-08-08 Thread Renk Thorsten
Do I want atmospheric scattering on or off? That affects which are the top two sliders. You want atmospheric scattering on. Then the top sliders are 'Landmass' and 'Transition'. These you want at 5. What did it take to make the correct dialog appear? Are you sure you have the updated

[Flightgear-devel] Console swamped with messages

2012-08-07 Thread Renk Thorsten
Some variants of this have been going on for some time - currently my console ends up swamped with messages (I suspect the AI traffic) like this: Checking for end of cruise stage for : Descent rate : 7.62 Descent speed : 154.333 VerticalDistance : -483.402. Altitude : 3584.04.

Re: [Flightgear-devel] Console swamped with messages

2012-08-07 Thread Renk Thorsten
Are you sure about the syntax of the --prop=/sim/... command line option? I thought it should be something like: --prop:/sim/... If I'm right, you might still have the traffic manager running. For all I know and can test, they're equivalent. Changing to --prop:/sim/... doesn't change the

Re: [Flightgear-devel] Procedural texturing merge request

2012-08-07 Thread Renk Thorsten
are there any screenshots available which compares before/after? Not as such... A collection of work in progress is in the forum http://www.flightgear.org/forums/viewtopic.php?f=47t=16884 but this is with my private not-necessarily-GPL development environment. The comparison is otherwise

Re: [Flightgear-devel] Procedural texturing merge request

2012-08-07 Thread Renk Thorsten
Is this work something that is active by default or does it need to be turned on? Or is it only availble in a particular area? Do I need to do anything special to look at the results beyond just take off and fly around anywhere? Forgot: Works currently only with

Re: [Flightgear-devel] Procedural texturing merge request

2012-08-07 Thread Renk Thorsten
Is this work something that is active by default or does it need to be turned on? Or is it only availble in a particular area? Do I need to do anything special to look at the results beyond just take off and fly around anywhere? * atmospheric light scattering: on * shader micromanagement

Re: [Flightgear-devel] Procedural texturing merge request

2012-08-07 Thread Renk Thorsten
Hmmm, my shader micromanagement dialog box is only showing two options right now. Category General: landmass and water. I don't have the bandwidth at the moment to pull back master, but I've checked the local branch from which I merged and I checked the log for FGData master on GIT - among

Re: [Flightgear-devel] Procedural texturing merge request

2012-08-07 Thread Renk Thorsten
I'm on the master/next branch here for these tests. But I haven't kept close enough tabs on the lightfield/regional gui options dialog box to quite know exactly what I should be seeing or where to start for hunting what's going on. Shouldn't I be seeing quite a few detailed shader

[Flightgear-devel] Procedural texturing merge request

2012-08-06 Thread Renk Thorsten
Hi Fred, I have created a merge request containing part of my recent experiments with procedural terrain texturing - please have a look (I hope I haven't messed up the request again...). https://www.gitorious.org/fg/fgdata/merge_requests/175 Thanks, * Thorsten

Re: [Flightgear-devel] Water reflection needs fix

2012-08-04 Thread Renk Thorsten
Are you sure you're using/looking at the correct fgdata? Looking at the files here they use the proper uniform to determine if the normalmap is dds, and reverse the normals only in that case: I was looking at my devel branch rebased against master. Seems like one of my 'GIT strikes again'

Re: [Flightgear-devel] Ideas for terrain shader structure in 3.0

2012-08-03 Thread Renk Thorsten
I've just pushed a change that allows a material definition in materials.xml to include a parameters section, which is merged with the parameters section of the effect. So you can now define parameters in the materials.xml file that can be used as uniforms in the effects file, and

[Flightgear-devel] Water reflection needs fix

2012-08-03 Thread Renk Thorsten
Just stumbled across this one: Effects/water.eff now declares png textures for reflection and nose to avoid dds. The relevant commit changed the effect file and water_sine.frag but didn't change the corresponding lines in water_lightfield.frag which has pretty identical normal-generating

Re: [Flightgear-devel] Ideas for terrain shader structure in 3.0

2012-08-01 Thread Renk Thorsten
I'm very keen on the placement maps myself, but they are fundamentally incompatible with the crop shader, as the placement information is required well above the shader layer. I like the idea of the placement masks, and one could use them to do LOD by passing the mask itself to the shader

[Flightgear-devel] Ideas for terrain shader structure in 3.0

2012-07-27 Thread Renk Thorsten
Since we usually don't have roadmaps and things, I thought I might try to put this up for discussion early on. I've been experimenting with a partially procedural texturing approach, and I think this is the way to go forward, the outcome looks very convincing. My experiments are coded within

Re: [Flightgear-devel] Functions to textures?

2012-07-25 Thread Renk Thorsten
Actually, the code that creates the texture is in scene/util/StateAttributeFactory.cxx, but you would have to do something similar to the noise texture code in TextureBuilder to access your texture from a texture. It would be nice if the Effects framework had a way to load arbitrary textures

[Flightgear-devel] Functions to textures?

2012-07-24 Thread Renk Thorsten
First of all, a big thanks to Tim - Akenine-Moller Co. is indeed quite an interesting read, and in addition to gaining a better understanding, I've so far experimented successfully with a heightfield for parallax and normal mapping and a simple irrandiance map instead of the ambient term in

Re: [Flightgear-devel] Rendering passes question

2012-07-22 Thread Renk Thorsten
The depth-pass-only pass is a well known optimization, but the fact it is not helping implies that our bottleneck is not in fragment processing. Most of the discussion is drifting a bit over my head now, but I'm pretty sure that's not what I am talking about. I am talking about a situation

Re: [Flightgear-devel] Rendering passes question

2012-07-19 Thread Renk Thorsten
This is an optimization to avoid running really expensive shaders on geometry that will be hidden from view. The GPU has an early Z capability and won't run a fragment shader if it knows the result will be discarded. But that can't be all that is going on. In this case I'd expect that if I

Re: [Flightgear-devel] Rendering passes question

2012-07-19 Thread Renk Thorsten
Which is very unfortunate, since in the common case it would allow a huge amount of tile/terrain pixels to be dumped. Could we use a buffer copying to trick to initialise a stencil plane on the far camera based on the near-camera Z-buffer? I've no idea what the penalty of a z-buffer

[Flightgear-devel] Rendering passes question

2012-07-18 Thread Renk Thorsten
May I ask yet another dumb question? In the first rendering pass of default terrain rendering, we use default.vert and terrain-nocolor.frag as shaders. I have so far mindlessly copied the first pass since I had no real clue as to what it is for. Its purpose seems to be to establish that

Re: [Flightgear-devel] Rendering passes question

2012-07-18 Thread Renk Thorsten
The main reason to render textures at this stage is that textures with transparency do change the fragments that are rendered. Calculating the fog color seems wrong, but I don't have the sources in front of me and gitorious is acting up. So since we're not using transparent textures for

Re: [Flightgear-devel] DDS usage in effects files

2012-07-14 Thread Renk Thorsten
A number of effects files use .dds textures, leading to error messages on the console. IIRC in the last release, we suppressed these error messages for the release, and I think we need to do something for for 2.8.0 as well. Of particular concern is terrain-default.eff which uses

Re: [Flightgear-devel] Shader menu structure

2012-07-14 Thread Renk Thorsten
Hi Tim, If I could give some gentle advice, perhaps based on out-of-date observations: you could really benefit from a serious study of computer graphics. I highly recommend the book Real Time Rendering by Akenine-Moller et al. Thanks, that's actually not a bad idea. I think I'll get myself

Re: [Flightgear-devel] Shader menu structure

2012-07-13 Thread Renk Thorsten
Believe it or not, computer graphics researchers (not me) think about shader work in those terms too. It comes off as a bit pompous to assume that no one here would understand what you are talking about or be able to come up to speed on the math if necessary. I'm assuming here that the

Re: [Flightgear-devel] Reduced tiling (was Re: Shader menu structure)

2012-07-13 Thread Renk Thorsten
..this kinda blending looks so good it should IMHO go into the current release, even if it means delaying the release. Just in case: The effect is quite tricky to get right, because the parameters and overlay texture need to be somewhat carefully tuned for each landclass, untuned it looks

Re: [Flightgear-devel] Shader menu structure

2012-07-12 Thread Renk Thorsten
Action plan for recovery : 1. Go straight to the point (actionee: Thorsten R.) 2. Write much shorter e-mails (actionee: Thorsten R.) 3. Read Thorsten's e-mails (actionee: rest of the world) Bertrand. (My) Life insurance : This is a miserable attempt of humour to try to remind everyone

Re: [Flightgear-devel] Shader menu structure

2012-07-09 Thread Renk Thorsten
So no reason the get polemic or arrogant: I wrote 'scenery and models', I did not write 'trees'. ... Which of these two statements did you find hard to understand? Heiko, that didn't come out of the blue. That came after I took the time to explain something, then explained it in different

Re: [Flightgear-devel] Random vegetation and Atmospheric light scattering (was Re: Shader menu structure)

2012-07-07 Thread Renk Thorsten
Hi Stuart, Question for Thorsten: I've only integrated the terrain-haze.[vert|frag], not terrain-haze-detailed.[vert|frag]. How much additonal quality does that add, and is it appropriate for trees? I'm in the middle of my holiday right now and will basically be mostly offline for another

Re: [Flightgear-devel] Shader menu structure

2012-07-07 Thread Renk Thorsten
I get to see a seamless and plausible match between sky and terrain from ground level to low Earth orbit, at all times of the day and under any weather condition. Scenery and models are now rendered correctly with the sky at all locations and all times. Really? Look at the trees- Does

Re: [Flightgear-devel] Shader menu structure

2012-06-28 Thread Renk Thorsten
Heiko: Thanks, that's now an answer I was looking for. Though I'm sure we will get bug reports as well by users complaining where the shader from 2.6.0 went, or why shaders won't work. Some of this confusion was already visible in the forum. I don't want to bitch, but the thread started

Re: [Flightgear-devel] Shader menu structure

2012-06-28 Thread Renk Thorsten
My (completely biased) opinion: *2.6.0 In 2.6.0 we had only the choice between default sky or Zan's sky shader. In both variants shaders on aircraft and on terrain worked, but there was the problem with horizon. It gave us pretty cool looking skies, as you can see on the 2.6.0 gallery.

Re: [Flightgear-devel] Shader menu structure

2012-06-27 Thread Renk Thorsten
Is there a way we can have all three possibilities (default, skydome shader, Thorstens atmospheric light scattering) selectable? Atmospheric light scattering should not be thought as different from skydome shader - it is the terrain/model/whatnot shader combination consistent with the

[Flightgear-devel] Shader menu structure

2012-06-19 Thread Renk Thorsten
Anyway, just reporting what I see, but I am sure other users must get VERY confused by such strange - it works, then it does not work - behavior... but I suppose when it is all documented the sun will shine, and shadows cast... Indeed. Forum reports suggest that users do get confused. So

Re: [Flightgear-devel] Shader menu structure

2012-06-19 Thread Renk Thorsten
So.if.someone.could.setup.a list of effect(combination)s that don't work, I can try to construct something. From my side: Lightfields currently support - of the detailed shader config dialog: water reflection (water slider) and snow/dust (currently on landmass slider), all other sliders

Re: [Flightgear-devel] A plan for a 3.0 release?

2012-06-19 Thread Renk Thorsten
There is a simple solution to that. Move the work in the fragment shader. You won't be scene complexity bound, and you'll also have the correct depth available as (...) Right... but I need the projection of the vertex position into the sun direction in the horizon plane to compute light -

[Flightgear-devel] Hard-coded movement for Nasal-generated models

2012-06-15 Thread Renk Thorsten
I would like to point the attention of people who can commit on flightgear and simgear to two merge requests put in by Vivian recently: https://www.gitorious.org/fg/simgear/merge_requests/26 https://www.gitorious.org/fg/flightgear/merge_requests/1564 This contains functionality which is

Re: [Flightgear-devel] Merge request: SF-25 Falke

2012-06-14 Thread Renk Thorsten
I'd appreciate it if someone could take a look at the aircraft as well to check that everything is OK or if there is anything to fix. Hi Vik, I rather liked the plane - some impressions in the Forum: http://www.flightgear.org/forums/viewtopic.php?f=19t=9446p=159456#p159456 No obvious

Re: [Flightgear-devel] A plan for a 3.0 release?

2012-06-14 Thread Renk Thorsten
I'd add to this list * lightfields integrating well with other shaders. For example, I know that the random vegetation doesn't work with lightfield shaders, and the fix that Emilian put together to allow the random buildings to work was a workaround rather than a full fix. I think this

Re: [Flightgear-devel] Enabled random buildings in preferences.xml

2012-06-11 Thread Renk Thorsten
I'd like to propose having random buildings enabled in preferences.xml, so they are switched on by default. I think they improve the realism of our Urban, Suburban and Town sceneries significantly. I would suggest to have them on as default (so that people are aware that they are there)

[Flightgear-devel] A plan for a 3.0 release?

2012-06-11 Thread Renk Thorsten
Torsten's question about what the release number should be got me thinking a bit what I would expect from a 3.0 version, and I thought maybe I can put my outcome for a discussion: I think what makes the difference isn't so much new cool feature, but really a good and intuitive integration of

Re: [Flightgear-devel] The next FlightGear release (summer 2012)

2012-06-08 Thread Renk Thorsten
1) What's the version number of the new release? a) 2.8.0 b) 3.0.0 My impression is that it would be best to advertize Rembrandt as a new, exciting, but optional and stil experimental development. The reason is similar to what others have said - it seems to do really impressive things

Re: [Flightgear-devel] Hawaii regional textures merge request

2012-06-08 Thread Renk Thorsten
Okay, I didn't get a message that this was merged, and despite the argument that there's need for a discussion of the regional texturing scheme there wasn't any discussion, so can I assume the subject isn't interesting at the moment, discontinue to try to come up with GPL compatible solutions

[Flightgear-devel] Two issues: Shader control and turbulence

2012-06-08 Thread Renk Thorsten
Issue #1: We finally found the reason why Heiko didn't get the lightfield scheme properly: /sim/rendering/shader-effects is required to be true in skydome.eff but apparently not set any more by recent GIT, it was however leftover in my autosave, so I didn't notice anything. I can simply

Re: [Flightgear-devel] Two issues: Shader control and turbulence

2012-06-08 Thread Renk Thorsten
The /sim/rendering/shader-effects property has been removed since before 2.6.0, and IIRC it was properly announced on this list. I believe each of those properties was documented on the wiki by Fred, and the major changes were announced on this list. I don't mean to blame anyone for lack of

<    1   2   3   4   5   >