Re: [Flightgear-devel] Iceland textures

2012-12-17 Thread Frederic Bouvier
Hi,

>  //use additional convergence speed-up
> #ifdef USE_QDM_ASCEND_INTERVAL
> if(frac(level*0.5) > EPSILON)
>   level++;
> #elseif USE_QDM_ASCEND_CONST
>  level++;
> #endif

Try :

#ifdef USE_QDM_ASCEND_INTERVAL
 if(frac(level*0.5) > EPSILON)
   level++;
#elif defined(USE_QDM_ASCEND_CONST)
  level++;
#endif

Regards,
-Fred

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Iceland textures

2012-12-17 Thread Renk Thorsten
> Apparently that's ok now, another issue cropped up in the  
> urban-lightfield
> shader, something wrong with an #if:
>
> FRAGMENT glCompileShader  
> "/home/chris/FlightGear/Shaders/urban-lightfield.frag"
> FAILED
> FRAGMENT Shader "/home/chris/FlightGear/Shaders/urban-lightfield.frag"  
> infolog:
> 0:196(22): preprocessor error: syntax error, unexpected IDENTIFIER,  
> expecting
> NEWLINE
> 0:193(1): preprocessor error: Unterminated #if

That seems to be in this block of code


 //use additional convergence speed-up
#ifdef USE_QDM_ASCEND_INTERVAL
if(frac(level*0.5) > EPSILON)
  level++;
#elseif USE_QDM_ASCEND_CONST
 level++;
#endif

which is a literal copy of what FredB did in urban.frag - the syntax here is 
somewhat unfamiliar to me and I don't know precisely what the effect is doing 
here - maybe Fred can comment what could be wrong with this?

* Thorsten
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Scenery manager

2012-12-17 Thread Adrian Musceac
On Sunday, December 16, 2012 23:11:44 Mathias Fröhlich wrote:
> Hi,
> 

Hi all,

I have added my new code for far-tiles in a merge request for flightgear and 
simgear. You can now test the code, and also check whether texture resizing is 
necessary for materials which are not inside the near tiles (during an osg 
cache cycle).
Piggy-backing on this is the map display used for testing. Feel free to use or 
discard that code. I used it for testing, and have a property check to switch 
it on or off, but I didn't mess with the GUI in fgdata.

Cheers,
Adrian

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] [Flightgear-commitlogs] SimGear branch, next, updated. fd39808ed8e0926f4389e2d8ad700a48354646a1

2012-12-17 Thread Thomas Geymayer
Am 2012-12-17 10:09, schrieb James Turner:
> Thomas, I think you may have forgotten to git add nasal_traits.hxx?

May be possible :) Should be complete now...

Tom

-- 
Thomas Geymayer  www.tomprogs.at / C-Forum und Tutorial: www.proggen.org

  Student of Computer Science @ Graz University of Technology
--- Austria 

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] [Flightgear-commitlogs] SimGear branch, next, updated. fd39808ed8e0926f4389e2d8ad700a48354646a1

2012-12-17 Thread James Turner

On 17 Dec 2012, at 00:04, Flightgear-commitlogs wrote:

>Nasal cppbindings: automatic conversion of vec2 to/from Nasal

Thomas, I think you may have forgotten to git add nasal_traits.hxx?

James


--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Performance

2012-12-17 Thread Renk Thorsten


Well, we did have

 
greater
0.01
  

everywhere in the cloud  effect files. So it's not clear to me how transparent 
fragments should even make it to the shader (?). Maybe I'm still confused about 
something...

* Thorsten
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] Scenery manager

2012-12-17 Thread Renk Thorsten
> There are many issues and tradeoffs with mesh simplification.  There are
> many algorithms and approaches, each with their own unique strengths and
> weaknesses.  Challenges include finding a strategy to hide the cracks
> between adjacent tiles draw with different levels of details (and  
> possibly more or less details on the edges.)  You also have issues of objects
> floating or being partially (completely) burried if the underlying  
> terrain becomes coarser or more detailed (or you have to move the objects up 
> or
> down which can also be odd looking.)

As I said previously, I wouldn't compute the simplified mesh online - I would 
compute it offline and store it in addition to the regular mesh on disk - if 
the simplified mesh has a factor 10 lower linear resolution, it has a factor 
100 less data and is hence just 1% more to store on disk.

Dropping mesh points offline, you can require that no vertices from the tile 
edges are ever dropped, hence a multiple tile mesh will stay continuous and 
never have cracks.

Objects should no longer be visible for tiles where we start seriously 
considering LOD schemes. We can render 40-50 km visibility of hires scenery 
just fine - so if I hear terrain LOD, I'm thinking how to simplify the mesh 
more than 50-60 km away, and objects from that distance are really a non-issue.

> So there is always the universal principle that it's faster to do less
> work.  But styles and algorithm popularity is a moving target as hardware
> is a moving target

In this case, I think it's rather straightforward. I don't have Curt's 
experience of course, but:

* terrain starts to get 'really nice' with rivers actually following valley 
bottoms and nice curving roads with a factor 10 or so (probably even more) 
better  linear resolution than default terrain. 

* a realistic visibility from 33.000 ft in clear weather is close to 1000 km, 
not the 120 km max. we offer

If we want to get 'realistic' in the present scheme and just go ahead and 
render full detail, memory requirements grow parametrically by a factor 10.000 
- you need to have that *before* you talk about algorithms to render it. Now, 
my impression is that currently the memory outfit of new computers  grows by 
about a factor 2 every 4 years. To get the factor 10.000, we need the hardware 
from about 50 years from now if the trend doesn't slow down (which it will, 
because there is a lower limit how small structures on a chip can be before 
quantum effects kick in and your memory chip becomes a random number generator).

Which, for me, is just screaming 'LOD scheme!'.

Well, just my two cents... 

* Thorsten
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel