plib-devel

R: [Plib-devel] SSG Tree help needed

[Paolo L. <p.l...@ci...>]

> -----Messaggio originale-----
> Da: pli...@li...=20
> [mailto:pli...@li...] Per conto di=20
> po...@cs...
> Inviato: sabato 19 novembre 2005 20.54
> A: pli...@li...
> Oggetto: [Plib-devel] SSG Tree help needed
>=20
>=20
> Hi! We are creating car simulation, and we are planning to=20
> use PLIB (SSG=20
> loader). I know the structure of SSG tree, but if I add some=20
> image (object)=20
> in the scence graph, I want to know in which classes the different=20
> attributes (like color, texture, animation) of that image=20
> goes?

As far as for 'adding an image to the scene graph' you mean a texture =
which
maps a (somehow flat) object, it is actually a texture attribute to a =
state.
A tipical node structure in SSG is:

ssgBranch (Transform, grouping, Range Selector, Switch, Texture =
transform,
etc.)
  |
  V
ssgLeaf (geometry, e.g. VtxArray)
  |
  V
ssgState (actually SimpleState, i.e. leaf attributes such as texture, =
color,
GL modes, etc.)

Thus, for answering the question, the different attributes go to the
ssgSimpleState class object, e.g.

  ssgSimpleState *s =3D new ssgSimpleState();
  s->setTexture( "imagefilename.ext", true, true );
  ssgLeaf *l;
  // create and fill geometry node l - ssgLeaf is just an abstract class
  l->setState( s );

About animation, we should agree on what kind of it - texture animation =
in
terms of texture transform can be accomplished in two ways:

1. inserting a ssgTextureTransform node before the ssgLeaf, and setting =
the
wanted texture transform on that;

2. setting up a pre-draw callback for the leaf node, which sets the GL
texture transform matrix, and a post-draw callback which resets it ti =
the
identity. The pre-draw one has to return 1 for the leaf to be drawn.

Choice 2. doesn't change your scene graph structure.

Other kind of animations could imply color attributes to be changed, yet =
you
have to manage for timing since there's no built-in mechanism for this. =
You
have timed swiches instead, which actually act by selecting one of =
children
nodes in a timed sequence. There should be other timed animation =
mechanisms
in SSG that you can search for in ssg.h, along with a mine of methods =
for
the standard classes which will be useful to you for your advanced apps.

> Because ssgVTable class contains the information like leaf geometry=20
> as arrays of=20
> vertex, normal, texture coordinate and colour data then what=20
> does the Root,=20
> branches and kids of the tree contains? Does kids only=20
> contains the objects=20
> of the scene?

Yes, leaf nodes contain scene objects, but are not the very last leaf in =
the
strict sense, being this the state node.

> What is exact difference between ssgRoot, ssgBaseTransform=20
> and ssgEntity? For the transform object does the ssgRoot is=20
> always be the=20
> parent node?

Regarding the realtion between a Transform and the Root node, yes and =
no,
since for structuring hierarchical transformation you'll probably create =
a
structure where a ssgTransform is one of the children of another
ssgTransform (the classic "robot arm" example). The Root node is still =
there
only for historical reasons, since latest Plib versions make =
ssgCullAndDraw
to start from a ssgBranch, and ssgLoad to return a ssgEntity.

> Kindly pls. find time to reply earliest possible.
> Thnaks a lot.
> - Poonam.

You're welcome, greetings -

Paolo Leoncini

Re: R: R: [Plib-devel] Possible problem in Frustum calculation (new release?)

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

Paolo Leoncini wrote:

> Ok, at leat what about warning setFOV users anywhere in the doc that putting
> e.g. (60, 45) args for a 4:3 window doesn't produce an isotropic coord
> space?

Ok, I updated the sg documentation in CVS, so that it now contains
a warning on aspect ratios.

I think some script needs to be run, to update the website from CVS,
but I dont know how to do this. So I can't say when the change will
show up in the webpage.

The warning I've put in, reads:

"When using setFOV, the application programmer should be
aware that aspect ratios are not enforced, thus these
ratios can deviate from the window aspect ratio.
If this happens, a sphere will look like an ellipse."


  Bram

-- 
Bram Stolk, VR Engineer SARA, Amsterdam.   tel +31 20 592 3000

"Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit
 operating system originally coded for a 4-bit microprocessor by a 2-bit
 company that can't stand 1 bit of competition."

R: R: [Plib-devel] Possible problem in Frustum calculation (new release?)

[Paolo L. <p.l...@ci...>]

> -----Messaggio originale-----
> Da: pli...@li...=20
> [mailto:pli...@li...] Per conto di steve
> Inviato: sabato 26 novembre 2005 16.01
> A: pli...@li...
> Oggetto: Re: R: [Plib-devel] Possible problem in Frustum=20
> calculation (new release?)
>=20
>=20
> Bram Stolk wrote:
> > Paolo Leoncini wrote:
> >=20
> >> Please consider inserting the following patch to sg.cxx for working
> >> around
> >> the subject problem:
> >=20
> >=20
> > Paolo,
> >=20
> > I would like to help you, but check out this thread:
> >=20
> >=20
> =
http://sourceforge.net/mailarchive/forum.php?thread_id=3D6692659&forum_i
> > d=3D4479
> >=20
> >=20
> > field-of-view behaviour is tricky.
> > Sometimes, you want the behaviour you implemented:
> > fix one fov dimension, and set the other depending on the window=20
> > aspect ratio. Sometimes, you want a fixed aspect, like=20
> steve described=20
> > in the thread. And in other cases you may want the current plib=20
> > behaviour. (Altough I agree that this messes up ratio's, and looks=20
> > ugly).
>=20
> Exactly.
>=20
> Whichever you do will displease roughly 50% of developers. =20
> We picked one at the outset - if we change it, we'll at best=20
> upset 50% of developers - and do nothing for the other 50%=20
> who have already worked around the issue.

The idea is to fix things for casual users who don't want to complicate
their life with frustum extents whilst getting their setFOV honored (and
don't want to ugly multiply the hfov by 1.045 at 60=B0).

IMHO whoever has worked around the problem did it with explicit frustum
extent calculation as Bram's code shows, which has a different path =
within
sgFrustum::update yet.

> At worst, we'll upset 100% of developers because the library changed
> in ways they didn't expect.

... or many could finally see actual spheres!

Seriously, I don't fully understand the referred post about the freedom =
left
by the current behavior, I'm just a little disappointed having had a =
wrong
aspect ration for five years, and for the last two years having worked
around with an unexplainable constant multiplication, and would like =
other
users don't do the same.

> We shouldn't do this.

Ok, at leat what about warning setFOV users anywhere in the doc that =
putting
e.g. (60, 45) args for a 4:3 window doesn't produce an isotropic coord
space?

Paolo

[Plib-devel] Problem with ssgRangeSelector

[Paolo L. <p.l...@ci...>]

Dear all,

In the rewrite of the useful lodmaker utility in order to make it work =
"by
single leaf"  instead of "by full model" (assuming that two LOD models =
has
the same scene graph structure) I noticed that all the houndreds
RangeSelectors put in the combined result ssg model all suddenly switch =
at
the same time during visualization, thus resembling the original =
lodmaker
bekavior.

By going into the code of ssgRangeSelector::cull, it seems to me too =
simple
and thus not general.

Infact assuming the camera matrix is passed as second parameter to
ssgRangeSelector::cull (is it?), the current code basically only tests =
which
depth range is the camera position in, thus select'ing the corresponding
child subgraph.

I could have misunderstood the code, or the purpose of the subject class
itself, yet I expected it would compare the actual position of an object
(e.g. by its Bsphere center) with the current camera position instead.

I got a much better behavior by changing the way of calculating

  float range =3D sgLengthVec3 ( m [ 3 ] ) ;

With

  const float *center =3D this->getKid(0)->getBSphere()->getCenter();  =
// just
refer to the first LOD
                                                                     // =
for
center information
  float range =3D sgDistanceVec3 ( center, m[3] ) ;

Of course this doesn't still keep into account the transformation path =
of
the node within the graph, which could require a getNetTransform() to
further transform the center.

Is that roughly right? How to proceed? Could it be a topic for the =
upcoming
release? Do I proceed improving and testing it rapidly?

Greetings -

Paolo Leoncini


-------------------------------------------------------------------------=

Paolo Leoncini     phone:  +39 (0823) 623134
Visualization & Virtual Reality   fax:    +39 (0823) 623126
CIRA - Italian Center for Aerospace Researches mailto:p.l...@ci...
Via Maiorise - 81043 Capua (CE) Italy  http://www.cira.it

RE: [Plib-devel] SSG Tree help needed

[Fay J. F C. AFSEO/SK <joh...@eg...>]

Gentlemen,

	Did anybody follow up on this query?  Unfortunately I don't know
much about SSG or I would answer it myself.

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
joh...@eg...
850-729-6330 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of
po...@cs...
Sent: Saturday, November 19, 2005 1:54 PM
To: pli...@li...
Subject: [Plib-devel] SSG Tree help needed

Hi! We are creating car simulation, and we are planning to use PLIB (SSG 
loader). I know the structure of SSG tree, but if I add some image (object) 
in the scence graph, I want to know in which classes the different 
attributes (like color, texture, animation) of that image goes? Because 
ssgVTable class contains the information like leaf geometry as arrays of 
vertex, normal, texture coordinate and colour data then what does the Root, 
branches and kids of the tree contains? Does kids only contains the objects 
of the scene? What is exact difference between ssgRoot, ssgBaseTransform 
and ssgEntity? For the transform object does the ssgRoot is always be the 
parent node?

Kindly pls. find time to reply earliest possible.
Thnaks a lot.
- Poonam.



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: R: [Plib-devel] Possible problem in Frustum calculation (new release?)

[steve <sjb...@ai...>]

Bram Stolk wrote:
> Paolo Leoncini wrote:
> 
>> Please consider inserting the following patch to sg.cxx for working 
>> around
>> the subject problem:
> 
> 
> Paolo,
> 
> I would like to help you, but check out this thread:
> 
> http://sourceforge.net/mailarchive/forum.php?thread_id=6692659&forum_id=4479 
> 
> 
> field-of-view behaviour is tricky.
> Sometimes, you want the behaviour you implemented:
> fix one fov dimension, and set the other depending on the
> window aspect ratio.
> Sometimes, you want a fixed aspect, like steve described in the thread.
> And in other cases you may want the current plib behaviour.
> (Altough I agree that this messes up ratio's, and looks ugly).

Exactly.

Whichever you do will displease roughly 50% of developers.  We picked
one at the outset - if we change it, we'll at best upset 50% of
developers - and do nothing for the other 50% who have already worked
around the issue.  At worst, we'll upset 100% of developers because
the library changed in ways they didn't expect.

We shouldn't do this.

Re: R: [Plib-devel] Possible problem in Frustum calculation (new release?)

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

Paolo Leoncini wrote:
> Please consider inserting the following patch to sg.cxx for working around
> the subject problem:

Paolo,

I would like to help you, but check out this thread:

http://sourceforge.net/mailarchive/forum.php?thread_id=6692659&forum_id=4479

field-of-view behaviour is tricky.
Sometimes, you want the behaviour you implemented:
fix one fov dimension, and set the other depending on the
window aspect ratio.
Sometimes, you want a fixed aspect, like steve described in the thread.
And in other cases you may want the current plib behaviour.
(Altough I agree that this messes up ratio's, and looks ugly).

Personally I dont use sgFustrum, so I'm hesitant to touch the
code (No plib examples use it either, but tuxkart, aqfh, fg, etc
may use it, so it would require a lot of testing).

Personally, I use a glut reshape func like the one below:

static void reshape(int w, int h)
{
   glViewport ( 0, 0, w, h ) ;

   aspectratio = w / (float) h;
   winw=w; winh=h;
   float fovy = 60.0 * M_PI / 180.0;
   float nearPlaneDistance = 0.4;
   float farPlaneDistance  = 2500.0;
   float y = tan(0.5 * fovy) * nearPlaneDistance;
   float x = aspectratio * y;
   context->setFrustum(-x,x,-y,y,nearPlaneDistance,farPlaneDistance);
}

Let's see what Steve's opinion is on this (if it's not aleady
clear from the mentioned thread).

    bram


> 
> In the sgFrustum::update function:
> 
>     if ( ortho )
>     {
>       right = SG_HALF * hfov ;
>       top   = SG_HALF * vfov ;
>     }
>     else
>     {
>       right = nnear * (SGfloat) tan ( hfov * SG_DEGREES_TO_RADIANS / SG_TWO
> ) ;
> //    top   = nnear * (SGfloat) tan ( vfov * SG_DEGREES_TO_RADIANS / SG_TWO
> ) ;  <= current code
>       top = right * vfov/hfov;
> <= new, patch code
>     }
> 
> This way the aspect ratio of the window gets finally honored.
> 
> Thanks a lot -
> 
> Paolo Leoncini
> 
> 
> 
>>-----Messaggio originale-----
>>Da: pli...@li... 
>>[mailto:pli...@li...] Per conto di 
>>Paolo Leoncini
>>Inviato: mercoledì 26 ottobre 2005 12.04
>>A: pli...@li...
>>Oggetto: [Plib-devel] Possible problem in Frustum calculation
>>
>>
>>Dear friends,
>>
>>I suspect a problem in the frustum calculation given hfov and 
>>vfov as implemented in sgFrustum::update() (sg.cxx). The 
>>focus is on the following
>>code:
>>
>>  if ( hfov != SG_ZERO && vfov != SG_ZERO )
>>  {
>>    // code for the check of a too narrow fov snipped 
>>
>>    if ( ortho )
>>    {
>>      right = SG_HALF * hfov ;
>>      top   = SG_HALF * vfov ;
>>    }
>>    else
>>    {
>>      // perspective, with explicitly assigned FOVs
>>      right = nnear * (SGfloat) tan ( hfov * 
>>SG_DEGREES_TO_RADIANS / SG_TWO
>>) ;
>>      top   = nnear * (SGfloat) tan ( vfov * 
>>SG_DEGREES_TO_RADIANS / SG_TWO
>>) ;
>>    }
>>
>>    left  = -right ;
>>    bot   = -top   ;
>>  }
>>
>>This code gets executed when a call to ssgSetFOV( hfov, vfov 
>>) occurs (and when near and far do, as well). In the case 
>>hfov=60, vfov=45, nnear=1 (the default, isn't?), i.e. aspect 
>>ratio=1.33333, we get:
>>
>>left -0.57735, right 0.57735, bot -0.414214, top 0.414214
>>  i.e.
>>width=1.1547, height=0.828428
>>
>>thus leading to an aspect ratio of 1.39385, which is not 
>>really 1.33333 as I'd expect. The resulting image is, infact, 
>>somehow distorted, but it's not so evident until you check 
>>against regular shapes such as a circle seen by a plane view 
>>(the differece between aspects is 4.5%, small yet noticeable).
>>
>>Yet having a suspect since time, I had a kind of confirmation 
>>when implemented my own general off-axis frustum value 
>>calculation, which, in the same case, produce l-r-b-t values 
>>leading to the right aspect ratio (screen ranging in h 
>>[-2:2], v [-1.5:1.5], eye at (0,0,2*sqrt(3)) leading to a 
>>hfov of 60° and vfov of 45°).
>>
>>According to 
>>http://www.opengl.org/resources/faq/technical/transformations.
> 
> htm FAQ #9.085 (How can I make a call to glFrustum() that matches my call to
> gluPerspective), the way of calculating 'top' seems correct. Instead 'right'
> seems not explicitly calculated, yet directly following by 'top' (*aspect).
> The problem in applying such approach for us is that our 'top' seems just
> the "wrong" value.
> 
> I'm sure Steve has the clarifying answer.
> 
> Greetings -
> 
> Paolo
> 
> 
> 
> -------------------------------------------------------------------------
> Paolo Leoncini     phone:  +39 (0823) 623134
> Visualization & Virtual Reality   fax:    +39 (0823) 623126
> CIRA - Italian Center for Aerospace Researches mailto:p.l...@ci... Via
> Maiorise - 81043 Capua (CE) Italy  http://www.cira.it
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005 Visit
> http://www.jboss.com/services/certification for more information
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
> Register for a JBoss Training Course.  Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_idv28&alloc_id845&op=click
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel

[Plib-devel] Large geometry objects and crash in ssgLOS

[Paolo L. <p.l...@ci...>]

Dear friends,

I use to load CAD-originated 3DS files containing quite large geometry
objects (e.g. #vert 26K, #faces 53K) - no problem in ordinary =
visualization,
yet I get a crash at ssgLOS call showing a problem in accessing =
vertex/index
arrays at signed short int boundary (i.e. after 32767).

Beyond the general recommendation by Steve not to have large objects for =
an
efficient frustum culling, the problem seems, infact, due to a general
unclarity about what the limit for a geometry object actually is. In
ssgXxxArray (Vertex, Normal, Index, ...) get/set methods accept unsigned =
int
arguments, the add method is not limited anyhow, yet e.g. =
ssgIndexArray::get
returns a pointer to short.

In the 3DS loader all the index elements are pointers to unsigned short, =
and
that's what contributes to fill ssgVtxArray's. Don't know about other
loader's policy on the topic.

Currently I locally patched the 3DS loader to split geometies in 10K
triangle chunks, since the 32K limit would strangely not solve the =
problem
yet.

In a next release I think it would worth a large effort to rationalize
various Vtable, VtxTable, and VtxArray in a single geometry leaf node,
optimally dealing with gfx card capability (e.g. has Vertex Arrays, =
VBO's,
...) under user hints (e.g. normally use VBO when available, but if the =
user
says 'use display list' it reverts to Vertex Arrays when available, =
etc.) -
all the loaders and ssgaShapes shoud be reworked a bit, but such a =
unique
geometry node would then be the place where to operate a centralized =
size
check/split policy. This would also favour further developments towards =
a
OGL 2.0-wise Plib 2.0 version, by avoiding coding things in three =
different
places.

Greetings -

Paolo Leoncini

-------------------------------------------------------------------------=

Paolo Leoncini     phone:  +39 (0823) 623134
Visualization & Virtual Reality   fax:    +39 (0823) 623126
CIRA - Italian Center for Aerospace Researches mailto:p.l...@ci...
Via Maiorise - 81043 Capua (CE) Italy  http://www.cira.it

R: [Plib-devel] Release !?

[Paolo L. <p.l...@ci...>]

Please consider my patch post titled:

[Plib-devel] Possible problem in Frustum calculation (new release?)

for the new release - it has impact on the correctness of the aspect =
ratio,
and, if confirmed by your kind analysis, it's a quite serious issue.

Furthermore I submitted patches for the 3DS loader and ssgaShapes
(completely new Cube generation) time ago, which have been proven not
breaking FG by Martin Spott. Could these be considered for inclusion =
too?

Greetings -

Paolo Leoncini


> -----Messaggio originale-----
> Da: pli...@li...=20
> [mailto:pli...@li...] Per conto di=20
> Martin Spott
> Inviato: mercoled=EC 23 novembre 2005 21.09
> A: pli...@li...
> Oggetto: Re: [Plib-devel] Release !?
>=20
>=20
> Martin Spott wrote:
>=20
> > as the FlightGear project is heading for a release it would=20
> help a lot=20
> > to have the patches, that accumulated since PLIB-1.8.4, to=20
> finalize in=20
> > a new PLIB release.
>=20
> Now, I realize that the source tree didn't change for about=20
> one week. Wouldn't it be great to pick what's in _now_ and=20
> 'sell' it as 1.8.5 !?
>=20
> Thanks,
> 	Martin.
> --=20
>  Unix _IS_ user friendly - it's just selective about who its=20
> friends are !
> --------------------------------------------------------------
> ------------
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep=20
> through log files for problems?  Stop!  Download the new AJAX=20
> search engine that makes searching your log files as easy as=20
> surfing the  web.  DOWNLOAD SPLUNK!=20
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> plib-devel mailing list
> pli...@li...=20
> https://lists.sourceforge.net/lists/listinfo/plib-devel
>=20

Re: [Plib-devel] Release !?

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

Martin Spott wrote:

> as the FlightGear project is heading for a release it would help a lot
> to have the patches, that accumulated since PLIB-1.8.4, to finalize in
> a new PLIB release.

Now, I realize that the source tree didn't change for about one week.
Wouldn't it be great to pick what's in _now_ and 'sell' it as 1.8.5 !?

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

Re: [Plib-devel] A bug in puaLargeInput.cxx ...

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

Fay John F Contr AFSEO/SK wrote:
> Gentlemen,
> 
>         I have been swatting nuisance bugs in my application and have
> found on in "puaLargeInput.cxx" on line 175.  The patch looks like this:
> 
> File puaLargeInput.cxx:173
>      if ( top_line_in_window < 0 ) top_line_in_window = 0 ;
> 
> -    right_slider->setValue ( 1.0f - float(top_line_in_window) /
> float(num_lines - lines_in_window) ) ;
> +    right_slider->setValue ( num_lines - lines_in_window -
> top_line_in_window ) ;
>    }
> 
> The value of the right slider used to be normalized from 0 to 1 but with
> the "puRange" this got changed.  If somebody could please put the patch
> into CVS for me I would appreciate it.

I can't find this file in my cvs tree:

$ find . -name puaLargeInput.cxx -print
$

A similarly named file puLargeInput.cxx is there, but line nr 175 looks
differently there.

Also, you seem like a knowledgable guy, with frequent contributions.
Steve Baker is very easy when it comes to giving cvs write access.
Maybe you should get one? (It can be fustrating if your patch to the
list gets dropped silently, I see occasional patches that are unintentionally
ignored).

  Bram

> 
> John F. Fay
> Technical Fellow, Jacobs/Sverdrup TEAS Group
> 850-729-6330
> joh...@eg...
>  
> 


-- 
Bram Stolk, VR Engineer SARA, Amsterdam.   tel +31 20 592 3000

"Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit
 operating system originally coded for a 4-bit microprocessor by a 2-bit
 company that can't stand 1 bit of competition."

Re: [Plib-devel] SSG and DirectX files [patch included]

[Jan R. <slo...@gm...>]

Am Sun, 20 Nov 2005 20:36:26 +0100 schrieb Jan Reucker <slo...@gm...>:

> just one quick question: I've tried to load several ".x" (MS DirectX)
> model files into a scenegraph, but never had any luck. I think it's

O.k., I found something. First, some files were corrupted, the
texture coordinate array does not correspond to the MS file format
spec. This is easy to fix in the .x file itself, but I'll have to
see which modeller generated these files.

Second and third, I think I found two bugs in the X loader and in
the intermediate loader mesh stuff.

First bug: When loading an .x file, all materials will be stored in
a globalMaterialList, but the materials are never added to the
LoaderWriterMesh. I've added a fix to ssgLoadX.cxx that adds the
created SimpleStates to the mesh.

Second bug is located in the mesh handler itself. There's a global
variable currentDiffuse that holds the most recent diffuse colour
found by the ASCII parser. Now when composing the final SSG branch,
all leafs not containing a colour array will be set to this
variable's value. This is, in fact, the colour that was defined last
in whatever file we were parsing. But this is wrong, the right
diffuse colour is located in the SimpleState that is used to draw
the leaf. Therefore we have to create the colour array with that
value. To understand the effect of this bug, here's what I experienced
while bug-hunting: I used a .x airplane model which contained 5 materials.
All materials but the last one were opaque, only the last (used to draw
the propeller disc) was 80% translucent. This caused the whole model
to look 80% translucent because the model did not contain any per-vertex
or per-face colour values, only the colours defined by the materials
(and the GL_COLOR_MATERIAL mode).

I don't know if this patch hurts anything, because the ASCII parser is
also used in some other file loaders and I'm not able to test them all.
And I can't believe that these bugs haven't been noticed for so long.
But on the other hand it would be very nice if the working .x loader
could still make it into 1.8.5... :-)

Kind regards,
Jan R.

-- 
Jan Reucker
email: jan dot reucker at web dot de
web:   http://www.reucker-online.de

R: [Plib-devel] Possible problem in Frustum calculation (new release?)

[Paolo L. <p.l...@ci...>]

Please consider inserting the following patch to sg.cxx for working =
around
the subject problem:

In the sgFrustum::update function:

    if ( ortho )
    {
      right =3D SG_HALF * hfov ;
      top   =3D SG_HALF * vfov ;
    }
    else
    {
      right =3D nnear * (SGfloat) tan ( hfov * SG_DEGREES_TO_RADIANS / =
SG_TWO
) ;
//    top   =3D nnear * (SGfloat) tan ( vfov * SG_DEGREES_TO_RADIANS / =
SG_TWO
) ;  <=3D current code
      top =3D right * vfov/hfov;
<=3D new, patch code
    }

This way the aspect ratio of the window gets finally honored.

Thanks a lot -

Paolo Leoncini


> -----Messaggio originale-----
> Da: pli...@li...=20
> [mailto:pli...@li...] Per conto di=20
> Paolo Leoncini
> Inviato: mercoled=EC 26 ottobre 2005 12.04
> A: pli...@li...
> Oggetto: [Plib-devel] Possible problem in Frustum calculation
>=20
>=20
> Dear friends,
>=20
> I suspect a problem in the frustum calculation given hfov and=20
> vfov as implemented in sgFrustum::update() (sg.cxx). The=20
> focus is on the following
> code:
>=20
>   if ( hfov !=3D SG_ZERO && vfov !=3D SG_ZERO )
>   {
>     // code for the check of a too narrow fov snipped=20
>=20
>     if ( ortho )
>     {
>       right =3D SG_HALF * hfov ;
>       top   =3D SG_HALF * vfov ;
>     }
>     else
>     {
>       // perspective, with explicitly assigned FOVs
>       right =3D nnear * (SGfloat) tan ( hfov *=20
> SG_DEGREES_TO_RADIANS / SG_TWO
> ) ;
>       top   =3D nnear * (SGfloat) tan ( vfov *=20
> SG_DEGREES_TO_RADIANS / SG_TWO
> ) ;
>     }
>=20
>     left  =3D -right ;
>     bot   =3D -top   ;
>   }
>=20
> This code gets executed when a call to ssgSetFOV( hfov, vfov=20
> ) occurs (and when near and far do, as well). In the case=20
> hfov=3D60, vfov=3D45, nnear=3D1 (the default, isn't?), i.e. aspect=20
> ratio=3D1.33333, we get:
>=20
> left -0.57735, right 0.57735, bot -0.414214, top 0.414214
>   i.e.
> width=3D1.1547, height=3D0.828428
>=20
> thus leading to an aspect ratio of 1.39385, which is not=20
> really 1.33333 as I'd expect. The resulting image is, infact,=20
> somehow distorted, but it's not so evident until you check=20
> against regular shapes such as a circle seen by a plane view=20
> (the differece between aspects is 4.5%, small yet noticeable).
>=20
> Yet having a suspect since time, I had a kind of confirmation=20
> when implemented my own general off-axis frustum value=20
> calculation, which, in the same case, produce l-r-b-t values=20
> leading to the right aspect ratio (screen ranging in h=20
> [-2:2], v [-1.5:1.5], eye at (0,0,2*sqrt(3)) leading to a=20
> hfov of 60=B0 and vfov of 45=B0).
>=20
> According to=20
> http://www.opengl.org/resources/faq/technical/transformations.
htm FAQ #9.085 (How can I make a call to glFrustum() that matches my =
call to
gluPerspective), the way of calculating 'top' seems correct. Instead =
'right'
seems not explicitly calculated, yet directly following by 'top' =
(*aspect).
The problem in applying such approach for us is that our 'top' seems =
just
the "wrong" value.

I'm sure Steve has the clarifying answer.

Greetings -

Paolo



-------------------------------------------------------------------------=

Paolo Leoncini     phone:  +39 (0823) 623134
Visualization & Virtual Reality   fax:    +39 (0823) 623126
CIRA - Italian Center for Aerospace Researches mailto:p.l...@ci... =
Via
Maiorise - 81043 Capua (CE) Italy  http://www.cira.it



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005 =
Visit
http://www.jboss.com/services/certification for more information
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

[Plib-devel] SSG and DirectX files

[Jan R. <slo...@gm...>]

Hello,

just one quick question: I've tried to load several ".x" (MS DirectX)
model files into a scenegraph, but never had any luck. I think it's
a mix of buggy files (some modellers seem to create buggy meshes
with missing commas) and maybe missing features in the .x loader.
Does someone have an .x file that works and please can send it to
me? I'd like to compare the ones I have to working files to see
if there's a major difference. It might have something to do with
the order of the optional data arrays in a mesh data record.

If anyone is interested I can also provide non-working files for
bug hunting.

Kind regards,
Jan R.

-- 
Jan Reucker
email: jan dot reucker at web dot de
web:   http://www.reucker-online.de

[Plib-devel] A bug in puaLargeInput.cxx ...

[Fay J. F C. AFSEO/SK <joh...@eg...>]

Gentlemen,

	I have been swatting nuisance bugs in my application and have found
on in "puaLargeInput.cxx" on line 175.  The patch looks like this:

File puaLargeInput.cxx:173
     if ( top_line_in_window < 0 ) top_line_in_window = 0 ;

-    right_slider->setValue ( 1.0f - float(top_line_in_window) /
float(num_lines - lines_in_window) ) ;
+    right_slider->setValue ( num_lines - lines_in_window -
top_line_in_window ) ;
   }

The value of the right slider used to be normalized from 0 to 1 but with the
"puRange" this got changed.  If somebody could please put the patch into CVS
for me I would appreciate it.

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
850-729-6330
joh...@eg...
 

[Plib-devel] SSG Tree help needed

[<po...@cs...>]

Hi! We are creating car simulation, and we are planning to use PLIB (SSG 
loader). I know the structure of SSG tree, but if I add some image (object) 
in the scence graph, I want to know in which classes the different 
attributes (like color, texture, animation) of that image goes? Because 
ssgVTable class contains the information like leaf geometry as arrays of 
vertex, normal, texture coordinate and colour data then what does the Root, 
branches and kids of the tree contains? Does kids only contains the objects 
of the scene? What is exact difference between ssgRoot, ssgBaseTransform 
and ssgEntity? For the transform object does the ssgRoot is always be the 
parent node?

Kindly pls. find time to reply earliest possible.
Thnaks a lot.
- Poonam.

RE: [Plib-devel] Re: Release !?

[Fay J. F C. AFSEO/SK <joh...@eg...>]

Hang on, I still need to get the "puAuxList.cxx" file up.  Let me send it to
Steve offline.

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
850-729-6330
joh...@eg...
 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of steve
Sent: Thursday, November 17, 2005 4:40 PM
To: pli...@li...
Subject: Re: [Plib-devel] Re: Release !?

Martin Spott wrote:
> Melchior FRANZ wrote:
> 
> 
>>Works here in a situation where it crashed before.
>>(Tested with FlightGear UDP & TCP on Linux.)
> 
> 
> Great. Steve, could we have a release now ?  :-)

Sure - I'll get on to that tomorrow.



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam for All
Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] Re: Release !?

[steve <sjb...@ai...>]

Martin Spott wrote:
> Melchior FRANZ wrote:
> 
> 
>>Works here in a situation where it crashed before.
>>(Tested with FlightGear UDP & TCP on Linux.)
> 
> 
> Great. Steve, could we have a release now ?  :-)

Sure - I'll get on to that tomorrow.

Re: [Plib-devel] Re: Release !?

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

Melchior FRANZ wrote:

> Works here in a situation where it crashed before.
> (Tested with FlightGear UDP & TCP on Linux.)

Great. Steve, could we have a release now ?  :-)

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

RE: [Plib-devel] Release !?

[Frederic B. <fre...@fr...>]

Perhaps you send the file to Bram or someone else ?

-Fred

Quoting Fay John F Contr AFSEO/SK:

> Sorry, pCVSc is causing me some troubles.  I've tried committing it but
> can't.
>
> John F. Fay
> Technical Fellow, Jacobs/Sverdrup TEAS Group
> joh...@eg...
> 850-729-6330
> -----Original Message-----
> From: pli...@li...
> [mailto:pli...@li...] On Behalf Of Frederic
> Bouvier
> Sent: Monday, November 14, 2005 10:51 AM
> To: pli...@li...
> Subject: Re: [Plib-devel] Release !?
>
> > Where is everyone regarding committing patches and such?
>
> puAuxList.cxx is still missing from the puAux directory
>
> -Fred
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Dow=
nload
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel
>

[Plib-devel] Re: Release !?

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

* Bram Stolk -- Wednesday 16 November 2005 16:24:
[crash due to broken netSocket code]
> I committed the change I proposed earlier.
> I believe the issue to be resolved.
> If someone still has problems with net/ let me know.

Works here in a situation where it crashed before.
(Tested with FlightGear UDP & TCP on Linux.)

m.

RE: [Plib-devel] Release !?

[Fay J. F C. AFSEO/SK <joh...@eg...>]

Sorry, pCVSc is causing me some troubles.  I've tried committing it but
can't.

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
joh...@eg...
850-729-6330 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Frederic
Bouvier
Sent: Monday, November 14, 2005 10:51 AM
To: pli...@li...
Subject: Re: [Plib-devel] Release !?

> Where is everyone regarding committing patches and such?

puAuxList.cxx is still missing from the puAux directory

-Fred


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] Re: Release !?

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

Fay John F Contr AFSEO/SK wrote:

> 
>         Definitely the issue needs to be resolved before any release.

I committed the change I proposed earlier.
I believe the issue to be resolved.
If someone still has problems with net/ let me know.

A test other than those in examples/src/net would be useful.

  Bram

-- 
Bram Stolk, VR Engineer SARA, Amsterdam.   tel +31 20 592 3000

"Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit
 operating system originally coded for a 4-bit microprocessor by a 2-bit
 company that can't stand 1 bit of competition."

RE: [Plib-devel] Re: Release !?

[Fay J. F C. AFSEO/SK <joh...@eg...>]

Gentlemen,

	I believe I put the offending piece of code into the "netSocket.cxx"
file; I was doing it for somebody else.  I don't have the details at my
fingertips, but if you check the e-mail traffic from the last week or two
you should find a notice of it, including a reference to the person for whom
I was doing this.  If I remember correctly, I changed something from the
person's original patch and asked if I had done it correctly.  Apparently I
didn't.

	Definitely the issue needs to be resolved before any release.

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
joh...@eg...
850-729-6330 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Bram Stolk
Sent: Wednesday, November 16, 2005 4:31 AM
To: pli...@li...
Subject: Re: [Plib-devel] Re: Release !?

Martin Spott wrote:
> Melchior FRANZ wrote:
> 
>>* Melchior FRANZ -- Sunday 13 November 2005 23:48:
>>
>>>* steve -- Sunday 13 November 2005 23:44:
>>>
>>>>Where is everyone regarding committing patches and such?
>>>
>>>The network patches applied last, a few days ago, crash for me.
>>>I'd revert them. Apart from that everything was fine. (Linux)
>>
>>See thread "netSocket patch" from Fri, 21 Oct 2005 12:38:24 +0200
>>(applied to net/netSocket.cxx and net/netSocket.h)
> 
> 
> Steve, do you think you can have a look at this _before_ end of this
> week and issue a release ?

The following seems to happen:
In version 1.31 an early return was introduced
"return (-2);" and "return (-1)" which causes a skipping
of the 'remove sockets that had no activity'.

My guess is that this could cause an fd of -1 to be used
in FD_SET during the next run of select.

Offending code is here: (line 405)
http://cvs.sourceforge.net/viewcvs.py/plib/plib/src/net/netSocket.cxx?annota
te=1.31

Three options:
(1) Replace 1.31 with the old 1.30 version, undoing the patch
(2) Fix the early return
(3) Check for fd==-1 before doing FD_SET

I would advice agaist (3) as it masks a problem.

For (2), I think it suffices to move the returns down, just before
the return num;
I tried this: net_echo no longer crashes, and other net examples still
work.

If you want, I'll commit, but: someone may want to test with a non-trivial
fully networked plib app, before the release?

 Bram

> 
> Thanks,
> 	Martin.


-- 
Bram Stolk, VR Engineer SARA, Amsterdam.   tel +31 20 592 3000

"Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit
 operating system originally coded for a 4-bit microprocessor by a 2-bit
 company that can't stand 1 bit of competition."


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] Re: Release !?

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

Martin Spott wrote:
> Melchior FRANZ wrote:
> 
>>* Melchior FRANZ -- Sunday 13 November 2005 23:48:
>>
>>>* steve -- Sunday 13 November 2005 23:44:
>>>
>>>>Where is everyone regarding committing patches and such?
>>>
>>>The network patches applied last, a few days ago, crash for me.
>>>I'd revert them. Apart from that everything was fine. (Linux)
>>
>>See thread "netSocket patch" from Fri, 21 Oct 2005 12:38:24 +0200
>>(applied to net/netSocket.cxx and net/netSocket.h)
> 
> 
> Steve, do you think you can have a look at this _before_ end of this
> week and issue a release ?

The following seems to happen:
In version 1.31 an early return was introduced
"return (-2);" and "return (-1)" which causes a skipping
of the 'remove sockets that had no activity'.

My guess is that this could cause an fd of -1 to be used
in FD_SET during the next run of select.

Offending code is here: (line 405)
http://cvs.sourceforge.net/viewcvs.py/plib/plib/src/net/netSocket.cxx?annotate=1.31

Three options:
(1) Replace 1.31 with the old 1.30 version, undoing the patch
(2) Fix the early return
(3) Check for fd==-1 before doing FD_SET

I would advice agaist (3) as it masks a problem.

For (2), I think it suffices to move the returns down, just before
the return num;
I tried this: net_echo no longer crashes, and other net examples still
work.

If you want, I'll commit, but: someone may want to test with a non-trivial
fully networked plib app, before the release?

 Bram

> 
> Thanks,
> 	Martin.


-- 
Bram Stolk, VR Engineer SARA, Amsterdam.   tel +31 20 592 3000

"Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit
 operating system originally coded for a 4-bit microprocessor by a 2-bit
 company that can't stand 1 bit of competition."