Re: [Flightgear-devel] No rudder (yaw) control using SAITEK X52 joystick

[Mark]

Hi,

i just took a look at the file $FGROOT/Input/Joysticks/Saitek/X52.xml 
which configures the X52.
Apparently the rudder was commented out. That's why it's not working.

To get it working change this line

!--axis n=3

into

axis n=3


and
 /axis--

into

 /axis


using any paintext editor you like (like notepad on Windows).

Hope this helps,

Mark



J.J. Brennan wrote:
 I have  a SAITEK X52 joystick which works with other sims, but not with 
 Flightgear (on the YAW axis, the others are all ok).

 Any ideas as to how I can fix this will be appreciated!

 JJ

 -
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and take
 control of your XML. No limits. Just data. Click to get it now.
 http://sourceforge.net/powerbar/db2/
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel
   

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] No rudder (yaw) control using SAITEK X52 joystick

[Mark]

If that's not an Freudian slip ;-)

Olaf Flebbe wrote:
 Hi,

   
 using any paintext editor you like (like notepad on Windows).
 

 Very indeed, notepad is a pain :-)

 Olaf

 -
 This SF.net email is sponsored by DB2 Express
 Download DB2 Express C - the FREE version of DB2 express and take
 control of your XML. No limits. Just data. Click to get it now.
 http://sourceforge.net/powerbar/db2/
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel
   

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] The sun is rendered as rectangle?

[Mark]

Hi Tat,

in 0.9.10 the sun was represented by a sphere and a square texture for 
the halo.
So what your seeing is actually the halo texture. At sundown the whole 
object is tilted and so it looks like a triangle, because you just don't 
see the the other half of the texture. There's nothing wrong with this.

However there seems to be a problem with transparency / alpha channel in 
your build. Normally the halo blends in smoothly and the edges aren't 
visible.
Maybe this helps to point you in the right direction.

I'd also check the PLIB version used, as Martin already said.
 
Mark

Tatsuhiro Nishioka wrote:
 Hi,

 I'm working on building 0.9.10 (universal binary) on Mac OS X (Tiger)  
 and I experienced a weird behavior that the sun is always rendered as  
 a white rectangle, or a yellow diamond, depending on time. The size  
 of a rectangle is much larger than the size of the sun. This happens  
 only in this build.
 It's hard to say but It's like a big tile covers the sun.
 This happens on both PPC Mac (PowerBook G4 with GeForce FX Go5200)  
 and  Intel Mac (Core 2 Duo MackBook Pro with ATI x1600).
 So I'm sure this is not a hardware or driver related problem.

 Plus, It doesn't happens in the previous 2 builds (0.9.9 or 0.9.10  
 ppc only release), so I'm wondering if I'm missing something.
 Have any of you encountered such a problem?
 Any help will be appreciable.

 What I use to build FlightGear are:
FlightGear soure: 0.9.10 release (from a mirror at  
 www.flightgear.org site)
FlightGear data : 0.9.0 base package / from cvs with  
 RELEASE_0_9_10 tag
Apple-OpenGL 1.4.13.2.0
Apple-AGL 2.5.9
Apple-GLUT 3.3.9
Apple-OpenAL  1.1
PLIB 1.8.4
SimGear 0.3.10

 Thanks,

 Tat

 ---
 Tatsuhiro Nishioka
 Mail: [EMAIL PROTECTED]
 ---




 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel
   

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] The sun is rendered as rectangle?

[Mark]

Hi again,

I'm pretty sure it's not a problem with Simgear. After all the code has 
been this way for 3-4 years.

I've had analog problems when developing the sun code in cvs.
When there isn't a file for the texture or the file is defective, the 
texture is displayed as a solid square.
Or it's filled with a red-white checkerboard (depending on platform).
If you have Gimp, please take a look at 
FG-base-dir/Textures/Sky/halo.rgba and see if it's ok.

Also make sure your not using the data-package from cvs because the 
sun-textures were redone/renamed.
And of course the GL/GLUT versions should be up to date (which they 
probably are - didn't check that :-)

Are there any errors on the console when running?

Mark

Tatsuhiro Nishioka wrote:
 On Nov 18, 2006, at 9:34 AM, Martin Spott wrote:
   
 PLIB 1.8.4 is very old and was released with known bugs, some of the
 features in FlightGear require PLIB CVS in order to work correctly.  
 I'm
 completely uncertain if this relates in any way to the geometry of the
 sun, but you could at least have a try,
 

 Thanks!
 I checked out the plib cvs and built fgfs, which made me to change  
 GUI/dialog.c a bit but it's OK.
 I compiled everything and ran it finding the same rectangle... sigh.

 On Nov 18, 2006 at 10:42 PM, ppm wrote:
   
 This might not be 'help'..., but certainly same thing happens here:
  iBook G4 with ATI Mobility Radeon 9200

 I tested both 0.9.10 PPC / Universal. Sun itself seems rendered same
 on two versions.
 But surrounding light ('flare'?) doesn't seem rendered correctly.

 Thank you for your work on Universal version, Tat!
 

 You're welcome and thanks for the report. it helps me a lot!
 What you said is exactly the same as I see here, so this is not the  
 hardware specific problem.
 Now I'm searching a target to lock on. so let me give some more time ;-)


 On Nov 19, 2006, at 1:09 AM, Mark wrote:
   
 in 0.9.10 the sun was represented by a sphere and a square texture for
 the halo.
 So what your seeing is actually the halo texture. At sundown the whole
 object is tilted and so it looks like a triangle, because you just  
 don't
 see the the other half of the texture. There's nothing wrong with  
 this.

 However there seems to be a problem with transparency / alpha  
 channel in
 your build. Normally the halo blends in smoothly and the edges aren't
 visible.
 Maybe this helps to point you in the right direction.

 I'd also check the PLIB version used, as Martin already said.
 

 I really appreciate your help. I've read SimGear / PLIB source and  
 now have the same opinion.
 This rendering is done at simgear/scene/sky/oursun.cxx, especially in  
 halo related methods / funcs.
 Weird thing about this is that it draws the sun as almost big solid  
 color rectangle.

 As two different versions of PLIB have the same result, I think it  
 has something to do with SimGear.
 I'm changing some code so I can try and error about this.
 Or should I try another version of SimGear?

 ---
 Tatsuhiro Nishioka
 Mail: [EMAIL PROTECTED]
 ---




 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel
   

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] GPL Violation?

[Mark]

Hi all,

I'm not sure if these kind of auctions we've been noticing are real GPL 
violations.
This one doesn't make any note of the fact that their simulator is 
Free Software.
And it doesn't mention the GPL nor that the source is available - which 
is a violation in my opinion.

Nevertheless, what bugs me on these auctions is not that they are making 
money with FG (if they are?).
It's actually they way they do it, since most of these free-riders are 
trying to trick potential customers to believe FG was a commercial 
flight sim.
An they're clearly making misleading statements about the features (e.g. 
the screenshot of the landing on San Jose).

So, to make an end to this kind of deception, why don't we display a 
small message on the start-up screen like this:

FlightGear is free software and distributed under the terms of the GPL . 
Visit us at http://www.flightgear.org

That way we make a clear statement where the software originates.
If we hard-code it, the average reseller won't be able to change it.
And if he does we have something to clearly prove a violation (if we had 
a copy).


Actually the fact that people are trying to market FlightGear actually 
is the best proof of how sophisticated and professional FG has become.
Take it as a compliment to all the developers who put so much effort in 
this great simulator.
And maybe we can learn a bit on marketing from these people, too?

Just my 2 cents,

Mark

Curtis Olson wrote:
 Someone just directed me to the following ebay vendor selling FlightGear.

 http://cgi.ebay.com.au/Realistic-Professional-Aviation-Flight-Simulator_W0QQitemZ260053619883QQihZ016QQcategoryZ80336QQrdZ1QQcmdZViewItem

 At first glance I thought, no big deal, just another person selling a 
 distribution of FlightGear.  But wait a second: this person is selling 
 it as a digital download.  So they are charging people money for the 
 right to download flightgear, when they could just as easily (well a 
 lot more easily) download it for free.

 The more I think about it, the more I have a problem with this.  If 
 they were selling FlightGear on CD, or on floppies, or on reels of 
 tape, or punch cards, or even printed versions of the source code, I 
 would have absolutely no problem.  That is specifically allowed for in 
 the GPL, and the vendor can set whatever price they want.

 But here they are not selling anything.  Can we call what they are 
 selling a distribution?  The rights to download something that is 
 already available for free download?

 So my questions:

 1. Am I right to be concerned about this?

 2. Is there any outright GPL violation going on here?

 3. If there is a GPL violation, how should we go about addressing it 
 (and legitimate, legal methods only please.)

 Thanks,

 Curt.
 -- 
 Curtis Olson - University of Minnesota - FlightGear Project
 http://baron.flightgear.org/~curt/ 
 http://baron.flightgear.org/%7Ecurt/  http://www.humanfirst.umn.edu/ 
   http://www.flightgear.org
 Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
 

 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys - and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 

 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel
   

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Flight Sim Development

[Mark]

I've taken the time and summed it up for all those, who don't want to 
read through all of it.

Basically the comments for improvement focus on three areas:

1. Usability
- controls said to be confusing ( if your used to msfs/x-plane? )
- new users are clueless how to use FG / features
- fgrun is not shipped with FG in most Linux distributions (new 
users prefer a graphical frontend even on Linux)
- tutorials and user education are missed
- creating new aircraft is seen as tedious
- customizing things by editing files is perceived as too geeky 
(users would like a GUI for everything...)
 
2. Performance
- framerate is lower than in other flightsims

3. Eyecandy
- airplane textures could be of higher resolution
- graphics / shading could be improved
- scenery is said to be lacking details (objects)
- unfinished planes


I also noticed many of the features that users say they would like 
already exist but users simply don't know of them or don't know how to 
use them (e.g. multiplayer functionality).
Since some of this has been already documented, I conclude they have 
problems in finding the information they need.

Overall the comments are mostly positive and especially the 
Linux-community has been very happy about the progress made in recent 
versions.
Actually many of the complaints made in older posts have been remedied. 
Also the realism and accuracy is often pointed out as positive.
Windows users and MSFS/X-Plane users are a bit more negative in their 
comments. It also appears many simply don't understand the way open 
source projects evolve.

Hope this puts it in a nutshell,

Mark



Jon S. Berndt wrote:
 Today, I was wondering what's someone else's take on FlightGear
 is, so I did some googling and came across this thread:
 http://forums.x-plane.org/lofiversion/index.php?t16495.html

 Happy reading,
 Ampere
 

 This is actually useful feedback, I believe. Some of it is on target and
 valid.

 Jon


 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys -- and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel
   

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] ocean rendering regression

[Mark]

Hi Melchior,

I was able to reproduce this. It seems to have to do with specular 
highlights, since it's only visible, if this option is not deactivated 
on the commandline.
Wasn't able to see this before, because I have that turned off for 
performance reasons.

At the first glance it it seems to have to do with the materials rather 
than the sun.
How do they both interact exactly?

Anyway, I looked into my code and tried some changes that could affect 
this. However there wasn't any impact.
So, to say the truth, I'm a bit clueless as to where this effect is 
coming from.
Any ideas?

How can I checkout a copy of sg/fg before the commit of my code?
This way I could see it it's indeed a bug I caused.

Mark


Melchior FRANZ wrote:
 * Melchior FRANZ -- Saturday 26 August 2006 10:05:
   
 or the whole ocean is very pale (also see new harrier splash screen,
 though it can be worse).
 

 Worse, as in this screenshot:

http://members.aon.at/mfranz/ocean-pale.jpg  [15 kB]

 m.

 -
 Using Tomcat but need to do more? Need to support web services, security?
 Get stuff done quickly with pre-integrated technology to make your job easier
 Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel
   

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] ocean rendering regression

[Mark]

I reverted to the version of the day previous to the introduction of the 
new sun coloring.
At first I though the artifacts Melchior recognized weren't there.
However, after a second Flight  from EDNY they also appeared:

http://www.akermann.org/fgfs/fgfs-screen-1.jpg
http://www.akermann.org/fgfs/fgfs-screen-2.jpg

I suppose the effect wasn't that visible before since the sun color was 
much less bright then.
So contrast wouldn't be as much and it is first visible if you increase 
visibility.

Then I checked material.xml, as Eric indicated and found it is indeed 
the specular component causing the effects.
If you change it to 1 the artifacts are drastically visible on tile 
edges; with 0.1 there almost gone.
But then the specular highlights are gone of course.

Another thing I noticed is that the drawn highlights cover almost the 
entire  tile.
This might be OK for some materials, but for water there should be a 
rather sharp highlight.
Maybe this was changed and now is causing the trouble?


Mark


Melchior FRANZ wrote:
 * Mark -- Saturday 26 August 2006 14:19:
   
 I was able to reproduce this. It seems to have to do with specular 
 highlights, since it's only visible, if this option is not deactivated 
 on the commandline.
 

 Not here. I see it with and without. (nvidia driver version 8756)

 m.

 -
 Using Tomcat but need to do more? Need to support web services, security?
 Get stuff done quickly with pre-integrated technology to make your job easier
 Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel
   

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Update: Sun

[Mark]

Hi Melchior,

that's OK. The code has to fit to the existing codebase and so I'll tidy 
it up a bit.
I just didn't look at those details. No problem.

CU Mark

Melchior FRANZ wrote:
 * Mark -- Thursday 20 July 2006 20:31:
   
 After it is in cvs I'd be happy for some feedback and suggestions for 
 improvement.
 

 Here's some already, mostly formal problems. (I'm the pedant here.)
 The important aspects seem to be OK.


   fgGetNode(/environment)); 

 ... in a constructor. Although the existence of the /environment is
 pretty much guaranteed, we still make sure that the node gets created:

   fgGetNode(/environment, true));
 


 --
 consistency:

 +SGPath ihalopath = path , ohalopath=path;

 Now, what is it? spaces around '=' (good) or not? Space in front of
 comma operator?

 +i_halo_color[0] = 1- (1.1* red_scat_f);
 +o_halo_color[0] = 1- (1.4* red_scat_f);

 Operators sticking on numbers at several places. Either spaces around
 operators (good IMHO) or not. Or is they kind of unary operators?  :-}


 --


 indentation:

 +ohalo-setCallback( SSG_CALLBACK_PREDRAW, sgSunHaloPreDraw );
 +ohalo-setCallback( SSG_CALLBACK_POSTDRAW, sgSunHaloPostDraw );
 +
 +   sun_transform-addKid( ohalo );
 +   sun_transform-addKid( ihalo );

 What about aligning those correctly?


 --


 +  if ( env_node ){
 +  env_node-setDoubleValue(atmosphere/altitude-troposphere-top,r_tropo 
 - r_earth);
 +  env_node-setDoubleValue(atmosphere/altitude-half-to-sun, alt_half);
 +  }

 Umm ... what about indenting that correctly?
 Yes, I know, the existing code isn't consistent either. But that's no
 reason to make the situation worse.

 m.

 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys -- and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel
   

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Update: Sun

[Mark]

Hi Vassilii,

it is indeed an debugging artifact. At least the using namespace std is.
The rest was existing code. I'll see what I can change.
As for the vector math, I didn't change any of that and this is all from 
the original implementation.
And I don't really want to fuzz with that.

Mark

Vassilii Khachaturov wrote:
 http://www.akermann.org/fgfs/simgear-sun.tar.gz
 
 The chunk
 @@ -109,6 +109,7 @@ void SGSky::build( double h_radius_m, do
  // 180 degrees = darkest midnight
  bool SGSky::repaint( const SGSkyColor sc )
  {
 +   using namespace std;
  if ( effective_visibility  1000.0 ) {
 enable();
 dome-repaint( sc.sky_color, sc.fog_color, sc.sun_angle,
 seems a debugging artifact to me.

 In oursun.cxx the constants (such as sqrt_m_log01) should probably be
 declared as const. Per-coordinate vector calculations there could be
 made to use the sg facilities of plib, but AFAIU it wouldn't change
 much except for shorten the code a tiny bit. It's pretty readable as it is
 anyhow, and fits in very nicely. Also, a patch to Thanks is due along
 with the commit, to mention yourself :)

 Thank you very much!!!

 Vassilii


 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys -- and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel
   

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Update: Sun

[Mark]

After doing some cleanup the patches are ready for review and 
(hopefully) committing to cvs again.

The new versions are here:
http://www.akermann.org/fgfs/halos.tgz
http://www.akermann.org/fgfs/flightgear-sun-2006072201.tgz
http://www.akermann.org/fgfs/simgear-sun-2006072201.tgz

I tried to do some changes on the halo-texture but there was no 
difference, so I'll leave the old one in the package for now.
The code was cleaned and polished and I must admit it wasn't very 
consistent.
Since there are many people involved in this project it's necessary to 
keep to certain conventions.-)
I didn't touch the vector calculations as Vassilii suggested though.

OK, still awaiting comments and suggestions,

Mark

BTW: Is it better to have one big file with all diffs concatenated or to 
provide a file for every file changed?



Melchior FRANZ wrote:
 * Mark -- Thursday 20 July 2006 20:31:
   
 After it is in cvs I'd be happy for some feedback and suggestions for 
 improvement.
 

 Here's some already, mostly formal problems. (I'm the pedant here.)
 The important aspects seem to be OK.


   fgGetNode(/environment)); 

 ... in a constructor. Although the existence of the /environment is
 pretty much guaranteed, we still make sure that the node gets created:

   fgGetNode(/environment, true));
 


 --
 consistency:

 +SGPath ihalopath = path , ohalopath=path;

 Now, what is it? spaces around '=' (good) or not? Space in front of
 comma operator?

 +i_halo_color[0] = 1- (1.1* red_scat_f);
 +o_halo_color[0] = 1- (1.4* red_scat_f);

 Operators sticking on numbers at several places. Either spaces around
 operators (good IMHO) or not. Or is they kind of unary operators?  :-}


 --


 indentation:

 +ohalo-setCallback( SSG_CALLBACK_PREDRAW, sgSunHaloPreDraw );
 +ohalo-setCallback( SSG_CALLBACK_POSTDRAW, sgSunHaloPostDraw );
 +
 +   sun_transform-addKid( ohalo );
 +   sun_transform-addKid( ihalo );

 What about aligning those correctly?


 --


 +  if ( env_node ){
 +  env_node-setDoubleValue(atmosphere/altitude-troposphere-top,r_tropo 
 - r_earth);
 +  env_node-setDoubleValue(atmosphere/altitude-half-to-sun, alt_half);
 +  }

 Umm ... what about indenting that correctly?
 Yes, I know, the existing code isn't consistent either. But that's no
 reason to make the situation worse.

 m.

 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys -- and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel
   

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Update: Sun

