Re: [Flightgear-devel] Merge request #181
On Sunday, October 07, 2012 11:28:24 Renk Thorsten wrote: > > 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 GUI dialog, I have no memory of touching it > and the merge request did not include any changes to the dialog - this must > be some other problem (?) > > Second, the "fast"(4) water lacks specularity, is this intended? > > Hm, could this be a dds problem again - the typical symptom is lack of > specularity? I thought I had understood how the dds nature is > communicated, but I might have messed this up. I see specular reflection > with the shader. > > Third, there are lawnmower/corn rows on the detail textures, I suspect > > these > > to come from texture fetching inside conditionals, but I might also be > > wrong. > No, that's just plain old tiling of textures. One would have to optimize the > detail overlay textures further to get completely rid of it, but I'm not > really good in texture creation. I suspect some of your dds material would > be rather good overlay textures, as they're very homogeneous and low > tiling, just what one needs for the detail overlay. > > Texture fetching inside uniform int conditionals can't give you artefacts in > a scene as far as I know. > > Fourth, and I'm sorry to say this, but the (micro)stuttering is horrible > > in high detail terrain, (just staying put and rotating the view), > > Would this be the stuttering that according to Vivian is Nasal related, of > which I claimed all along that it's caused by the shader? :-) > > I still think that doing heavy work in the vertex > > shader won't cut it, it might give *you* a fps boost in corner cases, but > > the way that scenery is going it will only make matters worse in the long > > run... > I have no clue about the way scenery is going. I think the optimal solution > would be LOD levels on disk, so we have low vertex resolution at the > horizon and relatively high vertex resolution nearby. You can try to > shuffle more work to the fragment shader, but personally I'm not fond of > flying with 5 fps, so I'm not going to do it (yes, I actually tried it...). > It doesn't give me a boost in some corner cases, it makes the difference > between unflyable 5 fps and usable 15 fps. > > I never intended the procedural texturing for use in custom scenery and I > don't use it in custom scenery. All the newer aditions are optional - if > they don't perform acceptable on you rmachine, then don't use them or use > the bare atmospheric scattering scheme which hasn't changed, or switch > trees off (they're pretty expensive for me). > > I'm frankly tired of 'This needs to be faster/smoother'. No, it doesn't. I'm > not forcing anyone to use it, I put a lot of effort into cooking up ways to > make it run faster, I don't work on things outside the rendering pipeline > which determine smoothness, I'm bitching all the time about things like > the instument panel should obscure terrain here on this list which I can't > do myself, and the result is optimized as I can make it. I'm not the > miracle man, sorry. > > It's simply not productive to point out that you'd like to have it faster > and smoother - we all do, it's an open secret. > > * Thorsten 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 Cheers, Emilian -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Merge request #181
> 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 GUI dialog, I have no memory of touching it and the merge request did not include any changes to the dialog - this must be some other problem (?) > Second, the "fast"(4) water lacks specularity, is this intended? Hm, could this be a dds problem again - the typical symptom is lack of specularity? I thought I had understood how the dds nature is communicated, but I might have messed this up. I see specular reflection with the shader. > Third, there are lawnmower/corn rows on the detail textures, I suspect > these > to come from texture fetching inside conditionals, but I might also be wrong. No, that's just plain old tiling of textures. One would have to optimize the detail overlay textures further to get completely rid of it, but I'm not really good in texture creation. I suspect some of your dds material would be rather good overlay textures, as they're very homogeneous and low tiling, just what one needs for the detail overlay. Texture fetching inside uniform int conditionals can't give you artefacts in a scene as far as I know. > Fourth, and I'm sorry to say this, but the (micro)stuttering is horrible > in high detail terrain, (just staying put and rotating the view), Would this be the stuttering that according to Vivian is Nasal related, of which I claimed all along that it's caused by the shader? :-) > I still think that doing heavy work in the vertex > shader won't cut it, it might give *you* a fps boost in corner cases, but the > > way that scenery is going it will only make matters worse in the long run... I have no clue about the way scenery is going. I think the optimal solution would be LOD levels on disk, so we have low vertex resolution at the horizon and relatively high vertex resolution nearby. You can try to shuffle more work to the fragment shader, but personally I'm not fond of flying with 5 fps, so I'm not going to do it (yes, I actually tried it...). It doesn't give me a boost in some corner cases, it makes the difference between unflyable 5 fps and usable 15 fps. I never intended the procedural texturing for use in custom scenery and I don't use it in custom scenery. All the newer aditions are optional - if they don't perform acceptable on you rmachine, then don't use them or use the bare atmospheric scattering scheme which hasn't changed, or switch trees off (they're pretty expensive for me). I'm frankly tired of 'This needs to be faster/smoother'. No, it doesn't. I'm not forcing anyone to use it, I put a lot of effort into cooking up ways to make it run faster, I don't work on things outside the rendering pipeline which determine smoothness, I'm bitching all the time about things like the instument panel should obscure terrain here on this list which I can't do myself, and the result is optimized as I can make it. I'm not the miracle man, sorry. It's simply not productive to point out that you'd like to have it faster and smoother - we all do, it's an open secret. * Thorsten -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Merge request #181
On Sunday, October 07, 2012 07:44:53 Renk Thorsten wrote: > > 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 Ireland regional definitions (islands are always > easier since it's clear where the boundaries are, I know it from first-hand > experience,...) at some point - let me know if you actually start for > Scotland, because I guess there's plenty of overlap :-) > > On a related note, I've just added a new feature to the ufo: > > Ctrl+Alt+click > > displays the lat/lon/alt and landclass(es) of the clicked upon point. > > Nice - been using a customized button with a Nasal one-liner for the same > purpose so far. > > Cheers, > > * Thorsten Hi Thorsten, Some quick finds: 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. Second, the "fast"(4) water lacks specularity, is this intended? Third, there are lawnmower/corn rows on the detail textures, I suspect these to come from texture fetching inside conditionals, but I might also be wrong. Fourth, and I'm sorry to say this, but the (micro)stuttering is horrible in high detail terrain, (just staying put and rotating the view), and that stuttering at the 22-25 fps it outputs gives a much worse impression than a fluid constant 16 fps. I still think that doing heavy work in the vertex shader won't cut it, it might give *you* a fps boost in corner cases, but the way that scenery is going it will only make matters worse in the long run... (NV 8800gt here, in case that matters) Sorry for being the negative voice :) Cheers Emilian -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Merge request #181
> 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 Ireland regional definitions (islands are always easier since it's clear where the boundaries are, I know it from first-hand experience,...) at some point - let me know if you actually start for Scotland, because I guess there's plenty of overlap :-) > On a related note, I've just added a new feature to the ufo: > Ctrl+Alt+click > displays the lat/lon/alt and landclass(es) of the clicked upon point. Nice - been using a customized button with a Nasal one-liner for the same purpose so far. Cheers, * Thorsten -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Merge request #181
On Sat, Oct 6, 2012 at 9:15 PM, Stuart Buchanan wrote: > I'll take a look at the changes to GrassCover in more detail when I > get the chance. 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 :) On a related note, I've just added a new feature to the ufo: Ctrl+Alt+click displays the lat/lon/alt and landclass(es) of the clicked upon point. Unfortunately due to the way that FG builds up the material definition, we can only display the group of landclasses that this particular terrain piece matches to in materials.xml, rather than the actual landclass itself. I.e, the terrain triangle may have type GrassCover, but if the currently valid materials.xml definition for GrassCover also applies to BareTundraCover and MixedTundraCover, all three will be displayed. Nevertheless, I find it makes it much easier for me to find appropriate pieces of terrain to test/identify for material changes. -Stuart -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Merge request #181
On Sat, Oct 6, 2012 at 12:24 PM, Renk Thorsten wrote: >> 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 capture an effect here which I have > created in my devel branch with an non-GPL texture similar to the Hawaii > green and which works fine for me where I have tested it (US West coast > California, Nevada and Oregon, Himalaya and South America). But admittedly > it's a matter of taste to define this world-wide - if you do not think it > fits other areas of the world, maybe we just give it the tropical South > America header to be on the safe side. I've made the new textures only affect tropical South America, purely to ensure that I could get the changes committed and pushed to origin/master, which is now done. I'll take a look at the changes to GrassCover in more detail when I get the chance. Thanks for your work, as always! -Stuart -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Merge request #181
> 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 capture an effect here which I have created in my devel branch with an non-GPL texture similar to the Hawaii green and which works fine for me where I have tested it (US West coast California, Nevada and Oregon, Himalaya and South America). But admittedly it's a matter of taste to define this world-wide - if you do not think it fits other areas of the world, maybe we just give it the tropical South America header to be on the safe side. * Thorsten -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Merge request #181
On Fri, 5 Oct 2012, Renk Thorsten wrote: > GIT specialists - please help: I actually did not want to mix all of > these topics together, so these are sorted into three different commits, > but I just discovered I can just create a merge request for a range of > commits, but not pick one. How should I do this - or is a combined merge > request with three commits okay? > > The way I've been operating is > > * take a clean copy of a rebased master into a new branch > * edit in all the changes I want to have in the merge request, copy in all > new files > * do a merge request from there rather than from my actual devel branch > > But this doesn't seem to do what I intend (?) What you want to do is create one clean copy of master of each of your merge requests: git branch my-merge-request-42 origin/master Switch to that branch: git checkout my-merge-request-42 Then cherry-pick the changes you want to have inside this merge request (use git log your-local-development-branch to find the commit ids): git cherry-pick git cherry-pick ... Finally, push your new merge request branch to your gitorious clone and then file the merge request in the gitorious UI: git push my-gitorious my-merge-request-42 You can delete a branch you no longer want in your gitorious repository with (IIRC, you might need -f): git push my-gitorious :branch-to-remove Cheers, Anders -- --- Anders Gidenstam WWW: http://gitorious.org/anders-hangar http://www.gidenstam.org/FlightGear/ -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Merge request #181
On Friday 05 October 2012 07:01:37 Renk Thorsten wrote: > * take a clean copy of a rebased master into a new branch > * edit in all the changes I want to have in the merge request, copy in all > new files * do a merge request from there rather than from my actual devel > branch > > But this doesn't seem to do what I intend (?) Merging is done at branch level, so it's either the full branch or nothing. So to have separate merge requests you have to use separate branches. Create one branch for each feature (based on current origin/master) and use git cherry- pick to import only the relevant commits for the branch. Then you can send merge requests for these branches. Stefan -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Merge request #181
I've just created a merge request https://gitorious.org/fg/fgdata/merge_requests/181 with the following content - if Fred and/or Stuart could take a look: Weather: * bugfixes for the combined weather GUI which restore the Advanced Weather functionality * new weather scenarios corresponding to the old Advanced Weather scenario selection now also defined in METAR strings to be parsed by both systems Regional textures: * regional texture definitions for standard and procedural texturing for tropical South America (tested in and around Canaima National Park, Venezuela) Shader work in the atmospheric scattering scheme: * dust effect also added to the tree shader (looked silly otherwise...) * a lowres version of the water shader available at quality level 4 which sums only few partial waves, looks very similar to the full water sine shader from high up and runs 50% faster * vegetation effect for wet climate supposed to simulate moss and lichen cover * parameter tweaks for dawn lighting GIT specialists - please help: I actually did not want to mix all of these topics together, so these are sorted into three different commits, but I just discovered I can just create a merge request for a range of commits, but not pick one. How should I do this - or is a combined merge request with three commits okay? The way I've been operating is * take a clean copy of a rebased master into a new branch * edit in all the changes I want to have in the merge request, copy in all new files * do a merge request from there rather than from my actual devel branch But this doesn't seem to do what I intend (?) * Thorsten -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
