[Flightgear-devel] FlightGear developers discussions flightgear-devel@lists.sourceforge.net

2012-05-26 Thread Renk Thorsten
Done. Could do with some more refinement, but it works. If you input speed-kt, then position updates are ignored and positions are calculated from input speed and pitch. Here are the patches: http://dl.dropbox.com/u/57645542/0001-SG%20Make-Models-move-with-heading-and -speed.patch

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

2012-05-25 Thread Renk Thorsten
But ... there is no visible structure in textures folder yet for regional textures, is it ? Want a zurich_kreis_6_neighbourhood_grass.png as a 30mb .dds for my next merge request ? ;-) I think that's because we don't know yet how a reasonable structure should look like. What I'm discovering

[Flightgear-devel] Hawaii regional textures merge request

2012-05-24 Thread Renk Thorsten
Okay, given yesterday's discussion, I don't know if there is still need to discuss further or not or if this should be merged or not, but I'm putting this up now as I'll be travelling next week and won't have any decent internet connection to rebase my local branch properly, so anyone can have

Re: [Flightgear-devel] Regional textures merge request

2012-05-23 Thread Renk Thorsten
Sorry for my impatience, but I think before one start to have tousands of custom scenery textures in fgdata we should discuss if such limited custom scenery changes makes sense to be in the (already heavy) fgdata repository. Okay, what would your answer to the following question be: 'We

Re: [Flightgear-devel] Random Buildings - memory consumption

2012-05-23 Thread Renk Thorsten
Using the default random building density, the tiles that are loaded initially when sitting on the runway generates ~ 340k random buildings. We might be generating too many buildings then? The greater Los Angeles area has between 13 and 16 million inhabitants (dependent on what you count).

Re: [Flightgear-devel] Random Buildings - memory consumption

2012-05-23 Thread Renk Thorsten
Besides being totally off topic, you can't do that direct comparison. First off, our default scenery lacks a lot of detail in the urban area boundaries in that area thus marking a far larger area as being urban - a far larger area on which to generate buildings That'd makes my point

Re: [Flightgear-devel] Random Buildings - memory consumption

2012-05-23 Thread Renk Thorsten
No, I think you're extrapolating from a particularly bad case of mismatch between reality and simulation. I wasn't talking about regionalized building placement, I was talking about bad landclass representation in that particular area, representation from which come the figures you used

Re: [Flightgear-devel] Nasal performance

2012-05-22 Thread Renk Thorsten
I have tested using only the test tile so far. The time spent in events is dramatically reduced to around 70ms vice 210ms. There remains some odd cyclical frames coming in, but the results are broadly in line with Basic Weather. Okay, that's good news. I'll continue working along these

Re: [Flightgear-devel] Nasal performance

2012-05-21 Thread Renk Thorsten
Not that we're there yet Heiko and Vivian, please try the following version and let me know if this improves anything. If possible, do all tests with the weather tile type 'Test' (that has no randomness in the cloud configuration selection, so it delivers a fairly reproducable situation in

Re: [Flightgear-devel] Nasal performance

2012-05-21 Thread Renk Thorsten
(Even if this works fine, please do not commit yet, I am not 100% sure that I didn't create an instability somewhere). Turns out I broke at least the visibility interpolation - to restore it, uncomment line 726 in Nasal/local_weather/local_weather.nas if (vis 0.0)

[Flightgear-devel] Nasal performance

2012-05-20 Thread Renk Thorsten
88 declared but unused variables 47 declarations of the same or similar variables 427 instances of else if instead of elsif 100 instances of I = I + 1 instead of i+=1 Numerous examples of variables declared inside for loops, and some of those are inside other for loops Variables declared

Re: [Flightgear-devel] Nasal performance

2012-05-20 Thread Renk Thorsten
just a quick note to this interesting thread ... its elsif in nasal , not elseif ... no e Thanks. That would explain it ;-) I hope you're not suggesting that C++ is always slower than Nasal? :-) Pascal summarized it nicely - we already have ported the important stuff to C++, so what remains

Re: [Flightgear-devel] Sea color

2012-05-19 Thread Renk Thorsten
With your scientific background you should know better than cherry-picking that statistic. Those on the forum are a self-selected minority of our users. (...) No I'm most definitely not. What I'm saying is that by optimising for a subset of users, you run the risk of sub-optimising for the

