plib-devel

RE: [Plib-devel] Installing PLIB on a new machine

[Fay J. F C. AAC/W. <joh...@eg...>]

Gentlemen,
 
    In installing "plib_examples-1.8.4" on my new system I find that the
file "pw_pui.dsp" is missing.  I also find problems with the path to the
"glut.h" file; fixing this will take some discussion.  I see three
alternatives for Windows/MSVC systems.
 
    - We could ask the user to define an environment variable such as
"GLUT_PATH".  I don't like this because it's something that is system-wide
and not obviously related to PLIB.
    - We could include a copy of "GL/glut.h" in the PLIB distribution.  This
is not good because "freeglut", at least, is still evolving (slowly) and
there may be file incompatibility problems.  I know there aren't supposed to
be, but I do not like having two copies of a file.
    - We could specify a default location for "glut.h" in the MSVC include
directory.  In fact, the "gl.h" files are already in such a directory.
 
What do people think?
 

John F. Fay
850-729-6330
joh...@eg...
  

 

  _____  

From: pli...@li...
[mailto:pli...@li...] On Behalf Of Fay John F
Contr AAC/WMG
Sent: Thursday, April 07, 2005 10:04 AM
To: pli...@li...
Subject: [Plib-devel] Installing PLIB on a new machine



Gentlemen,

            I am moving offices-actually adding a second seat-and am
installing PLIB on the new computer.  It is a Windows machine operating from
a network drive.  On my first attempt to compile it compiled very well with
no path problems, which is an extremely good thing.  However, I got one
compiler warning message:

 

ssgAux\ssgaFire.cxx(129) : warning C4800: 'unsigned char' : forcing value to
bool 'true' or 'false' (performance warning)

 

I got a couple of other messages as well, but they were from having a copy
of PLIB that differs from the CVS copy.

 

            Frankly, I think this was a rather stringent test of compiling
PLIB and it passed, pretty much with flying colors.

 

John F. Fay

850-729-6330

joh...@eg...

[Plib-devel] Installing PLIB on a new machine

[Fay J. F C. AAC/W. <joh...@eg...>]

Gentlemen,

            I am moving offices-actually adding a second seat-and am
installing PLIB on the new computer.  It is a Windows machine operating from
a network drive.  On my first attempt to compile it compiled very well with
no path problems, which is an extremely good thing.  However, I got one
compiler warning message:

 

ssgAux\ssgaFire.cxx(129) : warning C4800: 'unsigned char' : forcing value to
bool 'true' or 'false' (performance warning)

 

I got a couple of other messages as well, but they were from having a copy
of PLIB that differs from the CVS copy.

 

            Frankly, I think this was a rather stringent test of compiling
PLIB and it passed, pretty much with flying colors.

 

John F. Fay

850-729-6330

joh...@eg...

Re: [Plib-devel] searching scenegraphs

[Steve B. <sjb...@ai...>]

Bram Stolk wrote:
> Hi there,
> 
> I believe that plib's search functionality is currently limited to
> searching a direct child in a branch, by ssgEntity pointer. There
> does not seem to be a recursive search function, neither a search
> on different criteria. (I checked docs, and ssg includes, but could
> not find this).
> 
> I would like to be able to search by name, in a hierarchy.
> 
> What would be the proper thing to do?
> 
> - Do this in application space, and let plib be as is?

That's my current theory.

The problem with a more generalised search function is to
find a way to describe to SSG what the terminating conditions
are.

Doing the search yourself is a matter of a dozen lines of
programming - it would be very easy for a generalised searching
mechanism to consume a dozen lines of code just in telling it
the precise conditions it's searching for.

> - Do this in plib, as a non-member func in ssg, e.g.
>   ssgEntity *ssgFind(const char *name, ssgEntity *tree);

That might be appropriate as an ssgAux function.

> - Do this in a more generic way, so that:
>   * different criteria can be used, other than name-base.
>   * multiple hits can be returned.

To be at all useful, I think it needs that degree of generality.

If you are just trying to do something to each node with a particular
name, it's easier to do it as the model loads using the various
node creation callbacks.

> - Model it after SGI's OpenGL|Performer pfLookupNode, which is:
>      pfNode* pfLookupNode(const char *name, pfType* type);

I never found that to be very useful back when I last used Performer.
I'd always want either more generality (eg: Find all the leaf nodes
that contain purple polygons - or find all the transform nodes with
rotation components) - or I'd be frustrated because the 'type' match
might need to be 'isAKindOf' or 'isExactType' and Perfomer only does
one of those (I forget which).

If you really think you can come up with something good - make it
an ssgAux function - that way we don't add weight to the core SSG
nodes.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

[Plib-devel] searching scenegraphs

[Bram S. <br...@sa...>]

Hi there,

I believe that plib's search functionality is currently limited to
searching a direct child in a branch, by ssgEntity pointer. There
does not seem to be a recursive search function, neither a search
on different criteria. (I checked docs, and ssg includes, but could
not find this).

I would like to be able to search by name, in a hierarchy.

What would be the proper thing to do?

- Do this in application space, and let plib be as is?

- Do this in plib, as a non-member func in ssg, e.g.
   ssgEntity *ssgFind(const char *name, ssgEntity *tree);

- Do this in plib, as a member func of ssgBranch, e.g:
   ssgEntity *ssgBranch::Find(const char *name);

- Do this in a more generic way, so that:
   * different criteria can be used, other than name-base.
   * multiple hits can be returned.

- Model it after SGI's OpenGL|Performer pfLookupNode, which is:
      pfNode* pfLookupNode(const char *name, pfType* type);


I'll be happy to add the proper functionality, if there is consensus
about this on this mailing list. (Personally, I like performer's method).



   Bram

[Plib-devel] [BUG]? plib: culling

[Melchior F. <mf...@us...>]

No. False alarm! This seems to be a bug in SimGear (or even in the bo105
animation file, depending on your view). I'm about to fix it. Thanks for
listening and sorry for the noise!

m.

[Plib-devel] [Fwd: [Flightgear-devel] [BUG]? plib: culling]

[Andy R. <an...@pl...>]

From Melchior Franz, who can't send to Sourceforge mailing lists due to
a stale spam blacklist entry.

Andy

Re: [Plib-devel] joystick jungle

[Bram S. <br...@sa...>]

People,


Thanks for the feedback on the joystick issues.

To clarify one thing: I'm not addressing the issue of how
to map functionality onto switches.

At first, I only want to address the issue on retreiving
joystick specifics. Function mapping is app-specific.

The flightgear xml merely covers the mapping bit, (which
is based on implicit knowledge on the device specifics, and
is flightsim oriented).

Steve's suggestion about wiki sounds reasonable, and I
agree very much on the problem on nomenclature.


I've come up with this scenario:

Users are asked to run a tool.
The tool queries the joystick name, and sends it to a server.
The server checks if the name is known, if it is, and at least
two identical reports are submitted for it, thank the user for
participating.

If the joystick is unknown, or has a single unconfirmed report,
Ask the user:
   - turn wheel if present.
   - move joysticks up-right, going from leftmost js to rightmost js.
   - press pedals, going from leftmost pedal to rightmost pedal.
   - pull shoulder-buttons going from left to right,
   - etc...

The util will be able to check axis-polarity and axis-resolution
(if only -32768 0 and 32767 are seen, its digital).

Each month or so, the db content could be made available in a
plib header or something.

    Bram

Re: [Plib-devel] joystick jungle

[Bert D. <dri...@pl...>]

On Wed, 9 Mar 2005, Bram Stolk wrote:

> I'm struggling with the lack of joystick/gamepad/wheel standardization.
> There does not seem to be a manner by which I can get to
> know more about an axis for a linux joystick.
>
> Maybe this kind of stuff is in directx, but I want this
> kind of info on joystick axes:

I doubt DirectX fares better. I have four different USB joysticks geared 
more or less to flight simulation, plus a pedal set, and unless the app 
comes with a database of joysticks there is little logic to default 
assignments.

> - Is axis part of a 2DOF joystick?
> - Is axis an accelerator pedal?
> - Is axis a brake padel?
> - Is axis combined brake/accel?
> - If axis is up/down joystick, is up positive or negative?
> - Is the axis analog?
>  (Strangely enough, digital pads are treated as axes, not buttons)

I'm not sure how many plib apps support those hat switches; I think 
there is something to be said to introduce a seperate "hat" abstraction, 
along with axis and button.

> I assume no API exists for getting this info.
> And if this is the case, I think a 'joystick database' indexed
> by the USB device name would be a valuable asset for many projects.
>
> Does anyone on this list know whether such a db exists?
> And if not, I think I want to start one. I dont care if at first
> it will only contain a handful of the 1000s of current gamepads.
>
> The alternative is probably to burden the user by configuring
> his joystick which seems ugly to me.

Many Windows games come with extensive databases for joystick to 
application matching, and I rarely use the defaults for long. I have
copies of Microsoft Flight Simulator (of different vintages), I have 
X-Plane, I use FlightGear. Then, to make matters worse, I have MS 
TrainSim, Trainz and BVE, but no trainsim specific devices, so I control 
brake line pressure with the Cessna-styled "Mixture" control of a CH 
Yoke.

The three flightsims and four joysticks make for twelve combinations. 
There is no guessing which button will extend the flaps, or reduce 
them, not with an identical joystick across games, and not with an 
identical game across joysticks. The default aileron/elevator control on 
a Logitech Rumblepad is usually the left joystick, which really is a bad 
choice for righthanded folks. Etcetera, etcetera: my list of gripes is 
endless. Oh, and that's without changing airplane types in the sim, e.g. 
going from a plane with one brake to a type that support differential 
braking.

The practical upshot is this: the first thing I do when I get a new sim 
(or must re-install one) is to remove all assignments, then reassign 
them (the ones I need, that is).

I think the hard part is not in having to assign them, but in user 
interface design. I can recommend anyone interested in this to look at 
X-Plane 8.x (http://www.x-plane.com/, available for Windows, MacOS 9 or 
X, and some recent Linux versions). Download the demo and try to assign 
joystick axes and buttons. The screen looks daunting and unfriendly, but 
it isn't until you justapose MSFS's screen that you'll appreciate how 
well X-Plane's is done.

The ideal Joystick configuration GUI
  - knows different layouts for analogue inputs: X-Y, Y-only, X-only, 
slider, 270 degree knob (this needs a database)
  - can present all axes as simple representations of the above choices
  - can store profiles per app, per joystick
  - can default a profile to an existing one
  - can map all available axes to terms relevant to the app, so the user
    can answer the question "what does this button do?"

X-Plane's weakness is in dealing with hats (represented as eight 
unrelated buttons). I have not yet checked how well it can deal with 
different joysticks (in other words, if it stores profiles per Joystick 
or not).

And actually, FlightGears's fgjs ain't bad, except that it can be a 
challenge to get all button assignments right in one go, as eventually 
the "ANY" button will come up for assignment :-)

Other good ideas can be had from Logitech's Windoze drivers (which are 
not my favorite drivers, but they come with good representations to 
visualize button and axis assignments).

So if anyone has any time to burn, I would recommend improving the GUI 
to do assignment (possibly as an advanced plib widget, accepting a list 
of possible actions and preexisting assignments, and returning user 
assignments and/or maintaining profiles). The key functionality missing 
from most GUI's is the basic "what does this button do" thing. But even 
just a simple GUI version of fgjs that allows for going back and fixing 
mistakes would be an improvement. It should not be rocket science to 
write such a joystick profile manager to be application independent 
(but I'm the first to admit it will be a lot of work to get the GUI 
just right).

Anyway, before embarking on the idea of a joystick database I'd suggest 
having a critical look at existing attempts to do precisely that on 
Windows (e.g., Logitech's profile manager, which covers dozens of 
joysticks and hundreds of games and can make a 2GHz machine feel like 
a 486/33).

Cheers,

 				-- Bert

-- 
Bert Driehuis -- dri...@pl... -- +31-20-3116119
If the only tool you've got is an axe, every problem looks like fun!

Re: [Plib-devel] joystick jungle

[Andy R. <an...@pl...>]

Bram Stolk wrote:
> Does anyone on this list know whether such a db exists?  And if not,
> I think I want to start one. I dont care if at first it will only
> contain a handful of the 1000s of current gamepads.

FlightGear has definitions for most of the popular hardware available.
Most of those have axis/button enumerations in the comments at the top
of the XML file.  Probably a good place to start.

Andy

Re: [Plib-devel] joystick jungle

[Steve B. <sjb...@ai...>]

Bram Stolk wrote:
> 
> sgHello()
> 
> 
> I'm struggling with the lack of joystick/gamepad/wheel standardization.
> There does not seem to be a manner by which I can get to
> know more about an axis for a linux joystick.
> 
> Maybe this kind of stuff is in directx, but I want this
> kind of info on joystick axes:
> 
> - Is axis part of a 2DOF joystick?
> - Is axis an accelerator pedal?
> - Is axis a brake padel?
> - Is axis combined brake/accel?
> - If axis is up/down joystick, is up positive or negative?
> - Is the axis analog?
>   (Strangely enough, digital pads are treated as axes, not buttons)
> 
> I assume no API exists for getting this info.

Not AFAIK.

> And if this is the case, I think a 'joystick database' indexed
> by the USB device name would be a valuable asset for many projects.

Yes - it would - but only if it was actively maintained.  This would
actually be a fine job for a Wiki.

> Does anyone on this list know whether such a db exists?

Not that I know of.

> And if not, I think I want to start one. I dont care if at first
> it will only contain a handful of the 1000s of current gamepads.

Yep - if it could be EASILY updated by anyone, it would grow at
exactly the rate that people with new joysticks tried to use them.

You could include something like the PLIB 'joytest' program to help
people figure out which functions were on which buttons/axes.

The hard part (I guess) is coming up with a sufficiently rigerous - yet
flexible nomenclature for all of the buttons and axes.  For some people,
a controller with two foot pedals and a lever has 'Brake, Throttle and Shifter',
but for other people, it has two rudder pedals and a throttle lever.  That
could be pretty confusing!

> The alternative is probably to burden the user by configuring
> his joystick which seems ugly to me.

Yes, it is.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

[Plib-devel] joystick jungle

[Bram S. <br...@sa...>]

sgHello()


I'm struggling with the lack of joystick/gamepad/wheel standardization.
There does not seem to be a manner by which I can get to
know more about an axis for a linux joystick.

Maybe this kind of stuff is in directx, but I want this
kind of info on joystick axes:

- Is axis part of a 2DOF joystick?
- Is axis an accelerator pedal?
- Is axis a brake padel?
- Is axis combined brake/accel?
- If axis is up/down joystick, is up positive or negative?
- Is the axis analog?
   (Strangely enough, digital pads are treated as axes, not buttons)

I assume no API exists for getting this info.
And if this is the case, I think a 'joystick database' indexed
by the USB device name would be a valuable asset for many projects.

Does anyone on this list know whether such a db exists?
And if not, I think I want to start one. I dont care if at first
it will only contain a handful of the 1000s of current gamepads.

The alternative is probably to burden the user by configuring
his joystick which seems ugly to me.

   Bram

Re: [Plib-devel] [OT] FSAA with ati's fglrx

[Steve B. <sjb...@ai...>]

Bram Stolk wrote:

> I'm starting to think that this is a linux driver thing.
> Unfortunately, ati does zero linux support.

Yep.  At work (where we buy the very best cutting edge graphics
cards at a rate of several thousand per year and use ONLY Linux),
we've had no success in getting ATI to talk to us.  We initially
planned to support nVidia, ATI and 3Dlabs products - but ATI's
drivers are so poor and our ability to pass on bug reports and
get them looked at is ZERO.  So now, we don't even bother to buy
one of each of their cards for evaluation anymore.

Individual developers have zero chance of getting help from them.

3Dlabs are also very good at Linux support - and I certainly
recommend their hardware if you want to get into GLSL shaders
and such like.  But for home use, they are kinda expensive.

> Nvidia's linux support is so much better.

Yes - we've had many phone conferences with their developers and
talked Linux issues with them.  They are *reasonably* responsive
and their drivers are really solid and reliable.

If you buy one of their higher priced 'Quadro' cards instead of
the consumer-grade 'GeForce' range - you'll find their Quadro group
are even more responsive to questions.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [Plib-devel] [OT] FSAA with ati's fglrx

[Bram S. <br...@sa...>]

Steve,

Thank you for the suggestions.

> 1) Does the MOBILITY version of the Radeon 9700 even support
>    FSAA?  I know the mobility chipsets have quite a few limitations
>    compared to the regular 9700.

According to ATI's website, mobility Radeon 9700 does 6x fsaa:
http://ati.com/products/mobilityradeon9700/features.html
They call this SmoothVision(tm)2.1 :-)

> 
> 2) How much graphics memory do you have?  Turning on FSAA consumes
>    a LOT of graphics RAM - especially at higher screen resolutions.
>    Does FSAA turn on when you set the screen size to something
>    really tiny (like 640x480) ?

xfree86 reports 64Mb video memory.
I tried a 640x400 resolution (no virtual desktop).
This still does not do FSAA.

I'm starting to think that this is a linux driver thing.
Unfortunately, ati does zero linux support.
Nvidia's linux support is so much better. I occasionally write
to their linux feedback email address, and I often get usable
responses from them.

    bram

PS: I cannot check FSAA under windows, as this laptop was bought
     with debian pre-installed, although m$ tax was paid :-(

Re: [Plib-devel] [OT] FSAA with ati's fglrx

[Steve B. <sjb...@ai...>]

Bram Stolk wrote:
> Hi there,
> 
> This is not strictly a plib matter, but I think there a quite a few
> smart people on this list how may be able to help me out.
> And my posting on comp.os.linux.x had zero resonse.
> 
> All I'm trying to do is enable FSAA on a Radeon9700 with fglrx.
> I have in my xfree cfg:
> 
>         Option "FSAAEnable"   "yes"
>         Option "FSAAScale"    "4"
> 
> I tried 2x, 4x, 6x, but I always get contradictions in my XF86Config log,
> because first, xf86 tells me:
> 
> (**) fglrx(0): Option "FSAAScale" "4"
> (**) fglrx(0): Option "FSAAEnable" "yes"
> 
> And later in the log, I get:
> 
> (==) fglrx(0): HPV inactive
> (==) fglrx(0): FSAA enabled: NO
> (==) fglrx(0): FSAA Gamma enabled
> 
> What the heck is going on here????
> 
> glx works just fine for me, as this glxinfo output shows:
> 
> OpenGL vendor string: ATI Technologies Inc.
> OpenGL renderer string: MOBILITY RADEON 9700 Generic
> OpenGL version string: 1.3.4641 (X4.3.0-3.14.6)

Two questions:

1) Does the MOBILITY version of the Radeon 9700 even support
    FSAA?  I know the mobility chipsets have quite a few limitations
    compared to the regular 9700.

2) How much graphics memory do you have?  Turning on FSAA consumes
    a LOT of graphics RAM - especially at higher screen resolutions.
    Does FSAA turn on when you set the screen size to something
    really tiny (like 640x480) ?

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

[Plib-devel] [OT] FSAA with ati's fglrx

[Bram S. <br...@sa...>]

Hi there,

This is not strictly a plib matter, but I think there a quite a few
smart people on this list how may be able to help me out.
And my posting on comp.os.linux.x had zero resonse.

All I'm trying to do is enable FSAA on a Radeon9700 with fglrx.
I have in my xfree cfg:

         Option "FSAAEnable"   "yes"
         Option "FSAAScale"    "4"

I tried 2x, 4x, 6x, but I always get contradictions in my XF86Config log,
because first, xf86 tells me:

(**) fglrx(0): Option "FSAAScale" "4"
(**) fglrx(0): Option "FSAAEnable" "yes"

And later in the log, I get:

(==) fglrx(0): HPV inactive
(==) fglrx(0): FSAA enabled: NO
(==) fglrx(0): FSAA Gamma enabled

What the heck is going on here????

glx works just fine for me, as this glxinfo output shows:

OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: MOBILITY RADEON 9700 Generic
OpenGL version string: 1.3.4641 (X4.3.0-3.14.6)

I'm really puzzled.

     bram

Re: [Plib-devel] Request for Make Local on *nix

[Steve B. <sjb...@ai...>]

Fay John F Contr AAC/WMG wrote:
> Gentlemen,
> 
>         Is there a way to build the PLIB libraries and install them in a 
> local directory on a Linux box?

Just do a 'make' and don't to the 'install'.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

RE: [Plib-devel] Request for Make Local on *nix

[Fay J. F C. AAC/W. <joh...@eg...>]

Yes!  Thank you very much.  Now let me see if it works with "freeglut"
<grin>.

John F. Fay
joh...@eg...
850-729-6330 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Bert Driehuis
Sent: Monday, February 28, 2005 9:19 AM
To: pli...@li...
Subject: Re: [Plib-devel] Request for Make Local on *nix

On Mon, 28 Feb 2005, Fay John F Contr AAC/WMG wrote:

> 	Is there a way to build the PLIB libraries and install them in a
> local directory on a Linux box?  This would be useful for people who don't
> have root access, or who want to build a local experimental version of
PLIB
> and don't want to install it in the root library directory.

Doesn't

 	./configure --prefix=$HOME/plib-bin

do what you want to do? I build all of my stuff that way.

Cheers,

 				-- Bert

-- 
Bert Driehuis -- dri...@pl... -- +31-20-3116119
If the only tool you've got is an axe, every problem looks like fun!


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] Request for Make Local on *nix

[Bert D. <dri...@pl...>]

On Mon, 28 Feb 2005, Fay John F Contr AAC/WMG wrote:

> 	Is there a way to build the PLIB libraries and install them in a
> local directory on a Linux box?  This would be useful for people who don't
> have root access, or who want to build a local experimental version of PLIB
> and don't want to install it in the root library directory.

Doesn't

 	./configure --prefix=$HOME/plib-bin

do what you want to do? I build all of my stuff that way.

Cheers,

 				-- Bert

-- 
Bert Driehuis -- dri...@pl... -- +31-20-3116119
If the only tool you've got is an axe, every problem looks like fun!

[Plib-devel] Request for Make Local on *nix

[Fay J. F C. AAC/W. <joh...@eg...>]

Gentlemen,

	Is there a way to build the PLIB libraries and install them in a
local directory on a Linux box?  This would be useful for people who don't
have root access, or who want to build a local experimental version of PLIB
and don't want to install it in the root library directory.

John F. Fay
joh...@eg...
850-729-6330 

Re: [Plib-devel] Portability - policy suggestion

[Martin S. <Mar...@un...>]

Steve Baker wrote:
> Martin Spott wrote:

>> Would anyone consider reviewing the patches as proposed by Paolo
>> Leoncini ?
>> I think improving the 3DS loader is always a "good thing" (TM  :-)
> 
> Yeah - those are good changes - I've just been too busy to do anything
> about them.

Any progress in the meantime ? BTW, I made a copy of these patches
available here:

  ftp://ftp.uni-duisburg.de/FlightGear/Devel/lepa069/

.... in case the original source might go lost,

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

RE: [Plib-devel] proper plib coding example

[Norman V. <nh...@ca...>]

br...@sa... writes:
> 
> PS: The only plib app I could find that keeps aspects correct
> was ppe, but this was because ppe uses the opengl widget from
> FLTK, which properly recalculates frustums. 

PPE calculates its own aspect and frustum and handles all
of the OpenGL code thru PLIB al FLTK does is handle the
window rectangle

I think you will fine that FlightGear handles aspect ratio correctly also

Norman

Re: [Plib-devel] proper plib coding example

[Steve B. <sjb...@ai...>]

br...@sa... wrote:

>>I think that what most 3D applications truly need is to have the
>>user's choice of screen size be used by the application to set only
>>the WIDTH of the screen - and as he drags the window around, to
>>force the window dimensions such that the pixels remain square *and*
>>the horizontal and vertical fields of view are maintained.
> 
> 
> I think this is impossible, you could only maintain minimal fov vals,
> you cannot fix them and keep aspect ratio the same while user drags.
> (unless you disable non-linear window scaling).

You misunderstand.  Suppose the window is initially 3:4 aspect ratio
and the FOV set up such as to make the pixels square.  If the user
then manually resizes the window to (say) 1024x512 then the resize
callback would ignore the vertical dimension and calculate a new
vertical size of 1024*3/4 = 768, then it would resize the window
(under program control) to 1024x768.  Thus, the user can resize
the window but not alter the aspect ratio.

This ensures that overlaid symbols don't become illegible and
that the user cannot change the field of view and thereby mess
up careful camera positioning.

(Just try doing it the other way with an application that does
split-screen stuff!)

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [Plib-devel] proper plib coding example

[<br...@sa...>]

>
> Yeah - but there can be problems with some applications.  Very often,
> I'll position the camera very carefully so that you aren't intersecting
> adjacent walls, etc.  If you allow the user to (in effect) alter the
> field of view - then other things may go wrong.  In particular, it's
> possible that on-screen iconography will disappear off the top or
> bottom of the screen.

In the case of the viewer app, iconography can only disappear
left/right from the screen, due to the implementation:

Currently, I implemented it so that vertical fov is always fixed,
and horizontal fov is adapted to aspect ratio.

> I think that what most 3D applications truly need is to have the
> user's choice of screen size be used by the application to set only
> the WIDTH of the screen - and as he drags the window around, to
> force the window dimensions such that the pixels remain square *and*
> the horizontal and vertical fields of view are maintained.

I think this is impossible, you could only maintain minimal fov vals,
you cannot fix them and keep aspect ratio the same while user drags.
(unless you disable non-linear window scaling).

In the method I described above, vertical fov is garantueed.
I can imagine an algorithm that will guarantee minimal values
for fov-y and fov-x, will increase fov in one of the two dirs.
As I have it now, fov-x can both decrease and increase from start
setting.

But I agree with you that desired behaviour depends on the app,
although a varying aspect ratio seems bad to me for most cases.
There are also cases where you may want to derive fov-xy directly
from window size, so that increasing windowsize will let you
see more of your model (a ppe window comes to mind).

  bram

PS: The only plib app I could find that keeps aspects correct
was ppe, but this was because ppe uses the opengl widget from
FLTK, which properly recalculates frustums.

> ---------------------------- Steve Baker -------------------------
> HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
> HomePage : http://www.sjbaker.org
> Projects : http://plib.sf.net    http://tuxaqfh.sf.net
>             http://tuxkart.sf.net http://prettypoly.sf.net
> -----BEGIN GEEK CODE BLOCK-----
> GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
> V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
> -----END GEEK CODE BLOCK-----
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel
>

Re: [Plib-devel] proper plib coding example

[Steve B. <sjb...@ai...>]

Bram Stolk wrote:
> Hi there,
> 
> 
> I found out, that nowhere in plib examples, we show people how to properly
> write a plib application.
> 
> The main problem is that none of the demos properly handles resizing of the
> window. After a resize, the aspect ratio is likely to change. This causes
> distorted geometry in the rendering (Spheres look like elipses).
> 
> Also, I understand that the current recommended way to implement a plib 
> app,
> is to use ssgContext. However, none of the demos does this.
> 
> tuxkart, tux-aqfh and flightgear have the same problems.... so where to 
> turn
> to for a recommended plib app implementation?
> 
> Well, I've modified examples/src/ssg/viewer so that at least 1 app is 
> available
> that uses ssgContext, and properly handles window resizes. Maybe it 
> makes sense
> to fix all plib examples?

Yeah - but there can be problems with some applications.  Very often,
I'll position the camera very carefully so that you aren't intersecting
adjacent walls, etc.  If you allow the user to (in effect) alter the
field of view - then other things may go wrong.  In particular, it's
possible that on-screen iconography will disappear off the top or
bottom of the screen.

I think that what most 3D applications truly need is to have the
user's choice of screen size be used by the application to set only
the WIDTH of the screen - and as he drags the window around, to
force the window dimensions such that the pixels remain square *and*
the horizontal and vertical fields of view are maintained.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

[Plib-devel] proper plib coding example

[Bram S. <br...@sa...>]

Hi there,


I found out, that nowhere in plib examples, we show people how to properly
write a plib application.

The main problem is that none of the demos properly handles resizing of the
window. After a resize, the aspect ratio is likely to change. This causes
distorted geometry in the rendering (Spheres look like elipses).

Also, I understand that the current recommended way to implement a plib app,
is to use ssgContext. However, none of the demos does this.

tuxkart, tux-aqfh and flightgear have the same problems.... so where to turn
to for a recommended plib app implementation?

Well, I've modified examples/src/ssg/viewer so that at least 1 app is available
that uses ssgContext, and properly handles window resizes. Maybe it makes sense
to fix all plib examples?

    bram