plib-devel

[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

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-----

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...>]

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

[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