plib-devel

Re: [Plib-devel] VRML Loader issues

[Joel U. <joe...@ya...>]

Wolfram Kuss wrote:
> 
> Joel wrote:
> 
> > It would be good to have a repository of
> >completely free models, it would be a good place to put test models for
> >prettypoly too.
> 
> What would be the point?
> Why not just have links to the places where you got the models from?
> As Gil wrote, there are tons of places with 3D objects. I think more
> free objects would be good, but more free object sites would not.

Yes, I guess we could list some good ones on the PPE web page. I only
looked around briefly and didn't find many sites.

> I think we should ship one model with PPE so that users can test
> it.For plib we should have one test-object - at least for each format
> that there is no writer for.

Yep.

Bye - Joel.

Re: [Plib-devel] Networking Code

[Sam S. <sa...@sp...>]

----- Original Message -----
From: "Curtis L. Olson" <cu...@me...>
To: <pli...@li...>
Sent: Wednesday, August 23, 2000 3:05 PM
Subject: Re: [Plib-devel] Networking Code


> Sam Stickland writes:
> > You should have a look at this article on gamasutra:
> >
> > The Internet Sucks: Or, What I Learned Coding X-Wing vs. TIE Fighter
> > http://www.gamasutra.com/features/19990903/lincroft_01.htm
> >
> > It explains how, somewhat surprisingly (to me at least) the
> > programming team made the mistake of starting with TCP/IP. In the
> > end they had to recode it all to use UDP/IP.
> >
> > I haven't looked into T/TCP at all - how widely supported is it now?
>
> Never heard of T/TCP myself ... I think there is a ttcp utility for
> unix that helps you bench mark raw net performance but I doubt that's
> the same thing.
>
> > As regards the difference between TCP and UDP, *everything* that
> > makes TCP great for file transfer makes it rubbish for streaming
> > media and real-time games.  (And vice-versa UDP is great for
> > streaming makes it's rubbish for file transfer).
>
> First let me say I don't disagree with anything you have said here.  I
> just want to fill in a little bit bigger picture.  In my mind anyway I
> think there are places where both TCP and UDP type sockets are
> important to have.  A more complex game/simulation might find itself
> needing both at the same time (meaning multiple open connections.)

>
> Now that I've finished my message I see this little add on at the
> bottom of yours ... oh well ... :-)

Heh, it happens.

> I guess the point I'd like to still emphasize is that a network
> library really needs to be able to support both TCP and UDP socket
> protocols.

Actually while we're on this subject I am concerned about the accuracy of my network engine over true internet links.  It's somewhat
harder to test these yourself than it is to run tests on LANs.  Are there any *cheap* (read free :), WAN simulators out there.  Or
maybe just some 30 day trial ones I can use to knock the code up into shape after I've done all the testing I can do.

All the ones I've found are commerical and way outside of my price range, for what is, essentially a hobby.

Sam

Re: [Plib-devel] Networking Code

[Curtis L. O. <cu...@me...>]

Sam Stickland writes:
> You should have a look at this article on gamasutra:
> 
> The Internet Sucks: Or, What I Learned Coding X-Wing vs. TIE Fighter
> http://www.gamasutra.com/features/19990903/lincroft_01.htm
> 
> It explains how, somewhat surprisingly (to me at least) the
> programming team made the mistake of starting with TCP/IP. In the
> end they had to recode it all to use UDP/IP.
> 
> I haven't looked into T/TCP at all - how widely supported is it now?

Never heard of T/TCP myself ... I think there is a ttcp utility for
unix that helps you bench mark raw net performance but I doubt that's
the same thing.

> As regards the difference between TCP and UDP, *everything* that
> makes TCP great for file transfer makes it rubbish for streaming
> media and real-time games.  (And vice-versa UDP is great for
> streaming makes it's rubbish for file transfer).

First let me say I don't disagree with anything you have said here.  I
just want to fill in a little bit bigger picture.  In my mind anyway I
think there are places where both TCP and UDP type sockets are
important to have.  A more complex game/simulation might find itself
needing both at the same time (meaning multiple open connections.)

> Three major issues spring to mind that make TCP unsuitable.
> 
> 1) Every packet is always *guaranteed* to arrive.  This is
> especially bad for real-time games.  This means that if a packet
> failed to get through it will keep sending it until it does.  I.e..
> the lost packet that was sent *ages* ago about where a robot was
> will keep being sent until it arrives, by which time it is
> hopelessly out of date.  Under UDP if a packet doesn't make it
> through you can send a more up-to-date version rather than
> constantly sending the old packet again and again.

The flip side of this is that a simulation or game might need to send
a single packet or message that must arrive at it's destination.
Here's a couple examples:

Pretend we are syncing several displays/views over the network for a
flight sim.  The latest weather report comes in and the new visibility
for our area is 1.5 miles.  We need to notify all the views of this
change and we need to do it reliably.

My day job involves supporting and developing driving simulations.
Our simulations are composed of several pieces running on separate
machines that communicate via the network.  If the gui sends a "reset
position to x,y,z" message to the simulation engine, it had better do
it the first time.

I could bore you with many other examples ... :-)

> 2) Since it's stream orientated packets have to arrive in order -
> this makes issue 1) even worse.  Imagine the following example in
> which "packet" B has trouble arriving.  Now, you can't even *see*
> the information in Packets C & D until B has been successfully
> received - even though Packet C makes it completely superfluous.  If
> you were using UDP you could say, Packet B didn't arrive - so what?
> And just get on with it.

Again, for certain types of "command" communication, order is actually
important.

> (In reality certain parts of the game might will want to use TCP,
> where data integrity is essential - score updates, and initial
> logins for example).

Now that I've finished my message I see this little add on at the
bottom of yours ... oh well ... :-)

I guess the point I'd like to still emphasize is that a network
library really needs to be able to support both TCP and UDP socket
protocols.

Curt.
-- 
Curtis Olson   Human Factors Research Lab       Flight Gear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

RE: [Plib-devel] Networking Code

[Ben W. <be...@bg...>]

Thanks Sam,

I will have a look

Cheers, Ben

> -----Original Message-----
> From: Sam Stickland [mailto:sa...@sp...]
> Sent: Wednesday, August 23, 2000 10:42 AM
> To: pli...@li...
> Subject: Re: [Plib-devel] Networking Code
> 
> 
> 
> ----- Original Message -----
> From: "Ben Woodhead" <be...@bg...>
> To: <pli...@li...>
> Sent: Wednesday, August 23, 2000 12:01 PM
> Subject: RE: [Plib-devel] Networking Code
> 
> 
> > Ya, I am going to try to implement a version of T/TCP, 
> which is basicly a
> > connection based protocal like TCP except there is alot less error
> > correction, I think this should be perfect for games. (I am slowly
> > understanding what this networking stuff is)
> 
> You should have a look at this article on gamasutra:
> 
> The Internet Sucks: Or, What I Learned Coding X-Wing vs. TIE Fighter
> http://www.gamasutra.com/features/19990903/lincroft_01.htm
> 
> It explains how, somewhat surprisingly (to me at least) the 
> programming team made the mistake of starting with TCP/IP. In the end
> they had to recode it all to use UDP/IP.
> 
> I haven't looked into T/TCP at all - how widely supported is it now?
> 
> As regards the difference between TCP and UDP, *everything* 
> that makes TCP great for file transfer makes it rubbish for streaming
> media and real-time games.  (And vice-versa UDP is great for 
> streaming makes it's rubbish for file transfer).
> 
> Three major issues spring to mind that make TCP unsuitable.
> 
> 1) Every packet is always *guaranteed* to arrive.  This is 
> especially bad for real-time games.  This means that if a 
> packet failed
> to get through it will keep sending it until it does.  I.e..  
> the lost packet that was sent *ages* ago about where a robot was will
> keep being sent until it arrives, by which time it is 
> hopelessly out of date.  Under UDP if a packet doesn't make 
> it through you can
> send a more up-to-date version rather than constantly sending 
> the old packet again and again.
> 
> 2) Since it's stream orientated packets have to arrive in 
> order - this makes issue 1) even worse.  Imagine the 
> following example in
> which "packet" B has trouble arriving.
> 
>     Packet A
> Big bad BSOD moves to 10, 12
> 
>     Packet B                    <---- (This one gets lost and has
> Big bad BSOD moves to 10, 14    <----  to be sent several times)
> 
>     Packet C
> Big bad BSOD moves to 10, 16
> 
>     Packet D
> Big bad BSOD shoots
> 
> Now, you can't even *see* the information in Packets C & D 
> until B has been successfully received - even though Packet C makes it
> completely superfluous.  If you were using UDP you could say, 
> Packet B didn't arrive - so what?  And just get on with it.
> 
> 3) If TCP/IP has trouble sending data it actually sends 
> *less* data.  That's right *less* data.  The idea is that 
> more data will
> make the current data congestion worse.  So when there's net 
> congestion everybody deliberately sends less until the problem passes.
> Great(ish) for file-transfer - absolutely horrid for games.
> 
> Issue 3) affects bandwidth, which is becoming less of an 
> issue as time marching on.  But 1) & 2) are latency issues - 
> and that's
> going to be with us for a long long time.
> 
> There's also all the extra associated latency in processing 
> (TCP/IP batches requests) and wasted bandwidth (in header blocks) with
> TCP/IP but these are minor issues concerned to the others.
> 
> Not having studied T/TCP I don't know how many of these 
> issues it addresses, but I suspect while latency still 
> plagues us only UDP
> will truly cut it.
> 
> (In reality certain parts of the game might will want to use 
> TCP, where data integrity is essential - score updates, and initial
> logins for example).
> 
> Sam
> 
> 
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

Re: [Plib-devel] Networking Code

[Sam S. <sa...@sp...>]

----- Original Message -----
From: "Ben Woodhead" <be...@bg...>
To: <pli...@li...>
Sent: Wednesday, August 23, 2000 12:01 PM
Subject: RE: [Plib-devel] Networking Code


> Ya, I am going to try to implement a version of T/TCP, which is basicly a
> connection based protocal like TCP except there is alot less error
> correction, I think this should be perfect for games. (I am slowly
> understanding what this networking stuff is)

You should have a look at this article on gamasutra:

The Internet Sucks: Or, What I Learned Coding X-Wing vs. TIE Fighter
http://www.gamasutra.com/features/19990903/lincroft_01.htm

It explains how, somewhat surprisingly (to me at least) the programming team made the mistake of starting with TCP/IP. In the end
they had to recode it all to use UDP/IP.

I haven't looked into T/TCP at all - how widely supported is it now?

As regards the difference between TCP and UDP, *everything* that makes TCP great for file transfer makes it rubbish for streaming
media and real-time games.  (And vice-versa UDP is great for streaming makes it's rubbish for file transfer).

Three major issues spring to mind that make TCP unsuitable.

1) Every packet is always *guaranteed* to arrive.  This is especially bad for real-time games.  This means that if a packet failed
to get through it will keep sending it until it does.  I.e..  the lost packet that was sent *ages* ago about where a robot was will
keep being sent until it arrives, by which time it is hopelessly out of date.  Under UDP if a packet doesn't make it through you can
send a more up-to-date version rather than constantly sending the old packet again and again.

2) Since it's stream orientated packets have to arrive in order - this makes issue 1) even worse.  Imagine the following example in
which "packet" B has trouble arriving.

    Packet A
Big bad BSOD moves to 10, 12

    Packet B                    <---- (This one gets lost and has
Big bad BSOD moves to 10, 14    <----  to be sent several times)

    Packet C
Big bad BSOD moves to 10, 16

    Packet D
Big bad BSOD shoots

Now, you can't even *see* the information in Packets C & D until B has been successfully received - even though Packet C makes it
completely superfluous.  If you were using UDP you could say, Packet B didn't arrive - so what?  And just get on with it.

3) If TCP/IP has trouble sending data it actually sends *less* data.  That's right *less* data.  The idea is that more data will
make the current data congestion worse.  So when there's net congestion everybody deliberately sends less until the problem passes.
Great(ish) for file-transfer - absolutely horrid for games.

Issue 3) affects bandwidth, which is becoming less of an issue as time marching on.  But 1) & 2) are latency issues - and that's
going to be with us for a long long time.

There's also all the extra associated latency in processing (TCP/IP batches requests) and wasted bandwidth (in header blocks) with
TCP/IP but these are minor issues concerned to the others.

Not having studied T/TCP I don't know how many of these issues it addresses, but I suspect while latency still plagues us only UDP
will truly cut it.

(In reality certain parts of the game might will want to use TCP, where data integrity is essential - score updates, and initial
logins for example).

Sam

[Plib-devel] More Networking Code

[Ben W. <be...@bg...>]

Well I think I fucked everything up on this, is there any Mac coders in this
list, I have everything done except the startserver and the connection
section, but that does not mean anything atually works. But hey, this is
what I have done so far. I think at some point I am going to create seperate
files for each operating system, seems that non of the code can be shared
between mac and everything else. 
Anybody want to help with the mac code, or the windows code. Please let me
know.
Later Ben

RE: [Plib-devel] Networking Code

[Ben W. <be...@bg...>]

> -----Original Message-----
> From: Steve Baker [mailto:sjb...@ai...]
> Sent: Wednesday, August 23, 2000 12:36 AM
> To: pli...@li...
> Subject: Re: [Plib-devel] Networking Code
> 
> 
> > Dave McClurg wrote:
> > 
> > Hi Ben,
> > 
> > In adding networking code to plib, I recommend keeping it 
> simple like the code you showed me from tuxkart.  We just 
> need a portable way to setup a connection.  The application 
> code should be responsible for the rest.
> > 
> > A turn based game doesn't need dead-reckoning so setPos() 
> probably doesn't belong in plib proper.  Things like 
> real-time state management or match-making systems for 
> finding opponents could be placed in an auxillary library.
> 
> IMHO, the important thing with networking code is to 
> implement it in layers.
> 
>  * The basic OS socket library is the lowest level - but it's 
> not 100% portable.
> 
>  * So we build a simple (but portable) wrapper class on top 
> of it that doesn't
>    attempt to extend functionality - but DOES perhaps hide 
> irrelevent details
>    and restrict you to the lowest common denominator of the 
> lower levels.
> 
>  * Then you can get into higher level stuff like timing, 
> dead-reckoning, extrapolation,
>    finding opponents, etc.
> 
> But under no circumstances should you tangle those three layers.

I don't think I have 3 layers, meaning that the UDP socket layer from tux
kart is how I have been implementing everything. Althought I have not gotten
into any extra functionality, so I will keep that in mind for that.
 
> So, the API I have in TuxKart (which DOES work under Linux 
> and other UNIXen BTW)
> is OK as the middle layer.  It needs to be ported to other 
> OS's -
Ya I am porting it to Mac as we speak, and someone said that winsocks is
really close to bsd socks so I don't think that will take alot of work.
(Mind you I said that about Mac until I found out they have Open Transport)

> and you could
> perhaps argue a need for an error-tolerant version - either 
> using TCP instead
> of UDP - or based on some higher level protocols built on top of UDP.

I have already completed a TCP version of your code, that should work on
linux and other unixs (not been tested yet, although someone is working on
it), 
> 
> Most 'real' games can run on UDP-only if they are running 
> over a local network
> (UDP *never* goes wrong on a correctly configured LAN) - but 
> over the Internet,
> you'll definitely get into trouble if you rely on UDP for 
> critical messages.
> 
> On the other hand, error-tolerant protocols are slow and 
> expensive - so you
> certainly don't want to use them for things like "Where is 
> Tux's Kart this
> frame" type of messages.  Fortunately, those kinds of 
> messages can generally
> be 'lost' and nothing fatal will go wrong.
> 
> Hence, real games over the Internet will need *BOTH* UDP 
> *AND* either TCP or
> "UDP-with-an-error-correcting-layer".  So our 'middle' layer had
> better support both options and know how to mix them in one program.

Ya, I am going to try to implement a version of T/TCP, which is basicly a
connection based protocal like TCP except there is alot less error
correction, I think this should be perfect for games. (I am slowly
understanding what this networking stuff is)

> For high speed comms over an Ethernet LAN, other 
> considerations are important -
> you'll need to take care of collisions between two or more 
> machines trying
> to talk at once - that can do bad things to performance.  I'm 
> not sure we
> should go to the lengths necessary to fix that - it's getting 
> a bit more into
> the structure of the game than I'd want to venture.
> 
I have no idea, when I get this stuff finished, I will look into this. 

> -- 
> 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-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel

Later Ben

RE: [Plib-devel] Networking Code

[Ben W. <be...@bg...>]

I had a look at common c++, but it is really big as well. But it may help
with the Mac code. I have some of the code finished, basicly with mac you
have to rewrite everything. OpenTransport is alot different then BSD
sockets. They even have there own variables, instead of just using int.

Later Ben

-----Original Message-----
From: Norman Vine [mailto:nh...@ca...]
Sent: Tuesday, August 22, 2000 5:26 PM
To: pli...@li...
Subject: RE: [Plib-devel] Networking Code


Sam Stickland writes:

>"Ben Woodhead" writes:
>
>> >ACE is built upon on single core class ACE_OS, which provides a single
>> Unix/POSIX like >interface to all the standard thread and socket calls.
>
>> Thanks Ben
>> ps Can you send me a link to where I can find ace. I don't think I ran
>> across that yet.
>
>Yeah sure:
>
>http://www.cs.wustl.edu/~schmidt/ACE.html

Last time I looked ACE was a rather large package :-(
Though itt certainly is capable of doing anything we would want.

FWIW Have you guys seen Common C++ ?
http://cplusplus.sourceforge.net/

Norman


_______________________________________________
plib-devel mailing list
pli...@li...
http://lists.sourceforge.net/mailman/listinfo/plib-devel

Re: [Plib-devel] VRML Loader issues

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

Joel wrote:

> It would be good to have a repository of
>completely free models, it would be a good place to put test models for
>prettypoly too.

What would be the point? 
Why not just have links to the places where you got the models from?
As Gil wrote, there are tons of places with 3D objects. I think more
free objects would be good, but more free object sites would not.

I think we should ship one model with PPE so that users can test
it.For plib we should have one test-object - at least for each format
that there is no writer for.

I really hope that Steve "unlocks" the PPE code soon, then we can work
on that.

>Bye - Joel.

Bye bye,
Wolfram Kuss.

Re: [Plib-devel] VRML Loader issues

[Gil C. <g.c...@ca...>]

At 03:30 PM 8/23/00 +0800, you wrote:
> > As an alternative, I suppose we could ask SourceForge for another
> > account for free models.  They seem to be giving accounts away to
> > anyone who asks as far as I can tell.
>
>This would be great - I was looking for free 3D models at 3dcafe, but
>they had a licence agreement, that I thought was a little restrictive
>(non-commercial use stuff). It would be good to have a repository of
>completely free models, it would be a good place to put test models for
>prettypoly too.

I don't want to throw cold water on this idea, but there's gotta be enough 
sites hosting 3D models already - a google search on "free 3d models" 
returns 157,000 pages!  Do we plan on just adding one more URL to that 
crowd, or are we going to be PLIB/PPE specific?

>I could certainly setup the site if no one has time for it. (feature
>requests please...)

Well, my specific need at the moment is a place to store a hundred-odd 
little VRML files to test my loader.  These will be unnecessary to anybody 
else who just wants to use the loader, but they might be of academic 
interest for people who want to use PLIB for VRML-specific things.

Gil

Re: [Plib-devel] VRML Loader issues

[Joel U. <joe...@ya...>]

Steve Baker wrote:
> 
> Gil Carter wrote:
> > I'll be producing a full set of new VRML1 test files for the parser, so
> > hopefully they should provide a fairer test once they're done.  Since these
> > won't really form part of the PLIB distribution but would be useful to have
> > around, where should I put them?  Is there a convenient place in the CVS
> > tree for them, or would they be better just on my local web site?
> 
> I guess I could create a place for them on CVS - but perhaps a better
> idea would be to use them in the examples area for some kind of small
> demo or something.  That way they serve dual purpose and aren't such
> a waste of bandwidth.
> 
> As an alternative, I suppose we could ask SourceForge for another
> account for free models.  They seem to be giving accounts away to
> anyone who asks as far as I can tell.

This would be great - I was looking for free 3D models at 3dcafe, but
they had a licence agreement, that I thought was a little restrictive
(non-commercial use stuff). It would be good to have a repository of
completely free models, it would be a good place to put test models for
prettypoly too.

I could certainly setup the site if no one has time for it. (feature
requests please...)

Bye - Joel.

Re: [Plib-devel] Networking Code

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

> Dave McClurg wrote:
> 
> Hi Ben,
> 
> In adding networking code to plib, I recommend keeping it simple like the code you showed me from tuxkart.  We just need a portable way to setup a connection.  The application code should be responsible for the rest.
> 
> A turn based game doesn't need dead-reckoning so setPos() probably doesn't belong in plib proper.  Things like real-time state management or match-making systems for finding opponents could be placed in an auxillary library.

IMHO, the important thing with networking code is to implement it in layers.

 * The basic OS socket library is the lowest level - but it's not 100% portable.

 * So we build a simple (but portable) wrapper class on top of it that doesn't
   attempt to extend functionality - but DOES perhaps hide irrelevent details
   and restrict you to the lowest common denominator of the lower levels.

 * Then you can get into higher level stuff like timing, dead-reckoning, extrapolation,
   finding opponents, etc.

But under no circumstances should you tangle those three layers.

So, the API I have in TuxKart (which DOES work under Linux and other UNIXen BTW)
is OK as the middle layer.  It needs to be ported to other OS's - and you could
perhaps argue a need for an error-tolerant version - either using TCP instead
of UDP - or based on some higher level protocols built on top of UDP.

Most 'real' games can run on UDP-only if they are running over a local network
(UDP *never* goes wrong on a correctly configured LAN) - but over the Internet,
you'll definitely get into trouble if you rely on UDP for critical messages.

On the other hand, error-tolerant protocols are slow and expensive - so you
certainly don't want to use them for things like "Where is Tux's Kart this
frame" type of messages.  Fortunately, those kinds of messages can generally
be 'lost' and nothing fatal will go wrong.

Hence, real games over the Internet will need *BOTH* UDP *AND* either TCP or
"UDP-with-an-error-correcting-layer".  So our 'middle' layer had
better support both options and know how to mix them in one program.

For high speed comms over an Ethernet LAN, other considerations are important -
you'll need to take care of collisions between two or more machines trying
to talk at once - that can do bad things to performance.  I'm not sure we
should go to the lengths necessary to fix that - it's getting a bit more into
the structure of the game than I'd want to venture.

-- 
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-devel] directional lights

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

"Curtis L. Olson" wrote:

> Does plib provide any facilities for drawing or not drawing an object
> based on relative view angle?

Nope.  You could add it as a new ssgSelector node type I suppose.

> I'm pondering how I might impliment
> directional lights such as VASI for runways ... lights that change
> color depending on your relative angle to them.

I could get *shot* for revealing a trade secret here - so get your
brain nice and comfortable - and I'll just say two words...

   "Environment Maps"

...'nuff said?  No?  Well think harder!

VASI lights have to change colour gently BTW - they go through
a definite 'pink' phase between the red and white light colours.
A sudden 'blink' between the two colours is VERY distracting at
*just* the time when distraction would be "A Bad Thing"  :-)

-- 
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-devel] VRML Loader issues

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

Gil Carter wrote:

> Any chance you could try exporting a couple of TAQFH models out of AC3d in
> VRML format to give me some more fodder for the parser?

(I sent Gil some converted models as requested - but they were pretty
big - so I didn't inflict them on the mailing list).

> I'll be producing a full set of new VRML1 test files for the parser, so
> hopefully they should provide a fairer test once they're done.  Since these
> won't really form part of the PLIB distribution but would be useful to have
> around, where should I put them?  Is there a convenient place in the CVS
> tree for them, or would they be better just on my local web site?

I guess I could create a place for them on CVS - but perhaps a better
idea would be to use them in the examples area for some kind of small
demo or something.  That way they serve dual purpose and aren't such
a waste of bandwidth.

As an alternative, I suppose we could ask SourceForge for another
account for free models.  They seem to be giving accounts away to
anyone who asks as far as I can tell.

-- 
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-devel] directional lights

[Curtis L. O. <cu...@in...>]

Sam,

Thanks for the response.  I'm not sure if the specifics of what you
describe will work, but perhaps the general approach would.

The view direction doesn't really affect the choice I want to make.
The object position and view position produce one vector, but that
needs to be compared to a vector defining the optimal view direction
of the object.

Perhaps we would need to derive a new ssgSelector type class that
saves this directional vector and some tolerance and then does the
comparison when the scene graph is traversed.

Curt.


Sam Stickland writes:
> Hi, I'm not Steve but I think you could use the predraw callback to do this.
> Something like:
>
> int myCB ( ssgEntity *entity)
> {
>     /* Get the camera position */
>     sgVec3 camPos ;
>     ssgGetCurrentContext () -> getCameraPosition ( pos ) ;
>
>     /* Get the objects position */
>     sgVec3 objPos ;
>     sgSetVec3 ( objPos, entity -> getBSphere () -> getCenter () ) ;
>
>     /* Work out the angle between the two objects, and based on that either
> change the colour of the light ... */
>
>     sgVec4 *col = (ssgLeaf *) (entity) -> getColour ( blah) ;
>
>     sgSetVec4 ( *col, 1.0f, 0.0f, 0.0f, 0.5f ) ;
>
>     /* etc, you could also use getState() and alter that */
>
>     /* Choose to draw the object by returning TRUE to FALSE */
>
>     return TRUE;
> }
>
> Does that do the trick?
>
> Sam

--
Curtis Olson   Human Factors Research Lab       Flight Gear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: [Plib-devel] VRML Loader issues

[Gil C. <g.c...@ca...>]

At 09:05 PM 8/22/00 +0000, you wrote:
>On Tue, Aug 22, 2000 at 09:50:39AM +1000, Gil Carter wrote:
>
> > Got any URL's?  I'm trying to assemble a collection of models which people
> > would like to use with PLIB so that I can test with them, and it will make
> > my life easier if I can test against what you're looking at.
>
>The only URL I have to hand is that of a dopefish model at
>http://www.dopefish.com/stuff/dopefish2.wrl

I assume you realise that this is a VRML2 model?  My importer is targeted 
at VRML1 initially, and unfortunately, the file formats are completely 
different.  End result is that you initially won't be able to read this 
model into PLIB with my importer.

However, the importer is being designed from the start to recognise the 
different flavours of VRML - VRML 1, VRML2/VRML97 and gzipped 
VRML2/VRML97.  Due to some unfortunate de facto standards, all of these 
different file formats can have the same .wrl extension , so the importer 
has to determine which variety of VRML it is first and then hand the file 
off to the appropriate module.

Once VRML1 import/export is robust, I'll regroup and work on VRML2.  In the 
mean time, the importer will simply return an error code if you try to load 
a non-VRML1 file, but it will be an error code which suggests that this 
particular flavour of VRML is not supported yet...

Gil

Re: [Plib-devel] Networking Code

[Sam S. <sa...@sp...>]

> >Yeah sure:
> >
> >http://www.cs.wustl.edu/~schmidt/ACE.html
>
> Last time I looked ACE was a rather large package :-(

Yep, ACE is a *BIG* package as I've mentioned in earlier posts.

> Though itt certainly is capable of doing anything we would want.

Yeah, it does have quite a bag of tricks in it.

> FWIW Have you guys seen Common C++ ?
> http://cplusplus.sourceforge.net/

No, I hadn't seen that before - if I'd had found before ACE I'd had probably
never started using ACE in the first place :)

Sam

Re: [Plib-devel] directional lights

[Sam S. <sa...@sp...>]

> Steve,
>
> Does plib provide any facilities for drawing or not drawing an object
> based on relative view angle?  I'm pondering how I might impliment
> directional lights such as VASI for runways ... lights that change
> color depending on your relative angle to them.

Hi, I'm not Steve but I think you could use the predraw callback to do this.
Something like:

int myCB ( ssgEntity *entity)
{
    /* Get the camera position */
    sgVec3 camPos ;
    ssgGetCurrentContext () -> getCameraPosition ( pos ) ;

    /* Get the objects position */
    sgVec3 objPos ;
    sgSetVec3 ( objPos, entity -> getBSphere () -> getCenter () ) ;

    /* Work out the angle between the two objects, and based on that either
change the colour of the light ... */

    sgVec4 *col = (ssgLeaf *) (entity) -> getColour ( blah) ;

    sgSetVec4 ( *col, 1.0f, 0.0f, 0.0f, 0.5f ) ;

    /* etc, you could also use getState() and alter that */

    /* Choose to draw the object by returning TRUE to FALSE */

    return TRUE;
}

Does that do the trick?

Sam

Re: [Plib-devel] VRML Loader issues

[Chris P. <cj...@lo...>]

On Tue, Aug 22, 2000 at 09:50:39AM +1000, Gil Carter wrote:

> Got any URL's?  I'm trying to assemble a collection of models which people 
> would like to use with PLIB so that I can test with them, and it will make 
> my life easier if I can test against what you're looking at.

The only URL I have to hand is that of a dopefish model at
http://www.dopefish.com/stuff/dopefish2.wrl

-- 
Christopher John Purnell  | I thought I'd found a reason to live
http://www.lost.org.uk/   | Just like before when I was a child
--------------------------| Only to find that dreams made of sand
What gods do you pray to? | Would just fall apart and slip through my hands

[Plib-devel] directional lights

[Curtis L. O. <cu...@me...>]

Steve,

Does plib provide any facilities for drawing or not drawing an object
based on relative view angle?  I'm pondering how I might impliment
directional lights such as VASI for runways ... lights that change
color depending on your relative angle to them.

Thanks,

Curt.
-- 
Curtis Olson   Human Factors Research Lab       Flight Gear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

RE: [Plib-devel] Networking Code

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

Sam Stickland writes:

>"Ben Woodhead" writes:
>
>> >ACE is built upon on single core class ACE_OS, which provides a single
>> Unix/POSIX like >interface to all the standard thread and socket calls.
>
>> Thanks Ben
>> ps Can you send me a link to where I can find ace. I don't think I ran
>> across that yet.
>
>Yeah sure:
>
>http://www.cs.wustl.edu/~schmidt/ACE.html

Last time I looked ACE was a rather large package :-(
Though itt certainly is capable of doing anything we would want.

FWIW Have you guys seen Common C++ ?
http://cplusplus.sourceforge.net/

Norman

Re: [Plib-devel] Networking Code

[Sam S. <sa...@sp...>]

----- Original Message -----
From: "Ben Woodhead" <be...@bg...>
To: <pli...@li...>
Sent: Tuesday, August 22, 2000 4:01 PM
Subject: RE: [Plib-devel] Networking Code


> >ACE is built upon on single core class ACE_OS, which provides a single
> Unix/POSIX like >interface to all the standard thread and
> >socket calls.
> >
> >This is mostly done in ACE_OS.h as a large bunch of #ifdef's.  I haven't
> really studied it >that much, but it might be worthwhile
> >having a look.
> >
> >(One gottcha I should point out is that almost all the higher level ACE
> applications use >
> >recv and send - not read and write (these
> >calls are supposed to be identical), with the result that ACE_OS::read and
> ACE_OS::write >
> >appear to be broken under Win2000 with ACE
> >(This might actually be problems with WinSock under Win2K I haven't
> investigated)).
>
> I did not realise that you could use recv and send and not read and write
> with TCP, I think I  read somewhere that for the TCP section I should use
> read and write, I really don't know if there is a difference but I will have
> a look at it.

Yep, recv and send can be used on TCP sockets - at least I use them without problems.

> As well I have not had much of a chance to look at winsocks so I am not
> really sure what is the best way to deal with windows but I will be looking
> at that.

Well winsock is based on the BSD socket implementation, which is what most Unixes use so these really not a lot of difference so
long as you stick to the basic calls (and winsock requires some init() and fini() calls too.)  Might be that your code already
compiles fine on Win32 once the needed headers are added.  I'll test it tonight.

> Thanks Ben
> ps Can you send me a link to where I can find ace. I don't think I ran
> across that yet.

Yeah sure:

http://www.cs.wustl.edu/~schmidt/ACE.html

Sam

RE: [Plib-devel] Networking Code

[Ben W. <be...@bg...>]

Hello Sam,
 
First I want to get everything running and portable before I start thinking
about overloaded constructors. I am trying to keep everything nice and
simple. Also I would like to hear what dave thinks of the idea. 
But I do have good news, I am slowly getting through the OpenTransport stuff
for macs, who ever said that sdl net uses Open Transport, I read the docs on
it and things are moving along alot better now. 
 
Later Ben
ps There are a few things that I don't understand, all the examples are done
in c and a few of the memcopy sections and things like that I have been
having problems with, if someone could give me a hand with thoughs sections
it would help alot. 
 

-----Original Message-----
From: Sam Stickland [mailto:sa...@sp...]
Sent: Tuesday, August 22, 2000 1:11 PM
To: pli...@li...
Subject: Re: [Plib-devel] Networking Code


 

----- Original Message ----- 
From: Dave McClurg <mailto:Dav...@dy...>  
To: 'pli...@li...'
<mailto:'pli...@li...'>  
Sent: Tuesday, August 22, 2000 4:08 PM
Subject: RE: [Plib-devel] Networking Code


Hi Ben, 

In adding networking code to plib, I recommend keeping it simple like the
code you showed me from tuxkart.  We just need a portable way to setup a
connection.  The application code should be responsible for the rest.

A turn based game doesn't need dead-reckoning so setPos() probably doesn't
belong in plib proper.

Yes, that's certainly the case.  I hadn't ever really considered making the
full network library I'm working part of plib - I wanted it to be a stand
alone affair.  If it uses portable socket code in plib that's fine by me
though.

I'd personally be in favour of this structure for the socket library.

TCPSocket *mysock_con                  = new Socket(1234); // Create a new
socket on port 1234 on the server

TCPSocket *mysock_client_to_server = new Socket('spacething.org', 1234); //
Client attempts to connect to spacething.org on port 1234

TCPSocket *mysock_server_to_client = new Socket(mysock_con); // Server
accepts the client connection

But that's me.  Actually one disadvantage in the above system is that you
can't easily return errors in constructors without using exceptions - ugh.
Best to seperate out the constructor and initialisation code if you went
with the above.

Things like real-time state management or match-making systems for finding
opponents could be placed in an auxillary library.

 

Re: [Plib-devel] Networking Code

[Sam S. <sa...@sp...>]

RE: [Plib-devel] Networking Code
  ----- Original Message -----=20
  From: Dave McClurg=20
  To: 'pli...@li...'=20
  Sent: Tuesday, August 22, 2000 4:08 PM
  Subject: RE: [Plib-devel] Networking Code


  Hi Ben,=20

  In adding networking code to plib, I recommend keeping it simple like =
the code you showed me from tuxkart.  We just need a portable way to =
setup a connection.  The application code should be responsible for the =
rest.

  A turn based game doesn't need dead-reckoning so setPos() probably =
doesn't belong in plib proper.

Yes, that's certainly the case.  I hadn't ever really considered making =
the full network library I'm working part of plib - I wanted it to be a =
stand alone affair.  If it uses portable socket code in plib that's fine =
by me though.

I'd personally be in favour of this structure for the socket library.

TCPSocket *mysock_con                  =3D new Socket(1234); // Create a =
new socket on port 1234 on the server

TCPSocket *mysock_client_to_server =3D new Socket('spacething.org', =
1234); // Client attempts to connect to spacething.org on port 1234

TCPSocket *mysock_server_to_client =3D new Socket(mysock_con); // Server =
accepts the client connection

But that's me.  Actually one disadvantage in the above system is that =
you can't easily return errors in constructors without using exceptions =
- ugh.  Best to seperate out the constructor and initialisation code if =
you went with the above.

  Things like real-time state management or match-making systems for =
finding opponents could be placed in an auxillary library.

RE: [Plib-devel] Networking Code

[Ben W. <be...@bg...>]

Thanks Dave, 
 
Currently that is what I have been trying to do, just keep it simple, but I
am also trying to make sure that it runs in windows, linux, unix and mac.
And other then that just send and recieve. I am trying to keep it as simple
and general as possible. But thanks for sending it in for me, I will have a
look.
 
Later Ben

-----Original Message-----
From: Dave McClurg [mailto:Dav...@dy...]
Sent: Tuesday, August 22, 2000 12:09 PM
To: 'pli...@li...'
Subject: RE: [Plib-devel] Networking Code



Hi Ben, 

In adding networking code to plib, I recommend keeping it simple like the
code you showed me from tuxkart.  We just need a portable way to setup a
connection.  The application code should be responsible for the rest.

A turn based game doesn't need dead-reckoning so setPos() probably doesn't
belong in plib proper.  Things like real-time state management or
match-making systems for finding opponents could be placed in an auxillary
library.

-- Dave