plib-devel

[Plib-devel] Converting unsupported texture image file formats on the fly

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

Dear friends,

In ssgLoadTexture.cxx the function

  bool ssgConvertTexture( char * fname_output, const char * fname_input )

is devoted to the subject task. As it is now it has two problems which I
propose here to overcome.

Line 248 SVN:

if ( ulFileExists ( fname_output ) )
  	return true; // found *.rgb-file

fname_output is the .rgb version of the fname_input file name with
unsupported image ext. (e.g. .jpg). The current code says that if the .rgb
version of the input file name does exist no conversion is needed - but it
could be older than that. Thus a test on the two files' modification time is
also needed.


Line 258 SVN:

  258 // ****** found original file. convert it. ******
  259 #ifdef UL_WIN32
  260   char command [ 1024 ] ;
  261 	sprintf(command, "imconvert -verbose %s sgi:%s", fname_input,
fname_output);
  262 	unsigned int ui = WinExec(command, SW_HIDE );
  263 	if ( ui < 32 )
  264 	{	ulSetError(UL_WARNING, "Couldn't convert texture '%s'. Did
you install ImageMagick?"
  265 		                       " You may also convert it manually to
'%s' and reload the model.",
  266
fname_input, fname_output);
  267 		return false;
  268 	}
  269 #else
  270 	ulSetError(UL_WARNING, "Converting textures not yet implemented
under Linux."
  271 		                     "You may convert '%s' manually to '%s'
and reload the model.",
  272
fname_input, fname_output);
  273   //sprintf(command, "-verbose %s sgi:%s", fname_input, fname_output);
  274 	//execlp ( "convert", "convert",  command, NULL ) ;
  275 
  276 #endif
  277 	return true;
  278 }

Under UL_WIN32 the WinExec function spawn a separate process and allows the
calling program to continue, so that the latter could proceed using the
(supposedly converted) image file w/o waiting for it to be actually
generated.
Furthermore it is not supported elsewhere than under Win32.
I propose to use the simpler and widely supported system() function, which
is blocking, and to test the existance of the output file as success
conformation.

The modified code for fixing both problems in ssgLoadTexture.cxx is reported
in the following.


#include <sys/stat.h>

int fileMTimeCmp( const char *fname_input, const char *fname_output )
// Compare the two input file names against their modification time
// -1: fname_input newer than fname_output
//  1: fname_input older than fname_output
//  0: stat error
{
	struct _stat buffer_in, buffer_out;
#ifdef UL_WIN32
#define stat _stat
#endif
	if ( stat( fname_input, &buffer_in ) == 0 && stat( fname_output,
&buffer_out ) == 0 )
		return buffer_in.st_mtime > buffer_out.st_mtime ? -1 : 1;
	else
		return 0;
}


bool ssgConvertTexture( char * fname_output, const char * fname_input ) 
// converts file to .rgb (Silicon Graphics) format
// returns true if the file has been converted to rgb, or already exists as
rgb
// if it returns false, then it has already output an error message
{
	char *extension ;

	strcpy( fname_output, fname_input); // copy so that a) there is
enough room for .rgb and b) we don't change the buffer of fname_input
	extension = strrchr(fname_output, '.');
	if ( extension == NULL )
	{
		ulSetError(UL_WARNING, "There is no extension in the texture
'%s'.", fname_input);
		return false; // no extension -> give up
	}
	extension[1] = 'r';
	extension[2] = 'g';
	extension[3] = 'b';
	extension[4] = 0;

	// look for original, non-rgb - file
	if ( !ulFileExists ( fname_input ) )
	{
		ulSetError(UL_WARNING, "Can't find the texture file '%s'.",
fname_input);
		return false; // no input file => we can't convert it
	}

	if ( ulFileExists ( fname_output ) && fileMTimeCmp( fname_input,
fname_output ) != -1 )
		return true; // found *.rgb-file, and it's newer than
fname_input, so no conversion is needed

	// ****** found original file. convert it. ******
	char command [ 1024 ] ;
	char *conv_cmd = 
#ifdef UL_WIN32
		"imconvert";
#else
		"convert";
#endif
	sprintf(command, "%s -verbose %s sgi:%s", conv_cmd, fname_input,
fname_output);
	if ( system( command ) < 0 || !ulFileExists ( fname_output ) )
	{	ulSetError(UL_WARNING, "Couldn't convert texture '%s'. Did
you install ImageMagick?"
		                       " You may also convert it manually to
'%s' and reload the model.", 
	
fname_input, fname_output);
		return false;
	}

	return true;
}

fileMTimeCmp could, of course, become an additional ul file utility (other
OS-es please check the stat compatibility on non Win32 systems, but the
Win32 _stat should be POSIX-compliant).

Paolo Leoncini

Re: [Plib-devel] No longer blocking non power-of-two textures

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

You wrote:

>... asks that we add a new argument "bool freeData =3D false" so that =
the=20
>function will not always delete the input data.  Are there any =
objections=20
>to this?

All in all a good request, but it would be better to use
"bool freeData =3D true"=20
as that would be IMO compatible to the way it is now.

Anyway, IMO the most important thing now is to get a new version out
of the door, anything that could possibly delay it should be pushed
back to after the release.

BTW sorry for being slow right now, but I am very busy in both my two
jobs :(, it should be better in around 10 days.

>
>		- John


Bye bye,
Wolfram.

Re: [Plib-devel] No longer blocking non power-of-two textures

[John F. F. <joh...@cy...>]

Gentlemen,

	While we're on the question of "ssgMakeMipMaps", a feature request ...

http://sourceforge.net/tracker/index.php?func=detail&aid=1002001&group_i  
d=382&atid=350382

... asks that we add a new argument "bool freeData = false" so that the 
function will not always delete the input data.  Are there any objections 
to this?

		- John


-----Original Message-----
From:	John F. Fay
Sent:	Saturday, September 29, 2007 12:19 PM
To:	'PLIB Developers'
Subject:	Re: [Plib-devel] No longer blocking non power-of-two textures

OK, I didn't hear anybody scream so I have put the
"ssgSearchExtensionString" and "ssgIsExtensionSupported" functions at the
bottom ot "ssg.cxx" because it occurs to me that they are quite general.  I 

have put a prototype for "ssgIsExtensionSupported" into "ssg.h" and added
the extra test to "ssgMakeMipMaps" in "ssgLoadTexture.cxx".

	- John

-----Original Message-----
From:	Fay John F Dr CTR USAF 46 SK
Sent:	Friday, September 28, 2007 8:44 AM
To:	PLIB Developers
Subject:	Re: [Plib-devel] No longer blocking non power-of-two textures

It looks fine to my uneducated eye.  Unless somebody screams, I will put it 

into SVN this weekend.  (We can always take it out later if it breaks
something.)

John F. Fay
Technical Fellow
Jacobs Technology TEAS Group
850-883-1294

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Paolo
Leoncini
Sent: Friday, September 28, 2007 8:36 AM
To: 'PLIB Developers'
Subject: [Plib-devel] No longer blocking non power-of-two textures

Dear friends,

As most of you probably know the GL_ARB_texture_non_power_of_two OpenGL
extension, when supported, allows to overcome the subject limit at the only
implementation effort of checking if such extension is supported by the
hardware
(http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_non_power_o
f_tw
o.txt).

GL_ARB_texture_non_power_of_two has no relevant limitation, and is much
better than GL_EXT_texture_rectangle in which, e.g., texture coordinates
were addressed non-parametrically [0..w],[0..h].

Such check could be done in ssgMakeMipMaps at the very beginning just
before
the power-of-two test.
So in our case, in ssgLoadTexture.cxx:

ssgMakeMipMaps ( GLubyte *image, int xsize, int ysize, int zsize )
{
  bool non_power_of_two_tex_supported = ssgIsExtensionSupported(
"GL_ARB_texture_non_power_of_two" );

  if ( !non_power_of_two_tex_supported &&
      (! ((xsize & (xsize-1))==0) ||
       ! ((ysize & (ysize-1))==0)) )
  {
    ulSetError ( UL_WARNING, "Map is not a power-of-two in size!" ) ;
    return false ;
  }
  ...

Checking for such extension could be done, in this and future cases, by the
following code (code by Cesar Blecua Udias sent me by Roman Grigoriev when
testing VBOs):


static bool ssgSearchExtensionString(char *extString, char *extName) {
    // Returns GL_TRUE if the *extName string appears in the *extString
string,
    // surrounded by white spaces, or GL_FALSE otherwise.

    char *p, *end;
    int n, extNameLen;

    if ((extString == NULL) || (extName == NULL))
        return false;

    extNameLen = strlen(extName);

    p=extString;
    end = p + strlen(p);

    while (p < end) {
        n = strcspn(p, " ");
        if ((extNameLen == n) && (strncmp(extName, p, n) == 0))
            return GL_TRUE;

        p += (n + 1);
    }

    return GL_FALSE;
}

bool ssgIsExtensionSupported(char *extName) {
   // Returns GL_TRUE if the OpenGL Extension whose name is *extName
   // is supported by the system, or GL_FALSE otherwise.
   //
   // The *extName string must follow the OpenGL extensions naming scheme
   // (ie: "GL_type_extension", like GL_EXT_convolution)

    return ssgSearchExtensionString((char *)glGetString(GL_EXTENSIONS),
extName);
}

Waiting for reactions -

Paolo Leoncini


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel





-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] No longer blocking non power-of-two textures

[John F. F. <joh...@cy...>]

OK, I didn't hear anybody scream so I have put the 
"ssgSearchExtensionString" and "ssgIsExtensionSupported" functions at the 
bottom ot "ssg.cxx" because it occurs to me that they are quite general.  I 
have put a prototype for "ssgIsExtensionSupported" into "ssg.h" and added 
the extra test to "ssgMakeMipMaps" in "ssgLoadTexture.cxx".

	- John

-----Original Message-----
From:	Fay John F Dr CTR USAF 46 SK
Sent:	Friday, September 28, 2007 8:44 AM
To:	PLIB Developers
Subject:	Re: [Plib-devel] No longer blocking non power-of-two textures

It looks fine to my uneducated eye.  Unless somebody screams, I will put it 
into SVN this weekend.  (We can always take it out later if it breaks 
something.)

John F. Fay
Technical Fellow
Jacobs Technology TEAS Group
850-883-1294

-----Original Message-----
From: pli...@li... 
[mailto:pli...@li...] On Behalf Of Paolo 
Leoncini
Sent: Friday, September 28, 2007 8:36 AM
To: 'PLIB Developers'
Subject: [Plib-devel] No longer blocking non power-of-two textures

Dear friends,

As most of you probably know the GL_ARB_texture_non_power_of_two OpenGL
extension, when supported, allows to overcome the subject limit at the only
implementation effort of checking if such extension is supported by the
hardware
(http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_non_power_o  
f_tw
o.txt).

GL_ARB_texture_non_power_of_two has no relevant limitation, and is much
better than GL_EXT_texture_rectangle in which, e.g., texture coordinates
were addressed non-parametrically [0..w],[0..h].

Such check could be done in ssgMakeMipMaps at the very beginning just 
before
the power-of-two test.
So in our case, in ssgLoadTexture.cxx:

ssgMakeMipMaps ( GLubyte *image, int xsize, int ysize, int zsize )
{
  bool non_power_of_two_tex_supported = ssgIsExtensionSupported(
"GL_ARB_texture_non_power_of_two" );

  if ( !non_power_of_two_tex_supported &&
      (! ((xsize & (xsize-1))==0) ||
       ! ((ysize & (ysize-1))==0)) )
  {
    ulSetError ( UL_WARNING, "Map is not a power-of-two in size!" ) ;
    return false ;
  }
  ...

Checking for such extension could be done, in this and future cases, by the
following code (code by Cesar Blecua Udias sent me by Roman Grigoriev when
testing VBOs):


static bool ssgSearchExtensionString(char *extString, char *extName) {
    // Returns GL_TRUE if the *extName string appears in the *extString
string,
    // surrounded by white spaces, or GL_FALSE otherwise.

    char *p, *end;
    int n, extNameLen;

    if ((extString == NULL) || (extName == NULL))
        return false;

    extNameLen = strlen(extName);

    p=extString;
    end = p + strlen(p);

    while (p < end) {
        n = strcspn(p, " ");
        if ((extNameLen == n) && (strncmp(extName, p, n) == 0))
            return GL_TRUE;

        p += (n + 1);
    }

    return GL_FALSE;
}

bool ssgIsExtensionSupported(char *extName) {
   // Returns GL_TRUE if the OpenGL Extension whose name is *extName
   // is supported by the system, or GL_FALSE otherwise.
   //
   // The *extName string must follow the OpenGL extensions naming scheme
   // (ie: "GL_type_extension", like GL_EXT_convolution)

    return ssgSearchExtensionString((char *)glGetString(GL_EXTENSIONS),
extName);
}

Waiting for reactions -

Paolo Leoncini


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] No longer blocking non power-of-two textures

[Fay J. F Dr C. U. 46 S. <joh...@eg...>]

It looks fine to my uneducated eye.  Unless somebody screams, I will put =
it into SVN this weekend.  (We can always take it out later if it breaks =
something.)

John F. Fay
Technical Fellow
Jacobs Technology TEAS Group
850-883-1294=20

-----Original Message-----
From: pli...@li... =
[mailto:pli...@li...] On Behalf Of Paolo =
Leoncini
Sent: Friday, September 28, 2007 8:36 AM
To: 'PLIB Developers'
Subject: [Plib-devel] No longer blocking non power-of-two textures

Dear friends,

As most of you probably know the GL_ARB_texture_non_power_of_two OpenGL
extension, when supported, allows to overcome the subject limit at the =
only
implementation effort of checking if such extension is supported by the
hardware
(http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_non_power_of=
_tw
o.txt).

GL_ARB_texture_non_power_of_two has no relevant limitation, and is much
better than GL_EXT_texture_rectangle in which, e.g., texture coordinates
were addressed non-parametrically [0..w],[0..h].

Such check could be done in ssgMakeMipMaps at the very beginning just =
before
the power-of-two test.
So in our case, in ssgLoadTexture.cxx:

ssgMakeMipMaps ( GLubyte *image, int xsize, int ysize, int zsize )
{
  bool non_power_of_two_tex_supported =3D ssgIsExtensionSupported(
"GL_ARB_texture_non_power_of_two" );
 =20
  if ( !non_power_of_two_tex_supported &&
      (! ((xsize & (xsize-1))=3D=3D0) ||
       ! ((ysize & (ysize-1))=3D=3D0)) )
  {
    ulSetError ( UL_WARNING, "Map is not a power-of-two in size!" ) ;
    return false ;
  }
  ...

Checking for such extension could be done, in this and future cases, by =
the
following code (code by C=E9sar Blecua Ud=EDas sent me by Roman =
Grigoriev when
testing VBOs):


static bool ssgSearchExtensionString(char *extString, char *extName) {
    // Returns GL_TRUE if the *extName string appears in the *extString
string,
    // surrounded by white spaces, or GL_FALSE otherwise.

    char *p, *end;
    int n, extNameLen;

    if ((extString =3D=3D NULL) || (extName =3D=3D NULL))
        return false;

    extNameLen =3D strlen(extName);

    p=3DextString;
    end =3D p + strlen(p);

    while (p < end) {
        n =3D strcspn(p, " ");
        if ((extNameLen =3D=3D n) && (strncmp(extName, p, n) =3D=3D 0))
            return GL_TRUE;

        p +=3D (n + 1);
    }

    return GL_FALSE;
}

bool ssgIsExtensionSupported(char *extName) {
   // Returns GL_TRUE if the OpenGL Extension whose name is *extName
   // is supported by the system, or GL_FALSE otherwise.
   //
   // The *extName string must follow the OpenGL extensions naming =
scheme
   // (ie: "GL_type_extension", like GL_EXT_convolution)

    return ssgSearchExtensionString((char *)glGetString(GL_EXTENSIONS),
extName);
}

Waiting for reactions -

Paolo Leoncini


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

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

[Plib-devel] No longer blocking non power-of-two textures

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

Dear friends,

As most of you probably know the GL_ARB_texture_non_power_of_two OpenGL
extension, when supported, allows to overcome the subject limit at the =
only
implementation effort of checking if such extension is supported by the
hardware
(http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_non_power_of=
_tw
o.txt).

GL_ARB_texture_non_power_of_two has no relevant limitation, and is much
better than GL_EXT_texture_rectangle in which, e.g., texture coordinates
were addressed non-parametrically [0..w],[0..h].

Such check could be done in ssgMakeMipMaps at the very beginning just =
before
the power-of-two test.
So in our case, in ssgLoadTexture.cxx:

ssgMakeMipMaps ( GLubyte *image, int xsize, int ysize, int zsize )
{
  bool non_power_of_two_tex_supported =3D ssgIsExtensionSupported(
"GL_ARB_texture_non_power_of_two" );
 =20
  if ( !non_power_of_two_tex_supported &&
      (! ((xsize & (xsize-1))=3D=3D0) ||
       ! ((ysize & (ysize-1))=3D=3D0)) )
  {
    ulSetError ( UL_WARNING, "Map is not a power-of-two in size!" ) ;
    return false ;
  }
  ...

Checking for such extension could be done, in this and future cases, by =
the
following code (code by C=E9sar Blecua Ud=EDas sent me by Roman =
Grigoriev when
testing VBOs):


static bool ssgSearchExtensionString(char *extString, char *extName) {
    // Returns GL_TRUE if the *extName string appears in the *extString
string,
    // surrounded by white spaces, or GL_FALSE otherwise.

    char *p, *end;
    int n, extNameLen;

    if ((extString =3D=3D NULL) || (extName =3D=3D NULL))
        return false;

    extNameLen =3D strlen(extName);

    p=3DextString;
    end =3D p + strlen(p);

    while (p < end) {
        n =3D strcspn(p, " ");
        if ((extNameLen =3D=3D n) && (strncmp(extName, p, n) =3D=3D 0))
            return GL_TRUE;

        p +=3D (n + 1);
    }

    return GL_FALSE;
}

bool ssgIsExtensionSupported(char *extName) {
   // Returns GL_TRUE if the OpenGL Extension whose name is *extName
   // is supported by the system, or GL_FALSE otherwise.
   //
   // The *extName string must follow the OpenGL extensions naming =
scheme
   // (ie: "GL_type_extension", like GL_EXT_convolution)

    return ssgSearchExtensionString((char *)glGetString(GL_EXTENSIONS),
extName);
}

Waiting for reactions -

Paolo Leoncini

[Plib-devel] R: How many triangles in a leaf?

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

> -----Messaggio originale-----
> Da: pli...@li... 
> [mailto:pli...@li...] Per conto 
> di Steve Baker
> Inviato: domenica 23 settembre 2007 21.57
> A: joh...@cy...; PLIB Developers
> Oggetto: Re: [Plib-devel] How many triangles in a leaf?
> 
> I would strongly advise against this change.  Sending 32 bit 
> indices instead of 16 is a big penalty on reasonably size 
> meshes.  It's not hard to split big meshes into 65536 vertex 
> chunks and it's a bad idea to slow the package down for 
> reasonably sized models just in order to support the clueless.

I never thought to move all indices to 32 bit, and to support 2^32 vertices
per mesh.

Today the following limits hold for a ssgVtxArray:

- max number of vertices: sizeof(unsigned int) (a ssgVertexArray is a
ssgSimpleList)
- max number of indices: sizeof(unsigned int) (a ssgIndexArray is a
ssgSimpleList)
- max vertex index: sizeof(short) (indices are actually stored as shorts in
a ssgIndexArray)

Here's the mother of all inconsistencies: we can have up to 2^32 vertices,
but can address only the first 32768. So by loaders' point of view, it's not
important to have a limit, whatever it be, it's important to enforce the
respect of such a limit at ssgVtxArray creation. I don't know each loader
compliance to that, I took care of it only recently in the 3DS loader by
splitting larger meshes in sizeof(short)/3 (10922) triangles (triangle n has
indices n*3, n*3+1, n*3+2) (this is already in the SVN version of the 3DS
loader). Other loaders could make a more smarter use of the 32K-limited
indices so to address many more triangles than the 3DS one.

So it's solution time now:

a. cleanness: move to unsigned short indices, and limit the number of
vertices to that size - we would thus stay still within the 16-bit indices
so performances wouldn't suffer;

b. freedom: move to unsigned int indices, leave ssgVertexArray as it is
(since it is already unsigned int-capable) - virtually no mesh split longer
needed, performances would probably suffer a bit;

c. future: don't do anything now, let's wait to redesign the leaf geometry
storing from scratch in a possible Plib 2.0 version, where we could
parametrize several aspects of a ssgVtxArray, including whether to go to
Vertex arrays, VBOs, or possible newer, more performant OGL mechanisms.

As far as we are all aware of such intrinsic subtle limitation, I'm not in a
hurry to anything could compromise performances or Plib instability.
Wolfram, thanks for your agreeableness.

Greetings -

Paolo Leoncini


> John F. Fay wrote:
> > If somebody can send me some patches I can put them into 
> the code.  I 
> > have re-read Paolo's post and the responses and I do not 
> want to make 
> > such a subtle change to a library that I do not know well.
> > 
> > 	- John
> > 
> > 
> > -----Original Message-----
> > From:	Wolfram Kuss
> > Sent:	Saturday, September 22, 2007 3:02 PM
> > To:	PLIB Developers
> > Subject:	Re: [Plib-devel] How many triangles in a leaf?
> > 
> > I agree we should increase the limit.
> > The argument that this will encourage bad models is only half true 
> > IMHO as often I have to work with finished models and am 
> not even in 
> > contact with the modeller.
> > 
> > I am using "unsigned short" instead of "short" for a long time now 
> > (probably 2 years or so) without issues. Going to unsigned 
> int would 
> > probably be a bit more work, but would be welcome by me.
> > 
> > Bye bye,
> > Wolfram.
> > 
> > 
> ----------------------------------------------------------------------
> > --- This SF.net email is sponsored by: Microsoft Defy all 
> challenges. 
> > Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > plib-devel mailing list
> > pli...@li...
> > https://lists.sourceforge.net/lists/listinfo/plib-devel
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> ----------------------------------------------------------------------
> > --- This SF.net email is sponsored by: Microsoft Defy all 
> challenges. 
> > Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > plib-devel mailing list
> > pli...@li...
> > https://lists.sourceforge.net/lists/listinfo/plib-devel
> 
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Microsoft Defy all 
> challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel
> 

Re: [Plib-devel] How many triangles in a leaf?

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

I agree we should not force a slowdown on people.

So I suggest:
Let's not hold up the release on this.

I have not looked at the 16 to 32 bit change, but it may well be
possible to use a typedef or define so one change to the source
switches. I am very sure I have done this for the short to unsigned
short change.=20

Lets look at the 16 to 32 bit change. If fairly easily possible, and
if we can make it optional, let's do that. If not, let's at least do
the optional short to unsigned short change.=20


Bye bye,
Wolfram.

Re: [Plib-devel] How many triangles in a leaf?

[John F. F. <joh...@cy...>]

Roma locuta est, causa finita est.  ("Rome has spoken, the matter is 
finished.")

Until the next time somebody brings it up and I forget again that it was 
settled before.

I have an application at work that writes a binary file and then puts a 
"table of contents" in the front.  If the file is smaller than 2^32 bytes, 
the entries in the table of contents are written in four-byte words; if it 
is larger, they are written in four-byte words.  Talk about accounting 
nightmares!

	- John


-----Original Message-----
From:	Steve Baker
Sent:	Sunday, September 23, 2007 2:57 PM
To:	joh...@cy...; PLIB Developers
Subject:	Re: [Plib-devel] How many triangles in a leaf?

I would strongly advise against this change.  Sending 32 bit indices
instead of 16 is a big penalty on reasonably size meshes.  It's not
hard to split big meshes into 65536 vertex chunks and it's a bad idea
to slow the package down for reasonably sized models just in order to
support the clueless.

John F. Fay wrote:
> If somebody can send me some patches I can put them into the code.  I 
have
> re-read Paolo's post and the responses and I do not want to make such a
> subtle change to a library that I do not know well.
>
> 	- John
>
>
> -----Original Message-----
> From:	Wolfram Kuss
> Sent:	Saturday, September 22, 2007 3:02 PM
> To:	PLIB Developers
> Subject:	Re: [Plib-devel] How many triangles in a leaf?
>
> I agree we should increase the limit.
> The argument that this will encourage bad models is only half true
> IMHO as often I have to work with finished models and am not even in
> contact with the modeller.
>
> I am using "unsigned short" instead of "short" for a long time now
> (probably 2 years or so) without issues. Going to unsigned int would
> probably be a bit more work, but would be welcome by me.
>
> Bye bye,
> Wolfram.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel
>
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] How many triangles in a leaf?

[Steve B. <st...@sj...>]

I would strongly advise against this change.  Sending 32 bit indices 
instead of 16 is a big penalty on reasonably size meshes.  It's not
hard to split big meshes into 65536 vertex chunks and it's a bad idea
to slow the package down for reasonably sized models just in order to
support the clueless.

John F. Fay wrote:
> If somebody can send me some patches I can put them into the code.  I have 
> re-read Paolo's post and the responses and I do not want to make such a 
> subtle change to a library that I do not know well.
> 
> 	- John
> 
> 
> -----Original Message-----
> From:	Wolfram Kuss
> Sent:	Saturday, September 22, 2007 3:02 PM
> To:	PLIB Developers
> Subject:	Re: [Plib-devel] How many triangles in a leaf?
> 
> I agree we should increase the limit.
> The argument that this will encourage bad models is only half true
> IMHO as often I have to work with finished models and am not even in
> contact with the modeller.
> 
> I am using "unsigned short" instead of "short" for a long time now
> (probably 2 years or so) without issues. Going to unsigned int would
> probably be a bit more work, but would be welcome by me.
> 
> Bye bye,
> Wolfram.
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] How many triangles in a leaf?

[John F. F. <joh...@cy...>]

If somebody can send me some patches I can put them into the code.  I have 
re-read Paolo's post and the responses and I do not want to make such a 
subtle change to a library that I do not know well.

	- John


-----Original Message-----
From:	Wolfram Kuss
Sent:	Saturday, September 22, 2007 3:02 PM
To:	PLIB Developers
Subject:	Re: [Plib-devel] How many triangles in a leaf?

I agree we should increase the limit.
The argument that this will encourage bad models is only half true
IMHO as often I have to work with finished models and am not even in
contact with the modeller.

I am using "unsigned short" instead of "short" for a long time now
(probably 2 years or so) without issues. Going to unsigned int would
probably be a bit more work, but would be welcome by me.

Bye bye,
Wolfram.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] How many triangles in a leaf?

[John F. F. <joh...@cy...>]

OK, do we do this before or after the release?  I give you three datapoints:

(1)  I am not a project admin on PLIB, so I can't do any PLIB release work.

(2)  The October 1 deadline is about a week away and there hasn't been any motion towards a release yet.

(3)  A bird in the hand is worth two in the bush.

Therefore I would suggest that we put the change in now.

	- John


-----Original Message-----
From:	Wolfram Kuss 
Sent:	Saturday, September 22, 2007 3:02 PM
To:	PLIB Developers
Subject:	Re: [Plib-devel] How many triangles in a leaf?

I agree we should increase the limit.
The argument that this will encourage bad models is only half true
IMHO as often I have to work with finished models and am not even in
contact with the modeller. 

I am using "unsigned short" instead of "short" for a long time now
(probably 2 years or so) without issues. Going to unsigned int would
probably be a bit more work, but would be welcome by me.

Bye bye,
Wolfram.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] How many triangles in a leaf?

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

I agree we should increase the limit.
The argument that this will encourage bad models is only half true
IMHO as often I have to work with finished models and am not even in
contact with the modeller.=20

I am using "unsigned short" instead of "short" for a long time now
(probably 2 years or so) without issues. Going to unsigned int would
probably be a bit more work, but would be welcome by me.

Bye bye,
Wolfram.

Re: [Plib-devel] A new plib release?

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

Thank you for volunteering and in general for keeping PLIB
progressing!

Bye bye,
Wolfram.

Re: [Plib-devel] code for joystick in Solaris

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

"John F. Fay" wrote:
> OK, this is starting to look like a bit of a goat-rope.  Apart from the 
> "jsSolaris.cxx" and the previously-noted driver files ("driverSolaris.cxx" 
> and "driverSolaris.h"), I now find that we will need to include a "ujbf" 
> file for every specific joystick product.  Three are already included, but 
> how many dozen are not included and will need to be?  This could get very 
> messy very quickly.

I see. If the author of this patch, Mark Francis Villa, is unable to
respond in time, then it's certainly better to get a release out that
does not include this patch,

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

Re: [Plib-devel] code for joystick in Solaris

[John F. F. <joh...@cy...>]

OK, this is starting to look like a bit of a goat-rope.  Apart from the 
"jsSolaris.cxx" and the previously-noted driver files ("driverSolaris.cxx" 
and "driverSolaris.h"), I now find that we will need to include a "ujbf" 
file for every specific joystick product.  Three are already included, but 
how many dozen are not included and will need to be?  This could get very 
messy very quickly.

- John


-----Original Message-----
From:	Fay John F Dr CTR USAF 46 SK
Sent:	Wednesday, September 19, 2007 8:25 AM
To:	Mar...@mg...; PLIB Developers
Subject:	Re: [Plib-devel] code for joystick in Solaris

To quote Admiral Farragut in Mobile Bay (during the American Civil War),
"Damn the torpedoes, full speed ahead!"  ("Torpedoes" was what they
called naval mines at the time, and two other ships had just been sunk
by mines.)

If we are going to get a release out in two weeks, we'd better get busy.
I'll see what I can do tonight; any help from other people would also be
appreciated.

John F. Fay
Technical Fellow
Jacobs Technology TEAS Group
850-883-1294

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Martin
Spott
Sent: Wednesday, September 19, 2007 3:23 AM
To: pli...@li...
Subject: Re: [Plib-devel] code for joystick in Solaris

Hi John !

"John F. Fay" wrote:

>                 Do we want a "libusb" dependency in PLIB?
>
> It strikes me that "libusb" should be fairly widespread, since USB
devices
> are now found all over the place.  But I would like to wait for
Steve's
> sayso before I put the change in.

After Steve wasn't inclined to tell us his opinion on this topic for
more than three months now, I guess you're free to decide according to
your own belief  ;-)

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

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] code for joystick in Solaris

[Fay J. F Dr C. U. 46 S. <joh...@eg...>]

To quote Admiral Farragut in Mobile Bay (during the American Civil War),
"Damn the torpedoes, full speed ahead!"  ("Torpedoes" was what they
called naval mines at the time, and two other ships had just been sunk
by mines.)

If we are going to get a release out in two weeks, we'd better get busy.
I'll see what I can do tonight; any help from other people would also be
appreciated.

John F. Fay
Technical Fellow
Jacobs Technology TEAS Group
850-883-1294=20

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Martin
Spott
Sent: Wednesday, September 19, 2007 3:23 AM
To: pli...@li...
Subject: Re: [Plib-devel] code for joystick in Solaris

Hi John !

"John F. Fay" wrote:

>                 Do we want a "libusb" dependency in PLIB?
>=20
> It strikes me that "libusb" should be fairly widespread, since USB
devices=20
> are now found all over the place.  But I would like to wait for
Steve's=20
> sayso before I put the change in.

After Steve wasn't inclined to tell us his opinion on this topic for
more than three months now, I guess you're free to decide according to
your own belief  ;-)

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

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] code for joystick in Solaris

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

Hi John !

"John F. Fay" wrote:

>                 Do we want a "libusb" dependency in PLIB?
> 
> It strikes me that "libusb" should be fairly widespread, since USB devices 
> are now found all over the place.  But I would like to wait for Steve's 
> sayso before I put the change in.

After Steve wasn't inclined to tell us his opinion on this topic for
more than three months now, I guess you're free to decide according to
your own belief  ;-)

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

Re: [Plib-devel] A new plib release?

[Durk T. <d.t...@xs...>]

Hi John,

Just wanted to say that this is wonderful news. Really appreciate this. :-)

Cheers,
Durk

On Tuesday 11 September 2007 15:50, Fay John F Dr CTR USAF 46 SK wrote:
> Steve,
>
> 	I signed up last night from home as "fayjf2".  If you will sign
> me on as an admin I will get the thing out the door.
>
>
>
> Everybody else,
>
> 	If you have anything you want to get into PLIB before the
> feature freeze please announce it immediately and put the changes in as
> soon as possible.
>
> John F. Fay
> Technical Fellow
> Jacobs Technology TEAS Group
> 850-883-1294
>

Re: [Plib-devel] Serious problem with Windows SVN build

[John F. F. <joh...@cy...>]

Cancel red alert.  The problem, my dear Brutus, is not with our stars but 
with ourselves.  I mean, the problem, my dear Plibbers, is not with our 
source code but with our SVN download instructions.  On the page ...

http://sourceforge.net/svn/?group_id=382

... it says to use the SVN command ...

 svn co https://plib.svn.sourceforge.net/svnroot/plib plib

In TortoiseSVN, I used a "checkout" command and gave it the URL that was 
stated, ending in "svnroot/plib", and told it to download into a folder (as 
yet uncreated) called "plib".  That gave me a top-level directory of 
"plib/trunk".  When I tell TortoiseSVN to check out from the URL 
"https://plib.svn.sourceforge.net/svnroot/plib/trunk", I get everything in 
a directory named "plib" and the code builds nicely.  I still have some 
problems building the examples, but that is my own fault for not installing 
"freeglut"properly.

Somebody with access to the web site should modify the download page.

- John


-----Original Message-----
From:	Olaf Flebbe
Sent:	Saturday, September 15, 2007 2:55 PM
To:	PLIB Developers
Subject:	Re: [Plib-devel] Serious problem with Windows SVN build

Hi,

>>         While trying to build the examples in my SVN tree last night I
>> realized that the SVN checkout no longer puts the top-level PLIB
>> directory files into a directory named "plib".  This means that the
>> "#include <plib/ul.h>" statements are now broken.  Has anybody run into
>> this before?  What do you propose that we do about it?
>
> I have no Windows machine at the moment to test this(even thought you
> probably already tested it with a fresh checkout to see if it was
> because of recent patches or not), but, if most programs use
> <plib/ul.h> (and even more if that's the right way of using it), I
> suggest that the behavior is reverted.

If it breaks the examples, I would recommend reverting it. If I
understood the problem correctly this is not an especially new feature
in plib, I know it since the CVS days. I never built an plib example ;-)

Olaf


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] Serious problem with Windows SVN build

[John F. F. <joh...@cy...>]

	I guess my primary question is, is this an artifact of the way I 
downloaded SVN or is it something intrinsic?  Until we figure this out we 
probably shouldn't do anything.

	Let me try downloading it differently.

- John


-----Original Message-----
From:	Olaf Flebbe
Sent:	Saturday, September 15, 2007 2:55 PM
To:	PLIB Developers
Subject:	Re: [Plib-devel] Serious problem with Windows SVN build

Hi,

>>         While trying to build the examples in my SVN tree last night I
>> realized that the SVN checkout no longer puts the top-level PLIB
>> directory files into a directory named "plib".  This means that the
>> "#include <plib/ul.h>" statements are now broken.  Has anybody run into
>> this before?  What do you propose that we do about it?
>
> I have no Windows machine at the moment to test this(even thought you
> probably already tested it with a fresh checkout to see if it was
> because of recent patches or not), but, if most programs use
> <plib/ul.h> (and even more if that's the right way of using it), I
> suggest that the behavior is reverted.

If it breaks the examples, I would recommend reverting it. If I
understood the problem correctly this is not an especially new feature
in plib, I know it since the CVS days. I never built an plib example ;-)

Olaf


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] patch for current svn

[Olaf F. <fg...@of...>]

Hi,
> 
> 	I have just put this patch into SVN.  Please download the new version and 
> check whether it still works with your applications.
> 
> 	The patch was put in from a Window machine.  It would be good also if 
> people were to check for Windows line endings and, if any are found, please 
> remove them.
> 
> 		- John Fay

I am very sorry about the line endings. Beat me, I'm getting lazy.

plib works now out of the Box for FlightGear with MSVC8.

Thanks for your support,
   Olaf

Re: [Plib-devel] Serious problem with Windows SVN build

[Olaf F. <fg...@of...>]

Hi,

>>         While trying to build the examples in my SVN tree last night I
>> realized that the SVN checkout no longer puts the top-level PLIB
>> directory files into a directory named "plib".  This means that the
>> "#include <plib/ul.h>" statements are now broken.  Has anybody run into
>> this before?  What do you propose that we do about it?
> 
> I have no Windows machine at the moment to test this(even thought you
> probably already tested it with a fresh checkout to see if it was
> because of recent patches or not), but, if most programs use
> <plib/ul.h> (and even more if that's the right way of using it), I
> suggest that the behavior is reverted.

If it breaks the examples, I would recommend reverting it. If I 
understood the problem correctly this is not an especially new feature 
in plib, I know it since the CVS days. I never built an plib example ;-)

Olaf

Re: [Plib-devel] Serious problem with Windows SVN build

[<coz...@gm...>]

>         While trying to build the examples in my SVN tree last night I
> realized that the SVN checkout no longer puts the top-level PLIB
> directory files into a directory named "plib".  This means that the
> "#include <plib/ul.h>" statements are now broken.  Has anybody run into
> this before?  What do you propose that we do about it?

I have no Windows machine at the moment to test this(even thought you
probably already tested it with a fresh checkout to see if it was
because of recent patches or not), but, if most programs use
<plib/ul.h> (and even more if that's the right way of using it), I
suggest that the behavior is reverted.

-Coz

Re: [Plib-devel] code for joystick in Solaris

[John F. F. <joh...@cy...>]

Martin (and others),

	I've taken a look at the Solaris joystick code and noticed, as Mark Villa 
pointed out in his note, that it uses "libusb".  The "include" file 
"driverSolaris.h" also includes "/usr/sfw/include/usb.h" which appears to 
be simply another manifestation of "libusb".  But the question comes up, 
particularly for Steve Baker:

		Do we want a "libusb" dependency in PLIB?

It strikes me that "libusb" should be fairly widespread, since USB devices 
are now found all over the place.  But I would like to wait for Steve's 
sayso before I put the change in.

		- John


-----Original Message-----
From:	Martin Spott
Sent:	Friday, September 14, 2007 7:13 AM
To:	pli...@li...
Subject:	Re: [Plib-devel] code for joystick in Solaris

May I remind PLIB developers of the patch and the corresponding thread:

Mark Francis Villa wrote:

> I created a patch for PLIB's 'js' code to add support for joysticks
> in Solaris using 'libusb'.
>
> Documentation:
>
> http://www.dpo.uab.edu/~drmark/Solaris/README_Solaris.html
>
>
> Source Download:
>
> 
http://www.dpo.uab.edu/~drmark/Solaris/PLIB_Patch_Protoype_For_Solaris_2  
0060808.tgz

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel