plib-devel

[Plib-devel] PUI Mouse Button Problems

[Fay J. F C. AAC/W. <joh...@eg...>]

Gentlemen,

	I am trying to implement a PUI popup menu that is activated by
pressing the right mouse button.  It comes up very nicely.  Then when I drag
the mouse onto one of the buttons and release the mouse button, it
disappears and my callback is not called.  I have traced the problem to the
fact that "puButton.cxx" on line 213 checks whether the left mouse button is
the one being pressed, and I am having the right mouse button pressed.  Is
it okay for me to add a feature to PUI to allow the application to set which
mouse button it wants the widget callback to be invoked on?

John F. Fay
joh...@eg...
850-729-6330 

Re: [Plib-devel] texture filenames messed up

[Erik H. <er...@eh...>]

Bram Stolk wrote:
> Erik Hofman wrote:

>> You can call ssgTexturePath() prior to loading the textures/model now, 
>> so it shouldn't be that much of a problem anymore.
> 
> It is still a problem.
> ssgTexturePath will not fix this.
> 
> The ac loader will simply mess up filenames occasionally, and this
> is probably because
>     st -> setTexture( tex ) ;
> is never reached.

Ow, you're right. That's what you get when answering questions at 
23.45pm :-(

I've looked at the code just after you posted the message, but while I 
see what you mean (and it does look wrong) I can;t see an obvious answer 
to the problem.

Erik

RE: [Plib-devel] texture filenames messed up

[Fay J. F C. AAC/W. <joh...@eg...>]

Good - thanks.

John F. Fay
joh...@eg...
850-729-6330 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Erik Hofman
Sent: Monday, October 04, 2004 2:21 PM
To: pli...@li...
Subject: Re: [Plib-devel] texture filenames messed up

Fay John F Contr AAC/WMG wrote:
> Gentlemen,
> 
>         I am just back from a week out.  The issue mentioned is from two 
> years ago.  Has it now been resolved?  The file loaders are very much 
> outside my region of expertise.

You can call ssgTexturePath() prior to loading the textures/model now, 
so it shouldn't be that much of a problem anymore.

Erik


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] texture filenames messed up

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

Erik Hofman wrote:
> Fay John F Contr AAC/WMG wrote:
> 
>> Gentlemen,
>>
>>         I am just back from a week out.  The issue mentioned is from 
>> two years ago.  Has it now been resolved?  The file loaders are very 
>> much outside my region of expertise.
> 
> 
> You can call ssgTexturePath() prior to loading the textures/model now, 
> so it shouldn't be that much of a problem anymore.

It is still a problem.
ssgTexturePath will not fix this.

The ac loader will simply mess up filenames occasionally, and this
is probably because
     st -> setTexture( tex ) ;
is never reached.

Just run this prog on tuxedo.ac:

// plibconvert.cxx
//
// Build with
// g++ -o plibconvert plibconvert.cxx -lplibssg -lplibsg -lplibul -lGL


#include <assert.h>
#include <stdio.h>
#include <plib/ssg.h>

int main(int argc, char *argv[])
{
   if (argc!=3)
   {
     fprintf(stderr,"Usage: %s source destination\n", argv[0]);
     exit(1);
   }

   assert(strcmp(argv[1], argv[2]));

   ssgTexturePath ( "." ) ;
   ssgModelPath   ( "." ) ;

   ssgAddModelFormat ( ".ssg",   ssgLoadSSG  , ssgSaveSSG ) ;
   ssgAddModelFormat ( ".3ds",   ssgLoad3ds  , ssgSave3ds ) ;
   ssgAddModelFormat ( ".ac" ,   ssgLoadAC3D , ssgSaveAC  ) ;
   ssgAddModelFormat ( ".ase",   ssgLoadASE  , ssgSaveASE ) ;
   ssgAddModelFormat ( ".dof",   ssgLoadDOF  , NULL       ) ;
   ssgAddModelFormat ( ".dxf",   ssgLoadDXF  , ssgSaveDXF ) ;
   ssgAddModelFormat ( ".obj",   ssgLoadOBJ  , ssgSaveOBJ ) ;
   ssgAddModelFormat ( ".tri",   ssgLoadTRI  , ssgSaveTRI ) ;
   ssgAddModelFormat ( ".md2",   ssgLoadMD2  , NULL       ) ;
   ssgAddModelFormat ( ".x"  ,   ssgLoadX    , ssgSaveX   ) ;
   ssgAddModelFormat ( ".flt",   ssgLoadFLT  , ssgSaveFLT ) ;
   ssgAddModelFormat ( ".strip", ssgLoadStrip, NULL       ) ;
   ssgAddModelFormat ( ".m"  ,   ssgLoadM    , ssgSaveM   ) ;
   ssgAddModelFormat ( ".off"  , ssgLoadOFF  , ssgSaveOFF ) ;
   ssgAddModelFormat ( ".atg"  , ssgLoadATG  , ssgSaveATG ) ;
   ssgAddModelFormat ( ".qhi"  , NULL        , ssgSaveQHI ) ;
   ssgAddModelFormat ( ".wrl",   ssgLoadVRML1, ssgSaveVRML1 ) ;
   ssgAddModelFormat ( ".iv",    ssgLoadIV   , ssgSaveIV  ) ;
   ssgAddModelFormat ( ".asc",   NULL        , ssgSaveASC ) ;

   ssgEntity *e = ssgLoad(argv[1]);
   e->print(stdout);
   ssgSave(argv[2], e);
}


> Erik
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] texture filenames messed up

[Erik H. <er...@eh...>]

Fay John F Contr AAC/WMG wrote:
> Gentlemen,
> 
>         I am just back from a week out.  The issue mentioned is from two 
> years ago.  Has it now been resolved?  The file loaders are very much 
> outside my region of expertise.

You can call ssgTexturePath() prior to loading the textures/model now, 
so it shouldn't be that much of a problem anymore.

Erik

RE: [Plib-devel] texture filenames messed up

[Fay J. F C. AAC/W. <joh...@eg...>]

Gentlemen,

	I am just back from a week out.  The issue mentioned is from two
years ago.  Has it now been resolved?  The file loaders are very much
outside my region of expertise.

John F. Fay
joh...@eg...
850-729-6330 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Bram Stolk
Sent: Tuesday, September 28, 2004 3:25 AM
To: pli...@li...
Subject: [Plib-devel] texture filenames messed up

Hi,

The issue described here:
http://sourceforge.net/mailarchive/message.php?msg_id=1866706
and here:
http://sourceforge.net/mailarchive/message.php?msg_id=9644979

...may very well be caused by the fact that the code for
static ssgState *get_state ( _ssgMaterial *mat )
in ssg/ssgLoadAC.cxx contains unreachable code.

There are two clauses in the form of
   if (current_tfname != NULL) {
from which the 1st one will always return.
Therefore, the body of the 2nd clause is never executed.
This will skip the crucial st->setTexture()

This results in ssg trees, created from ac, to
incorrectly use old texture filenames.

You can use plibconvert.cxx, posted at ppe devel list
to trigger the bug.

To view ssgLoadAC.cxx, you can look here:
http://cvs.sourceforge.net/viewcvs.py/plib/plib/src/ssg/ssgLoadAC.cxx?rev=1.
33&view=markup

I must say it is quite a hassle to follow the trail of textures in the
system,
from ssgLoadAC to ssgLoad, to ssgRenderOptions, to ssgTextureArray, to 
ssgTexture with a detour over ssgState. Somewhere along this complicated
path, the ball was dropped.

   Bram


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

[Plib-devel] *.ac files and "crease".

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

I have tweaked the AC loader to ignore the lines with "crease". Until
now, there was a fatal error since it was an unknown token. Such ac
files can now be loaded.

Also, I improved the fatal error handling for Windows (l)users.

Bye bye,
Wolfram.

[Plib-devel] texture filenames messed up

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

Hi,

The issue described here:
http://sourceforge.net/mailarchive/message.php?msg_id=1866706
and here:
http://sourceforge.net/mailarchive/message.php?msg_id=9644979

...may very well be caused by the fact that the code for
static ssgState *get_state ( _ssgMaterial *mat )
in ssg/ssgLoadAC.cxx contains unreachable code.

There are two clauses in the form of
   if (current_tfname != NULL) {
from which the 1st one will always return.
Therefore, the body of the 2nd clause is never executed.
This will skip the crucial st->setTexture()

This results in ssg trees, created from ac, to
incorrectly use old texture filenames.

You can use plibconvert.cxx, posted at ppe devel list
to trigger the bug.

To view ssgLoadAC.cxx, you can look here:
http://cvs.sourceforge.net/viewcvs.py/plib/plib/src/ssg/ssgLoadAC.cxx?rev=1.33&view=markup

I must say it is quite a hassle to follow the trail of textures in the system,
from ssgLoadAC to ssgLoad, to ssgRenderOptions, to ssgTextureArray, to 
ssgTexture with a detour over ssgState. Somewhere along this complicated
path, the ball was dropped.

   Bram

Re: [Plib-devel] iv exports

[Erik H. <er...@eh...>]

Erik Hofman wrote:

> This doesn't look too involved, but we might end up with funny looking 
> models. I'll do some tests with this change.

If you don't know where to look at you probably won't even know the 
difference. But all in all it is a nice improvement, especially for 
billboarded objects.

Erik

Re: [Plib-devel] iv exports

[Erik H. <er...@eh...>]

Bram Stolk wrote:
> Erik Hofman wrote:
> 
>> Could you elaborate on that one a bit, since FlightGear depends 
>> heavily on plib's ac3d loader and I don't want to convert all models 
>> just because of this.

> The change I made in the loader is described here:
> http://sourceforge.net/mailarchive/forum.php?thread_id=5647230&forum_id=7201 
> 
> I dont think that it affects the loading of ac models by
> flightgear in any negative way.
> If it does, let me know, and I will investigate it further.
> At least dog.ac and tuxedo.ac show no problems.

This doesn't look too involved, but we might end up with funny looking 
models. I'll do some tests with this change.

Thanks for the explanation.

Erik

Re: [Plib-devel] iv exports

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

Erik Hofman wrote:

> Could you elaborate on that one a bit, since FlightGear depends heavily 
> on plib's ac3d loader and I don't want to convert all models just 
> because of this.

Ok,

When the AC loader loads a file, it will parse
ac materials.

 From these materials, ssgSimpleStates are constructed.
These ssgSimpleStates had their GL_SPECULAR, GL_EMISSION
values set, but not the GL_DIFFUSE.

This causes the un-intialized diffuse value of
0,0,0,0 being used in the ssgSimpleState node.
The un-initialized data may even be random, but
on my machine I observed 0,0,0,0 diffuse values
which make no sense.

That you dont see this weirdness normally, is probably
caused by the colour-per-vertex values that often overide
it.

Keeping un-initialized values in ssgSimpleStates is
bad anyway, because of PLIB's approach on vectors,
(which are float arrays, and not classes), plib
will not set a colour to a sane default.

The change I made in the loader is described here:
http://sourceforge.net/mailarchive/forum.php?thread_id=5647230&forum_id=7201

I dont think that it affects the loading of ac models by
flightgear in any negative way.
If it does, let me know, and I will investigate it further.
At least dog.ac and tuxedo.ac show no problems.

   Bram

> Erik

Re: [Plib-devel] iv exports

[Erik H. <er...@eh...>]

Bram Stolk wrote:

> Also, I had to add a line to sggLoadAC.cxx because
> when loading .ac files, I would get strange diffuse
> values, with alpha set to 0. This would lead to
> problems if I convert transparent materials from
> ac to iv.
> I don't think that alpha values 0.0 for diffuse
> make any sense, as it would make the geometry
> invisable.
> The issue seemed to be caused by simply ignoring
> diffuse values of ac materials.

Could you elaborate on that one a bit, since FlightGear depends heavily 
on plib's ac3d loader and I don't want to convert all models just 
because of this.

Erik

[Plib-devel] iv exports

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

Hi,


The iv exporter is in cvs.
I included it in ssg/Makefile.am and in ssg.dsp
I tested the Makefile.am only, but I expect win builds
should succeed with no problems.

I tested plib with ppe, and it works as expected.
If you encounter problems with saving .iv files,
let me know.

Also, I had to add a line to sggLoadAC.cxx because
when loading .ac files, I would get strange diffuse
values, with alpha set to 0. This would lead to
problems if I convert transparent materials from
ac to iv.
I don't think that alpha values 0.0 for diffuse
make any sense, as it would make the geometry
invisable.
The issue seemed to be caused by simply ignoring
diffuse values of ac materials.

    Bram

Re: [Plib-devel] plib-cvs notification broken?

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

This problem magically disappeared: the next did succeed.

    Bram

Bram Stolk wrote:
> stolk@amoras:~/src/plib/src/ssg$ cvs commit -m "Removed unused static 
> data to avoid warning" ssgLoadPCX.cxx
> br...@cv...'s password:
> Checking in ssgLoadPCX.cxx;
> /cvsroot/plib/plib/src/ssg/ssgLoadPCX.cxx,v  <--  ssgLoadPCX.cxx
> new revision: 1.5; previous revision: 1.4
> done
> Mailing pli...@li......
> Generating notification message...
> Generating notification message... done.
> Mailing pli...@li......
> Generating notification message...
> Traceback (most recent call last):
>   File "/cvsroot/plib/CVSROOT/syncmail", line 337, in ?
>     main()
>   File "/cvsroot/plib/CVSROOT/syncmail", line 330, in main
>     blast_mail(subject, people, specs[1:], contextlines, fromhost)
>   File "/cvsroot/plib/CVSROOT/syncmail", line 254, in blast_mail
>     resp = conn.sendmail(address, people, s.getvalue())
>   File "/usr/lib/python2.2/smtplib.py", line 654, in sendmail
>     if not (200 <= self.ehlo()[0] <= 299):
>   File "/usr/lib/python2.2/smtplib.py", line 384, in ehlo
>     (code,msg)=self.getreply()
>   File "/usr/lib/python2.2/smtplib.py", line 335, in getreply
>     raise SMTPServerDisconnected("Connection unexpectedly closed")
> smtplib.SMTPServerDisconnected: Connection unexpectedly closed
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel

[Plib-devel] plib-cvs notification broken?

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

stolk@amoras:~/src/plib/src/ssg$ cvs commit -m "Removed unused static 
data to avoid warning" ssgLoadPCX.cxx
br...@cv...'s password:
Checking in ssgLoadPCX.cxx;
/cvsroot/plib/plib/src/ssg/ssgLoadPCX.cxx,v  <--  ssgLoadPCX.cxx
new revision: 1.5; previous revision: 1.4
done
Mailing pli...@li......
Generating notification message...
Generating notification message... done.
Mailing pli...@li......
Generating notification message...
Traceback (most recent call last):
   File "/cvsroot/plib/CVSROOT/syncmail", line 337, in ?
     main()
   File "/cvsroot/plib/CVSROOT/syncmail", line 330, in main
     blast_mail(subject, people, specs[1:], contextlines, fromhost)
   File "/cvsroot/plib/CVSROOT/syncmail", line 254, in blast_mail
     resp = conn.sendmail(address, people, s.getvalue())
   File "/usr/lib/python2.2/smtplib.py", line 654, in sendmail
     if not (200 <= self.ehlo()[0] <= 299):
   File "/usr/lib/python2.2/smtplib.py", line 384, in ehlo
     (code,msg)=self.getreply()
   File "/usr/lib/python2.2/smtplib.py", line 335, in getreply
     raise SMTPServerDisconnected("Connection unexpectedly closed")
smtplib.SMTPServerDisconnected: Connection unexpectedly closed

Re: [Plib-devel] Inventor exporter available

[LAVIGNE,ERIC <la...@uf...>]

His SF account is bram.

On Sat Sep 25 11:01:24 EDT 2004, Steve Baker 
<sjb...@ai...> wrote:


> Give me your sourceforge account name.
> 

Re: [Plib-devel] Inventor exporter available

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

Bram Stolk wrote:
> Well,
> 
> What's the verdict? Surely plib can use a good iv exporter.
> Should I email the thing, or is cvs-write access a possibility?

Sure - I can give you CVS access.

Give me your sourceforge account name.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [Plib-devel] Inventor exporter available

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

Well,

What's the verdict? Surely plib can use a good iv exporter.
Should I email the thing, or is cvs-write access a possibility?

    bram


Bram Stolk wrote:
> Hello plibbers,
> 
> 
> I implemented ssgSaveIV()
> The results are quite satisfactory.
> I tested it on tuxedo.ac and dog.ac, and the output
> looks fine in ivview.
> 
> The code is already quite robust, and it correctly
> handles:
> - scene hierarchy
> - transformations
> - states
> - texture coords
> - textures
> - normals
> 
> not yet implemented: lights, lines, points, shademodel, camera.
> 
> Additionally, the code is quite clean, and introduces no
> new dependencies, as I managed to stay away from stl and
> libinventor. It's a single .cxx file, and some entries
> in ssg.cxx, sgg.dsp, Makefile.am, ssg.h
> 
> I prefer to be granted cvs write access, so I can commit my
> changes. If cvs-write access for me is deemed undesirable, I
> could mail someone the output of a cvs diff run on my tree,
> otherwise, my sourceforge id is bram
> 
> regards,
> 
>    Bram
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel

RE: [Plib-devel] plib logo

[Fay J. F C. AAC/W. <joh...@eg...>]

CLIPPIE ?!!???!????!????!?!?!??!?!?!?

I like it!  Unfortunately some of the symbolism isn't there any more since
Windows XP doesn't have Clippie.  I did a quick Google search on "Clippie
copyright" and didn't turn up anything obvious.

John F. Fay
joh...@eg...
850-729-6330 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Steve Baker
Sent: Friday, September 24, 2004 12:03 PM
To: pli...@li...
Subject: Re: [Plib-devel] plib logo

Bram Stolk wrote:

> I can't think of a 3D character that comes close to being
> universaly recognized like pacman.

Tux?

> And modern 3d icons are bound to be problemetic due to copyrights.
> (lara croft). Also, I would hesitate to put some tools to work
> on that one :-)

There are lots of OpenSource characters that we could do.  I have
the BSD Daemon, the KDE dragon and others as 3D models.

Using different opensource icons would have three effects:

1) It would emphasise the OpenSource nature of the project.
2) Using both Tux and Beastie (and - dare I say it - 'Clippie') would
    emphasise the cross-platform nature of the project.
3) *NOT* using games characters per-se would somewhat de-emphasise
    the idea that PLIB is *ONLY* for games (which it most certainly
    is not.

If we used Clippie - we could have a tool bending him open...to
symbolise the opening of Windows...?

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] plib logo

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

Steve Baker wrote:

> If we used Clippie - we could have a tool bending him open...to
> symbolise the opening of Windows...?

Nah!
Putting tux and clippy together symbolize os war. and this has
already been covered expertly by this excelent game :-)
http://stolk.org/xgame/
(shameless plug)

So I wouldnt go that way.

pacman symbolizes games
tux symbolizes linux
teapot symbolizes computer graphics
cornelbox symbolizes realistic rendering

the very characteristic bzflag tank may symbolize 3d games?

so, what symbolizes a portable game library?

  Bram



> ---------------------------- Steve Baker -------------------------
> HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
> HomePage : http://www.sjbaker.org
> Projects : http://plib.sf.net    http://tuxaqfh.sf.net
>            http://tuxkart.sf.net http://prettypoly.sf.net
> -----BEGIN GEEK CODE BLOCK-----
> GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
> V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
> -----END GEEK CODE BLOCK-----
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] plib logo

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

Bram Stolk wrote:

> I can't think of a 3D character that comes close to being
> universaly recognized like pacman.

Tux?

> And modern 3d icons are bound to be problemetic due to copyrights.
> (lara croft). Also, I would hesitate to put some tools to work
> on that one :-)

There are lots of OpenSource characters that we could do.  I have
the BSD Daemon, the KDE dragon and others as 3D models.

Using different opensource icons would have three effects:

1) It would emphasise the OpenSource nature of the project.
2) Using both Tux and Beastie (and - dare I say it - 'Clippie') would
    emphasise the cross-platform nature of the project.
3) *NOT* using games characters per-se would somewhat de-emphasise
    the idea that PLIB is *ONLY* for games (which it most certainly
    is not.

If we used Clippie - we could have a tool bending him open...to
symbolise the opening of Windows...?

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [Plib-devel] plib logo

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

Fay John F Contr AAC/WMG wrote:
> I agree with Steve.  (I'm old enough to recognize the Pac-Man 
> characters, but probably a lot of other folks aren't.)  The 3-d 
> rendering would also address my concern about it being cartoonish.

For me, it wasn't so much the cartoonishness - just the PLIB is all
about 3D applications - and PacMan is pretty much as far away from that
as you can get.

Put a 3D Tux's head into that vice (which needs to be a 3D model) and replace
PacMan with some other distinctive 3D character - and I think we have a good
web page manner - although it's too complex to call it a logo.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [Plib-devel] plib logo

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

Steve Baker wrote:

> I love the idea - tools working on game characters - but what it
> really needs is 3D rendered tools and 3D game characters that people
> might recognise.

I can't think of a 3D character that comes close to being
universaly recognized like pacman.

And modern 3d icons are bound to be problemetic due to copyrights.
(lara croft). Also, I would hesitate to put some tools to work
on that one :-)

Maybe a 3d pacman (wireframed?) could work?

    Bram

RE: [Plib-devel] plib logo

[Fay J. F C. AAC/W. <joh...@eg...>]

I agree with Steve.  (I'm old enough to recognize the Pac-Man characters,
but probably a lot of other folks aren't.)  The 3-d rendering would also
address my concern about it being cartoonish.

John F. Fay
joh...@eg...
850-729-6330 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Steve Baker
Sent: Friday, September 24, 2004 8:45 AM
To: pli...@li...
Subject: Re: [Plib-devel] plib logo

Bram Stolk wrote:
> Hello,
> 
> The 2002 plib logo competition was a big fiasco:
>
http://sourceforge.net/mailarchive/forum.php?thread_id=904174&forum_id=4480
> 
> However, why not try again?
> My entry is at:
> http://stolk.org/plib.png

I love the idea - tools working on game characters - but what it
really needs is 3D rendered tools and 3D game characters that people
might recognise.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] plib logo

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

Bram Stolk wrote:
> Hello,
> 
> The 2002 plib logo competition was a big fiasco:
> http://sourceforge.net/mailarchive/forum.php?thread_id=904174&forum_id=4480
> 
> However, why not try again?
> My entry is at:
> http://stolk.org/plib.png

I love the idea - tools working on game characters - but what it
really needs is 3D rendered tools and 3D game characters that people
might recognise.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----