[Mark]

Hi,

since I have finished the integration of my suncode in the environment 
I'd like to set the implementation in the wild.
So far everything is ready for committing it to cvs. The patches are here:

http://www.akermann.org/fgfs/simgear-sun.tar.gz
http://www.akermann.org/fgfs/flightgear-sun.tar.gz

The changes include modifications in simgear as well as in flightgear 
and should be committed to both at the same time.
There's also the sun-texture pack that has to be put into cvs including 
these textures:

Textures/Sky/inner_halo.rgba
Textures/Sky/outer_halo.rgba
Textures/Sky/sun.rgba

You can find the texture pack here:
http://www.akermann.org/fgfs/halos.tgz

After it is in cvs I'd be happy for some feedback and suggestions for 
improvement.
You can change the sun's appearance by changing altitude and visibility 
and it also will react to humidity (which is out of the users control).


TIA,

Mark

P.S.: Who can I send patches for simgear without penetrating the list?

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] A New Sun

[Mark]

Aurorae would be a nice addition indeed.
Basically they could be simulated by using many squares with a 
translucent texture.

Haven't had any problems with transparency or coloring of the sun, though.
The problem Steve addressed is actually caused naturally because the 
graphics-cards cut out hard-looking edges on overlapping objects.

Mark

Lee Elliott wrote:
 I once tried to do some aurorae using very large 3d objects and 
 while I could see them ok I couldn't get any colour in to them - 
 they just looked white and the transparency I used in the 
 texture was ineffective, so I could see the entire object, sharp 
 edges and all  :(

 dunno if you might have the same problem with using a 3d object 
 for the sun.

 Haven't got around to trying it yet but meteors might work ok.

 LeeE

 On Sunday 16 July 2006 20:14, Mark wrote:
   
 Hi Curt,

 I've been thinking about the idea with the cylinder the last
 days. What I like about it is, that this way the fog of the
 distant objects is thicker at ground-level and gets thinner
 with increasing altitude. And it's less stress on the hardware
 than shaders.
 The cylinder could be part of the SGSky class, maybe as
 atmosphere-object.

 But I want to get the sun ready before touching anything else.
 So if anyone else would like to try out implementing the
 cylinder, that would be great.-)

 Bye, Mark

 Curtis L. Olson wrote:
 
 Mark wrote:
   
 Hi Steve,

 which line do you mean? The surface of the earth cutting of
 the sundisc? I agree this looks too sharp but I don't know
 how this could be improved with standards means.
 At least the sun's halos are blended with the fog already.
 
 I've been wondering about placing a short cylinder between
 the sky dome and the terrain.   This would have fog color
 at the base and blend to completely transparant at the top. 
 This would help hide the outer fringe of the tiles in some
 circumstances, and it would allow things like the sun and
 moon to blend smoothly into the true horizon.  This could
 also help with sky dome - earth transition problems in
 various areas.  We might consider moving this cylinder up
 and down to match the current view point altitude.  This
 should be really easy to implement without needing any fancy
 opengl tricks (maybe make it part of they sky dome model),
 but I just haven't had time to try it out.

 Curt.
   
 --
 --- Using Tomcat but need to do more? Need to support
 web services, security? Get stuff done quickly with
 pre-integrated technology to make your job easier Download IBM
 WebSphere Application Server v.1.0.1 based on Apache Geronimo
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057;
 dat=121642 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel
 



 -
 Using Tomcat but need to do more? Need to support web services, security?
 Get stuff done quickly with pre-integrated technology to make your job easier
 Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel
   


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] RFC: A new sun

[Mark]

Hi there!

After some time of coding and restructuring I finally managed to clean 
up the repaint-code using the property-tree as interface for the data 
between fg and sg. Now everything is calculated where it's supposed to 
be: Environmental data in fg's environment, positional data in the 
reposition code and color in repaint. Nice and clean ;-)

I'm using the following property-tree nodes for interaction between the 
sun-code and the environment:

/environment/relative-humidity   // data for repaint
/environment/atmosphere/density-tropo-avg// data for repaint

/environment/atmosphere/altitude-half-to-sun // data for calculating 
avg density
/environment/atmosphere/altitude-troposphere-top   // data for 
calculating avg density

Is the location of the nodes ok, or should I move them somewhere else?

I'm really happy about the solution with the property tree.
Since everything is working fine, I can address the other points in the 
coming days.

Mark

Melchior FRANZ wrote:
 * Melchior FRANZ -- Monday 10 July 2006 20:24:
   
 If you let fgfs tell sg which node to get the density from, and
 make this a node with tied getter function, [...]
 

 Or, illustrated with some code:


 fgfs:

   static double calc_density() {
  // stuff
  return density;
   }

   void Whatever::bind() {
fgTie(/calculate/density, calc_density);
   }

   void Whatever::unbind() {
fgUntie(/calculate/density);
   }


 now you tell sg that it can have the density from /calculate/density,
 and whenever sg or anyone else reads that property, the density is
 calculated freshly (and only then).

 m.


 -
 Using Tomcat but need to do more? Need to support web services, security?
 Get stuff done quickly with pre-integrated technology to make your job easier
 Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel
   


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] A New Sun

[Mark]

Hi Curt,

I've been thinking about the idea with the cylinder the last days.
What I like about it is, that this way the fog of the distant objects is 
thicker at ground-level and gets thinner with increasing altitude.
And it's less stress on the hardware than shaders.
The cylinder could be part of the SGSky class, maybe as atmosphere-object.

But I want to get the sun ready before touching anything else.
So if anyone else would like to try out implementing the cylinder, that 
would be great.-)

Bye, Mark

Curtis L. Olson wrote:
 Mark wrote:
   
 Hi Steve,

 which line do you mean? The surface of the earth cutting of the sundisc?
 I agree this looks too sharp but I don't know how this could be improved 
 with standards means.
 At least the sun's halos are blended with the fog already.
   
 

 I've been wondering about placing a short cylinder between the sky dome  
 and the terrain.   This would have fog color at the base and blend to 
 completely transparant at the top.  This would help hide the outer 
 fringe of the tiles in some circumstances, and it would allow things 
 like the sun and moon to blend smoothly into the true horizon.  This 
 could also help with sky dome - earth transition problems in various 
 areas.  We might consider moving this cylinder up and down to match the 
 current view point altitude.  This should be really easy to implement 
 without needing any fancy opengl tricks (maybe make it part of they sky 
 dome model), but I just haven't had time to try it out.

 Curt.

   


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] RFC: A new sun

[Mark]

Great! I wasn't aware that the property tree could also trigger 
functions after they are bound.
So now I'll have to see how I can integrate my code with fg's environment.
I hope i'll have some time for this on the weekend.

Thanks alot,

Mark

Melchior FRANZ wrote:
 * Melchior FRANZ -- Monday 10 July 2006 20:24:
   
 If you let fgfs tell sg which node to get the density from, and
 make this a node with tied getter function, [...]
 

 Or, illustrated with some code:


 fgfs:

   static double calc_density() {
  // stuff
  return density;
   }

   void Whatever::bind() {
fgTie(/calculate/density, calc_density);
   }

   void Whatever::unbind() {
fgUntie(/calculate/density);
   }


 now you tell sg that it can have the density from /calculate/density,
 and whenever sg or anyone else reads that property, the density is
 calculated freshly (and only then).

 m.


 -
 Using Tomcat but need to do more? Need to support web services, security?
 Get stuff done quickly with pre-integrated technology to make your job easier
 Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel
   


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] A New Sun

[Mark]

Hi Steve,

which line do you mean? The surface of the earth cutting of the sundisc?
I agree this looks too sharp but I don't know how this could be improved 
with standards means.
At least the sun's halos are blended with the fog already.

Actually the reason for the less sharper look in real life is 
diffraction caused by the higher temperature of the air, which washes 
out the sharpness.
Since there is no support for atmospheric effects in OpenGL this 
probably only could be done with special shader-programs.
However, I don't know how to program them yet and since they aren't used 
in Fg already and there's an ongoing discussion about using OSG anyway, 
i suppose this won't be an option in the near future.

Mark

Steve Knoblock wrote:
 Thank you for doing this.

 I love accurate meteorology, sky conditions and astronomically correct
 sky. It looks very photographic with the exception of the halo. One
 thing that always bothered me was when the sun disc is close to the
 horizon, the line seems too well defined. Where the extended sun glare
 disc meets the horizon it is very sharp. Beyond that the fog obscures
 the horizon line. Is there some way to blend the sun more smoothly
 into the horizon?

 Steve


 Back to our regularly scheduled programming...for(i=0;i=10;i++) { print i }


 -
 Using Tomcat but need to do more? Need to support web services, security?
 Get stuff done quickly with pre-integrated technology to make your job easier
 Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel
   


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] RFC: A new sun

[Mark]

Hi Durk,

The previous sun implementation was very fine. Actually I only changed 
maybe 20%.
Finetuning, if you like. So you did a great job on that.

I also made the same observation with the halo turning to be more of an 
ellipse at the horizon.
Actually the sun gets squeezed too and this is related to the horizon 
effect we are already using.
Since we are using textures now for everything, it shouldn't be too hard 
to emulate this in the horizon-effect code.

Hm, yes, the outer halo. Well, I made this texture really quickly and it 
probably could be improved so that it blends better.
But I still think the problem is mainly that the colors of the skydome 
and fogcolor don't fit the halo's color.

CU Mark




Durk Talsma wrote:
 On Sunday 09 July 2006 19:03, Mark wrote:
   
 Hello everybody,

 I've been experimenting with a redone implementation of the sun in simgear.
 My goal is to create a more acurate looking sun that also has more
 variability in its appearance.
 I'm pretty much done and like to ask for comments and advice.

 For those of you who'd like to take a look at my current results:

 http://www.akermann.org/fgfs/sun_light_yellow.jpg
 http://www.akermann.org/fgfs/sun_yellow.jpg
 http://www.akermann.org/fgfs/sun_orange.jpg
 http://www.akermann.org/fgfs/sun_white.jpg

 

 This looks great. The original sun changes color near the horizon scheme 
 was 
 done by me, and if I recall recorrectly has been fine tuned by various people 
 over the years. The original scheme has always been a bit of a hack waiting 
 for a proper implimentation, and I would consider your atmosphere based code 
 to be exactly that. Thanks for your contribution. 

 I agree with other people commenting that the edge of the halo looks a bit 
 too 
 explicit, but I believe that's something that can be fine tuned.

 Another thing to consider is that while the halo is oftentimes more or less 
 circular when the sun is high in the sky, I get the impression it compresses 
 as the sun sinks toward the horizon, and blends in with the rest of the 
 (reddish) sky. I never really came up with a good solution to do this, so 
 I've always left the halo as a perfectly round disk.

 Cheers,
 Durk


 -
 Using Tomcat but need to do more? Need to support web services, security?
 Get stuff done quickly with pre-integrated technology to make your job easier
 Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel
   


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] RFC: A new sun

[Mark]

Hi,

I looked at the rain code and it seems a more elegant solution than what 
I've done so far.
I just passed the needed info as elements of a struct which I filled 
with the same get-methods in renderer.cxx.

However, as it appears you can only read and set the information in the 
property tree. But what I would need is a function I could call that 
calculates some values. So even when I would use the set-methods to put 
my data in the property tree, this wouldn't be adequate.

The reason for this is that I'm considering the average density along 
the light-path.  This is necessary because it can differ vastly 
depending on the planes position and results without this aren't 
realistic. 

For example,  take two positions, in which the distance of the 
light-path is equal  but the altitude of the observer is different. The 
sun will be much more yellowish for the observer at a lower altitude 
because the average density is higher and there's more scattering taking 
place.

Also the light-path can go through areas of higher and lower density if 
the observer is at a higher altitude and the sun is setting.
In this case the light first travels through low density arriving from 
the sun, then higher density at earth-level and then again traverses low 
density air at the observer.
So only taking the observers density and the density at the top of the 
atmosphere in account is not going to act as a accurate substitute.

To figure out the average altitude I determine the density at the 
observers position, the density at about 8-16 km (depending on the lat 
due to different thickness of the stratosphere at the poles and the 
equator) and the density at the half of the distance the light travels 
through the stratosphere.
This gives a rough idea of the average density that is good enough for 
our purposes.

So ideally I would have to pass an altitude to the function and it 
should return the density at that height.
But then the environment code is in Flightgear. I could, however, put 
the code somewhere else in Simgear, but what's the sense to scatter 
basically the same type of functions around different parts of fg/sg?

I don't know. Any Ideas?

Mark






Melchior FRANZ wrote:
 * Mark -- Sunday 09 July 2006 19:03:

 Looks beautiful, indeed. (Only the outer halo border is a bit too
 obvious.  :-)



   
 Right now i'm doing alot of calculations in the repaint-method that 
 deals with enviromental values, such as humidity, visibility and density.
 This is necessary, since this kind of information currently is dealt 
 with in FlightGear's Enviroment branch. Since the sun is calculated in 
 Simgear, I can't access the information there.
 

 Look how the rain code does it. It uses default parameters, but has
 a config function in simgear/environment/visual_enviro.cxx that is
 called with a property node as argument. This is then called from
 fgfs and tells simgear where to get the 'real' parameters from.

   SGEnviro::config(const SGPropertyNode* n)

 m.


 -
 Using Tomcat but need to do more? Need to support web services, security?
 Get stuff done quickly with pre-integrated technology to make your job easier
 Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel
   


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] RFC: A new sun

[Mark]

Hello everybody,

I've been experimenting with a redone implementation of the sun in simgear.
My goal is to create a more acurate looking sun that also has more 
variability in its appearance.
I'm pretty much done and like to ask for comments and advice.

For those of you who'd like to take a look at my current results:

http://www.akermann.org/fgfs/sun_light_yellow.jpg
http://www.akermann.org/fgfs/sun_yellow.jpg
http://www.akermann.org/fgfs/sun_orange.jpg
http://www.akermann.org/fgfs/sun_white.jpg

As you can see the sun's color differs depending on weather conditions 
and time of day.
The implementation is based on the physics that actually affect the 
suncoloring.
So by figuring out the amount of Raleigh Scattering, it calculates the 
colors.

What the implementation calculates is basically the distance the light 
travels through the atmosphere (depending on sunangle and atmosphere 
thickness), the density and humidity which all influence the amount of 
scattering and uses this to determine the color.

The sun consists of three textures for the suncore, a halo directly 
surrounding the sun and an outer halo.
Each of them has a different color. The size of the halos also vary 
depending on sunangle and visibility.

Although there is more calculation done in comparision to the existing 
implementation, the effect on framerates is insignificant. At least I 
didn't notice a difference.

Now, the current glitch i'd like to ask you for advice is this:
Right now i'm doing alot of calculations in the repaint-method that 
deals with enviromental values, such as humidity, visibility and density.
This is necessary, since this kind of information currently is dealt 
with in FlightGear's Enviroment branch. Since the sun is calculated in 
Simgear, I can't access the information there.
So adding the missing calculations there wouldn't make sence and I have 
to take care of that in Simgear/the sun-code.

Any ideas how this could be done more elegantly?
What should be changed before it is commitable to cvs?


Oh, if you wan't to experiment with the implementation here's what 
you'll need:
- Textures for the halos in $FGROOT/Textures/Sky: 
http://www.akermann.org/fgfs/halos.tgz
- Patches for files in FG: http://www.akermann.org/fgfs/fgfs-diff
- Patches for files in SG: http://www.akermann.org/fgfs/simgear-diff


Mark



-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] RFC: A new sun

[Mark]

Thank you!

Yes, I agree the border looks somewhat displaced but this is actually 
because the fogcolor and the skydome don't match the sun (yet ;-).
It's noticeable especially in the picture with the Citation or if the 
sun gets orange-red while the sky's blue and the fog is pinkish.
If the sky/fogcolors would be close to the outer halo you won't notice. 

Besides the halo get's smaller the higher the sun is, so the big halo is 
actually only  visible  at angles  near the horizon.

I'll take a look at the visual_environment code these days (if it's not 
to hot to sit in front of this heater called computer...).
I hope this'll bring a solution, however i'm not quite sure if i can get 
everything out of the repaint method.
We'll see and I'll keep you informed.


@Vassilii: *g* What a compliment ;-)

Mark

Melchior FRANZ wrote:
 * Mark -- Sunday 09 July 2006 19:03:

 Looks beautiful, indeed. (Only the outer halo border is a bit too
 obvious.  :-)



   
 Right now i'm doing alot of calculations in the repaint-method that 
 deals with enviromental values, such as humidity, visibility and density.
 This is necessary, since this kind of information currently is dealt 
 with in FlightGear's Enviroment branch. Since the sun is calculated in 
 Simgear, I can't access the information there.
 

 Look how the rain code does it. It uses default parameters, but has
 a config function in simgear/environment/visual_enviro.cxx that is
 called with a property node as argument. This is then called from
 fgfs and tells simgear where to get the 'real' parameters from.

   SGEnviro::config(const SGPropertyNode* n)

 m.


 -
 Using Tomcat but need to do more? Need to support web services, security?
 Get stuff done quickly with pre-integrated technology to make your job easier
 Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel
   


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] No textures rendered with i915 graphic card

[Mark]

Actually that square is the sun's halo.
Things look this way if fg can't load the texture-files.
I'd check out the permissions and ownership of the files and directories
in FGROOT.

Also, could you provide FlightGear's output? If it's a problem with
loading the textures there should be a message.
Besides, is this the default fg of Kubuntu?

Burcu Mella wrote:

Sal 13 20:15 tarihinde, Arnt Karlsen şunları yazmıştı: 
  

On Tue, 13 Jun 2006 15:12:16 +, savas wrote in message

[EMAIL PROTECTED]:


Hi,

Simply my problem is like this:

http://img119.imageshack.us/img119/6794/f7im.jpg
  

..huh???  A square sun???  You are definetly _somethere_, but which
galaxy???  ;o)



The Sim works ok,but everything rendered without textures.I use
FG-cvs,simgear-cvs,plib-1.8.4,Kubuntu Dapper Drake.

Any other GL app works like a charm.No texture problem.

What have i miss?
  

..the url to your (root's) output of dmesg, lspci -v, glxinfo,
glxgears, and /var/log/Xorg.0.log and your fgfs commandline.



dmesg :

http://pastebin.ca/65311

lspci :

http://pastebin.ca/65312

glxinfo :

http://pastebin.ca/65313

Xorg.0.log :

http://pastebin.ca/65315

fg command line :

fgfs --aircraft=737-300 --airport=LTBA --geometry=1280x800 
--fg-root=/usr/share/games/FlightGear/ 
--fg-scenery=/home/ortak/kurulmadan_calisan/fg_scenery/



___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
  




___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] FlightGear PR; Was: In the press

[Mark]

Well, I think we should do some PR when FlightGear makes it to 1.0.
And there's also an aniversary coming up.
So by doing some PR we could get more attention, broaden our user-base
and maybe get some more developers out of it.

>From what I can see, Curt has been doing alot of PR for the project
already.
So we might just support his efforts and take some work of his
shoulders.

As for me, I could dedicate some time to this. 
However, I am not that familiar with everything and I would have to ask
around for infos.
But I'd be happy to participate in some way.

Mark

Martin Spott wrote:

  Martin Spott wrote:

  
  
As Mark already suggested, we'll try to place a larger article that
covers FlightGear when the 1.0 release happens - whenever this will
happen,

  
  
BTW, we should form a FlightGear PR department which consists of an
official press contact (where in fact all the work is being dumped  :-)
and a little 'corona' of people to whom the work should be delegated -
at least in theory.
I'd say Pigeon definitely belongs to the corona as he provides
invaluable support for the PR department with his work on the FGLive
CD. Who would like to participate, Mark ? Georg ? Does anyone like to
play the head of this department ? Somebody with limited programming
skills but with experience in this sector ?

Cheers,
	Martin.
  



___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] European Scenery Textures

[Mark]

Hi,

I also did some tweaking on the textures. What I found is that
increasing saturation does enhance contrast and makes the textures look
more natural.
And the texture borders aren't as visible as when you only increase
contrast.
Especially the mixedcrop texture benefited from more saturation.

Mark


Georg Vollnhals wrote:

 Rob Oates schrieb:

 Hi,
  
 I spent the last few days working on regional textures for Europe.
 This is just a preliminary release so I can get feedback on these
 textures. 


 Hi Rob,

 I just experimented a little with your textures, changed some content
 and made them have more contrast, did it a pretty quick and dirty way
 due to lacking time, just as a sample :-)
 Please have a look at them, do you see where the differences are
 despite of contrast/colour???

 http://home.arcor.de/vollnhals-bremen/RobTexSamp/data.zip


 This is *only* my nonverbal feedback, as all is not only a matter of
 personal taste but also of the hardware you have (screen-type, the
 parameter you use, 16,24,32 bit colour, etc.

 The disadvantage of more contrast is that you now see the texture
 boarders very clearly - and I have not adapted the single textures
 against each other.

 Second thing I will work on is the colour of the sand we have for the
 Northsea-Islands. The sand is too golden, the real colour would be
 more gray-white (or so). I changed one sand-texture but have to do all
 because otherwise there is a checkboard pattern on the islands.

 Regards
 Georg


 ---
 This SF.Net email is sponsored by xPML, a groundbreaking scripting
 language
 that extends applications into web and mobile media. Attend the live
 webcast
 and join the prime developer group breaking into this new coding
 territory!
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Textures update ...

[Mark]

Erik Hofman wrote:


 There is really no need to abandon any good texture, either from me,
 form Rob or from you. It would be great to create an excellent set
 from all available sources, no?

 Erik


Hi Erik. That's my idea, too. That way we can combine our efforts to
create formidable textures.

I took a look at your hires textures. Where did you get the images of
the fields in the irrcrop-textures from?
I was trying to create some myself that would fit better for my area,
but failed to find any suitable images of crop.
Do you still have the originals?

@Rob:

I've been flying around all evening and I can recommend flying over the
alps.
The current texture set looks good there and the tundra/herb tundra
textures look kindof alpine, too.

If there was texture-blending on the seems, it would really look great.
Well, I'm sure that'll come sometime.

Mark



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Textures update ...

[Mark]

Hi Rob!

First of all let me thank you for your contribution.
I've been experimenting with textures in FGFS myself for a while and I
know how hard it is to get to such quality textures.
So keep up the good work ;-)

When I had a first look at the textures I initially liked them better
than the default textures.

After that I also shared the opinon of Melchior and Georg about the images.
I specially modified them with increased contrast and other adapitions
which actually made them look worse.
That means more like in MS-FS 2002, which looks unnatural to me.

So being unsatisfied with that, I reverted to the default-set.
It's true that the default textures are sharper and have more contrast,
but I feel your textures do look and mix better after all.

But of course they're not perfect yet. For example the crop textures
don't actually show crop and look more like grassland / prairie.
It could look a bit more like this for southern Germany:

http://www.akermann.org/fgfs/mixedcrop.jpg

[The picture is of a unknown source, so it may not be distributed.]

The city textures are OK and do suit my local surroundings better than
the original ones, which look kinda american.
I like the town texture from the default set better, since it isn't as
dense as yours and has more vegetation.
However, since it's not available in hires, yours does look better in
the simulation.
Shrub, sand and tundra textures are definately an improvement while I
still would like to see better ones for forests and deciduous areas.
So much to my comments..

Since I've also been playing with textures, I thought I might also
contribute the better ones I created.
I did use textures from various sources and so it's not possible to
share all of them for copyright reasons.
A source I found very useful is NASA's Website:
http://visibleearth.nasa.gov/ .

You can find a texture-pack containing my snow, galcier and packice
images here:
http://www.akermann.org/fgfs/fg_phototex_ma.tgz

I would be happy to see them included in your set ;-)

Another issue I was thinking about is Copyright. As far as I could see,
you are not distributing your textures with any copyright notice.
This is ok for sharing it in the community, but actually you should name
the original source and terms of use in a file somewhere, even if they
are in the public domain.
And if the textures are used as official set, this will be a MUST.
I have provided a file for my files and you could just add your lines to
it (I actually already added your name in the header).


Mark



Georg Vollnhals wrote:

 Rob Oates schrieb:

 New scenery update!
  
 Hopefully this gets everyones blessing :)
  


 Hi Rob, hi all!

 I am very glad you are such an engaged contributer to FlightGear and
 have seen that you are improving your skills during the work.

 But I am sorry to say - after testing your latest work - that these
 textures should not be the default FlightGear textures for the next
 release.
 1. They are not universal or generic world-wide
 They might fit for US-America but absolutely not for the local area of
 Northern Europe. The old textures were not best possible but fit much
 more better if I compare it.
 2. General quality is poorer
 And the new textures are POOR IN CONTRAST especially in the areas
 where the satellite made his shots through clouds. This is also the
 main reason I am not satisfied. Poor contrast gives the impression of
 poor color display (not wrong color display).
 The old textures have more contrast and better colors.
 3. Structure sizes wrong?
 One can also discuss wheather the size of the displayed structures
 (fields, houses) are as they should be, especially comparing the
 different textures against each other.

 THIS IS NOT A PROBLEM FOR ME as I just take the old ones.
 But the impression a newcomer to FlightGear will have at first glance
 is important and therefore we should provide the new textures as an
 alternative to the old ones, not as the default.

 Rob, hat up for your work. But please understand that I frankly and
 free tell my opinion. If something replaces really good stuff in the
 FlightGear default package then it should be of higher quality than
 the old materials. You have not reached this point now with your work
 after my opinion.
 Keep on working. Get better basic photos free from cloud disturbances
 and more universal. Improve your graphic skills. Show us what you are
 able to. Accept for now your textures are a good alternative but are
 not able to hit the old ones.

 Georg EDDW






 Anyways, Thanks for everyone's input. These textures are really
 looking good!
  
 -Rob Oates




 ---
 This SF.Net email is sponsored by xPML, a groundbreaking scripting
 language
 that extends applications into web and mobile media. Attend the live
 webcast
 and join the prime developer group breaking into this new coding
 territory!
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642

Re: [Flightgear-devel] FlightGear photo scenery

[Mark]

Run time scenery bumb-mapping was already implemented some time ago by
some russian developer.
However it never made it to cvs. But I don't know why:

http://mail.flightgear.org/pipermail/flightgear-devel/2005-April/035721.html

Erik Hofman wrote:

 Buchanan, Stuart wrote:

 Hi Erik,

 Are you bump-mapping the textures at run-time? If so, how?


 Nah, just altering the textures using Gimp.
 Runtime bump-mapping would be a great addition though.

 Erik



---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] two scenery ideas

[Mark]

 Until you hear those texture where created by someone from Europe.

Hmm, not really. Actually the city textures, like builtup.rgb and
resgrid.rgb, are probably taken from satellite images of some US
resident area. At least it looks like this :-)

As far as I see it, the manual alteration of the city textures should be
kept as an option.
By default the use of the regional textures makes more sence, since
modifying every town would be just too time consuming.
Using the poligons as a virtual marker for the regions sounds good.
This way the regions can be defined much better as based on coordinates.
The question is, how difficult it would be to detect in which region you
are then.

Ultimately, the according textures might be packaged with the
scenery-tiles. This way, if we would have many MBs of
regional textures, you only would have to download the textures you need.
Well - just an idea, don't know if that would be technically possible.

So to sum it up - we already have people with textures and willing to
create new ones and populate 'the world' with them.
But so far we lack the ability to use them, since the landcovertypes are
not used by terragear at the moment, the PostGIS-DB isn't used by
terragear for scenery-generation yet and the regions aren't defined yet.

Or am I mistaken?

Mark



Martin Spott wrote:

Jon Stockill wrote:

  

We have a more european city texture already - just no way of using it 
on anything but a global scale



Obviously there are different ways to employ different city/whatever
textures. One way would be to manually re-adjust all cities over the
world and assign the appropriate textures to them.
We actually _can_ do this with the Landcover DB but this is very time
consuming and I don't think it will lead to the desired result. On the
other hand somebody could define different continents/regions for different
textures (think of: North America, South America, Central Europe, East
Euurope, Middle Asia .) and let FlightGear apply the appropriate
texture based on the current location.

We could define some polygons that surround a well-defined region and
then prepend some identifier to the texture name that matches the
according region.

Cheers,
   Martin.
  



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] two scenery ideas

[Mark]

Since there is already a PostGIS database for custom scenery
contribution in work, I assume this maybe could be added to that database?

I agree that localized textures would be a big improvement. The city
textures look good for locations in the states, but not realistic for
Europe.
But I can't see why we shouldn't use more of the landcover types anyway
if we would have suitable textures.
This would add to more diversity.

Mark


Josh Babcock wrote:

Paul Surgeon wrote:
  

On Wednesday 25 January 2006 21:44, flightgear wrote:



I noticed this, too , since the landcover data actually has a large
amount of landcovertypes that are currently ignored.
So my question is: If somebody would brew up some new textures for these
types, is there any reason for not using them?
  


The problem is that the land cover types don't contain enough info to figure 
out exactly what type of textures should be used.
Yes, we know that we need to display grass, trees, water, etc. but these 
types 
of textures need to be regional and not global like they currently are.

Grass or tree cover in the California doesn't look anything like it does in 
Germany. Crops in the USA look very different from those in the UK.
European cities look vastly different from cities outside of Europe.

I did start making some textures for FlightGear a couple of years ago but 
since there's no way to keep them local I stopped.
Adding nice desert textures to Nevada makes Europe look the same and no one 
could come up with a solution.

Paul


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel




Well, the hard part of this is setting up a database in the first place
and getting people to populate it with new entries. The database could
have the following in each entry:
1. a shape
2. a landuse type
3. a texture

I don't think it would be too hard to modify terragear with an extra
step right before the UV mapping happens. It could look in the database
and for each entry do the following:
1. Cut any poly of that land use type along the edges of the shape
listed in the DB.
2. Change the texture of any poly within that shape to the texture
listed in the database entry.

Josh



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
  



---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel