plib-users

[Plib-users] Geometry library?

[Marlin M. <mar...@ho...>]

I needed to compute 2-D line segment intersections.  I looked through plib 
and saw some 3D intersection routines, but no 2D.  After a few hours of 
searching for an efficient line-sweep intersection algorithm, I finally 
found one in IRIT at http://www.cs.technion.ac.il/~irit/ .  I am currently 
downloading it.  Now, I'd rather use something in plib, but it doesn't 
appear to have anything like this or did I miss something?

Marlin
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: [Plib-users] c++

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

> amat wrote:
> 
> i need to know about syntax error......please............

RULE 1 OF ASKING QUESTIONS VIA EMAIL:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   "ALWAYS provide all error messages and system information"

Your question is utterly meaningless...

   * What is the exact error message?  (Cut it off the screen
      and paste it into the email so we can see it).

   * What compiler are you using?

   * ...under what operating system?

   * What were you compiling at the time?

   * What version of PLIB are you talking about?

RULE 2 OF ASKING QUESTIONS VIA EMAIL:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   "NEVER post using HTML mail to mailing lists"

It's rude to do that because no everyone uses a web browser
to read their email.


-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net
                         http://freeglut.sourceforge.net

[Plib-users] c++

[amat <ama...@ho...>]

i need to know about syntax error......please............

Re: [Plib-users] CAM using plib was: Wanted--bitmap

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

Marlin Mixon wrote:

> >So, if this works, you owe me a 2 foot tall foam model of Tux - OK?  :-)
> 
> You got it!

Excellent!
 
> A few additions to the algorithm.  It appears that the MSFS models are
> often non-contiguous meshes--a forward section of the fuselage placed next
> to a rear section.

Bummer.

If there is merely a small gap or overlap then a first pass to 'snap'
together adjacent vertices would be needed.

What you need to do is to delete edges that are NOT shared *before* you
backface cull the model - then after it's back-face culled, delete only
edges that *ARE* shared.  Hence only edges that changed from being shared
to non-shared *because* you backface culled will show up as profile edges.

That's not a bullet-proof strategy...but it'll do.

> So I think the following changes are in order:
> 
> * You have to build a linked list structure of 3-d verticies in order to
>   detect non-contiguousity. (Hey! A brand new word!)
> * Plot a final graph.  Each 2-D vertex needs an attribute telling it
>   which 3-d network it came from.
> * On the final 2-D graph, check each remaining edge too see if it
>   intersects with any other edge.  If so fix the graph so there's a
>   vertex there.

Yes - but they may not intersect.


     ______________________
    |           |          |
    |           |          |
    |___________|_ A       |
    |           | |        |
    |___________|_|B       |
    |______________________|

The edge A/B doesn't intersect anything - but it does need to be discarded.

> * For each vertex, do a point in polygon to see if that point lies in
>   any OTHER polygon and if so delete it.

Point-in-polygon tests can't work in 3D.
 
> I kind of like the hybrid idea.  Any opinions?  Any pitfalls?

I would *strongly* recommend you stay clear of raster-based hacks.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net
                         http://freeglut.sourceforge.net

Re: [Plib-users] CAM using plib was: Wanted--bitmap

[Marlin M. <mar...@ho...>]

>From: Steve Baker <sjb...@ai...>
>I would:
>
>* Read the model into PPE.
>* Delete the wings and tail fins. (Select primitives and Edit/Cut)
>* Write the fuselage data out in ".TRI" format.
>* Read the data into a C++ program from a 'TRI' format file (it's
>   *REALLY* easy to write a parser for that format).
>* Rotate the model whatever number of degrees is needed using routines
>   from libplibsg
>* Compute the surface normal for each triangle (there is a PLIB/SG routine
>   for that) - and discard those that are facing away from us.
>* Treat each triangle as three edges (each with two vertices).
>* Make a table of the UNIQUE vertices in the model...discard duplicate
>   vertices.
>* Make a table of edges in the model - according to which vertices
>   they share.
>* For each edge, check to see if there is a duplicate edge somewhere
>   on another triangle.  Delete all edges that have duplicates - along
>   with those duplicates.
>* Since the only edges remaining came from triangles whose neighbours
>   were back-face culled, we have a pretty good profile.
>
>
>So, if this works, you owe me a 2 foot tall foam model of Tux - OK?  :-)

You got it!

A few additions to the algorithm.  It appears that the MSFS models are
often non-contiguous meshes--a forward section of the fuselage placed next 
to a rear section.  So I think the following changes are in order:

* You have to build a linked list structure of 3-d verticies in order to
  detect non-contiguousity. (Hey! A brand new word!)
* Plot a final graph.  Each 2-D vertex needs an attribute telling it
  which 3-d network it came from.
* On the final 2-D graph, check each remaining edge too see if it
  intersects with any other edge.  If so fix the graph so there's a
  vertex there.
* For each vertex, do a point in polygon to see if that point lies in
  any OTHER polygon and if so delete it.

Nope, Nevermind.  This doesn't work, illustrated by the fact that you could 
have a rectangle determined by four points and another separate graph's 
rectangle determined by four other verticies and if they were to form a 
cross, you would get four new intersection verticies, but you couldn't get 
rid of the new edges that link these new verticies.

Well, you could if you bisected any edge touching a new vertex to see if 
that point was inside any polygon (not just on the edge) and if so, delete 
the whole edge.

No doubt about it, it's starting to get complicated, but I can't see any
other way, unless we resort to some sort of hybrid raster operation:

* Transform your wire mesh as needed
* Plot the ENTIRE mesh in a 2-D map in black on a white background.
  (retain the vector 2-d mesh in memory for subsequent operations)
* Pick a pixel that's outside the bounding rectangle
* Flood fill at that point in red.
* Examine each node in the vector graph and relocate it's pixel
  position.
* Check it's eight pixel neighbors to see if any are red.  If so, it's a
  keeper.  If I only see black and white neighbors, I drop it.

The problem with this method is two verticies--one that you care about--
could coexist in the same pixel and keeping both of them screws up your
profile.  You could probably solve it by replotting the map at a finer
resolution if you detect coexistance.  Another problem is sharp interior
angles not permitting a red pixel to get near a true bounding vertex.
But I can live with that since that situation typically won't occur on a 
fuselage and certainly not on Tux :-)

I kind of like the hybrid idea.  Any opinions?  Any pitfalls?

Thanks,

Marlin
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: [Plib-users] BGL Loader

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

John Tsao wrote:

> I have tried ssgVtxTable in tux_example. Looks Ok.  To be safe, I think I won't use
> ssgaCube.
> One little question: I know what a normal vector of a surface is. However, it looks like
> every vertix can have it's own normal vector. I am confused.

OpenGL (and hence SSG) uses the concept of a normal to the *true* surface shape - not
necessarily the shape of the polygons that you use to represent it.  Think of a sphere
that's approximated by a dodecahedron or something....the polygons are only an approximation
of the sphere - but you can compute normals that stick radially outwards to better represent
the spherical shape.

By using these "more correct" normals computed at the vertices of each triangle, OpenGL
can perform lighting calculations at each vertex and then blend the resulting colours
to get smoother looking lighting.  With this, you can make things look rounded even
though they are made of flat planes.

For surfaces like spheres and cylinders, it's easy to generate the correct normal at
each vertex.  For things like cubes (and dodecahedrons that you *want* to look facetted
rather than smooth) you should take the true normal for each polygon and apply that
to each vertex.  For more 'freeform' surfaces, people generally compute the true
normal of each triangle that shares a particular vertex - then take the average of
those to form a 'composite' normal for the surface at that vertex.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net
                         http://freeglut.sourceforge.net

Re: [Plib-users] BGL Loader

[John T. <ndc...@mx...>]

Steve Baker wrote:

> John Tsao wrote:
> >
> > Surprisingly to me, about 90% of the the polygons in BGL files (for urban areas)
> > are actually composed by  BGL_BUILDING.  The command takes 4 arguments of  the
> > dimension of the buildings (another 4 are typically just 0's)...
>
> Probably the origin of the building is three of those...dunno what the fourth would
> be.  Probably a rotation angle.
>
> > ...and simply draws blocks.
> > I need to think about how to embed this procedure into ssgLoaderMDL.
>
> Just make it generate an ssgVtxTable containing a cubeoid.
>
> You can hack the code to generate an arbitary cuboid from plib/src/ssgAux/ssgaShapes.cxx
> (ssgaCube::regenerate() is the function you need).  Please don't actually generate an
> ssgaCube object though (although that would *seem* reasonable) because it would create
> a dependance on libplibssgaux.a that would break the build mechanism for 90% of PLIB
> applications.
>

I have tried ssgVtxTable in tux_example. Looks Ok.  To be safe, I think I won't use
ssgaCube.
One little question: I know what a normal vector of a surface is. However, it looks like
every vertix can have it's own normal vector. I am confused.

John Tsao

Re: [Plib-users] CAM using plib was: Wanted--bitmap

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

Marlin Mixon wrote:

> This is for a CAM application using foam and hotwire, so textures don't
> actually come into play. Here's what I'm doing and I think I'm on the right
> track:
> 
> I'm taking an aircraft fuselage and presenting it in a true sideview with an
> ortho projection.

OK.

> (ortho-projection = oxymoron?)

No - there are other kinds of projection - Perspective for example.

> (I'm not actually
> interested in the textures, they are just a bonus in that they are pleasing
> to the eye.)

I see.
 
> Then, by clicking my modified-viewer's right mouse button, it starts the
> recording process:  Using Steve Bakers snippet of code, I'll take a snapshot
> image of the sideview, rotate the fuselage like it was on a barbecue spit 10
> degrees, take a snapshot, 10 more degrees, snapshot, etc. until I've got 18
> images for 180 degrees.

Sounds painful.  I would have taken the 3D model, saved in some simple ASCII
format like 'TRI' (PPE can convert models to that) - and write a program to
plot out the profiles in (say) Postscript with a grid behind them...but that's
quite a bit of work.
 
> Now I've got 18 profiles.  I'll process them in such a way that I've got a
> silhouette, that is I'm only interested in two colors: model vs background.
> Finally, I'll need to figure out a way to compute the edge

(A Sobel filter for example - GIMP has one of those)

> i.e. find all
> the white pixels sitting next to black pixels and figure out the set of line
> segments that delineates the edge.  This I will call the "linear profile."

That's tremendously hard work...and a lot less accurate than going directly
from the triangle data.

I would:

 * Read the model into PPE.
 * Delete the wings and tail fins. (Select primitives and Edit/Cut)
 * Write the fuselage data out in ".TRI" format.
 * Read the data into a C++ program from a 'TRI' format file (it's
   *REALLY* easy to write a parser for that format).
 * Rotate the model whatever number of degrees is needed using routines
   from libplibsg
 * Compute the surface normal for each triangle (there is a PLIB/SG routine
   for that) - and discard those that are facing away from us.
 * Treat each triangle as three edges (each with two vertices).
 * Make a table of the UNIQUE vertices in the model...discard duplicate
   vertices.
 * Make a table of edges in the model - according to which vertices
   they share.
 * For each edge, check to see if there is a duplicate edge somewhere
   on another triangle.  Delete all edges that have duplicates - along
   with those duplicates.
 * Since the only edges remaining came from triangles whose neighbours
   were back-face culled, we have a pretty good profile.

> With the linear profiles, I can scale them up to real-world units and apply
> them to my neighbor's computerized foam cutter:  Situate the foam and cut
> the first linear profile.  Rotate 10 degrees and cut the second linear
> profile, rotate, cut, etc.

That should work.
 
> After the 18 profiles have been cut, you will have a real-world replica of
> the virtual fuselage.  I know there will be a few limitations, like if you
> left the tail feathers on, there would be some peaks and valleys that would
> not be cut enough--excess material.  Also any compound concavity won't be
> rendered correctly such as scoop inlets.

Yes...that's a problem...but it's inevitable with a hot-wire core cutter.

So, if this works, you owe me a 2 foot tall foam model of Tux - OK?  :-)

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net
                         http://freeglut.sourceforge.net

Re: [Plib-users] Little question please help

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

John Tsao wrote:
> 
> After defineing a ssgVtxTable, and adding vertices and normals to the object, how do i
> render the object?
> 
> Can I simply do the following ?
> scene    -> addKid (pVtx);

Yes.

> How does plib's coordinate system work? (I am randomly trying to position my camera to find
> my object on my screen)

Z is up. X is East, Y is North.

If the object is close to the origin then you should see it if your camera is at

  (0, 0, -bignumber)

> PS.  1."scene" is a ssgRoot object ,  pVtx is the ssgVtxTable object.
>         2. The way I added vertices to the pVtx is by using vertices->add( <sgVec3>).
> "vertices" is an argument passed to ssgVtxTable's  constructor.

Seems reasonable.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net
                         http://freeglut.sourceforge.net

[Plib-users] Little question please help

[John T. <ndc...@mx...>]

After defineing a ssgVtxTable, and adding vertices and normals to the object, how do i
render the object?

Can I simply do the following ?
scene    -> addKid (pVtx);

How does plib's coordinate system work? (I am randomly trying to position my camera to find
my object on my screen)


PS.  1."scene" is a ssgRoot object ,  pVtx is the ssgVtxTable object.
        2. The way I added vertices to the pVtx is by using vertices->add( <sgVec3>).
"vertices" is an argument passed to ssgVtxTable's  constructor.

John Tsao

RE: [Plib-users] CAM using plib was: Wanted--bitmap

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

Marlin Mixon writes:
>
>This is for a CAM application using foam and hotwire, so textures don't
>actually come into play. Here's what I'm doing and I think I'm on the right
>track:

Ah..  Neat
I used hot wire and foam alot in my surfboard building days :-)

Here's a tip :-)
http://www.zcorp.com/

Cheers

Norman

[Plib-users] CAM using plib was: Wanted--bitmap

[Marlin M. <mar...@ho...>]

This is for a CAM application using foam and hotwire, so textures don't 
actually come into play. Here's what I'm doing and I think I'm on the right 
track:

I'm taking an aircraft fuselage and presenting it in a true sideview with an 
ortho projection. (ortho-projection = oxymoron?) (I'm not actually 
interested in the textures, they are just a bonus in that they are pleasing 
to the eye.)

Then, by clicking my modified-viewer's right mouse button, it starts the 
recording process:  Using Steve Bakers snippet of code, I'll take a snapshot 
image of the sideview, rotate the fuselage like it was on a barbecue spit 10 
degrees, take a snapshot, 10 more degrees, snapshot, etc. until I've got 18 
images for 180 degrees.

Now I've got 18 profiles.  I'll process them in such a way that I've got a 
silhouette, that is I'm only interested in two colors: model vs background.  
Finally, I'll need to figure out a way to compute the edge, i.e. find all 
the white pixels sitting next to black pixels and figure out the set of line 
segments that delineates the edge.  This I will call the "linear profile."

With the linear profiles, I can scale them up to real-world units and apply 
them to my neighbor's computerized foam cutter:  Situate the foam and cut 
the first linear profile.  Rotate 10 degrees and cut the second linear 
profile, rotate, cut, etc.

After the 18 profiles have been cut, you will have a real-world replica of 
the virtual fuselage.  I know there will be a few limitations, like if you 
left the tail feathers on, there would be some peaks and valleys that would 
not be cut enough--excess material.  Also any compound concavity won't be 
rendered correctly such as scoop inlets.

Marlin
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

RE: [Plib-users] Wanted--bitmap

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

Steve Baker writes:
>
>Marlin Mixon wrote:
>>
>> Question:  is there a way to get a handle to a bitmap of,
>say, frame 7?
>
>No.
>
>You can read the contents of the frame buffer do to a 'screen dump' if
>that's what you need - but if you were thinking of doing some direct
>writing to the screen by simply addressing it as an array - forget it.
>3D chipsets are very posessive when it comes to the frame buffer and
>*ALL* rendering must go via OpenGL (which is what PLIB uses of course).
>
>"bitmap" is the wrong term BTW since it implies a one
>bit-per-pixel image.
>
>So, if you want to add a screen dump feature, you could use
>something like this:

< snip >

>> One reason why I'm enthusiastic about viewer.cxx is I've got some great
>> aircraft models that I downloaded from www.flightsim.com .  One in
>> particular is outstanding: a Kawasaki Ki-61 Hien.  File: st-hien2.zip.
The
>> airplane is generally similar to a Messershmidt Bf-109, however the paint
>> scheme is particularly colorful with some mean looking spotty camo.

Sounds to me like Marlin is asking
"is there away to get at the texture used in a ppe model"

If so the answer is sort of.
There is preliminary support in PPE for viewing the 'ssg model graph'
This is alpha and could use lot's of work if someone wants a project.
The hooks are all in place :-)

Anticipating Marlin's next question.
"Is it possible to interactively modify the texture"

3D paint in PPE would be cool but is not doable today.
Getting better interactive manipulation of the SSG scenegraph
would go along ways towards making this a reality.
< see afore mentioned project >

Cheers

Norman Vine

Re: [Plib-users] Wanted--bitmap

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

Marlin Mixon wrote:
> 
> Working with viewer.cxx--great program BTW.  Trying to figure out how it
> works.  I was trying to figure out where it generated the bitmap, when it
> dawned on me: duh, it's handled by the video card.  So, ssgLoadAndCull() +
> GLUT basically sends the handle of the 3-d object to the card and the card
> renders the image right?

Well, there's a *bit* more to it than that - there are 30,000 lines of code
between "ssgCullAndDraw" and the graphics card(!) - but essentially, yes.

> Question:  is there a way to get a handle to a bitmap of, say, frame 7?

No.

You can read the contents of the frame buffer do to a 'screen dump' if
that's what you need - but if you were thinking of doing some direct
writing to the screen by simply addressing it as an array - forget it.
3D chipsets are very posessive when it comes to the frame buffer and
*ALL* rendering must go via OpenGL (which is what PLIB uses of course).

"bitmap" is the wrong term BTW since it implies a one bit-per-pixel image.

So, if you want to add a screen dump feature, you could use something like
this:

void do_screen_grab ( int width, int height )
{
  unsigned char pixels [ width * height * 3 ] ;
 
  glReadPixels ( 0, 0, width, height, GL_RGB, GL_UNSIGNED_BYTE, pixels ) ;
 
  FILE *fd = fopen ( "tmp.ppm", "wa" ) ;
  assert ( fd != NULL ) ;
  fprintf ( fd, "P3\n# Screen Dump\n%d %d\n255\n", width, height ) ;
  for ( int i = height-1 ; i >= 0 ; i-- )
    for ( int j = 0 ; j < width*3 ; j++ )
    {
      fprintf ( fd, "%d ", pixels[i*width*3+j] ) ;
      if ( (j+1)%4 == 0 )
        fprintf ( fd, "\n" ) ;
    }
 
  fclose ( fd ) ;
}

...this writes a file in "ppm" format - which is probably the easiest format to
write out.

glReadPixels does the job of transferring the screen image into main memory.

> One reason why I'm enthusiastic about viewer.cxx is I've got some great
> aircraft models that I downloaded from www.flightsim.com .  One in
> particular is outstanding: a Kawasaki Ki-61 Hien.  File: st-hien2.zip.  The
> airplane is generally similar to a Messershmidt Bf-109, however the paint
> scheme is particularly colorful with some mean looking spotty camo.  The
> original author, Shigeru Tanaka of Kobe Japan does really nice work.  I
> emailed him a few years ago and he said that he was modeling plastic models,
> but most of his collection was destroyed during the Kobe earthquake.  More
> recently he's been shifting his energies to virtual modelling that can be
> shared over the internet.  Anyone who's interested in a copy, just send me
> an email and I'll be happy to pass it on.

I believe Wolfram Kuss is collecting aircraft models for the FlightGear list - if
he doesn't already have this one, I'm *sure* he'd be interested. (He's a regular
on this list BTW).

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net
                         http://freeglut.sourceforge.net

RE: [Plib-users] Distributing Win32 compilations (cygwin)

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

Marlin Mixon writes:
>
>Curious, what files do you need to install a plib win32 EXE?  
>I started a 
>collection of dll's based on error messages, but I stopped getting 
>meaningful error messages after I determined the following:
>
>The.exe
>cygwin1.dll
>glut32.dll
>
>I would think that you'd need some or all of the libplibxx.a 
>files, except in a dll format right?

For a cygwin executable you can use cygcheck ie.

bash-2.04$ cygcheck tux_example.exe
Found: .\tux_example.exe
.\tux_example.exe
  c:\cygwin\bin\cygwin1.dll
    C:\WINDOWS\SYSTEM\KERNEL32.dll
  C:\WINDOWS\SYSTEM\GLU32.DLL
    C:\WINDOWS\SYSTEM\MSVCRT.dll
    C:\WINDOWS\SYSTEM\OPENGL32.dll
      C:\WINDOWS\SYSTEM\CRTDLL.dll
      C:\WINDOWS\SYSTEM\ADVAPI32.dll
      C:\WINDOWS\SYSTEM\GDI32.dll
      C:\WINDOWS\SYSTEM\DCIMAN32.dll
      C:\WINDOWS\SYSTEM\USER32.dll
  C:\WINDOWS\SYSTEM\glut32.dll
    C:\WINDOWS\SYSTEM\WINMM.dll
  c:\cygwin\bin\cygpng2.dll
    c:\cygwin\bin\cygz.dll

But be advised as to the requirements for distributing the cygwin dll
http://www.cygwin.com/licensing.html

Cheers

Norman Vine

Re: [Plib-users] Distributing Win32 compilations (cygwin)

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

Marlin Mixon wrote:

> Curious, what files do you need to install a plib win32 EXE?  I started a
> collection of dll's based on error messages, but I stopped getting
> meaningful error messages after I determined the following:
> 
> The.exe
> cygwin1.dll
> glut32.dll
> 
> I would think that you'd need some or all of the libplibxx.a files, except
> in a dll format right?

PLIB doesn't install as DLL's it's a bunch of .LIB's (I think that's right
for windoze...statically linked libraries anyway).

You should also need opengl32.dll - but that's probably dragged in by
GLUT.  I don't use windoze - but I thought I'd heard that you need
something called mmsystem.dll - the multimedia library...I could
easily be wrong about that though.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net
                         http://freeglut.sourceforge.net

[Plib-users] Wanted--bitmap

[Marlin M. <mar...@ho...>]

Working with viewer.cxx--great program BTW.  Trying to figure out how it 
works.  I was trying to figure out where it generated the bitmap, when it 
dawned on me: duh, it's handled by the video card.  So, ssgLoadAndCull() + 
GLUT basically sends the handle of the 3-d object to the card and the card 
renders the image right?

Question:  is there a way to get a handle to a bitmap of, say, frame 7?

One reason why I'm enthusiastic about viewer.cxx is I've got some great 
aircraft models that I downloaded from www.flightsim.com .  One in 
particular is outstanding: a Kawasaki Ki-61 Hien.  File: st-hien2.zip.  The 
airplane is generally similar to a Messershmidt Bf-109, however the paint 
scheme is particularly colorful with some mean looking spotty camo.  The 
original author, Shigeru Tanaka of Kobe Japan does really nice work.  I 
emailed him a few years ago and he said that he was modeling plastic models, 
but most of his collection was destroyed during the Kobe earthquake.  More 
recently he's been shifting his energies to virtual modelling that can be 
shared over the internet.  Anyone who's interested in a copy, just send me 
an email and I'll be happy to pass it on.

Marlin
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

[Plib-users] Distributing Win32 compilations (cygwin)

[Marlin M. <mar...@ho...>]

Hi all,

Curious, what files do you need to install a plib win32 EXE?  I started a 
collection of dll's based on error messages, but I stopped getting 
meaningful error messages after I determined the following:

The.exe
cygwin1.dll
glut32.dll

I would think that you'd need some or all of the libplibxx.a files, except 
in a dll format right?

BTW, happily compiling after some assistance from Norman :)

Marlin
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: [Plib-users] BGL Loader

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

John Tsao wrote:
> 
> Surprisingly to me, about 90% of the the polygons in BGL files (for urban areas)
> are actually composed by  BGL_BUILDING.  The command takes 4 arguments of  the
> dimension of the buildings (another 4 are typically just 0's)...

Probably the origin of the building is three of those...dunno what the fourth would
be.  Probably a rotation angle.

> ...and simply draws blocks.
> I need to think about how to embed this procedure into ssgLoaderMDL.

Just make it generate an ssgVtxTable containing a cubeoid.

You can hack the code to generate an arbitary cuboid from plib/src/ssgAux/ssgaShapes.cxx
(ssgaCube::regenerate() is the function you need).  Please don't actually generate an
ssgaCube object though (although that would *seem* reasonable) because it would create
a dependance on libplibssgaux.a that would break the build mechanism for 90% of PLIB
applications.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net
                         http://freeglut.sourceforge.net

Re: [Plib-users] BGL Loader

[John T. <ndc...@mx...>]

Surprisingly to me, about 90% of the the polygons in BGL files (for urban areas)
are actually composed by  BGL_BUILDING.  The command takes 4 arguments of  the
dimension of the buildings (another 4 are typically just 0's) and simply draws
blocks.
I need to think about how to embed this procedure into ssgLoaderMDL.
Any comment?

John Tsao

Re: [Plib-users] BGL Loader

[Wolfram K. <w_...@rz...>]

John Tsao <ndc...@mx...> wrote:

>Besides polys, what information in a mdl file is required by =
ssgLoaderMDL so
>that ssgLoaderMDL can function well?
>I created a minimum bgl file with only one polygon. ssgLoaderMDL does =
parse all
>three commands in the file(I set debug messages), including =
BGL_SCALE_AGL,
>BGL_TEXTURE, and BGL_RESLIST. However, ppe doesn'g show any thing =
(neither can
>it save the poly to a .ac file)

Strange. It is a filled poly, is it not?
PrettyPoly has the Command "printSceneGraph". I think it is bound to
the key "p" (It is for me at home ;-)), if not add a line to the
keybindings. Send us the resulting scene graph (it appears on stdout).

>John Tsao

Bye bye,
Wolfram.

RE: [Plib-users] cygwin compile q's

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

Marlin Mixon writes:
>
>Maybe I'll install Linux.  I've been messing around with 
>cygwin for a week, 
>but I haven't gotten close to having any fun :(

Installing Linux is probably a 'good' thing todo 
but I might try reinstalling Cygwin.

Just click on the install Cygwin now icon at 
http://www.cygwin.com

The setup program is smart enough to not download
anything that it doesn't need to.  Just make sure that
you tell it the directory that you previously downloaded
to when asked.

FWIW -- this sounds like an installation problem.

After reinstalling if you still have no joy you can send me
not the list the output from a bash prompt of

% cygcheck -s -v -r

and I can help you troubleshoot your system
but a reinstallation should just work :-)

FYI  
Lots of people are using Cygwin and PLib with lots of 'fun'

Cheers

Norman

Re: [Plib-users] BGL Loader

[John T. <ndc...@mx...>]

Besides polys, what information in a mdl file is required by ssgLoaderMDL so
that ssgLoaderMDL can function well?
I created a minimum bgl file with only one polygon. ssgLoaderMDL does parse all
three commands in the file(I set debug messages), including BGL_SCALE_AGL,
BGL_TEXTURE, and BGL_RESLIST. However, ppe doesn'g show any thing (neither can
it save the poly to a .ac file)

One thing, BGL files like BGL_SPNT a lot. (Does this matter? Any way I will
implement it later)

John Tsao

RE: [Plib-users] cygwin compile q's

[Marlin M. <mar...@ho...>]

>From: "Norman Vine" <nh...@ca...>
>Marlin
>after replacing your current configure.in with this one
>you will need to do from a bash prompt
>
>% rm config.*
>% aclocal
>% automake -a
>% autoconfig
>% ./configure
>% make
>% make install

I tried the above...curious thing, my cygwin's make is very broken.  It will 
happily create an empty libplibpu.a even though there's not a single .o file 
in the directory.

Maybe I'll install Linux.  I've been messing around with cygwin for a week, 
but I haven't gotten close to having any fun :(

Marlin
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

RE: [Plib-users] cygwin compile q's

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

Steve Baker writes:
>Marlin Mixon wrote:
>
>> 1. What is glx.h and where is it obtained?
>> Also, is there a library that goes with it?
>
>glx.h is an X-windows header file.  I don't think you should need it
>with Cygwin.  It sounds like something isn't being configured 
>correctly.

This is definately a configuration problem.

FYI
The Cygwin Toolkit has matured rapidly since going to a component 
based rather then a monolithic distribution method in the last year.

One of the things that has changed is that the default gcc 'specs' no
longer assumes that you are compiling for a Win32 enviroment.

I didn't believe that this change had made it into the 'normal' vs the
developers distribution yet. 
Apparently it has and we need to change our configure.in

I have placed a trial configure.in at
http://www.vso.cape.com/~nhv/files/PLib/configure.in

This should fix Marlin's problem but I am hesitant to 
post it to the CVS until it has been tested on nonCygwin systems
Could others test this please 

Marlin
after replacing your current configure.in with this one 
you will need to do from a bash prompt

% rm config.*
% aclocal
% automake -a
% autoconfig
% ./configure
% make
% make install

Cheers

Norman