plib-users

[Plib-users] TuxFleet 0.3.0 binaries for aix,sparc-solaris

[Alexander R. <a_r...@in...>]

Hi,

I've just compiled TuxFleet 0.3.0 for rs6000-ibm-aix and
sparc-solaris27.

Both binaries are available from my project Homepage or FTP-space.

The aix binary was linked against whatever GL library was installed on
that
machine.

The sparc-solaris27 binary was linked/compiled against MesaGL-3.2.1 and
Glut 3.7
because there where no GL libraries available per default on that
machine.
The GL binary libs used to compiled/link against TuxFleet are also
available
from my Homepage or FTP-Space.

I failed to compile tuxfleet-0.3.0 for Beos5 (yet), because of:
	symbol PF_INET unknown

I searched all header files for PF_INET, I found AF_INET, but no
PF_INET.
Everything other is there - but no PF_INET.


Any ideas?




Alex

-- 
                   Alexander Rawass
          Email: ale...@us...
     Project Homepage: http://tuxfleet.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

[Plib-users] max number of surfaces per model

[Alexander R. <a_r...@in...>]

Hi,

Alexander Rawass wrote:
> 
> Hi,
> 
> Phrostie wrote:
> >
> > I would be willing to work with you on building models for tuxfleet.
> 
> Great! You're welcome.
> 
> > most of my 3d has been either engineering/mechanical or raytracing/renderman.
> > if you can give me a direction to work i will see what i can come up with.
> >
> > max number of surfaces per model?
> > max total size of textures per model?
> 
> That's a difficult question to ask.
> I will post that question to pli...@us..., since the
> people
> who wrote the rendering engine that TuxFleet users will know better what
> their library can render than me, but there is yet an answer from me:

So, what would you say to him?

Please make the following assumptions:
1) the HudObjects using glut have been replaced or switched off and
therefore
   take up not much cpu time
2) my code that does the game logic takes up from 0.001 to 0.005 secs
each frame
3) the rest of the time is ssgCullAndDraw

I personally just cant image how many polygons a suitable object should
have,
how many polygons plibssg can render (if not slowed down by game code or
huds)?

But read here, what I wrote Phrostie as anser and give comments:

> As less surfaces/as less polygons as possible.
> 
> This answer may not satisfy you, so let me just explain with some
> examples
> what I mean:
> 
> Have a look at the bee (data/bee.ac). It's my favorite model, it looks
> so
> *cute* :-)
> 
> This bee consists of different parts, some appear once, some more often:
> 
> eye wing bodyball striped_bodyball sting snout
> 
> Now, go ahead and split up that bee in it's different subparts and save
> them
> as ac3d-files, like 'bee_eye.ac'  'bee_striped_bodyball.ac' etc.
> 
> Then create new bees.
> 
> A bee with three eyes.
> A bee without wings.
> A bee with four wings.
> A longer bee with 2 striped_bodyballs instead of one.
> A longer bee with 2 striped_bodyballs and 3 bodyballs and 4 eyes and 6
> wings
> A tandem bee, meaning two bee-bodies connected by a wing.
> 
> Now back to your question about nr. of surfaces:
> 
> Just take the bodyball/striped_bodyball for instance.
> 
> How many polygons/surfaces should such a ball have?
> 
> Now create a new bodyball, that has some more surfaces than the bodyball
> before, so
> making it look rounder and save it as "bee_bodyball_high.ac".
> Then create a new bodyball, with less surfaces/polygons than that
> before, it
> will probably look ugly and not round at all, but it will be suitable as
> a low
> detail model, so save it as "bee_bodyball_low.ac".
> You could go as far as creaing a cube with that color and save it as
> "bee_bodyball_verylow.ac".
> 
> Now it is my job to write an utility that takes as input the different
> body
> parts in all detail resolutions and construct out of these the complete
> new models in all detal resolutions - and bingo, we have many different
> kinds of bees in different level of details.
> 
> Then go on and do the same job on other objects, like the flying saucer
> or the shark (dest1.ac), and re-do them in different level of details.
> 
> You can also decide not to work on existing models but start creating
> your
> own (whatever you want).
> 
> You just have to ask _yourself_, how can I do that what I want with as
> few
> polygons as possible?
> If you're using too many polygons in a part of your ship, that will
> reduce
>  rendering speed, so you should create that part in lower resolution,
> too.
> 
> For bad examples about 'lots of lots of polygons', have a look at avalon
> or
> the Star Wars Modelling Alliance.
> 
> A model suitable for TuxFleet should, for example, have no polygons at
> the inside
> of the model (if possible), details should be done with texturing.
> 
> Please tell me what models you'd like to do - update existing ones,
> create
> completely new ones from your personal fantasy, or create models that
> look
> like spaceships know from elsewhere/tv/movies?
> 
> If you could describe what visions you have on your mind, I can try to
> answer you better.
> 
> But I fear, every time you design an object for TuxFleet, you have to
> ask
> _yourself_: "How few polygons do I need for that part in that level of
> detail?"
> 
> Another example would be the freighter (freight1.ac).
> 
> This ship has far too many polygons for a low detail models, due to the
> cockpit, the many transport-cubes and the engines.
> As well, it looks ugly when you fly near to it, so it isn't suitable for
> high detail either.
> 
> For a low polygon model of the freighter, create a simple block that's
> got
> sort snout (the cockpit) at one end and no engines, and wrap around it a
> texture that looks like as if this simple block/rectangle would consist
> of these transport-cubes.
> 
> Then create a higher detail model by wrapping texture around the
> different
> transport-cubes.
> Re-do the cockpit, by replacing the polygons the cockpit is constructed
> of
> by a texture that looks like as if there would be a cockpit.
> 
> And always save the different parts of the ships you create in their
> respective detail level, so that they can be re-used easily.
> 
> Now for your question of texture size:
> 
> This is even harder for me to answer, since the models I use yet came
> with-
> out any texture, but I suspect, you've got to use the same dynamic rule
> like for polygons/surfaces:
> 
> As few textures as possible, and each texture should be as small as
> possible
> with respect to different detail levels.
> 
> You could again start with the bee.
> 
> Take the bodyballs you made in higher resolution, and wrap a texture
> around
> it so that it will look more a bee's bodyball than before.
> 
> Take the eyes. Remove the black eyeball done with polygons and do create
> a new
> eye with a texture that looks like an eyeball.
> Create an eye that's got a texture that looks as if the eye hadn't had
> sleep
> at night and drunk too much, like some blood-red zigzag lines coming
> from the eyeball.
> 
> Take the wings. Wrap a texture around it, that looks at if streaks of
> red blood
> are pulsing through the veins of those wings.
> Make the wing texture nearly transparent, exept for the veins.
> 
> Take the flying saucer and wrap a texture onto it, that looks like
> engines and turrets and air locks.
> 
> To end this mailing, I just want to say that the number of polygons
> for a whole ship in medium detail should be less than 100 polygons if
> possible - if have converted some 3ds models from 2000 polygons down
> to 300 polygons and they were too slow.
> 
> But I have to admit that I know nothing of 3D modelling, I simply
> can't image myself how few polygons one needs to contruct a spaceship
> that looks good AND renders fast.
> 
> Of course - it's a tedious act to create all subparts of the ships in
> different
> detail levels, but that's the only way to improve rendering speed.
> If I've got no low detail models, I have to render them with lots of
> polygons
> even if they're just 1cm on the screen.
> At present, the complete lack of models in different level of details
> (LOD)
> is one of the reasons why TuxFleet is yet so slow.
> 
> Hope to hear from you
> 


Alex

-- 
                   Alexander Rawass
          Email: ale...@us...
     Project Homepage: http://tuxfleet.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

[Plib-users] Re: TuxFleet (-l3dtk -lplibul wrong)

[Alexander R. <a_r...@in...>]

Hi,

Note for people who want to compile TuxFleet:

the src/Makefile contains an error, it will try to link against -l3dtk
-lplibul,
which will produce link errors on most end-user systems, unless you're
lib3dtk
and plib developer.

If linkage fails, remove '-l3dtk' as well as '-lplibul' from the
Makefile and
try again.

Christoph Egger wrote:
> >
> > New Release:
> >
> > tuxfleet-0.3.0 is available from tuxfleet.sourceforge.net
> >
> 
> I got some compiler warnigs:
> 
> space_command.cxx: In method `void SpaceObject::ProcessCommand(int)':
> space_command.cxx:156: warning: `int new_target_nr' might be used uninitialized in this function

Noticed.

> And one linkage error:
> 
> make[1]: Entering directory `/home/programmer/src/tuxfleet-0.3.0/src'
> gcc -o tuxfleet -L/usr/X11R6/lib  -L/fire-win/koba-backup/plib
> -L/boot/home/config/lib ssgUtil.o hudobject.o hud_radars.o hud_displays.o
> hud_others.o hud_camera.o joystick.o spaceobject.o space_pitchmove.o
> space_command.o spacemodel.o space_checks.o space_energy.o space_hardpoints.o
> space_radar.o space_target.o space_throttle.o space_weapons.o space_dirvecs.o
> ki.o ki_special.o ki_player.o ki_dumbkis.o ki_attacker1.o ki_attacker2.o
> ki_attacker3.o mission.o engine.o engine_update.o keymap.o explosion.o
> engine_kis.o engine_huds.o simulator.o cache.o engine_collisions.o
> engine_keyboard.o engine_spacejunk.o engine_initgfx.o engine_load.o
> fleet_scene_ssg.o weapons.o engine_create.o fleet_sound.o guimenu.o
> puScrollList.o guimenu_callback.o radio.o eventbase.o triggers.o events.o
> fleet_scene_3dtk.o fleet_scene.o fleet_net.o engine_net.o tuxfleet.o -lplibssg
> -lplibsg -lplibsl -lplibsm  -lplibpu -lplibul -lglut  -lGL -lGLU -lSM -lICE
> -lX11 -lXi -lXmu -lXext -lm -l3dtk
                               ^^^^^^
> /usr/i486-linux/bin/ld: cannot open -lplibul: No such file or directory
                                        ^^^^^^^
Uh - yes, I have to correct that.

I used plib from cvs to compile/link, plibul isn't there in older plib
versions.

I will take that out in new releases and use plib-1.3.0 if possible (but
then I cannot change to puFilePicker)

I will also have to take out -l3dtk per default in the next release,
cause
this lib is optional and most users won't have it.

So, if you get linkage errors - just remove -lplibul and -l3dtk from the
Makefile.


Sorry, but big thanks for reporting.




Alex

-- 
                   Alexander Rawass
          Email: ale...@us...
     Project Homepage: http://tuxfleet.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

[Plib-users] Quaternion rotations

[Bob H. <ham...@ho...>]

Hi,

I downloaded the latest CVS version of plib and found the new quaternion =
demo (with the two rotating cubes).  This demo rotates the quaternions =
around the world axes (using sgRotQuat(..) ).

How can I use quaternions to rotate an object around it's axes?  I've =
got an idea that might work.  Say I want to rotate around the x axis, I =
convert my quaternion to a matrix, extract the first column and use this =
as the vector passed to sgRotQuat.

Ie.

sgMat4 tmpMat ;
sgQuatToMat ( tmpMat, myQuat ) ; // Make the matrix from the quaternion
sgRotQuat ( myQuat, 5.0, tmpMat [0] ) ; // Rotate 5 degress around =
objects x axis

Since we're only using the first row of the matrix the above can =
probably be simplified.

Will this work? Is there anything else I need to know (stuff that might =
bite me in the ass?) ?

[Plib-users] Namechange: Kobayashi Maru -> TuxFleet

[Alexander R. <a_r...@in...>]

Hi,

Kobayashi Maru is now TuxFleet

This is a Namechange from Kobayashi Maru to TuxFleet and had to be done
to avoid possible legal problems.
Thanks to Steve Baker for giving me his point, see thread in plib-devel.

Homepage:     tuxfleet.sourceforge.net
Mailing-List: tux...@li...

Please correct all your links and bookmarks, the old site/mailing-list
will
get obsolete in a few days.

Dear Steve, if you like, you can use the picture of 'Tux Iceswimmer'
(he is a cousin to the famous 'Tux the Penguin' as known from 
 'A Quest for Herring') as a logo to put on the plib homepage.


New Release:

tuxfleet-0.3.0 is available from tuxfleet.sourceforge.net as source and
binary
for i386-linux.

If anyone of you is able to build binaries for other platforms/os,
please
drop them in ftp://tuxfleet.sourceforge.net/pub/tuxfleet/incoming/ and
send
me notice via mail.


Important changes are:
the names used for some symbols,
basic net/multiplayer support
fixed an evil bug that made screen flicker red/green


Note about Net/Multiplayer:

This is yet at an early development stage, it is not designed to run on
modem lines, currently the client shows a copy of the servers window
See tuxfleet.sourceforge.net/net_multiplayer.html for more details.



ChangeList:

tuxfleet-0.3.0  30 Aug 2000
        implemented basic net/multiplayer support, not usable yet,
	 will not work on modem lines 
        remove the more-than-one-line printfs 
        in Gui/Modelview you can see now the model rotating 
        new Events/Triggers 
        written a better KI_Galaxy to avoid rotating galaxies :-) 
        I've taken the explosion frames from SpaceThing and fixed a bug
in
	 the explosion routine 
        fixed bad bad bug that was introduced in 0.2.0 and made the
screen
	 flicker green or red when a turret fired a shot 
            I'm so happy about that, I'll declare the new  version to be
0.3.0 
        changes to support lib3dtk by Christoph Egger as alternate
scenegraph
	 (still in development) 
        corrected bug in SpaceObject->setTarget 
        new features : plays music ("*.mod"-files) if you like 


Alex


-- 
                   Alexander Rawass
          Email: ale...@us...
     Project Homepage: http://tuxfleet.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

[Plib-users] problems with ssgStateSelector

[Eric E. <Eri...@fr...>]

I have 2 problems with ssgStateSelector (plib 1.2.0):

1 - minor: the print don't get stderr by default, you should pass
           at least the fd (may be ssgState is lacking the default
           value also)

2 - major: The clone provokes an error and the program exits. 
	    I have some problems with my gdb so I can't say
	    a lot... here is the gdb output:

Program received signal SIGSEGV, Segmentation fault.
0x41ebf0d6 in ?? () from /home/torcs/sb/torcs/runtime/modules/graphic/ssggraph.so
(gdb) symbol /home/torcs/sb/torcs/runtime/modules/graphic/ssggraph.so
Load new symbol table from "/home/torcs/sb/torcs/runtime/modules/graphic/ssggraph.so"? (y or n) y
Reading symbols from /home/torcs/sb/torcs/runtime/modules/graphic/ssggraph.so...done.
(gdb) where
#0  0x41ebf0d6 in ?? () from /home/torcs/sb/torcs/runtime/modules/graphic/ssggraph.so
#1  0x41ebf0dc in ?? () from /home/torcs/sb/torcs/runtime/modules/graphic/ssggraph.so
#2  0x41ebf0dc in ?? () from /home/torcs/sb/torcs/runtime/modules/graphic/ssggraph.so
#3  0x41ebf0dc in ?? () from /home/torcs/sb/torcs/runtime/modules/graphic/ssggraph.so
#4  0x41ebf0dc in ?? () from /home/torcs/sb/torcs/runtime/modules/graphic/ssggraph.so
...

In my program, I have the following actions:

	myssgStateSelector = new ssgStateSelector(1);
	myssgSimpleState = new ssgSimpleState;
	myssgSimpleState->setTexture(image);
	myssgStateSelector->setStep(0, myssgSimpleState);

then I clone the ssgStateSelector with:

	otherssgStateSelector = (ssgStateSelector*)myssgStateSelector->clone(0);

and then boom.

If the problems are not known, I'll try to sort them out tomorrow... it's too late now.

Thanks in advance,
Eric.
-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

                       TORCS
            The Open Racing Car Simulator
                 http://torcs.org

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

Re: [Plib-users] Crash in plibsl

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

David Bateman wrote:
> 
> Hmmm, it seems to play just fine on my plib-1.2.0 install, if a bit on the
> LOUD side. All I did was copy bigjapn2.mod to examples/sl in plib_examples,
> rename it to "Paravoka.mod", and "./mod_demo".

Nope - it Seg Faulted on my machine...it looks like it did it when the music
ended and it was due to wrap-around an start playing for a second time.

Program received signal SIGSEGV, Segmentation fault.
_MOD_instHirevLoop (ihip=0x807df50) at slMODinst.cxx:129
129         int d = ( signed char ) ( *ihiPtr ^ 0x80 ) ;
(gdb) where
#0  _MOD_instHirevLoop (ihip=0x807df50) at slMODinst.cxx:129
#1  0x804d3c4 in _MOD_instLoop () at slMODinst.cxx:468
#2  0x804f073 in _MOD_playNote () at slMODnote.cxx:435
#3  0x804b2dc in MODfile::play_one (this=0x806f730, ppat=12)
    at slMODfile.cxx:400
#4  0x804bb0f in MODfile::update (this=0x806f730) at slMODfile.cxx:523
#5  0x804a52f in slMODPlayer::low_read (this=0x806f6d8, nframes=1024,
    dst=0x806e6b8 't' <repeats 12 times>, at slMODPlayer.cxx:41
#6  0x804a30d in slPlayer::read (this=0x806f6d8, nframes=1024,
    dst=0x806e6b8 't' <repeats 12 times>, next_env=0) at slPlayer.cxx:62
#7  0x80494a2 in slScheduler::realUpdate (this=0x8053da0, dump_first=0)
    at slScheduler.cxx:196
#8  0x8048d2f in main () at /usr/include/plib/sl.h:676

Also, I loaded it into FunkTrackerGOLD - it didn't complain *or* crash
but it *did* play the tune at about twice the normal speeed.  That double
speed thing is *strange* - other tunes play at the same speed in
Funktracker and SL.

Does this mean that there is a bug in SL?  Does it mean that the MOD file
is somehow 'broken'?   I'm not sure.  I was hoping for more concrete
evidence.

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

Re: [Plib-users] Crash in plibsl

[David B. <da...@fi...>]

Hmmm, it seems to play just fine on my plib-1.2.0 install, if a bit on the
LOUD side. All I did was copy bigjapn2.mod to examples/sl in plib_examples,
rename it to "Paravoka.mod", and "./mod_demo".

Alexander Rawass wrote:
> 
> Hi,
> 
> Steve Baker wrote:
> >
> > OK!  So we can be sure it's not an application failure.
> >
> > > I suspect an illegal MOD file - it was just lying around, never tested
> > > it before.
> >
> > OK - better email it to me (*NOT* to the list please).
> 
> You may have overread it in my mail before:
> 
> ftp://kobayashimaru.sourceforge.net/pub/kobayashimaru/plib/
> File bigjapn2.mod
> 
> Alex

Re: [Plib-users] Transparent Background

[Alexander R. <a_r...@in...>]

Hi,

Steve Baker wrote:

> > I did load one of those into gimp, and gimp showed me that the picture
> > had
> > no alpha channel, and that the background was indeed black not
> > transparent.
> 
> In GIMP, do this:

Thanks , I did it that way.

But I have to say, my mouse walked a mile ;-)


Alex

-- 
                   Alexander Rawass
          Email: ale...@us...
   Project Homepage: http://kobayashimaru.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

Re: [Plib-users] Crash in plibsl

[Alexander R. <a_r...@in...>]

Hi,

Steve Baker wrote:
> 
> OK!  So we can be sure it's not an application failure.
> 
> > I suspect an illegal MOD file - it was just lying around, never tested
> > it before.
> 
> OK - better email it to me (*NOT* to the list please).

You may have overread it in my mail before:

ftp://kobayashimaru.sourceforge.net/pub/kobayashimaru/plib/
File bigjapn2.mod


Alex

-- 
                   Alexander Rawass
          Email: ale...@us...
   Project Homepage: http://kobayashimaru.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

Re: [Plib-users] Transparent Background

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

Alexander Rawass wrote:

> I have some pictures I like to use as explosion, galaxies, background
> image etc.,
> but I need their background to be transparent, instead of color black.
> 
> I did load one of those into gimp, and gimp showed me that the picture
> had
> no alpha channel, and that the background was indeed black not
> transparent.

In GIMP, do this:

  1) Add an alpha channel.
  2) Under the 'select' menu, choose 'Select by colour'
  3) Click on some nice large black area - it'll select all the black
     in the image and you can wipe it out (to transparent) simply by
     clicking on 'cut' in the 'Edit' menu.
  4) By playing with the slider in the select/by-colour menu, you
     can control just how close to the colour of the pixel you
     clicked on will be selected.
  5) If that doesn't work well (eg there are also other dark areas
     that you want to keep - but you still have a dark 'halo' around
     the image) - then do a 'grow' in the select menu to increase the
     'thickness' of the selection before you hit 'cut'.
  6) UNDO (control-Z) can be your friend!  Use it!

> Or can I say GL/plib to load an object/image an declare color black as
> transparent?

No - I think GIMP is good enough to do this right.

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

[Plib-users] Transparent Background

[Alexander R. <a_r...@in...>]

Hi,

I have some pictures I like to use as explosion, galaxies, background
image etc.,
but I need their background to be transparent, instead of color black.

I did load one of those into gimp, and gimp showed me that the picture
had
no alpha channel, and that the background was indeed black not
transparent.

OK - I managed to add a alpha layer to the picture and could erase parts
of
the picture from black to transparent with the eraser but - parts of the
picture
are too fine/delicate for that tool, I'd better like to say something
like
"Hey gimp, please fill from here with transparency" or
"Hey gimp, please replace color black with transparency" but
I didn't find it (gimp newbie). Comments?
I managed to fill with some other color, but not with transparency.

Or is there an other batch-tool, that converts color black to
transparency for all
images I like?

Or can I say GL/plib to load an object/image an declare color black as
transparent?


Alex

-- 
                   Alexander Rawass
          Email: ale...@us...
   Project Homepage: http://kobayashimaru.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

Re: [Plib-users] Crash in plibsl

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

Alexander Rawass wrote:

> alex@annika:/vast1/source/3d/plib/plib-cvs0808/examples/src/sl > time
> ./mod_demo
> 
> Segmentation fault

OK!  So we can be sure it's not an application failure.
 
> Somehow, it crashes, but no debug printout this time.

Interesting.
 
> I suspect an illegal MOD file - it was just lying around, never tested
> it before.

OK - better email it to me (*NOT* to the list please).

> Urks - I don't know if I've got some Tracker lying around.

You should probably grab a copy of Funktracker or something - it's always
handy for simple things like speeding the music up or slowing it down.

> Aeh - no.
> You should abort the playing of this mod, maybe try it from the
> beginning
> (if called as loopMusic()), but you shouldn't abort the hole program if
> there's any chance that gameplay can continue without playing the MOD
> (or without playing any sounds) or report an error somehow back to the
> game that uses sl, but please no exit().

Well, that degree of error checking is expensive to implement - and you
wouldn't REALLY ever deliver a game with a corrupt MOD file - so I don't
think it's unreasonable to exit when you find a bad one.
 
> Have you thought about playing MIDI-Files? (I know it's very different
> in playing from mods)
> I personally would like that better, and I have many MIDI-files around.

Well, very few end-users have their MIDI set up done correctly...and even
when they do, you have no guarantee that their instrument setups are
compatible with the original artist's intentions.  You might play a
subtle, gentle piano sonata - only to find that your end user has that
voice set up as "Trobone" or something!  There is a standard for this
"General MIDI" - but the selection of instruments is miserable.

Altogether - MIDI is a poor choice.

I'm told there are tools to convert MIDI to MOD - but I have no idea
what they are.

> I didn't touch MODs since I dumped my Amiga, and I expect one can probably
> find more corrupt MODs with real bad sound in the net than good ones?

Not so far.  Every MOD file up until now has played OK.

> I proably didn't run that mission with that MOD for more that 2min
> before, so the error didn't occur

OK. But the mod_demo test proves it's not application problems - so
we need to look at the MOD file and go from there.

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

Re: [Plib-users] Crash in plibsl

[Alexander R. <a_r...@in...>]

Hi,

Steve Baker wrote:

> I guess the first question is whether your application is corrupting
> something that *SUBSEQUENTLY* kills SL.  The simplest way to prove
> that either way would be to play your MOD file using the sample program.
> 
> Change 'mod_demo.cxx' so that instead of loading "Paravoka.mod", it
> loads your MOD file - and let me know if it still crashes.

This is the file:

alex@annika:/vast1/source/kobayashimaru > dir sounds/big*
-r--r--r--   1 alex     users       58596 Oct 15  1996
sounds/bigjapn2.mod

I copied the file to the examples/src/sl directory as Paravoka.mod, and
tried
it:

alex@annika:/vast1/source/3d/plib/plib-cvs0808/examples/src/sl >
./mod_demo 
Segmentation fault
alex@annika:/vast1/source/3d/plib/plib-cvs0808/examples/src/sl > time
./mod_demo
 
Segmentation fault

real    2m2.278s
user    0m0.070s
sys     0m0.000s
alex@annika:/vast1/source/3d/plib/plib-cvs0808/examples/src/sl > time
./mod_demo
 
Segmentation fault

real    2m2.286s
user    0m0.080s
sys     0m0.000s
alex@annika:/vast1/source/3d/plib/plib-cvs0808/examples/src/sl > time
./mod_demo
 
Segmentation fault

real    2m2.282s
user    0m0.050s
sys     0m0.030s
alex@annika:/vast1/source/3d/plib/plib-cvs0808/examples/src/sl >
./mod_demo 
Segmentation fault


Somehow, it crashes, but no debug printout this time.

> If it does crash - then we are certain the problem isn't in your
> application - and you can rest easy.  Presumably we'd be looking

Phew. Lucky me ;-)

> at either a straight SL
> bug or a corrupted or illegal MOD file -

I suspect an illegal MOD file - it was just lying around, never tested
it
before.

> and a problem that SL is not detecting that corruption and reporting
> it.

Probably.

> We could go on to try to play the MOD file in another MOD player like
> FunkTrackerGOLD (which I use).  If that reports a problem (or crashes

Urks - I don't know if I've got some Tracker lying around.

> or something) then we'll know it's a corrupt MOD file - and we'll have

I can send it to you/ put it in my ftp-space, if you like.

> to chase down SL's error recovery routines to find out why it died after
> complaining instead of just exiting fatally but cleanly or aborting the
> music or something.  Something as simple as changing the existing printf's
> into something more like "Corrupt MOD file - Bye-Bye" - followed by an 'exit'
> will suffice IMHO.

Aeh - no.
You should abort the playing of this mod, maybe try it from the
beginning
(if called as loopMusic()), but you shouldn't abort the hole program if
there's any chance that gameplay can continue without playing the MOD
(or without playing any sounds) or report an error somehow back to the
game that uses sl, but please no exit().

> If the 'mod_demo' crashes - but FunkTracker plays it flawlessly - then
> we have a genuine SL bug and you'll have to send me the MOD file so I
> can debug SL.  The MOD player is horribly complex and I wouldn't wish
> that problem on anyone!

I'll copy it to my ftp-space, directory plib before I send this mail.

> > I am currently using plib from cvs date 8. August 2000
> 
> SL hadn't changed in well over a year - so it shouldn't matter which
> version you have.

Have you thought about playing MIDI-Files? (I know it's very different
in playing
from mods)
I personally would like that better, and I have many MIDI-files around.

> It's by *far* the most stable PLIB component - and I'm pretty suprised
> to find a bug report.

Shove me a virtual glass of champagne :-)

I didn't touch MODs since I dumped my Amiga, and I expect one can
probably
find more corrupt MODs with real bad sound in the net than good ones?

> So, work through the decision tree and tell us which branch you end up in!
> 
>                          Try playing MOD in mod_demo
>                                     / \
>                                    /   \
>                               Works     Crashes
                                          ^^^^^^^

> Another 'gut feeling' is that if it crashes intermittantly then it's MUCH
> more likely to be an application problem than an SL bug.  Interactive

I proably didn't run that mission with that MOD for more that 2min
before,
so the error didn't occur


Alex

-- 
                   Alexander Rawass
          Email: ale...@us...
   Project Homepage: http://kobayashimaru.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

Re: [Plib-users] Crash in plibsl

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

Alexander Rawass wrote:

> today I got this error while playing KobayashiMaru:
> 
> bug: restF=160
> end-ptr=-152045057 w=176954717
> wAcc = 0
> Segmentation fault
> 
> I grepped plib and found the lines which print these errors in
>         slMODinst.cxx

Hmm - yes - that looks like some debug I'd left in there during
development.

'end-ptr' means "The address of the end of the sound sample MINUS
the address of the current replay pointer" - and it's value is
pretty insanely negative - hence the error report.

The program should probably do an 'abort' on that condition - but
it's clearly not something that should ever happen.
 
> Yes, I am playing MOD-files, just like it's shown in the easy-example
> you support with plib, but I thought it would work since a week.
> This error probably only happens some time, when there's an incorrect
> MOD or so. Tell me more.

Well, I've never had a report of a bug in the MOD player - and it's
never died on any MOD file's I've ever seen...but that doesn't mean
it's flawless.  :-)

I guess the first question is whether your application is corrupting
something that *SUBSEQUENTLY* kills SL.  The simplest way to prove
that either way would be to play your MOD file using the sample program.

Change 'mod_demo.cxx' so that instead of loading "Paravoka.mod", it
loads your MOD file - and let me know if it still crashes.

If it does crash - then we are certain the problem isn't in your
application - and you can rest easy.  Presumably we'd be looking
at either a straight SL
bug or a corrupted or illegal MOD file -
and a problem that SL is not detecting that corruption and reporting
it.

(Well, it *is* reporting some kind of problem - but then crashing which
isn't exactly friendly).

We could go on to try to play the MOD file in another MOD player like
FunkTrackerGOLD (which I use).  If that reports a problem (or crashes
or something) then we'll know it's a corrupt MOD file - and we'll have
to chase down SL's error recovery routines to find out why it died after
complaining instead of just exiting fatally but cleanly or aborting the
music or something.  Something as simple as changing the existing printf's
into something more like "Corrupt MOD file - Bye-Bye" - followed by an 'exit'
will suffice IMHO.

If the 'mod_demo' crashes - but FunkTracker plays it flawlessly - then
we have a genuine SL bug and you'll have to send me the MOD file so I
can debug SL.  The MOD player is horribly complex and I wouldn't wish
that problem on anyone!

On the other hand - 

If the example program DOESN'T crash while playing your MOD file then we
must expect it's a bug in your application somewhere that's screwing up
some memory that belongs to SL or something.  It's not for *sure* that
it's an application bug - it could be that SL has a data/timing dependant
bug - but given it's previous 100% reliability record in literaly dozens
of programs and with dozens of MOD files, I'd very much doubt that.

If we end up at this point in the 'decision tree' then I'm betting on
an application error...especially since yours is a fairly new program
that probably doesn't have all of the kinks worked out of it yet.

> I am currently using plib from cvs date 8. August 2000

SL hadn't changed in well over a year - so it shouldn't matter which
version you have.

It's by *far* the most stable PLIB component - and I'm pretty suprised
to find a bug report.

The *only* known problem comes in FlightGear when insanely large frequency
and volume parameters are applied to a sound sample, that can cause some
problems - but not in the music code - which is really very separate from
the sound *sample* replayer stuff.

So, work through the decision tree and tell us which branch you end up in!

                         Try playing MOD in mod_demo
                                    / \
                                   /   \
                              Works     Crashes
                                 /       \
                                /         \
                         Application       Play MOD in Funktracker
                           bug?            / \
                                          /   \
                                     Works     Fails
                                        /       \
                                 Serious SL      Bad MOD file,
                                     bug

Another 'gut feeling' is that if it crashes intermittantly then it's MUCH
more likely to be an application problem than an SL bug.  Interactive
applications do wildly different things each time they are run - but the
job of the music player is *almost* the same every time (not quite because
the timing changes from run to run - but *ALMOST* the same).

Hence, intermittant bugs are most likely to be caused by the application in
this case...not for *sure* but the odds are stacked that way.

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

[Plib-users] Crash in plibsl

[Alexander R. <a_r...@in...>]

Hi,

today I got this error while playing KobayashiMaru:

bug: restF=160
end-ptr=-152045057 w=176954717
wAcc = 0
Segmentation fault

I grepped plib and found the lines which print these errors in
	slMODinst.cxx

Yes, I am playing MOD-files, just like it's shown in the easy-example
you
support with plib, but I thought it would work since a week.
This error probably only happens some time, when there's an incorrect
MOD
or so. Tell me more.

I am currently using plib from cvs date 8. August 2000

Alex

-- 
                   Alexander Rawass
          Email: ale...@us...
   Project Homepage: http://kobayashimaru.sourceforge.net
...but some day you'll be a STAR in somebody else's SKY...

Re: [Plib-users] Problem with sgHPRfromVec3

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

Steve wrote:

>What's odd is that this code was just moved out of Tux_AQFH - where
>I use it to keep Tux glued onto the ground (given the surface normal
>of the polygon).

Hm, I simply searched Tux_AQFH for sgHPRfromVec3.
There is one occurence in hooks.cxx, but only hpr[0]
is used, so this one is uninteresting.
There is also one in whale.cxx:

  sgHPRfromVec3 ( heading, to_tux ) ;
[... much deleted]
	coord.hpr[1] = blend_angle ( coord.hpr[1], -heading[1] ) ;

Look at the minus-sign!

Bye bye,
Wolfram.

Re: [Plib-users] Problem with sgHPRfromVec3

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

Wolfram Kuss wrote:
> 
> Troy wrote:
> 
> >I saw a post about this before (I think in the plib-devel list)
> >but didn't see any response to confirm the problem.
> 
> Yes, that post was by me. I think it is a bug in plib and its still in
> the newest CVS and all "official" versions.
> 
> Steve, if you want to see it "in action", in PPE
> choose view/camera/rotate h,p and look into the console window.

What's odd is that this code was just moved out of Tux_AQFH - where
I use it to keep Tux glued onto the ground (given the surface normal
of the polygon).

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

Re: [Plib-users] RE: How should I use plib?

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

Troy Yee wrote:

> Thanks for your response Steve.  I don't know how you
> managed to fit all you do into a day...

It's 2:00am...I don't manage to fit it all in!

> So one way to use plib is to develop maps/scenes/tiles using
> some package that exports to a format for which plib has a loader
> (or write a new loader which reproduces the hierarchy of the scene).

Yes.

> Would one expect this to be the most common method of getting
> a scene into one's application?

Yes - by far the most common.
 
> How does one add dynamic objects to the scene?  Just add a
> transform node to the root?

Exactly.

I tend to organise my 3D models into 'fixed scenery' (mountains,
lakes, etc), 'positionable scenery' (houses, trees, etc) and
'moving models' (planes, cars, boats, etc).

I generally create a text file that contains the name of the
scenery file - and the names and coordinates of the positionable
scenery.  That makes it easy to move things around in the scene
to get them where you need them.

For dynamic models, the program knows what it needs and where it's
going to put them - so it can deal with that stuff in software.

Then the application program parses the text file, creating an
ssgTransform for every file it loads - which can then either be
set up one-time to position (for example) a house...or updated
every iteration of the application to create moving models like
boats and planes.

> Try to find out where in the scene
> hierarchy it should be placed?  Probably the former - what is the
> impact on rendering?

Not *too* bad.  It depends a lot on your hardware/driver - but on
the GeForce-256, the cost of an ssgTransform is about the same
as ten additional triangles on the model.

If you are *desperate* for every last drop of performance, there
is a routine called 'ssgFlatten' that multiplies out the ssgTransforms,
makeing the polygons down in the leaf nodes beneath be permenantly
nailed to their current positions.

> I'm using ssgLoadAC(), not creating it myself.  After I load the model,
> I add it to a transform node, rotate it (I hand built the model in z-is-up
> format so I have to undo the rotate that the loader does), then scale
> it from unit size to the game board size.  I don't make any other changes
> after that. Do I have to force a recalculation of the BSphere in this case?
> (I thought cullAndDraw would do a recalc if it was needed).

No you don't need to recalc the sphere if you didn't create the
vertices in your own code.  The loader takes care of it.
 
> > You should use a triangular mesh I think.
> 
> Yes, I knew that but I wanted to generate something I could
> look at with a minimum of effort.  Load - scale - move was
> much easier than trying to generate a mesh on the fly.

I have to confess that scaling isn't highly recommended.  It
*seriously* clobbers OpenGL performance - and I suspect may
be the cause of your 'vanishing model' problems.

I've never actually tried scaling things in SSG (because it's
so seriously inefficient at the OpenGL level) - and thinking
about it, I strongly suspect there is something broken in
SSG for field-of-view culling with scaled models.
 
> My choice of the word 'warp' was not the best.  It sounds like
> you took it to mean something like 'fly really really really fast'.
> I was actually thinking in the X-windows sense of warping a
> pointer - an instantaneous move to a new location.  The idea
> here is that a user selects a new entity from which to look at
> the scene.  This isn't *VERY* complex is it?

Oh - I see.  No - your program just tells SSG where it wants the
camera to be every frame.  I don't care whether it moves smoothly
or 'teleports' a thousand miles in one frame.
 
> I suspect the issue is that the new location could be quite
> far away from the current location so the tiles likely wouldn't
> be loaded.  I don't imagine that the new tiles can be loaded
> quickly enough to satisfy most users or can they?

Well, SSG doesn't deal with terrain paging - you need to look at
a higher level of abstraction - which is where Terragear comes in.

In any case like that though, the need to page terrain from disk
is what keeps you from doing instantaneous 'teleports'.  If you
do that, you probably want to just blank the screen for a few
seconds while the terrain pager catches up.
 
> I'll look at TerraGear.  I suspect I'll be able to get away with
> a lot less detail - the simulation will survive with no 3D at all
> (but won't be nearly as interesting!).

Well, that's your call. TerraGear is *awfully* cute!
 
-- 
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

[Plib-users] RE: How should I use plib?

[Troy Y. <tro...@ho...>]

FROM: Steve Baker
DATE: 08/15/2000 22:28:39
SUBJECT: RE:  [Plib-users] How should I use plib?

Thanks for your response Steve.  I don't know how you
managed to fit all you do into a day but I'm certainly
glad you do.  I really appreciate your input.

Steve Baker wrote:
> Troy Yee wrote:
>> 
>> Q: What is the best way to create a scene/world using plib?
>>    It seems to me that loaders are extremely useful but
>>    what is their impact on one`s ability to render a scene
>>    quickly and efficiently?  Aside from loading a model,
>>    and scaling/rotating/translating it what else must be
>>    done to manage the scene/world (i.e. BSP trees, LOD, etc.)?
>
> Theoretically - you don`t need to do ANYTHING - that`s what
> SSG is good at.
>
> SSG uses whatever the hierarchy of the scene is in the
> model file - and does heirarchical field-of-view checking to
> ensure nothing outside the field of view gets rendered.

> In TuxKart and TuxAQFH, I`ve used comment fields with a magic
> first character to tell the loader to generate certain kinds
> of ssgBranch node that the loader wouldn`t otherwise be able
> to generate.  That`s one way to get LOD nodes into your
> scene.
>
> However, the idea is that you dump the scene into SSG and let
> it worry about all the rendering issues.
>

So one way to use plib is to develop maps/scenes/tiles using
some package that exports to a format for which plib has a loader
(or write a new loader which reproduces the hierarchy of the scene).
Would one expect this to be the most common method of getting
a scene into one's application?

How does one add dynamic objects to the scene?  Just add a
transform node to the root?  Try to find out where in the scene
hierarchy it should be placed?  Probably the former - what is the
impact on rendering?

>> One of the immediate problems with my ocean approach is that
>> the ocean often disappears - it depends on the direction the
>> camera is pointing and where in the scene it is placed.  I`m
>> guessing that it`s getting culled because there are no vertices
>> of the ocean inside the view frustum.
>
> No - that`s not possible.  SSG computes a bounding sphere around
> all the vertices in each leaf node - if any part of the sphere
> lies inside the view frustum, the node will be passed on to OpenGL.
>
> Are you creating the ocean model in code - or loading it via
> one of the SSG loaders?

Hmm...
I'm using ssgLoadAC(), not creating it myself.  After I load the model,
I add it to a transform node, rotate it (I hand built the model in z-is-up
format so I have to undo the rotate that the loader does), then scale
it from unit size to the game board size.  I don't make any other changes
after that. Do I have to force a recalculation of the BSphere in this case?
(I thought cullAndDraw would do a recalc if it was needed).

>> Here`s the worst part (I think) of how I`m realizing this land
>> in the scene... <cringing in anticipation of being bashed about
>> the head>... I`m loading a single instance of a unit sized AC3D
>> cube, scaling the height to match the height of a grid point
>> (by adding model to ssgTransform node) and translating it to
>> the appropriate grid location.  The net result is lots of
>> stretched cubes clustered about.
>
> You certainly need some serious help!

:)

> You should use a triangular mesh I think.

Yes, I knew that but I wanted to generate something I could
look at with a minimum of effort.  Load - scale - move was
much easier than trying to generate a mesh on the fly.

>> How does one deal with being able to warp the
>> camera anywhere on the map though?
>
> Well, it`s *VERY* complex.  <snip>

My choice of the word 'warp' was not the best.  It sounds like
you took it to mean something like 'fly really really really fast'.
I was actually thinking in the X-windows sense of warping a
pointer - an instantaneous move to a new location.  The idea
here is that a user selects a new entity from which to look at
the scene.  This isn't *VERY* complex is it?

I suspect the issue is that the new location could be quite
far away from the current location so the tiles likely wouldn't
be loaded.  I don't imagine that the new tiles can be loaded
quickly enough to satisfy most users or can they?

I'll look at TerraGear.  I suspect I'll be able to get away with
a lot less detail - the simulation will survive with no 3D at all
(but won't be nearly as interesting!).

Thanks again for taking the time to respond,

Troy.

RE: [Plib-users] Problem with sgHPRfromVec3

[Dave M. <Dav...@dy...>]

If you want to build ssg camera views from direction vectors, you could try
using ssgSetCameraLookAt(eye,center,up);  It eventually calls this routine
in sg.cxx:

void sgMakeLookAtMat4 ( sgMat4 dst, const sgVec3 eye, const sgVec3 center,
const sgVec3 up )
{
  // Caveats:
  // 1) In order to compute the line of sight, the eye point must not be
equal
  //    to the center point.
  // 2) The up vector must not be parallel to the line of sight from the eye
  //    to the center point.

  /* Compute the direction vectors */
  sgVec3 x,y,z;

  /* Y vector = center - eye */
  sgSubVec3 ( y, center, eye ) ;

  /* Z vector = up */
  sgCopyVec3 ( z, up ) ;

  /* X vector = Y cross Z */
  sgVectorProductVec3 ( x, y, z ) ;

  /* Recompute Z = X cross Y */
  sgVectorProductVec3 ( z, x, y ) ;

  /* Normalize everything */
  sgNormaliseVec3 ( x ) ;
  sgNormaliseVec3 ( y ) ;
  sgNormaliseVec3 ( z ) ;

  /* Build the matrix */
#define M(row,col)  dst[row][col]
  M(0,0) = x[0];    M(0,1) = x[1];    M(0,2) = x[2];    M(0,3) = 0.0;
  M(1,0) = y[0];    M(1,1) = y[1];    M(1,2) = y[2];    M(1,3) = 0.0;
  M(2,0) = z[0];    M(2,1) = z[1];    M(2,2) = z[2];    M(2,3) = 0.0;
  M(3,0) = eye[0];  M(3,1) = eye[1];  M(3,2) = eye[2];  M(3,3) = 1.0;
#undef M
}

Re: [Plib-users] Problem with sgHPRfromVec3

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

Troy wrote:

>I saw a post about this before (I think in the plib-devel list)
>but didn't see any response to confirm the problem.

Yes, that post was by me. I think it is a bug in plib and its still in
the newest CVS and all "official" versions.

Steve, if you want to see it "in action", in PPE 
choose view/camera/rotate h,p and look into the console window.


>Troy.

Bye bye,
Wolfram.

Re: [Plib-users] How should I use plib?

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

Troy Yee wrote:
> 
> Sorry for the long post.  I'll ask my question(s)
> up front.  A description of what I've been up to follows.
> 
> Q: What is the best way to create a scene/world using plib?
>    It seems to me that loaders are extremely useful but
>    what is their impact on one's ability to render a scene
>    quickly and efficiently?  Aside from loading a model,
>    and scaling/rotating/translating it what else must be
>    done to manage the scene/world (i.e. BSP trees, LOD, etc.)?

Theoretically - you don't need to do ANYTHING - that's what
SSG is good at.

SSG uses whatever the hierarchy of the scene is in the
model file - and does heirarchical field-of-view checking to
ensure nothing outside the field of view gets rendered.

SSG supports LOD nodes - but if there aren't any supported
in whatever file format you are using - then the loader can't
create any and SSG won't 'magically' insert them.

In TuxKart and TuxAQFH, I've used comment fields with a magic
first character to tell the loader to generate certain kinds
of ssgBranch node that the loader wouldn't otherwise be able
to generate.  That's one way to get LOD nodes into your
scene.

However, the idea is that you dump the scene into SSG and let
it worry about all the rendering issues.

> One of the immediate problems with my ocean approach is that
> the ocean often disappears - it depends on the direction the
> camera is pointing and where in the scene it is placed.  I'm
> guessing that it's getting culled because there are no vertices
> of the ocean inside the view frustum.

No - that's not possible.  SSG computes a bounding sphere around
all the vertices in each leaf node - if any part of the sphere
lies inside the view frustum, the node will be passed on to OpenGL.

Are you creating the ocean model in code - or loading it via
one of the SSG loaders?

If you are creating it, then perhaps you just need to call

   your_node -> recalcBSphere () ;

...to force SSG to recompute a fresh, accurate bounding sphere.

> I mentioned above that the game area is quite large - 2000
> nautical miles on a side.  Although all action will typically
> take place in a very small portion of the map, there is no
> way to decide up front where that might be.  It is also
> possible to 'warp' any entity to any place on the map at any
> time. Since this is a naval simulation, most of the action
> will take place on the water but may be near a major land mass.

Perhaps you should look at Curt Olson's "Terragear" project.

Once you get to scenes more than a few tens of miles across,
the curvature of the earth becomes very significant - and the
amount of polygonal information needed to display things at
a reasonable precision rapidly grows beyond the ability of the
PC to hold it in RAM - so it has to be paged from disk on-the-fly.

> Here's the worst part (I think) of how I'm realizing this land
> in the scene... <cringing in anticipation of being bashed about
> the head>... I'm loading a single instance of a unit sized AC3D
> cube, scaling the height to match the height of a grid point
> (by adding model to ssgTransform node) and translating it to
> the appropriate grid location.  The net result is lots of
> stretched cubes clustered about.

You certainly need some serious help!

You should use a triangular mesh I think.

Take a look at the 'Majik3D' example program.  It demonstrates
creating polygonal terrain from a height field.
 
>  I noted that
> FlightGear has defined a bunch of tiles that get loaded
> in and I assume that something like this is the way to go
> here.

FlightGear's terrain stuff is what is now in 'Terragear' - which
is why I advised you to look there.

> How does one deal with being able to warp the
> camera anywhere on the map though?

Well, it's *VERY* complex.  Because you need reasonably good
precision to stop the ocean from 'shaking' violently, yet you
still need thousands of miles of terrain, you rapidly discover
that floating point numbers are not accurate enough.  You could
consider going to 'doubles' but OpenGL doesn't support them
internally.  In the end you need to keep the camera still and
move the terrain relative to it...this gets insanely messy - but
that's what you need to do.

Then you get into earth curvature - you can't tesselate squares
or rectangles to make a sphere - so you need terrain tiles that
are actualy subtly curved parallellograms.
 
> Well, thanks for your time.  Any pointers/comments would
> be appreciated - perhaps you know of a 'getting started'
> tutorial?  Anyway, welcome to my adventure! :)

Check out Terragear - or start with something MUCH less ambitious
until you get proficient with 3D.
 
-- 
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

Re: [Plib-users] Please Help!

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

Ibrahim El-Shafei wrote:
 
>     At the installation, I typed ./configure and its ok no problem but when
> I typed make I got the message attached with my E-Mail.

That's a pretty strange error message - it doesn't say what exactly is wrong!

It looks like some problem in the Mesa/OpenGL install.

You *should* have your OpenGL headers in /usr/include/GL - but it's complaining
about something in /usr/local/include/GL/glx.h

Is it possible that you have an old, broken OpenGL/Mesa in /usr/local/include?

> make[2]: Entering directory `/tmp/plib-1.2.0/src/pui'
> c++ -DPACKAGE=\"plib\" -DVERSION=\"1.2.0\" -DHAVE_LIBDL=1 -DHAVE_LIBMESAGL=1 -DHAVE_LIBGLU=1
> -DHAVE_LIBGLUT=1 -DSTDC_HEADERS=1 -DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1 -DLINUX_JOYSTICK_IS_PRESENT=1
>  -I. -I.  -I../../src/sg -I../../src/fnt    -g -O2 -O6 -Wall -c pu.cxx
> In file included from /usr/local/include/GL/glx.h:46,
>                 from puLocal.h:11,
>                 from pu.cxx:2:
> make[2]: *** [pu.o] Error 1
> make[2]: Leaving directory `/tmp/plib-1.2.0/src/pui'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/tmp/plib-1.2.0/src'
> make: *** [all-recursive] Error 1 


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

[Plib-users] Problem with sgHPRfromVec3

[Troy Y. <tro...@ho...>]

I saw a post about this before (I think in the plib-devel list)
but didn't see any response to confirm the problem.

I found that I had to do the following when I tried to use 
sgHPRfromVec3() to set my camera to look at a the
desired point.

sgSetVec3(lLookFrom, lX, lY, lZ);
sgSubVec3(lLookDir, gLookAt, lLookFrom);

sgHPRfromVec3(lLookHPR, lLookDir);

/* Seems to be an error in sgHPRfromVec3().
// Need to change pitch sign to get correct result.
*/
lLookHPR[1] *= -1.0;

/* set up the camera
*/
sgSetCoord(&lCameraPos, lLookFrom, lLookHPR);

Am I doing something wrong or is there really a problem?
I've been using v1.1.11 - was it a problem that has been fixed?
(I've upgraded to v1.2.0 but don't recall a change in behaviour -
I'll have to check to be sure I recompiled though).

Thanks for any help,

Troy.