Re: [Flightgear-devel] Re: error compiling fresh fgrun cvs

2005-02-25 Thread Jorge Van Hemelryck
On Fri, 25 Feb 2005 08:43:29 +0100
Melchior FRANZ wrote:

> I had the same problem. fgrun does since very recently use threads, but fltk
> hadn't been compiled with threads on SuSE 9.2. (I dropped them a line and hope
> that they'll change that in the next release.) Seems that FC2 suffers from the
> same problem. You need to compile fltk with "--enable-shared 
> --enable-threads".

It happened to me too on Mandrake 10.1. I grabbed the source rpm,
installed it, modified the spec file fltk.spec in /usr/src/RPM (yours
would probably be in /usr/src/redhat) so that the line with ./configure
in the %build section would end with "--enable-shared --enable-threads".
Then I typed rpm -ba /usr/src/RPM/fltk.spec, and ended up with fresh new
packages (libfltk1.1 and libfltk1.1-devel) in /usr/src/RPM/RPMS/i586
(yours might be in /usr/src/redhat/RPMS/i386).

You might need to --force the rpm install afterwards, because rpm might
complain that it is already installed.

You can find the source there, for instance:

ftp://rpmfind.net/linux/fedora/extras/3/SRPMS/fltk-1.1.4-8.src.rpm

-- 
Jorge Van Hemelryck

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] hang on mac os x with latest simgear/fg source + 3.3 gcc

2005-02-25 Thread ima . sudonim
There is a hang in isnan() during fg start if simgear is built using 
gcc 3.3 compiler (which I installed about two months back) on mac os x.

Due to a variety of issues (mostly the weather 8-) ), I've not been 
able to look at this problem until recently, but I've got a fix for it 
that I'll give below.

Under gdb, breaking into the hang I have:

No bindings for joystick 9
Joystick 9 not found
^C
Program received signal SIGINT, Interrupt.
isnan(double) (r=0) at soundmgr_openal.cxx:40
40  inline int (isnan)(double r) { return isnan(r); }
(gdb) Quit
(gdb) Quit
(gdb) bt
#0  isnan(double) (r=0) at soundmgr_openal.cxx:40
#1  0x00316ccc in SGSoundMgr::set_source_pos_all(float*) 
(this=0x1457cd50, pos=0xb440) at soundmgr_openal.cxx:40
#2  0x4e50 in fgMainLoop() () at ../../src/Main/globals.hxx:290
#3  0x87521e18 in -[GLUTApplication run] ()
#4  0x8753bd28 in glutMainLoop ()
#5  0x75b8 in fgMainInit(int, char**) (argc=1, argv=0x5c39ec) at 
main.cxx:958
#6  0x31e0 in main (argc=1, argv=0x15fd5e00) at bootstrap.cxx:192
(gdb)

Program received signal SIGINT, Interrupt.
isnan(double) (r=0) at soundmgr_openal.cxx:40
40  inline int (isnan)(double r) { return isnan(r); }
(gdb) stepi
40  inline int (isnan)(double r) { return isnan(r); }
(gdb) u isnan
isnan(double) (r=0) at soundmgr_openal.cxx:40
40  inline int (isnan)(double r) { return isnan(r); }
(gdb)
---
The fix is to modify src/simgear/simgear/sound/soundmgr_openal.cxx as 
follows:

The original (1.16) reads:
#if defined (__APPLE__)
// any C++ header file undefines isinf and isnan
// so this should be included before 
inline int (isinf)(double r) { return isinf(r); }
inline int (isnan)(double r) { return isnan(r); }
#endif
the fix is to replace the above with:
#if defined (__APPLE__)
#  ifdef __GNUCC__
#if __GNUCC__ == 3
#  if __GNUC_MINOR >= 3
#include 
#  endif
#endif
# else
// any C++ header file undefines isinf and isnan
// so this should be included before 
inline int (isinf)(double r) { return isinf(r); }
inline int (isnan)(double r) { return isnan(r); }
#  endif
#endif
Looks like the undefining of isnan, at least, is fixed using gcc 3.3 on 
mac os x. Could someone please check this fix into CVS?

Thanks!
Ima
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Camera/FOV/View Frustum question.

2005-02-25 Thread Manuel Massing
Hello again,

sorry, I didn't read your whole mail, so my response 
was probablly not relevant to your problem.

> Going back to my original query.  My little experiment to pan the view
> frustum side to side using this technique worked great in all the
> external views, but totally screwed up the outside world in view #0 ...
> I ended up with extreme overzoom and no panning relative to the outside
> scenery, but the 3d cockpit worked ok and panned as I was hoping it would.

This is just a wild guess, but it might have to do with the near-far 
clipping planes being changed for the scenery rendering in renderer.cxx. 
This results in an update of the frustum parameters, so maybe you will need to
reapply your viewport modifications at different stages?

Manuel

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Camera/FOV/View Frustum question.

2005-02-25 Thread Manuel Massing
Hello Curtis,

> First let me explain what I need to do.  I need to configure an
> "asymmetric view frustum".  I need to place 3 monitors next to each
> other, aligned along a flat plane.  The view drawn in each monitor needs
> to be projected on that same flat plane.  I cannot just set a view
> offset for the side channels because the view won't come out right.  If
> I simply rotate the view offset and take a symmetric view frustum, the
> plane of projection will be perpendicular to the viewer in each
> channel.  That won't work for this particular application and it's not
> what I need.  I need to configure an actual asymmetric view frustum for
> each side channel.  If someone thinks they can help me, but is confused
> by my description, I'm happy to explain this further.  Think about this

I hope the attached camera class might help you - I implemented support for
off-center and tiled projections for a similar project (powerwall
rendering).

The parts that probably interest you are in update_frustum() and the
parameters set via the setTiling(...) method.

hope to help,

 Manuel
/***
  Camera.cpp  -  description
 ---
begin: Thu Apr 18 2002
written by   : Manuel Massing
email: [EMAIL PROTECTED]
 ***/

/***
 * *
 *   This program is free software; you can redistribute it and/or modify  *
 *   it under the terms of the GNU General Public License as published by  *
 *   the Free Software Foundation; either version 2 of the License, or *
 *   (at your option) any later version.   *
 * *
 ***/

#include "Camera.h"

Camera::Camera()
{
	n = 1.0f;
	f = 4000.f;
	fov = 45.f;
	eye_separation = 0.f;
	focal_length = 2000.f;

	resx = 1; resy = 1;
	llx = lly = 0;
	aspect = 4.f/3.f;;
	tile_t = tile_r = 1.f;
	tile_b = tile_l = 0.f;
	frustum_dirty = orientation_dirty = obj2clip_dirty = true;
}

void Camera::update_frustum() const
{
	if (frustum_dirty) {
		// Calculate the symmetric frustum extent at focal distance.
		float frustum_top = focal_length*tanf(fov*M_PI/360.f);
		float frustum_left = -frustum_top*aspect*((tile_t-tile_b)/(tile_r-tile_l));

		// Adapt frustum to desired viewport region.
		t = (2.f*tile_t - 1.f)*frustum_top;
		b = (2.f*tile_b - 1.f)*frustum_top;
		l = (1.f - 2.f*tile_l)*(frustum_left - eye_separation);
		r = (1.f - 2.f*tile_r)*(frustum_left - eye_separation);

		float rescale = n/focal_length;
		t*= rescale;
		b*= rescale;
		l*= rescale;
		r*= rescale;
	
		local_clipplane[cpNear] = Plane(Vector3d(0.f, 0.f, -1.f), n); // near
		local_clipplane[cpFar] = Plane(Vector3d(0.f, 0.f, 1.f), -f);  // far

		Vector3d cpn(n, 0, l);
		cpn*=1.f/cpn.length();
		local_clipplane[cpLeft] = Plane(cpn, 0);  // left

		cpn = !Vector3d(-n, 0, -r);
		local_clipplane[cpRight] = Plane(cpn, 0); // right

		cpn = !Vector3d(0, -n, -t);
		local_clipplane[cpTop] = Plane(cpn, 0);   // top

		cpn = !Vector3d(0, n, b);
		local_clipplane[cpBottom] = Plane(cpn, 0);// bottom

		frustum = Matrix4x4( 2.f*n/(r - l),  0.f, (r + l)/(r - l),   0.f,
		 0.f,2.f*n/(t - b),   (t + b)/(t - b),   0.f,
		 0.f,0.f,-(f + n)/(f - n),  -2.f*f*n/(f - n),
		 0.f,0.f,-1.f,   0.f);


		#ifdef LOGGING
		if (hasLogfile())
			get_logfile().setItem("fov", fov);
		#endif

		frustum_dirty = false;
		obj2clip_dirty = true;
	}
}

void Camera::update_modelview() const
{
	if (orientation_dirty) {
		if (vp == vpLookAt) {
			Vector3d xAxis, zAxis, tmp_up = up;

			zAxis = !(lookat - pos);
			xAxis = !cross(zAxis, tmp_up);
			tmp_up = !cross(xAxis, zAxis);

			Matrix3x3 rotation = Matrix3x3(xAxis, tmp_up, -zAxis).transpose();
			modelview = Matrix4x4(rotation, rotation*(-pos - eye_separation*xAxis));
		}
		else if (vp == vpTargetRoll) {
			Vector3d xAxis, zAxis, tmp_up = up;
			zAxis = !(lookat - pos);
			// Make sure we are not looking down the y-axis
			if (!zAxis.x && !zAxis.z)
tmp_up = Vector3d(-zAxis.y, 0.f, 0.f);
			else
tmp_up = Vector3d(0.f, 1.f, 0.f);

			xAxis = !cross(zAxis, tmp_up);
			tmp_up = !cross(xAxis, zAxis);

			Matrix3x3 rotation = Matrix3x3(xAxis, tmp_up, -zAxis).transpose();
			Matrix3x3 camroll;
			camroll.setRotateZ(roll);
			rotation = camroll * rotation;
			modelview = Matrix4x4(rotation, rotation*(-pos - eye_separation*xAxis

RE: [Flightgear-devel] Camera/FOV/View Frustum question.

2005-02-25 Thread Norman Vine
Curtis L. Olson writes:
> 
> First let me explain what I need to do.  I need to configure an 
> "asymmetric view frustum".  

..
 
> For what it's worth, I think the same issue is happening with the "TR" 
> tiled rendering routines that generate the ultra-highres tiled screen 
> shots ... that code suffers the same problem in view #0 with the outside 
> world seen through extreme overzoom (i.e. you only get a tiny, itsy, 
> bitty bit of the outside world expanded to fill the screen.)

Not very helpful but I think you are correct about this being the 
'same issue'

FWIW I never did figure out exactly what was causing this but IIRC 
this was a problem even when I implemented the TR view but was 
not an issue for me as I was only interested in the '2D' panel' if any 
when not in exterior view mode.

Norman



___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] xml sound : Does negative pitch work?

2005-02-25 Thread Paul Surgeon
I'm busy hooking up the sounds for a vario but can't get the sink tone to 
work. I'm using the vertical speed property to test against.

Here is the my xml sound config for the sinking tone :

  
sinkcue
looped
Aircraft/LAK-19/Instruments/ILEC_SC-7/sink-tone.wav

  

/instrumentation/vertical-speed-indicator/indicated-speed-fpm
-50
  


  0.3
  0.3


  
/instrumentation/vertical-speed-indicator/indicated-speed-fpm
  0.001
  1.0

  

As you can see I've configured the tone to start playing when the vertical 
speed drops below -50 fpm. That works perfectly.
However the pitch doesn't change - it loops (with an annoying click) and stays 
at a constant pitch regardless of what I throw at the pitch config.

According to the docs the pitch is calculated like this when the factor is 
positive :
value += factor[n] * function(property[n])

So if the indicated-speed-fpm = -300 and the factor = 0.001 the intermediate 
value for pitch should be equal to -0.3 (the default function is linear)

The final calculation is  value = offs + value
With the offset = 1.0 the final value of the pitch should be
1.0 + (-0.3) = 0.7
This is not happening.

BTW : There is a typo in the README.xmlsound doc.
"volume = offs + value;" should read "value = offs + value;" since it's the 
same logic for both volume and pitch according to the doc.

I also tried changing the factor to -1.0 which mathematically isn't what I 
want but it has no effect either!

Am I doing something wrong or is something broken?
Thanks
Paul

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


RE: [Flightgear-devel] Camera/FOV/View Frustum question.

2005-02-25 Thread Giles Robertson
> world seen through extreme overzoom (i.e. you only get a tiny, itsy, 
> bitty bit of the outside world expanded to fill the screen.)

This isn't the same problem - and won't help you - but does anyone else
see visual corruption when loading up view 0 for the first time, that
clears when you reset the system, but not before? I see a view where
every polygon has been drawn with at least one corner at a vanishing
point in the centre of the screen - I've not been able to trace the
source, but the error occurs on both MingW and MSVCC binaries, and it
makes me wonder what view 0 actually does?

Giles Robertson
(ATI 9700/Win XP)

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d