Re: [Flightgear-devel] Sea color

2012-05-18 Thread Renk Thorsten
After sleeping it over... Now set all Advanced Weather settime() to 0.0 and retest with METAR. Wow!!! Improvement, not as good as Basic Weather , but much better. Worst fps is stable at 24, av. is still unstable. You had a worst of 27 in your list

Re: [Flightgear-devel] Sea color

2012-05-18 Thread Renk Thorsten
The facts are: -it isn't that much important if you have 20fps or 60fps. But it is more important that the framerates are stable !!! It is for Vivian. We seem to agree that a stable 20 fps is possible (I get it and Vivian gets it if he throttles down), but he aims at more. Which is okay

Re: [Flightgear-devel] Sea color

2012-05-17 Thread Renk Thorsten
Conclusion: don't try to optimise, particularly for a poor system - you might make it better for that system, but more likely you will make it worse for everyone else. Judging by framerate comparisons with people in the forum, my system is still somewhere in the upper third - many people

Re: [Flightgear-devel] Sea color

2012-05-16 Thread Renk Thorsten
Yes. You have produced a very nice piece of work which gives variable results in different systems. We need to at least understand the cause and try to fix it GC according to what I can test. Pity you didn't use standard scenery. I don't think custom scenery and the ufo will produce

Re: [Flightgear-devel] Sea color

2012-05-16 Thread Renk Thorsten
Concorde has of the order of 6000 lines of active code, and yes, it displays exactly the same discontinuities as Advanced Weather (approx. 10,000 lines of code). So far, I have not found any other examples. Just to idly continue my list - the A380 has in excess of 8000 lines of Nasal,

Re: [Flightgear-devel] Regional textures merge request

2012-05-15 Thread Renk Thorsten
Quick question to Stuart: Currently the conditionals for texture selection are done using /position/longitude-deg,... i.e. aircraft position. The actual tile position however is different from that by the visibility and an direction, which makes for some uncertainty. So, it'd be more

Re: [Flightgear-devel] Sea color

2012-05-12 Thread Renk Thorsten
I did a bit of testing of my own yesterday, and I have made a few other observations as well. User feedback: I've largely come to ignore that (with few exceptions such as Vivian's performance table), because trying to make sense of it is a path into madness. Just a few examples: On my own

Re: [Flightgear-devel] model-combined-shader

2012-05-12 Thread Renk Thorsten
Is it just me or has the model-combined shader stopped reflecting ? Moving the model slider seems to have no effect now . Skydome shader on by any chance? (That would probably de-activate it). * Thorsten -- Live

Re: [Flightgear-devel] Sea color

2012-05-11 Thread Renk Thorsten
Tested extensively today, and the short answer is no. There is some improvement as the flags are successively set to 0, but Advanced Weather never becomes as smooth as Basic Weather (and that's not without staggers of its own). (...) I suppose the bottom line is that this just might

Re: [Flightgear-devel] Sea color

2012-05-10 Thread Renk Thorsten
It is the largest expanse of intertidal mudflats and sand in the United Kingdom! Neither of these locations could be remotely described as deep ocean, and yes, we should certainly be investigating how to best model such areas of sea. Okay, if you're specifically after deep ocean (i.e.

Re: [Flightgear-devel] Sea color

2012-05-10 Thread Renk Thorsten
Does the problem go away if you set local-weather/dynamics-loop-flag=1 from the property browser *after* Advanced Weather is started? Does the problem go away if you set local-weather/timing-loop-flag=1 from the property browser *after* Advanced Weather is started? Does the problem go

[Flightgear-devel] Sea color (was: Re: Regional textures merge request)

2012-05-09 Thread Renk Thorsten
Hmm I've got something wrong here then - if I understand that right I select Advanced Weather, and skydome and the sea colour stuff should run? I get this: http://dl.dropbox.com/u/57645542/fgfs-screen-190.png It doesn't seem to have any interpolation. The color seems about right to me

Re: [Flightgear-devel] Sea color

2012-05-09 Thread Renk Thorsten
There are good sources for sea colour out there - here is one: http://oceancolor.gsfc.nasa.gov/FEATURE/IMAGES/A2008129125500.Scotland.png The Northern North Sea, away from the turbidity and major river outfalls of the Southern North Sea, is indistinguishable from the Atlantic, the other

Re: [Flightgear-devel] Regional textures merge request

2012-05-08 Thread Renk Thorsten
This scheme introduces yet another for loop in Nasal, of undetermined size. This potentially introduces yet another source of stagger to FG, or it would if it worked, but as far as I can see it never runs here. Is it meant? Well, anticipating your reaction, yes, at this point it's meant

[Flightgear-devel] Location setting bug?

2012-05-07 Thread Renk Thorsten
In a fresh pull of everything as of this morning, I lost the ability to re-locate by choosing an airport from the list. Trying to do so results in command 'presets-commit' failed with exception message:invalid leg index (from FlightPlan::setCurrentIndex) written to the console and the

Re: [Flightgear-devel] Random buildings improvements - phase 2

2012-05-04 Thread Renk Thorsten
For the purpose of making the tests more comparable, would not it be better to use a standard setting/script/options which would set FG to some defined state? In this case clearly no. I'm interested in the relative change matrix of framerates for two features being on or off, not in the

Re: [Flightgear-devel] Random buildings improvements - phase 2

2012-05-04 Thread Renk Thorsten
At the moment it seems to me that FG requirements are increasing faster than the performance of affordable computers. I can't confirm that. The 'bare' current binary (= all shaders off) runs even a bit faster for me than previous releases. I think one clearly needs to distinguish between

Re: [Flightgear-devel] Random buildings improvements - phase 2

2012-05-03 Thread Renk Thorsten
Since the random buildings are now in the effect system, I've run a few tests with the lightfield shaders yesterday. The good news is: It works just fine. The bad news is: It eats performance like mad. For comparison: Without lightfield shading, I had a test case involving a large urban area

Re: [Flightgear-devel] Terrain Haze v1.3

2012-05-02 Thread Renk Thorsten
The runway effect parameters override any parameters it has in common with the terrain-default effect (since it inherits from it), it is not a bug, that's how the system is supposed to work. I don't know, it doesn't strike me as consistent. There are two control structures here:

Re: [Flightgear-devel] Terrain Haze v1.3

2012-05-02 Thread Renk Thorsten
No, you got the system wrong. When an effect inherits from another it rewrites those parts that are common between the two xml files, keeping the parts that are different. Yes, but what's wrong with making that conditional based on technique number? What functionality would this destroy?

[Flightgear-devel] 'Black model problem'

2012-05-02 Thread Renk Thorsten
So far we had: start with skydome shader on and landmass set to 4: - models appear black and are not shaded properly Click on landmass slider without changing the value: - modelss jump to proper shading I've made one more observation: Do the above at noon. Then change to dawn - models remain

Re: [Flightgear-devel] 'Black model problem'

2012-05-02 Thread Renk Thorsten
Using tied properties as uniforms? I don't think so, because the same parameters do get updated per frame just fine when shading the terrain. * Thorsten -- Live Security Virtual Conference Exclusive live event will

Re: [Flightgear-devel] 'Black model problem'

2012-05-02 Thread Renk Thorsten
Hmm, that would be really strange, and a legitimate bug then. Worth a try with the property filter to see if that fixes them. That's actually how terminator-relative-position-m (the sun position for shader purposes) is done - see Environment/local-weather-rules.xml * Thorsten

Re: [Flightgear-devel] 'Black model problem'

2012-05-02 Thread Renk Thorsten
Sorry, was looking at the wrong shader. You don't assign the terminator to an uniform in the technique n=5 in the model-default.eff. I'll be buggered... you're right. How embarrassing... * Thorsten -- Live Security

Re: [Flightgear-devel] Terrain Haze v1.3

2012-05-01 Thread Renk Thorsten
Hi Heiko, Okay, so cloud and terrain shaders on both detail levels perform okay, but the skydome shader doesn't come on - one can see the mismatch between terrain and sky in the distance, and there's no scattering effect at all in the sky. Which means we need to find the reason why, and

[Flightgear-devel] Texturing questions.

2012-05-01 Thread Renk Thorsten
I would like to ask a few opinions on the following points: I've been experimenting with regional textures after Stuart's re-organization of materials.xml, and I have a few nice adaptions which I would like to suggest. For instance, one can use 18th_century_city.png to texture cities in

Re: [Flightgear-devel] Terrain Haze v1.3

2012-04-30 Thread Renk Thorsten
I did try that- after some more tryings with different settings I found out that I didn't know yet that it only works with advanced weather AND at high altitudes (above 10.000ft!!) Agreeing somewhat with Fred, the screenshots don't make it easy to see what is going on, as there is neither

Re: [Flightgear-devel] Random Buildings improvements - phase 1

2012-04-30 Thread Renk Thorsten
I've just checked in a change so the buildings now use the Effects system properly, which includes a global cache of the textures. This might help. Nice - have to try this. Btw - could you take a look at the ambient value of the material declaration? I have the feeling it is very low, I'm

Re: [Flightgear-devel] Terrain Haze v1.3

2012-04-30 Thread Renk Thorsten
I tested last night with win7 and xp using ATI cards (winXP - hd3850, win7 64bit hd5870 tested with all ATI drivers since 11.4 beside the latest) and the skydome shader is crashing fgfs. The crash looks like the crash that occours if i enable the generic shader. No console output. Well,

Re: [Flightgear-devel] Random Buildings improvements - phase 1

2012-04-30 Thread Renk Thorsten
From memory, I've set it to 0.3. It is configurable in the data/Effects/buidling.eff file under parameters/material/ambient if you want to have a look yourself. I'm happy to accept a change to the value - I haven't spent any time tuning it. Okay, that explains it. I think it should be in

Re: [Flightgear-devel] Terrain Haze v1.3

2012-04-27 Thread Renk Thorsten
The direct link to the merge request is usually handy. Will do next time. Effects/terrain-default.eff has two techniques number 4. They seem similar Could you check ? Aarg... GIT strikes again. The two blocks with technique 4 are identical copies - one of them can go. Must be my screwup

Re: [Flightgear-devel] Terrain Haze v1.3

2012-04-27 Thread Renk Thorsten
It also seems that some model are not lighted anymore : http://frbouvi.free.fr/flightsim/fgfs-haze-1.3.gif The only place models get the effect is if they go via Effects/model-default.eff if they're using their own effect file they are not in the scheme. In addition, neither the random

Re: [Flightgear-devel] Terrain Haze v1.3

2012-04-27 Thread Renk Thorsten
That problem goes away if landmass shader is disabled. The strange thing is that when set to some value, the problem appears but as soon as you click on the landmass slider, without changing the value, the problem goes away too. Is this anything I could have caused? Because I have no idea

Re: [Flightgear-devel] Terrain Haze v1.3

2012-04-27 Thread Renk Thorsten
I have no idea too. It looks like an uninitialized value that get one when we click on the slider. Do you reproduce the problem I see ? For some (yet to be determined) reason the shader settings are not archived on Flightgear exit in my local devel branch since my next-to-last update three

Re: [Flightgear-devel] Terrain Haze v1.3

2012-04-27 Thread Renk Thorsten
Do you reproduce the problem I see ? Okay, found the problem with userarchive and eliminated it Now I see the same thing you describe, the model shader doesn't start up correctly, but all goes well once one just clicks the slider. The model shader doesn't seem to be doing anything at all,

Re: [Flightgear-devel] Terrain Haze v1.3

2012-04-27 Thread Renk Thorsten
This doesn't happen when you click on another slider or when we start at 1. Should be something specific to landmass. Tenuous, but: Terrain and models are sent to the same shader code (terrain-haze.*) by the effect file technique 5. To switch the detailed terrain rendering on, I used the

Re: [Flightgear-devel] Issue 717: Disabling advanced weather crashes the sim

2012-04-26 Thread Renk Thorsten
So, maybe we could find a better method of switching between the weather systems - though this isn't the main issue here. Using radio buttons or a drop-down list would be a more standard way to toggle between alternatives. Otherwise, just updating (and maybe moving) the button descriptions

[Flightgear-devel] Terrain Haze v1.3

2012-04-26 Thread Renk Thorsten
I've just created a merge request containing the recent work I've done for the haze shaders (haze in water shader, dust effect, Mie scattering on clouds, ...). The procedure described in the wiki to create a merge request did not work for me, I could not push a local branch containing my

Re: [Flightgear-devel] GIT as of today unstable

2012-04-25 Thread Renk Thorsten
What about the mentioned problems? Better? Worse? A quick 3 minute test flight with the ufo looks very promising - I didn't see any obvious issues with the version pulled 10 minutes ago. I will do longer tests later toady. * Thorsten

Re: [Flightgear-devel] Random Buildings

2012-04-25 Thread Renk Thorsten
Hm... I'm getting good performance, but the rendering of the random buildings do not seem to go via model-default.eff - they respond to the normal visibility, but not to the terrain haze layer, so they remain visible when I turn on heavy ground fog. Is there a conceptual problem, or can this be

[Flightgear-devel] Issue 717: Disabling advanced weather crashes the sim

2012-04-25 Thread Renk Thorsten
Hooray alerted me to that one, and I would like to ask a few opinions on what to do and offer my own thoughts. *What steps will reproduce the problem?* 1.F10-Environment-Weather-Advanced Weather 2.Select METAR 3.Return to Basic weather *What is the expected output? What do you see

[Flightgear-devel] GIT as of today unstable

2012-04-24 Thread Renk Thorsten
I've just pulled and compiled simgear and flightgear and pulled a fresh FGData to start package the next lightfield shader version, but it turns out the resulting binary is unstable. I get segfaults about 10 seconds after startup with the master branch, no other errors written to the console,

Re: [Flightgear-devel] GIT as of today unstable

2012-04-24 Thread Renk Thorsten
I had similar problem this weekend, and a full rebuild (simgear + flightgear) solved the issue. I have the sentiment that changes to SGReferenced (in simgear) could have created this instability I pulled everything fresh and compiled both simgear and flightgear new, so things shouldn't be out

Re: [Flightgear-devel] GIT as of today unstable

2012-04-24 Thread Renk Thorsten
Can you get a backtrace? Okay, following your instructions I did make clean in any of my build folders, ran cmake with -DCMAKE_BUILD_TYPE=Debug added, recompiled simgear and flightgear, and did gdb ./fgfs run --log-level=info --airport=KSFO --disable-real-weather-fetch --disable-fullscreen

Re: [Flightgear-devel] GIT as of today unstable

2012-04-24 Thread Renk Thorsten
Oops, missed that part of the instructions *blush* Here's the output: (gdb) bt #0 0x5e3d9a08 in ?? () #1 0x088dd542 in hashForAirport (c=0x13bedd28, apt=0xdcd3988) at /home/fgfs/CMake/flightgear/src/Scripting/NasalPositioned.cxx:113 #2 0x088ddc29 in f_airportinfo (c=0x13bedd28, me=

Re: [Flightgear-devel] GIT as of today unstable

2012-04-24 Thread Renk Thorsten
Okay, this is my fault, but I don't know why / how it's crashing for you. Presumably you have some aircraft or nasal that makes additional airportinfo() calls, and you've managed to find a test-case that my testing has not encountered. Unfortunately we need to find out the relevant

Re: [Flightgear-devel] Water shader issues

2012-04-23 Thread Renk Thorsten
Bertrand, apparently I am really doing a bad job expressing myself. After having read this long post, I had mixed feelings. Posts that start by something like First of all, I find that you are all doing a great job are, in most cases, intended to tell the exact opposite. This is not one of

Re: [Flightgear-devel] Water shader issues

2012-04-23 Thread Renk Thorsten
There's the problem Thorsten. I didn't have the info or the knowledge to do the second bit. Neither you nor Emilian honestly could have come up with something like this? = var setBasicWeatherScattering = func { # establish the minimum cloud cover var max_cover = 5; for

Re: [Flightgear-devel] Water shader issues

2012-04-22 Thread Renk Thorsten
After the last related discussion, I've really been thinking a while if I should bring this up again or not. I don't want to annoy people just for the sake of it, I know open source development is often a thankless task in which one frequently gets to hear more complaints about things not

Re: [Flightgear-devel] An empassioned plea

2012-04-19 Thread Renk Thorsten
And a more simple second question, what do the developers accept as proper performance (value) in regards of frames per second. Perhaps i demand/expect too much, but 20 - 30 fps i find rather disappointing, flight is far from smooth at such numbers, but others might find that (more

Re: [Flightgear-devel] An empassioned plea

2012-04-19 Thread Renk Thorsten
What do people think about dynamically scaling the eye candy to meet a target framerate? Define 'the eye candy' and you'll spot the problem. In general, the performance-driving factors are (not an exhaustive list) 1) visibility range, i.e. number of terrain vertices in the scene 2) cloud

Re: [Flightgear-devel] Random Buildings

2012-04-18 Thread Renk Thorsten
Before and after screenshots: Before - http://www.nanjika.co.uk/flightgear/buildings-old.jpg After - http://www.nanjika.co.uk/flightgear/buildings.jpg Wow, this looks pretty good! Why are there buildings on the street though - isn't that a different landclass? Does this have to an US-style

Re: [Flightgear-devel] Random Buildings

2012-04-18 Thread Renk Thorsten
However, one of the issues I'm hitting right now is that I have to avoid overlapping buildings by binning buildings that are too close to other buildings. As density increases you get more overlapping, and spend more time binning points, so scenery loading starts taking longer. Create a

Re: [Flightgear-devel] An empassioned plea

2012-04-18 Thread Renk Thorsten
What *is* the baseline hardware fg ought to be aiming at? I guess in practice every developer works such that stuff runs well on his own system. What else can we do? I'm not buying a second computer just to test how it would run on a Mac. Advances in quality always requires more resources.

[Flightgear-devel] Snow questions

2012-04-16 Thread Renk Thorsten
I've implemented the snow shader effect into lightfield rendering yesterday - this looks quite promising already: http://www.flightgear.org/forums/viewtopic.php?f=47t=14755start=165#p155463 but I have a few questions I've come across? I've tried to use /environment/snow-level-m to control the

Re: [Flightgear-devel] Water shader issues

2012-04-14 Thread Renk Thorsten
I don't think your analysis can be correct; I don't particulary care. In my version of the shader, the problem is fixed for good and performance is improved, I've posted the code which does it, if you prefer your version of the code for whatever reason, be my guest. Likewise, if you and

Re: [Flightgear-devel] Now Rembrandt here...

2012-04-13 Thread Renk Thorsten
I have the same bug when the skydome scattering shader is enable. Are you sure you have disable skydome scattering shader ? Look, I literally wrote the part of the effect file that controls what shaders run when the skydome shader is enabled and what shaders don't, I did a fair share of the

[Flightgear-devel] Shader - Environment interfacing issues

2012-04-13 Thread Renk Thorsten
I've made a case study converting the high quality water shader (my favourite shader effect :-) ) to lightfield rendering in the last two days (see some pics in the forum here http://www.flightgear.org/forums/viewtopic.php?f=47t=14755start=150#p155110 sunrises with water reflection look

Re: [Flightgear-devel] Shader - Environment interfacing issues

2012-04-13 Thread Renk Thorsten
(*)No it's not bad design, it's a conscious hack around the state that the environment interface was in when the shader was developed. Something like a property rule or a Nasal script outside the shader would have done the trick as well... But I'm not arguing why it's done the way it is, and

Re: [Flightgear-devel] Shader - Environment interfacing issues

2012-04-13 Thread Renk Thorsten
Emilian proposes the weather system to be agnostic about the shaders, not the shaders to be agnostic about weather. Advanced Weather works based on abstraction layers. The high levels are unaware of any technical issues ('we have a tile with 6/8 Nimbostratus coverage and light rain'), as the

Re: [Flightgear-devel] Shader - Environment interfacing issues

2012-04-13 Thread Renk Thorsten
To be safe you need to limit yourself to 32 float varyings. Note: a vec3 counts as 3 float varyings, a vec4 as 4 etc. Okay thanks, then I am safe. Btw (spotted this while checking) - is there any particular reason to compute a normal from gl_Normal in the vertex shader, use a full varying

Re: [Flightgear-devel] Shader - Environment interfacing issues

2012-04-13 Thread Renk Thorsten
Apart that the earth is a sphere and ocean tiles are large pieces of terrain where the curvature is quite apparent, how whould you define flat ? 'flat' = 'For any visibility we can actually render, the normal (before wave noise) is (0,0,1) in model space to such a good approximation that you

[Flightgear-devel] (no subject)

2012-04-13 Thread Renk Thorsten
'flat' = 'For any visibility we can actually render, the normal (before wave noise) is (0,0,1) in model space to such a good approximation that you won't spot the difference to the actual normal including earth curvature if I show you a picture.' Cheers, * Thorsten That will give

Re: [Flightgear-devel] Shader - Environment interfacing issues

2012-04-13 Thread Renk Thorsten
If it looks right in one limited test case, doesn't mean it's right, or the proper way to deal with it (so it won't backfire later on) Look, basic ray optics says that the error in ray propagation I make by neglecting the curvature is linear proportional to the error in normal angle which I

[Flightgear-devel] Water shader issues

2012-04-13 Thread Renk Thorsten
Plus, if you neglect the curvature effect in every relevant vector, the rendering artefacts at the tile boundaries must go away, because the differences in rendering geometry between tiles go away, and they're the only thing which can introduce the artefacts in the first place. Turns

Re: [Flightgear-devel] Now Rembrandt here...

2012-04-12 Thread Renk Thorsten
I think that is what we have for now. You can do better by increasing your shadow map size to 8192 or 16384, but at the 16384 resolution my performance goes into the tank, and at 8192, there are still many shadow artifacts due to lack of resolution. (clearly blocky/xelated/aliasing edges,

Re: [Flightgear-devel] Now Rembrandt here...

2012-04-12 Thread Renk Thorsten
The disappearing shadow was caused by the sun camera and range animation and was fixed a while back - can you confirm that you are using the very latest fg/sg/fgdata? And it's probably worth checking that you have the very latest nVidia drivers. FG, SG and FGData are pulled and

Re: [Flightgear-devel] No Rembrandt here...

2012-04-11 Thread Renk Thorsten
The first line says it all. Okay... so what does it mean? I'd first try to reduce the size of the shadow map : --prop:/sim/rendering/shadows/map-size=1024 No success, problem persists. or reduce the window size : --geometry=800x600 to reduce the memory footprint. Same as above, problem

Re: [Flightgear-devel] No Rembrandt here...

2012-04-11 Thread Renk Thorsten
Be sure I value your feedback, but we are exploring new lands here. There is not so much OSG deferred rendering example or real application around, so please be forgiving. And I don't think Flightgear is unusable for anybody. The Rembrandt renderer is optional and the classical/2.6 renderer

[Flightgear-devel] No Rembrandt here...

2012-04-10 Thread Renk Thorsten
Just freshly pulled and compiled GIT, fresh FGData master, trying to start with --enable-rembrandt results in garbage on the screen and an impressive list of errors - (I've omitted messages with meaning known to me in the following as well as repetitions). Running without Rembrandt looks fine

Re: [Flightgear-devel] More Rembrandt Feedback

2012-04-05 Thread Renk Thorsten
No moon shadows? I see a long discussion coming up about how unrealistic this all is ;-) Did we not have a discussion a while back about our nights being too dark? I think moonlight would be great, but we would need to take into account the phases of the moon. Something to do as a

Re: [Flightgear-devel] Earthview - Orbital terrain rendering in FG

2012-03-27 Thread Renk Thorsten
Hi Mathias, thanks for the detailed answer. That indeed helps a lot. May I ask a follow-up question? I typically prepare a lot of things that are usually sensible and helpful for its own but with such a final goal in mind. Once all is set up in place I just need to grab into the black hat

[Flightgear-devel] Spaceflight patches

2012-03-22 Thread Renk Thorsten
Independent of using Earthview or not, I've found that the following series of code modifications makes Flightgear support flights into low orbits (without Earthview, you can enjoy a fogged sphere, but without the changes, JSBSim models never reach high enough and rendering artefacts (grey

[Flightgear-devel] Skydome shader rendering artefact

2012-03-22 Thread Renk Thorsten
I guess most people are aware of the rendering artefact in the skydome shader. I've made an observation which might shed some light into what it happening. Under most angles, the artefact appears as a thin light grey line with subtly mismatched colors to both sides of it. However, under some

Re: [Flightgear-devel] Earthview - Orbital terrain rendering in FG

2012-03-22 Thread Renk Thorsten
For anyone who wants to have a look at Earthview in action, I've made the first version available for download here: http://www.flightgear.org/forums/viewtopic.php?f=6t=15754#p153257 (I have the next higher resolution level textures as well, but they're too large to host for me). Anyway, this

Re: [Flightgear-devel] Earthview - Orbital terrain rendering in FG

2012-03-21 Thread Renk Thorsten
Before going into more detail, you might want to check with Mathias' recent work to integrate space-view into FlightGear. Otherwise you'll probably be doing duplicate work. Well, if Mathias could simply comment on the issue? What can we expect at what timescale? (And how do you know

Re: [Flightgear-devel] Earthview - Orbital terrain rendering in FG

2012-03-20 Thread Renk Thorsten
Once you understand how the scattering integrals work it's natural to compute them also from the outside of the atmosphere. Okay, now I am *really* confused. Are we trying to solve the same problem? Light scattering in the atmosphere is not part of what Earthview does at all. That is

[Flightgear-devel] Project dynamics (was: Earthview - Orbital terrain rendering in FG)

2012-03-19 Thread Renk Thorsten
You haven't really looked at any of my designs so far, have you? Nice trick - didn't work Martin, I have no clue what the point of this is. I'm in the habit of trying to say what I think as clearly as possible, rather than trying to play tricks (I've been hanging around in international

Re: [Flightgear-devel] Earthview - Orbital terrain rendering in FG

2012-03-19 Thread Renk Thorsten
You ought to be able to initialize any vehicle at any altitude (up to and even beyond 3000 km). At this time, only the Vostok has control jets, as far as I know. Actually I can not do that. Trying to initialize the ufo at 1.000.000 ft works fine, and so does flying the ufo to the altitude.

Re: [Flightgear-devel] Earthview - Orbital terrain rendering in FG

2012-03-18 Thread Renk Thorsten
When balancing different arguments I'd recommend to consider this one as well: Backing out a kludge after it's been adopted by the users, detangling additional hacks which start building on top of the mentioned kludge is highly ungrateful work most of the time. You haven't really looked at

Re: [Flightgear-devel] Earthview - Orbital terrain rendering in FG

2012-03-17 Thread Renk Thorsten
Before going into more detail, you might want to check with Mathias' recent work to integrate space-view into FlightGear. Otherwise you'll probably be doing duplicate work. Well, if Mathias could simply comment on the issue? What can we expect at what timescale? (And how do you know these

Re: [Flightgear-devel] Two small weather issues

2012-03-11 Thread Renk Thorsten
the hardcoded value of 1000.0m is now settable at runtime with /sim/rendering/minimum-sky-visibility and defaults to 1000m, so the default behaviour is unchanged. For the precipitation effect, I'm currently working on exposing most of the effect's properties to the property tree and

[Flightgear-devel] Moonlight

2012-03-11 Thread Renk Thorsten
Now that lightfields are in GIT, it occurred to me that we could have moonlight with this bit of technology relatively easy (before anyone mentions Project Rembrandt, I was thinking of rendering cloud layers in the moonlight, or snow-covered mountain ranges, i.e. for any distance from high

[Flightgear-devel] Window glass reflection effects

2012-03-10 Thread Renk Thorsten
I have a request to aircraft developers. I was trying the DR400 yesterday, and I liked the plane as such quite well - but the canopy glass effect spoiled all my fun. The reflection effects are just way too strong. I have a similar problem with the cockpit windows of the CRJ700 which also dull

Re: [Flightgear-devel] auto-coordination

2012-03-09 Thread Renk Thorsten
Ok I haven't entirely given up on the idea of removing the auto-coordination from the code. Why? Wouldn't it be more appropriate to add that rudder control to controls.nas? Nasal runs per graphical frame, FDMs may need to run faster at low framerates. Nasal AP systems tend to become

Re: [Flightgear-devel] Lightfields to GIT

2012-03-08 Thread Renk Thorsten
I've just tested the runtime-switchable lightfield with GIT as of 30 minutes ago, and it seems to run just fine. If anyone would care to pick it up, here is the link: http://users.jyu.fi/~trenk/files/terrain-haze-v1.2.tgz In fact, choosing a technique index of 7 has the pleasant side effect

Re: [Flightgear-devel] auto-coordination

2012-03-08 Thread Renk Thorsten
I could add a check every time autopilot is engaged to disable it while autopilot is active , but my real question is , can it be removed from the code ? It consists of three lines in flightgear/src/Aircraft/controls.cxx , but it seems that this should be handled by the autopilot system.

<    1   2   3   4   5   >