plib-devel

Re: [Plib-devel] PLIB 1.8.5 released.

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

Steve Baker writes:
> 
> It's been a L-O-N-G time since our last PLIB release.
> 
> This is version 1.8.5.
> 
> Grab it from http://plib.sf.net

Awesome  :-)

More so in that you are contemplating a 2.0 version.

I am in complete agreement that a break with the PLIB as 
we have known it is in order to take advantage of tomorrows 
OpenGL.

Thanks

Norman

Re: [Plib-devel] PLIB 1.8.5 released.

[Christos D. <ole...@fa...>]

Steve Baker wrote:
> It's been a L-O-N-G time since our last PLIB release.
> 
> This is version 1.8.5.
> 
> Grab it from http://plib.sf.net
> 
yay!

[Plib-devel] PLIB 1.8.5 released.

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

It's been a L-O-N-G time since our last PLIB release.

This is version 1.8.5.

Grab it from http://plib.sf.net

Re: [Plib-devel] Release 1.8.5....and a glimpse of the future.

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

Jan Reucker wrote:
> Am Sat, 08 Mar 2008 08:29:36 -0600 schrieb Steve Baker <st...@sj...>:
> 
>>> but rewriting all the GUI code would be impossible. And I'm quite happy
>>> with it, so why change it? I hope that we still can get a PLIB-1.8.x
>>> release every now and then even after PLIB-2.0 is born, just in case bad
>>> bugs have been fixed.
>> The reason to change is that OpenGL is changing.
> 
> I never questioned a general rewrite of SSG. I was only talking for my own
> PLIB application which will happily live with 1.8.x as long as there's a
> GFX card driver that supports the current OpenGL features.

Well, 1.8.x will be around for as long as anyone wants to maintain it. 
Who knows how long that will be?  I stopped working on it two years 
ago..but other people are still adding stuff.  It's hard to predict how 
long it would continue.  SourceForge will presumably keep the servers 
running indefinitely.

> I also support the idea of switching to OpenAL. Just one question: Does OpenAL
> support audio input?

Yes - it does...but the Linux version is a few rev levels behind the 
latest - so it's possible that Linux doesn't have it yet...but it will.

> This is a feature found in only a few portable audio
> libraries (e.g. in PortAudio), and I think it's a valuable feature (CRRCsim
> uses PortAudio to sample PPM signals from r/c transmitters; and just think
> of the Nintendo DS, where many great games make use of the built-in mic).

Yep.

> Another feature I really missed in 1.8.x was proper full-screen support in
> PW. But I guess there's no need to rewrite PW to work with the new PLIB.

Agreed - PW is one of the few things I don't want to rewrite - although 
we might want to think about how to integrate screen-based rendering 
contexts with other render targets into something more coherent...I 
suspect that's something we'll get a clearer idea of when OpenGL 3.0 (or 
whatever) finally surfaces.  But adding stuff like true full-screen 
support is something we can do at any time.

Re: [Plib-devel] Release 1.8.5....and a glimpse of the future.

[Jan R. <slo...@gm...>]

Am Sat, 08 Mar 2008 08:29:36 -0600 schrieb Steve Baker <st...@sj...>:

> > but rewriting all the GUI code would be impossible. And I'm quite happy
> > with it, so why change it? I hope that we still can get a PLIB-1.8.x
> > release every now and then even after PLIB-2.0 is born, just in case bad
> > bugs have been fixed.
> 
> The reason to change is that OpenGL is changing.

I never questioned a general rewrite of SSG. I was only talking for my own
PLIB application which will happily live with 1.8.x as long as there's a
GFX card driver that supports the current OpenGL features.

I also support the idea of switching to OpenAL. Just one question: Does OpenAL
support audio input? This is a feature found in only a few portable audio
libraries (e.g. in PortAudio), and I think it's a valuable feature (CRRCsim
uses PortAudio to sample PPM signals from r/c transmitters; and just think
of the Nintendo DS, where many great games make use of the built-in mic).

Another feature I really missed in 1.8.x was proper full-screen support in
PW. But I guess there's no need to rewrite PW to work with the new PLIB.

Kind regards,
Jan R.

-- 
Jan Reucker
email: jan dot reucker at web dot de
web:   http://www.reucker-online.de

Re: [Plib-devel] Release 1.8.5....and a glimpse of the future.

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

Jan Reucker wrote:
> Am Thu, 06 Mar 2008 22:11:49 -0600 schrieb Steve Baker <st...@sj...>:
> 
>> However, the new, improved SSG will be PERFECT for that stuff.  If it 
>> has 'plugin' capability as I'm planning - then PUI simply builds an SSG 
>> scene graph and plugs in it's own culling mechanisms.   SSG provides the 
>> geometry maintenance, shader services, etc.  It's a good match.
> 
> Steve,
> 
> all that you wrote about "PLIB-2.0" or however it will be called sounds
> very interesting. And I hope that someone will implement something like
> PUI on top of it. PUI was one of the main reasons why I chose PLIB for
> CRRCsim - originally I was only looking for an OpenGL font library to
> implement my own GUI, then I discovered PUI, and then the rest of PLIB.
> 
> And right now the references to PUI are the main reason why I stick
> with PLIB-1.8.x although other SceneGraph libs are offering more features.
> Using a different scene graph for model rendering would be an easy task,
> but rewriting all the GUI code would be impossible. And I'm quite happy
> with it, so why change it? I hope that we still can get a PLIB-1.8.x
> release every now and then even after PLIB-2.0 is born, just in case bad
> bugs have been fixed.

The reason to change is that OpenGL is changing.

There was to have been a radically simplified OpenGL coming out this 
year called "OpenGL 3.0" - although they are now talking in terms of an 
intermediate 2.something release appearing first.

The change is one that I've long felt was necessay.   OpenGL has a 
wildly complicated feature set - everything from drawing dotted lines to 
  multi-textured polygons that are lit differently on the front and back 
faces.  There are at least three or four ways to send polygons to the 
graphics card...the list goes on.

However, with the advent of shader technology - you really don't need 
all of those features.  There are now just a few core concepts: Bulk 
data transfer to the graphics card - textures, shaders and uniform 
variables...and that's about it.

All of the other OpenGL features can be implemented using just a handful 
of basic concepts.

The trouble with OpenGL as it is today is that all that wild and 
complicated stuff MUST be implemented and tested in every single OpenGL 
driver - and that's a huge cost to the graphics card manufacturers. 
Worse still - we have one of OpenGL's biggest markets being in the 
embedded device arena - cellphones, PDA's, MP3 players, etc.  Those 
devices have to be lean and mean - low power consumption, not much 
memory, etc.  So they NEED a radically slimmed down OpenGL.

So - the next major revisions rips out all of that dusty old junk and 
leaves only ONE mechanism for sending polygons to the GPU - and all of 
the complicated polygon lighting and structured line stuff vanishes - 
the API shrinks to less than half it's former size!  The present 
features get added back in via an obscelescence package that implements 
the old features on top of the new streamlined API - but those features 
don't have to run very fast because they are on the way out.

This is a very good thing - it lets the card manufacturers concentrate 
on optimising the heck out of the core, modern features - and they don't 
have to worry about maintaining increasingly obscure features like the 
old lighting code anymore when no new software will use it.

Eventually the obscelescence library will be quietly dropped too.

So - in the light of that, it's highly appropriate that PLIB change to 
fit the new paradigm - and that means that we HAVE to rewrite it sooner 
or later or it will simply stop working.

Meanwhile - if we could slim it down sooner rather than later - we could 
have PLIB programs running on cellphones.

So - PUI (which uses all those old dusty features) *MUST* be rewritten 
sometime in the next year or two.  Ditto the font library.

Putting it on top of the new SSG makes a lot of sense, structurally.

Since PLIB-2 (or whatever we call it) is NOT going to be compatible with 
PLIB-as-it-is-now (nor would you want it to be) - the current PLIB will 
continue to be maintained - and possibly new versions will need to be 
released for a few more years...but sooner or later it'll be running on 
the obscelescence library of OpenGL - and at that point we should 
probably let it die.

Since we are making a HUGE break with the past - we only really want to 
do that very rarely.  So this is a good time to make any other large 
breaks with the past that we might need.  One that is L-O-N-G overdue is 
dumping the sound library ('SL') and placing it as a layer on top of 
OpenAL.  Making OpenAL a requirement for PLIB-2 is a major decision - 
but the benefits it brings are worthwhile.   For example, we could 
arrange to allow SL sound objects to be attached to objects in the SSG 
scene graph and have them be culled and "rendered" in a special audio 
rendering pass.  This would make it ridiculously easy to attach noises 
to 3D objects such that as you move around in the virtual world, you 
heare the sound produced by nearby objects automatically.  OpenAL is a 
3D audio library - it shares a lot of OpenGL features - so the 
integration path is easy.  It implements things like range attenuation, 
stereo or quadrophonic or synthetic-3D sound placement and doppler 
effects - all without intervention from the application code.

With PUI-on-top-of-SSG and with SL nodes being attachable to SSG objects 
- you could even have a GUI where the buttons make sounds as your mouse 
glides past them - or have talking pop-up help - or sliders that make 
upward sounding whistles when you slide them to the right and downward 
sounding whistles as you slide them to the left...well, it all sounds 
perfectly awful to me...but it'll come "for free" and doubtless someone 
will want to use it.



> Kind regards,
> Jan R.
> 

Re: [Plib-devel] Release 1.8.5....and a glimpse of the future.

[Jan R. <slo...@gm...>]

Am Thu, 06 Mar 2008 22:11:49 -0600 schrieb Steve Baker <st...@sj...>:

> However, the new, improved SSG will be PERFECT for that stuff.  If it 
> has 'plugin' capability as I'm planning - then PUI simply builds an SSG 
> scene graph and plugs in it's own culling mechanisms.   SSG provides the 
> geometry maintenance, shader services, etc.  It's a good match.

Steve,

all that you wrote about "PLIB-2.0" or however it will be called sounds
very interesting. And I hope that someone will implement something like
PUI on top of it. PUI was one of the main reasons why I chose PLIB for
CRRCsim - originally I was only looking for an OpenGL font library to
implement my own GUI, then I discovered PUI, and then the rest of PLIB.

And right now the references to PUI are the main reason why I stick
with PLIB-1.8.x although other SceneGraph libs are offering more features.
Using a different scene graph for model rendering would be an easy task,
but rewriting all the GUI code would be impossible. And I'm quite happy
with it, so why change it? I hope that we still can get a PLIB-1.8.x
release every now and then even after PLIB-2.0 is born, just in case bad
bugs have been fixed.

Kind regards,
Jan R.

-- 
Jan Reucker
email: jan dot reucker at web dot de
web:   http://www.reucker-online.de

Re: [Plib-devel] R: R: Release 1.8.5....and a glimpse of the future.

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

Paolo Leoncini wrote:
>> I havn't thought too much about file readers and writers - I 
>> certainly don't have the time to rewrite all of the loaders 
>> and savers that we currently have.
>>     
>
> We should select among these which one to support in Plib-2. Once the new
> API will be pre-released we could share the porting load.
>   
Well, the work of writing loaders and savers is generally one where "He 
who needs it - implements it!"...this generally gets you most of the 
important loaders fairly easily - but you also get landed with a bunch 
of obscure ones and some that are only incompletely written.  It's not 
the most glamorous job!

>> I've added an XML load/dump feature which should provide a 
>> way to keep files current in the future.
>>     
>
> Is this the same as the one of the Blender exporter? Or is it a more
> low-level one?
>   
Yes - it's the same on that my Blender exporter writes.  That's just a 
Python script that constructs XML in memory then calls the XML output 
module to dump it to disk.  Writing blender exporters is a total crap 
shoot though - they change the API with every release - update the 
documentation about once a decade - and the Python API always lags 
behind the feature set of blender's 3D modeller - so you just never 
quite get to catch up with everything.   But that's still better than 
trying to parse '.blend' files.   It's OK for exporting simple geometry 
- but when you start wanting to write out heirarchy or stuff like bone 
structures and vertex weights or animation curves...the lack of decent 
documentation and the lag in the Python API can really kill you.   Also, 
you have to update your Python code with almost every blender release.

I really hate blender...but my kid loves it - so I'm stuck having to 
support it!

> A plug-in facility in Plib. Sounds good. Have you anything already in mind?
> Or is it a "just in case" sort of thing to came later? Should anybody work
> on this in the meanwhile?
>   
No - don't work on ANYTHING because I'm still in a very early design phase.

The plan is to allow plugins in Java and as precompiled C++.   Java was 
not my language of choice - but I have an ulterior motive in that my son 
is learning it at school and I want him to exercise his programming 
skills.   It's not too terrible - but it wouldn't have been my first choice.
> Yet it'd be sane to offer still a file support for basic, non shader-based,
> material definition as far as it's not heavy to do.
>
>   
Well, that kinda falls out from what I just said.  There is a "default" 
material - that just renders one texture with no fancy features.  So if 
you apply a texture to a mesh and don't provide a material for it in the 
material.xml file then you get a simple gouraud-shaded, textured, lit 
surface.  Pretty much what you'd expect.   You can override the standard 
"default.vs" and "default.fs" (vertex shader and fragment shader) to 
make the default material do something else if you wanted to.   In my 
application, I have it doing simple phong shading with white specular 
light and a standard shininess of 10.0.   Kinda makes everything look 
like plastic.

That lets you write applications without having to learn anything about 
shaders - but you'll probably want to use them most of the time because 
it's where the cool features are!

>> I don't want to write my own Collada loader because it's too 
>> phreaking complicated - but if you want to do it - or if you 
>> want to write the plugin-stub for Collada and depend on an 
>> external library - feel free to 
>> do that.   I don't need it - and I don't generally write what 
>> I don't need.
>> Past experience says that these standard formats typically 
>> have a whole lot of features that I don't want to implement - 
>> and I have implemented a whole lot of features that they 
>> don't support....so it's never a good 
>> match.
>>     
>
> I agree with you, but it usually lead to a lot of work in non-standard
> directions. And, before or after, the custom format gets abandoned.
>   
Well - maybe.  But I'm not going to do it - if someone else wants to - 
the hooks are there.  I typicaly write very stand-alone applications 
that come with their own models - so long as I have a working 
tool-chain, I'm happy.  With what I have, I can build models in AC3D and 
my kid can build them (and animate them) in Blender.   Blender is pretty 
much the de-facto OpenSource modeller - so that's plenty for my needs.

> Google Earth, for example, does only support Collada geometry, and nobody
> says "why I can't play physics on top of a volcano". But I don't know what
> happens with non-SketchUp models.
>   
Well, exactly.  If it doesn't support ALL of Collada then it's not 
really a standard.  SketchUp writes some special subset of Collada which 
GoogleEarth reads.  If you want features that GoogleEarth doesn't 
support but Collada does - then SketchUp can't produce them - if you 
author your Collada models with something else, it's completely unknown 
whether the model will look right in GoogleEarth.   If other people 
write applications (as we surely would) that implement a DIFFERENT 
subset of Collada then you end up having to build material that uses the 
intersection of two subsets...that gets really ugly.

As I pointed out years ago when we tried to get some traction behind a 
project called "LodeStone" - what we REALLY need is a standard scene 
graph API so that standard loaders and savers can be written.   But that 
somehow never happens.
> Furthermore Collada supports the detailed inclusion of shaders (possibly
> even the actual shader code?), and physics definition data, which is a "must
> have" of modern games. So we shouldn't feel obliged to support all at once.
>   
Well, maybe - but as I said - it just doesn't interest me - so I won't 
be doing it...period.
> Anyway it was just a thought to share with you and others before going in a
> certain direction, after having evaluated what really the distance between
> the two formats is.
>   
My format will bear ZERO resemblence to Collada - it's basically an 
XML'ed version of the PLIB in-memory structures.  The reason being that 
I don't care much how long it takes to write a file - but I care 
passionately about how long it takes to load.  Hence the effort of 
standards conversions should be kept in off-line tools and not in the 
interactive application.

I can run a batch job once in a great while to convert models from 
whatever they are in (Collada, Blender, AC3D) to ".plib" and if it takes 
a couple of hours to run - that's no big deal.  However, when my end 
user starts up the game (or whatever) it needs to get going FAST - we 
don't want to be hanging around while some chunk of complicated code is 
trying to convert Collada shaders into GLSL or some fancy winged edge 
topography into triangle meshes.   This needs to be fast.

But as I said - there is nothing to stop people writing their own 
loaders and savers as they have for PLIB-1.

[Plib-devel] R: R: Release 1.8.5....and a glimpse of the future.

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

> -----Messaggio originale-----
> Da: pli...@li... 
> [mailto:pli...@li...] Per conto 
> di Steve Baker
> Inviato: venerdì 7 marzo 2008 13.12
> A: PLIB Developers
> Oggetto: Re: [Plib-devel] R: Release 1.8.5....and a glimpse 
> of the future.
> 
> Paolo Leoncini wrote:
> > Steve,
> >
> > As a Plib/SSG enthusiast I'm happy to hear such very good news from 
> > you for the next-gen Plib.
> > The revamp you have depicted was infact really needed.
> >   
> Yes - sadly, until recently I didn't have the time to work on 
> PLIB - so it's lagged seriously behind the technology.  
> That's why such massive change is needed.  There is now too 
> much to do for slow incremental change - hence a disconnect 
> from the past is needed.

No problem, it'll worth the effort.

> > I'd like you could spend some more words on formats:
> >   
> I havn't thought too much about file readers and writers - I 
> certainly don't have the time to rewrite all of the loaders 
> and savers that we currently have.

We should select among these which one to support in Plib-2. Once the new
API will be pre-released we could share the porting load.

> > - will the SSG native binary dump still live? It's very 
> efficient in 
> > loading and I'd dislike for it to "go away";
> >   
> Some sort of binary dump will exist - but it won't be 
> compatible with the present format.  The trouble with these 
> super-efficient binary formats is that they are hard to 
> change in a compatible way and still retain that highly 
> desirable efficiency.
> 
> I've added an XML load/dump feature which should provide a 
> way to keep files current in the future.

Is this the same as the one of the Blender exporter? Or is it a more
low-level one?

> > - what about your position to avoid dependencies on 
> external libraries?
> That most certainly doesn't change.  Right now - I depend on 
> OpenGL and the 'tinyXML' library - but I intend to distribute 
> tinyXML as a part of
> PLIB-2 so that's not an external dependency.  When we change 
> the audio 
> library - we'll add a dependency on OpenAL.   Aside from that 
> - no new 
> dependencies.
> >  I refer in particular to 3D data loaders from other 
> formats. IMHO we 
> > should open to specialized libraries for reliably loading e.g. 
> > VRML2/X3D (CyberX3D) or 3DS (lib3ds), then walking their 
> scene graph 
> > to translate it into SSG-equivalent.
> >   
> For that kind of thing we need to use plugins that are linked 
> at runtime.  Treating foreign format loaders as 
> runtime-plugins allows people who don't want those 
> dependencies for their software to simply never load a file 
> of that format and thereby not have the dependency.

A plug-in facility in Plib. Sounds good. Have you anything already in mind?
Or is it a "just in case" sort of thing to came later? Should anybody work
on this in the meanwhile?

> > - the new XML-based one: is it a scene format? Does it point to 
> > (reference) external files for large data sets, or will it 
> include the 
> > actual geometry in it? Or both?
> >   
> I'm still working on that - my current loader (for which I 
> have a blender exporter) ".plib" allows external files - but 
> the blender 
> exporter doesn't use that feature.   In practical use - I have "level 
> files" (one for each "level" of the game) that pull in 
> geometry files.  
> You can refer to non-.plib files from within .plib files - 
> and the format is nice enough that you can hand-edit your 
> "level" files in a text editor or a generic XML editor.
> 
> The tricky part is that I don't intend to load 
> material/shader descriptions from ".plib" files - the 3D 
> modellers out there just don't save the information OpenGL 
> needs in a shader-rich environment.  So I do what all of my 
> previous games have done which is to have an external 
> "material file" that links the name of the primary texture 
> map in the geometry file to the name of a material - which in 
> turn pulls in a vertex and a fragment shader, and a bunch of 
> uniform variables...which 
> can (of course) be texture maps.   So in practical use - you 
> sit in your 
> modeller - you apply a simple brick texture  
> ("textures/brick.png" say) and the loader sees that a 
> particular polygon mesh uses that map - strips the directory 
> and suffix from the filename (so now, we have
> "brick") - then searches the material file for a material 
> with that name.  The material "brick" may or may not refer to 
> the file "textures/brick.png" - that's up to you.  For 
> convenience, if that material is not found you get a warning 
> message and the "default" 
> material is used instead.  If the chosen material (either 
> "default" or "brick" in this case) exists but has no uniform 
> variable that refers to a texture map (as is the case with 
> "default"), then the system will automatically generate a 
> uniform called "texture" that is set to 
> "<your_texture_path>/<materialname>.rgb".   This mechanism 
> allows you to 
> use a basic default material without having to go and type in 
> a material for every single texture type you use.
> I expect many of the other loaders we use will want to use a similar 
> mechanism.   The AC3D loader (for example) only knows about 
> one texture 
> map and a set of diffuse/spec/emiss/ambient colours.  It's 
> impossible to specify shaders or multiple textures or 
> whatever...so you model "brick" 
> inside AC3D and you tell PLIB what "brick" looks like by 
> giving me shaders, multiple textures, a normal map, 
> cube-mapped environmental reflections....whatever.

Yet it'd be sane to offer still a file support for basic, non shader-based,
material definition as far as it's not heavy to do.

> Shaders are written in GLSL...but it wouldn't be hard to add 
> Cg if anyone really wanted to.
> 
>  > - what do you think about Collada? If the new plib-XML 
> isn't far from it why
> > don't bet on Collada support from the beginning?
> >   
> I don't want to write my own Collada loader because it's too 
> phreaking complicated - but if you want to do it - or if you 
> want to write the plugin-stub for Collada and depend on an 
> external library - feel free to 
> do that.   I don't need it - and I don't generally write what 
> I don't need.
> Past experience says that these standard formats typically 
> have a whole lot of features that I don't want to implement - 
> and I have implemented a whole lot of features that they 
> don't support....so it's never a good 
> match.

I agree with you, but it usually lead to a lot of work in non-standard
directions. And, before or after, the custom format gets abandoned.

> Implementing ALL of the Collada spec would be exceedingly 
> difficult - and when you don't implement all of it you find 
> that half of the models out there won't load.

Google Earth, for example, does only support Collada geometry, and nobody
says "why I can't play physics on top of a volcano". But I don't know what
happens with non-SketchUp models.

Furthermore Collada supports the detailed inclusion of shaders (possibly
even the actual shader code?), and physics definition data, which is a "must
have" of modern games. So we shouldn't feel obliged to support all at once.

Anyway it was just a thought to share with you and others before going in a
certain direction, after having evaluated what really the distance between
the two formats is.

Paolo

Re: [Plib-devel] R: Release 1.8.5....and a glimpse of the future.

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

Paolo Leoncini wrote:
> Steve,
>
> As a Plib/SSG enthusiast I'm happy to hear such very good news from you for
> the next-gen Plib.
> The revamp you have depicted was infact really needed.
>   
Yes - sadly, until recently I didn't have the time to work on PLIB - so 
it's lagged seriously behind the technology.  That's why such massive 
change is needed.  There is now too much to do for slow incremental 
change - hence a disconnect from the past is needed.
> I'd like you could spend some more words on formats:
>   
I havn't thought too much about file readers and writers - I certainly 
don't have the time to rewrite all of the loaders and savers that we 
currently have.
> - will the SSG native binary dump still live? It's very efficient in loading
> and I'd dislike for it to "go away";
>   
Some sort of binary dump will exist - but it won't be compatible with 
the present format.  The trouble with these super-efficient binary 
formats is that they are hard to change in a compatible way and still 
retain that highly desirable efficiency.

I've added an XML load/dump feature which should provide a way to keep 
files current in the future.
> - what about your position to avoid dependencies on external libraries?
That most certainly doesn't change.  Right now - I depend on OpenGL and 
the 'tinyXML' library - but I intend to distribute tinyXML as a part of 
PLIB-2 so that's not an external dependency.  When we change the audio 
library - we'll add a dependency on OpenAL.   Aside from that - no new 
dependencies.
>  I refer in particular to 3D data loaders from other formats. IMHO we should
> open to specialized libraries for reliably loading e.g. VRML2/X3D (CyberX3D)
> or 3DS (lib3ds), then walking their scene graph to translate it into
> SSG-equivalent.
>   
For that kind of thing we need to use plugins that are linked at 
runtime.  Treating foreign format loaders as runtime-plugins allows 
people who don't want those dependencies for their software to simply 
never load a file of that format and thereby not have the dependency.
> - the new XML-based one: is it a scene format? Does it point to (reference)
> external files for large data sets, or will it include the actual geometry
> in it? Or both?
>   
I'm still working on that - my current loader (for which I have a 
blender exporter) ".plib" allows external files - but the blender 
exporter doesn't use that feature.   In practical use - I have "level 
files" (one for each "level" of the game) that pull in geometry files.  
You can refer to non-.plib files from within .plib files - and the 
format is nice enough that you can hand-edit your "level" files in a 
text editor or a generic XML editor.

The tricky part is that I don't intend to load material/shader 
descriptions from ".plib" files - the 3D modellers out there just don't 
save the information OpenGL needs in a shader-rich environment.  So I do 
what all of my previous games have done which is to have an external 
"material file" that links the name of the primary texture map in the 
geometry file to the name of a material - which in turn pulls in a 
vertex and a fragment shader, and a bunch of uniform variables...which 
can (of course) be texture maps.   So in practical use - you sit in your 
modeller - you apply a simple brick texture  ("textures/brick.png" say) 
and the loader sees that a particular polygon mesh uses that map - 
strips the directory and suffix from the filename (so now, we have 
"brick") - then searches the material file for a material with that 
name.  The material "brick" may or may not refer to the file 
"textures/brick.png" - that's up to you.  For convenience, if that 
material is not found you get a warning message and the "default" 
material is used instead.  If the chosen material (either "default" or 
"brick" in this case) exists but has no uniform variable that refers to 
a texture map (as is the case with "default"), then the system will 
automatically generate a uniform called "texture" that is set to 
"<your_texture_path>/<materialname>.rgb".   This mechanism allows you to 
use a basic default material without having to go and type in a material 
for every single texture type you use.

I expect many of the other loaders we use will want to use a similar 
mechanism.   The AC3D loader (for example) only knows about one texture 
map and a set of diffuse/spec/emiss/ambient colours.  It's impossible to 
specify shaders or multiple textures or whatever...so you model "brick" 
inside AC3D and you tell PLIB what "brick" looks like by giving me 
shaders, multiple textures, a normal map, cube-mapped environmental 
reflections....whatever.

Shaders are written in GLSL...but it wouldn't be hard to add Cg if 
anyone really wanted to.

 > - what do you think about Collada? If the new plib-XML isn't far from 
it why
> don't bet on Collada support from the beginning?
>   
I don't want to write my own Collada loader because it's too phreaking 
complicated - but if you want to do it - or if you want to write the 
plugin-stub for Collada and depend on an external library - feel free to 
do that.   I don't need it - and I don't generally write what I don't need.

Past experience says that these standard formats typically have a whole 
lot of features that I don't want to implement - and I have implemented 
a whole lot of features that they don't support....so it's never a good 
match.   Implementing ALL of the Collada spec would be exceedingly 
difficult - and when you don't implement all of it you find that half of 
the models out there won't load.

[Plib-devel] R: Release 1.8.5....and a glimpse of the future.

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

Steve,

As a Plib/SSG enthusiast I'm happy to hear such very good news from you for
the next-gen Plib.
The revamp you have depicted was infact really needed.

I'd like you could spend some more words on formats:

- will the SSG native binary dump still live? It's very efficient in loading
and I'd dislike for it to "go away";

- what about your position to avoid dependencies on external libraries? I
refer in particular to 3D data loaders from other formats. IMHO we should
open to specialized libraries for reliably loading e.g. VRML2/X3D (CyberX3D)
or 3DS (lib3ds), then walking their scene graph to translate it into
SSG-equivalent.

- the new XML-based one: is it a scene format? Does it point to (reference)
external files for large data sets, or will it include the actual geometry
in it? Or both?

- what do you think about Collada? If the new plib-XML isn't far from it why
don't bet on Collada support from the beginning?

Thanks againg for your valuable commitment to Plib,

Paolo Leoncini


> -----Messaggio originale-----
> Da: pli...@li... 
> [mailto:pli...@li...] Per conto 
> di Steve Baker
> Inviato: venerdì 7 marzo 2008 2.28
> A: PLIB Developers
> Oggetto: [Plib-devel] Release 1.8.5....and a glimpse of the future.
> 
> I guess I have no excuses left then!
> 
> I'll get to it at the weekend.
> 
> Actually, I've been doing work on "Son of PLIB" in odd idle 
> moments - I have a version that'll work with OpenGL 3.0 (or 
> whatever they are going to call it) that uses 100% shaders - 
> no standard pipeline at all.  As with OpenGL, my main effort 
> is to slim-down, simplify and provide more flexibility for 
> data formats and plugins for algorithmic flexibility.
> 
> But I'm not making any effort on backwards, forwards or 
> sideways compatibility...anything I need to change, or merely 
> feel like changing
> - I'll change.
> 
> Multitextures and decent multipass, bucket sorting and a 
> 'posteffects' 
> mechanism are all there - plus Java scripting and XML-based 
> configuration files.  Bulk vertex data can have 
> user-specified data types and you can add your own per-vertex 
> attributes to feed data to your shaders - so stuff like 
> normal-mapping is now easy.
> 
> But I'm developing it for a rather specific purpose and I 
> don't plan to do the work collaboratively because I have a 
> clear vision of what I need and I don't want to cloud it with 
> other people's needs until I'm ready - I will, however 
> OpenSource it under LGPL when it's done.
> 
> The myriad of SSG node types has been slimmed down to just 
> two - "Leaf" 
> and "Branch" - the Leaf will hide the data transfer 
> mechanisms to the GPU and the Branch will use plugins that 
> operate at cull-time to simulate the old ssgTransform, 
> ssgRangeSelector, etc.  ssgTexture gets some love and care so 
> it can do 1D, 2D, 3D and Cube maps - ssgState becomes a 
> container for ssgShaderPair and a bunch of ssgUniform 
> variables that can (of course) be bool, int, half-float or 
> float...or ssgTexture handles - all of the messy lazy state 
> switching code 'goes 
> away' (thank God for that!).   The SG math library supports 
> every data 
> type from char to short to int to halffloat to float to 
> double with almost all of the usual functions - and to keep 
> it all up to date, it's mostly auto-generated code.
> 
> What mostly needs to be done is to have the PUI library "go 
> away" and be implemented as a layer on top of SSG - and the 
> SL audio code "go away" 
> and be replaced with an OpenAL wrapper...I'll probably 
> release what I have before I attack those things.  Sadly, 
> none of the file loaders will survive intact and it's too 
> much work to rewrite them all.  My son is Blender fanatic 
> (<sigh>) and I have a blender plugin that writes files in a 
> ".plib" format (which is XML).
> 
> Anyway - this is off in the future somewhere - I'm not making 
> promises or commitments.
> 
> 
> Jan Reucker wrote:
> > Hello,
> >
> > here's a patch to take away the last excuses not to release 
> PLIB-1.8.5.
> > It sets the version information in configure.in and ul.h to 
> 1.8.5 and
> > contains all necessary changes to the web site.
> >
> > Needless to say that PLIB SVN passes "make distcheck" 
> without errors.
> > And there hasn't been a bug report or submitted patch for a 
> while, so
> > a new release is overdue.
> >
> > What's left to do (from my point of view):
> >
> > - Someone with SVN access should apply the patch.
> > - Someone has to run "make dist" to create the 1.8.5 tarball
> > - Someone with SSH and SVN access must update the web site
> >   (emulate the transferCvs2WebSite script)
> > - Someone with file release privileges must upload the tarball
> >   to SF.net
> > - "make distcheck" fails for the examples, at least on my PC,
> >   but I don't know how to fix it.
> >
> > Did I forget something?
> >
> > Kind regards,
> > Jan R.
> >
> >   
> > 
> --------------------------------------------------------------
> ----------
> >
> > 
> --------------------------------------------------------------
> -----------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > 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 2008.
> 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] Release 1.8.5....and a glimpse of the future.

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

John F. Fay wrote:
> Alas!  Poor PUI.  I knew him, Horatio.
>
> I really don't have much to complain about.  My PUI application has been 
> retired for a couple of years now and I've been given new projects at work. 
>  But I hate to let go of things that I have worked on.
>   
The trouble is that PUI has grown from a very minimal way to toss a 
handful of buttons onto the bottom of a screen full of 3D graphics into 
a fully grown scene-graph API - it has branch nodes and leaf nodes and 
traversals and culling, rendering states, geometry - and that's exactly 
what SSG has to have.  Layering PUI on top of SSG makes sense because 
they can share code and PUI can have textured, lit, bumpmapped, 
animated, glowing buttons...who knows what?

The whole of PUI is based on the OpenGL 1.x 'standard pipeline' API and 
that's going away (or at least it's not going to be The One True Way To 
Do Graphics).  So in the next year or two we'll really be forced to 
either rewrite a chunk of PUI or see it go utterly obsolete.  At the 
very least the bottom end renderer has to change to use blocks of vertex 
data and shaders.   The PUI API is particularly ill-suited to that 
because it doesn't use the concept of "rendering state" - it just has a 
bunch of ad-hoc data scattered throughout the scene graph.   It 
generates geometry on-the-fly from the sizes of the widgets - but what 
we really need is precalculated vertex tables at each node.  That means 
it has to know how to build and maintain those things - shared states 
means ref-counting and such.  Shaders need to be compiled and have 
mechanisms to pass uniform data to them.  None of that stuff exists in PUI.

However, the new, improved SSG will be PERFECT for that stuff.  If it 
has 'plugin' capability as I'm planning - then PUI simply builds an SSG 
scene graph and plugs in it's own culling mechanisms.   SSG provides the 
geometry maintenance, shader services, etc.  It's a good match.

I don't think it'll suffer too badly in the transition...but I don't 
plan on ripping into PUI for a while - I've got to get the new SSG 
working well first.

Re: [Plib-devel] Release 1.8.5....and a glimpse of the future.

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

Alas!  Poor PUI.  I knew him, Horatio.

I really don't have much to complain about.  My PUI application has been 
retired for a couple of years now and I've been given new projects at work. 
 But I hate to let go of things that I have worked on.

	- John


-----Original Message-----
From:	Steve Baker
Sent:	Thursday, March 06, 2008 7:28 PM
To:	PLIB Developers
Subject:	[Plib-devel] Release 1.8.5....and a glimpse of the future.


...

What mostly needs to be done is to have the PUI library "go away" ...

[Plib-devel] Release 1.8.5....and a glimpse of the future.

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

I guess I have no excuses left then!

I'll get to it at the weekend.

Actually, I've been doing work on "Son of PLIB" in odd idle moments - I 
have a version that'll work with OpenGL 3.0 (or whatever they are going 
to call it) that uses 100% shaders - no standard pipeline at all.  As 
with OpenGL, my main effort is to slim-down, simplify and provide more 
flexibility for data formats and plugins for algorithmic flexibility.

But I'm not making any effort on backwards, forwards or sideways 
compatibility...anything I need to change, or merely feel like changing 
- I'll change.

Multitextures and decent multipass, bucket sorting and a 'posteffects' 
mechanism are all there - plus Java scripting and XML-based 
configuration files.  Bulk vertex data can have user-specified data 
types and you can add your own per-vertex attributes to feed data to 
your shaders - so stuff like normal-mapping is now easy.

But I'm developing it for a rather specific purpose and I don't plan to 
do the work collaboratively because I have a clear vision of what I need 
and I don't want to cloud it with other people's needs until I'm ready - 
I will, however OpenSource it under LGPL when it's done.

The myriad of SSG node types has been slimmed down to just two - "Leaf" 
and "Branch" - the Leaf will hide the data transfer mechanisms to the 
GPU and the Branch will use plugins that operate at cull-time to 
simulate the old ssgTransform, ssgRangeSelector, etc.  ssgTexture gets 
some love and care so it can do 1D, 2D, 3D and Cube maps - ssgState 
becomes a container for ssgShaderPair and a bunch of ssgUniform 
variables that can (of course) be bool, int, half-float or float...or 
ssgTexture handles - all of the messy lazy state switching code 'goes 
away' (thank God for that!).   The SG math library supports every data 
type from char to short to int to halffloat to float to double with 
almost all of the usual functions - and to keep it all up to date, it's 
mostly auto-generated code.

What mostly needs to be done is to have the PUI library "go away" and be 
implemented as a layer on top of SSG - and the SL audio code "go away" 
and be replaced with an OpenAL wrapper...I'll probably release what I 
have before I attack those things.  Sadly, none of the file loaders will 
survive intact and it's too much work to rewrite them all.  My son is 
Blender fanatic (<sigh>) and I have a blender plugin that writes files 
in a ".plib" format (which is XML).

Anyway - this is off in the future somewhere - I'm not making promises 
or commitments.


Jan Reucker wrote:
> Hello,
>
> here's a patch to take away the last excuses not to release PLIB-1.8.5.
> It sets the version information in configure.in and ul.h to 1.8.5 and
> contains all necessary changes to the web site.
>
> Needless to say that PLIB SVN passes "make distcheck" without errors.
> And there hasn't been a bug report or submitted patch for a while, so
> a new release is overdue.
>
> What's left to do (from my point of view):
>
> - Someone with SVN access should apply the patch.
> - Someone has to run "make dist" to create the 1.8.5 tarball
> - Someone with SSH and SVN access must update the web site
>   (emulate the transferCvs2WebSite script)
> - Someone with file release privileges must upload the tarball
>   to SF.net
> - "make distcheck" fails for the examples, at least on my PC,
>   but I don't know how to fix it.
>
> Did I forget something?
>
> Kind regards,
> Jan R.
>
>   
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> 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] Next try: Release 1.8.5

[Jan R. <slo...@gm...>]

Hello,

here's a patch to take away the last excuses not to release PLIB-1.8.5.
It sets the version information in configure.in and ul.h to 1.8.5 and
contains all necessary changes to the web site.

Needless to say that PLIB SVN passes "make distcheck" without errors.
And there hasn't been a bug report or submitted patch for a while, so
a new release is overdue.

What's left to do (from my point of view):

- Someone with SVN access should apply the patch.
- Someone has to run "make dist" to create the 1.8.5 tarball
- Someone with SSH and SVN access must update the web site
  (emulate the transferCvs2WebSite script)
- Someone with file release privileges must upload the tarball
  to SF.net
- "make distcheck" fails for the examples, at least on my PC,
  but I don't know how to fix it.

Did I forget something?

Kind regards,
Jan R.

-- 
Jan Reucker
email: jan dot reucker at web dot de
web:   http://www.reucker-online.de

Re: [Plib-devel] Patch for puSDL.h

[Jan R. <slo...@gm...>]

Am Sun, 18 Nov 2007 15:46:59 -0600 schrieb "John F. Fay" <joh...@cy...>:

> Done.

Thanks a lot!

Now what can we do to accelerate a new PLIB release? Can we take anything
off Steve's shoulders, like, say, write up the release notes?

Kind regards,
Jan R.

-- 
Jan Reucker
email: jan dot reucker at web dot de
web:   http://www.reucker-online.de

Re: [Plib-devel] Patch for puSDL.h

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

Done.

	- John F. Fay

-----Original Message-----
From:	Jan Reucker 
Sent:	Sunday, November 18, 2007 2:23 PM
To:	pli...@li...
Subject:	[Plib-devel] Patch for puSDL.h

Hello,

I just noticed a small inconvenience in puSDL.h: this file includes
<SDL/SDL.h> instead of "SDL.h" (which is recommended by the libSDL FAQ,
see http://www.libsdl.org/faq.php?action=listentries&category=2#19 ).

This causes problems if the path to the SDL directory is not contained
in the preprocessor's include path. For example, on Windows/MinGW, 
/usr/include is not by default included in the search patch, and
`sdl-config --cflags` will report "/usr/include/SDL", so including
<SDL/SDL.h> will fail. Same applies if you keep a development copy
of SDL in some non-standard directory.

The attached trivial patch fixes this issue.

Kind regards,
Jan R.

-- 
Jan Reucker
email: jan dot reucker at web dot de
web:   http://www.reucker-online.de
 << File: puSDL_h_include_patch.diff >>  << File: ATT00005.txt >>  << File: ATT00006.txt >> 

[Plib-devel] Patch for puSDL.h

[Jan R. <slo...@gm...>]

Hello,

I just noticed a small inconvenience in puSDL.h: this file includes
<SDL/SDL.h> instead of "SDL.h" (which is recommended by the libSDL FAQ,
see http://www.libsdl.org/faq.php?action=listentries&category=2#19 ).

This causes problems if the path to the SDL directory is not contained
in the preprocessor's include path. For example, on Windows/MinGW, 
/usr/include is not by default included in the search patch, and
`sdl-config --cflags` will report "/usr/include/SDL", so including
<SDL/SDL.h> will fail. Same applies if you keep a development copy
of SDL in some non-standard directory.

The attached trivial patch fixes this issue.

Kind regards,
Jan R.

-- 
Jan Reucker
email: jan dot reucker at web dot de
web:   http://www.reucker-online.de

Re: [Plib-devel] Converting unsupported texture image file formatson the fly

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

Aaaarrrgh!  It's probably called "stat" in *nix.

I'll get onto it tonight if nobody else gets to it first.

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

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of Melchior
FRANZ
Sent: Tuesday, October 02, 2007 2:00 AM
To: pli...@li...
Subject: Re: [Plib-devel] Converting unsupported texture image file
formatson the fly

* Melchior FRANZ -- Tuesday 02 October 2007:
> * John F. Fay -- Tuesday 02 October 2007:
> > Done ... see change set 2127.
>=20
> ssgLoadTexture.cxx: In function 'int fileMTimeCmp(const char*, const
char*)':
> ssgLoadTexture.cxx:243: error: aggregate '_stat buffer_in' has
incomplete type and cannot be defined
> ssgLoadTexture.cxx:243: error: aggregate '_stat buffer_out' has
incomplete type and cannot be defined
>=20
> What's _stat?!

OK, make it stat. _stat is apparently the braindead MS Windows
variant.


--- src/ssg/ssgLoadTexture.cxx  (revision 2127)
+++ src/ssg/ssgLoadTexture.cxx  (working copy)
@@ -239,10 +240,10 @@
 //  1: fname_input older than fname_output
 //  0: stat error
 {
-  struct _stat buffer_in, buffer_out;
 #ifdef UL_WIN32
 #define stat _stat
 #endif
+  struct stat buffer_in, buffer_out;
   if ( stat( fname_input, &buffer_in ) =3D=3D 0 && stat( fname_output,
&buffer_out ) =3D=3D 0 )
     return buffer_in.st_mtime > buffer_out.st_mtime ? -1 : 1;
   else


m.

------------------------------------------------------------------------
-
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] R: Converting unsupported texture image file formatson the fly

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

> -----Messaggio originale-----
> Da: pli...@li...=20
> [mailto:pli...@li...] Per conto=20
> di Melchior FRANZ
> Inviato: marted=EC 2 ottobre 2007 8.57
> A: pli...@li...
> Oggetto: Re: [Plib-devel] Converting unsupported texture=20
> image file formatson the fly
>=20
> * John F. Fay -- Tuesday 02 October 2007:
> > Done ... see change set 2127.
>=20
> ssgLoadTexture.cxx: In function 'int fileMTimeCmp(const=20
> char*, const char*)':
> ssgLoadTexture.cxx:243: error: aggregate '_stat buffer_in'=20
> has incomplete type and cannot be defined
> ssgLoadTexture.cxx:243: error: aggregate '_stat buffer_out'=20
> has incomplete type and cannot be defined
>=20
> What's _stat?!

Probably it's the stat structure if it exists under 'NIX - try to move =
the
#ifdef UL_WIN32 block before the variable declaration so that both the =
_stat
variable declaration and the _stat function name get converted.

> m.

Many thanks for the check. Greetings,

Paolo


> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Microsoft Defy all=20
> 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
>=20

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

[Melchior F. <mf...@us...>]

* Melchior FRANZ -- Tuesday 02 October 2007:
> * John F. Fay -- Tuesday 02 October 2007:
> > Done ... see change set 2127.
> 
> ssgLoadTexture.cxx: In function 'int fileMTimeCmp(const char*, const char*)':
> ssgLoadTexture.cxx:243: error: aggregate '_stat buffer_in' has incomplete type and cannot be defined
> ssgLoadTexture.cxx:243: error: aggregate '_stat buffer_out' has incomplete type and cannot be defined
> 
> What's _stat?!

OK, make it stat. _stat is apparently the braindead MS Windows
variant.


--- src/ssg/ssgLoadTexture.cxx  (revision 2127)
+++ src/ssg/ssgLoadTexture.cxx  (working copy)
@@ -239,10 +240,10 @@
 //  1: fname_input older than fname_output
 //  0: stat error
 {
-  struct _stat buffer_in, buffer_out;
 #ifdef UL_WIN32
 #define stat _stat
 #endif
+  struct stat buffer_in, buffer_out;
   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


m.

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

[Melchior F. <mf...@us...>]

* John F. Fay -- Tuesday 02 October 2007:
> Done ... see change set 2127.

ssgLoadTexture.cxx: In function 'int fileMTimeCmp(const char*, const char*)':
ssgLoadTexture.cxx:243: error: aggregate '_stat buffer_in' has incomplete type and cannot be defined
ssgLoadTexture.cxx:243: error: aggregate '_stat buffer_out' has incomplete type and cannot be defined

What's _stat?!

m.

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

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

Done ... see change set 2127.

	- John


-----Original Message-----
From:	Paolo Leoncini 
Sent:	Monday, October 01, 2007 7:54 AM
To:	'PLIB Developers'
Subject:	[Plib-devel] Converting unsupported texture image file formats on	the fly

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


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

Wolfram,

	You're absolutely right about making the default setting to be "true". 
 I'm making the change now.

	You're also right about getting out a new version.  I can't do that, 
unfortunately, and Steve is apparently quite busy right now.  So while we 
are waiting for him, I am doing something about the backlog of bug reports 
and feature requests.

	Does anybody have a good test case for the new texture loading code?

		- John


-----Original Message-----
From:	Wolfram Kuss
Sent:	Monday, October 01, 2007 3:50 AM
To:	PLIB Developers
Subject:	Re: [Plib-devel] No longer blocking non power-of-two textures

You wrote:

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

All in all a good request, but it would be better to use
"bool freeData = true"
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.

-------------------------------------------------------------------------
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] Converting unsupported texture image file formats on the fly

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

Looks good.
=46ixing those two issues would be a good thing.
Is it allowed that fname_input is a *.rgb file (no conversion needed)
and if so, does your code handle it correctly?

Bye bye,
Wolfram.