Thread: [Plib-devel] PLIB 'Neat stuff' library
Brought to you by:
sjbaker
Menu
▾
▴
plib-devel
|
From: Vallevand, M. K <Mar...@UN...> - 2000-07-25 01:45:55
|
Steve, are you planning on collecting some neat stuff into PLIB? An auxiliary library of stuff. I have a few small, useful classes that someone else might find handy. The auxiliary library would be a good places to put collections of textures, wav files, mod files and models. Regards. Mark K Vallevand ma...@rs... Never try and teach a pig to sing: it's a waste of time, and it annoys the pig. |
|
From: Joel U. <joe...@ya...> - 2000-07-26 07:04:43
|
"Vallevand, Mark K" wrote: > > Steve, are you planning on collecting some neat stuff into PLIB? An > auxiliary library of stuff. I have a few small, useful classes that > someone else might find handy. The auxiliary library would be a good > places to put collections of textures, wav files, mod files and models. When you get back, Steve, I wonder about something like this for the more complex primtives for PPE - sphere/cylinder that sort of thing. I think that they might be better in an auxillary library to ssg, which builds onto the features of ssg. Just a suggestion to save all this continual adding to ssg simply for PPE. Bye - Joel. |
|
From: Steve B. <sjb...@ai...> - 2000-07-29 22:30:02
|
Joel Utting wrote:
>
> "Vallevand, Mark K" wrote:
> >
> > Steve, are you planning on collecting some neat stuff into PLIB? An
> > auxiliary library of stuff. I have a few small, useful classes that
> > someone else might find handy. The auxiliary library would be a good
> > places to put collections of textures, wav files, mod files and models.
>
> When you get back, Steve,
I'm back. I have 1900 emails in my home account - and I'm scared to
look into my work account! SigGraph was *exhausting* - I may sleep
for a couple of days.
*LOTS* of great new ideas to try though. I want to get into texture
synthesis from image samples and stuff...I may also have a new game
project to start - I'm VERY excited about that because it's going to
solve the artwork problem...but it's not firmly agreed yet and I can't
say more.
> I wonder about something like this for the
> more complex primtives for PPE - sphere/cylinder that sort of thing. I
> think that they might be better in an auxillary library to ssg, which
> builds onto the features of ssg.
>
> Just a suggestion to save all this continual adding to ssg simply for
> PPE.
Yes. I agree 100%. PPE (NIV100) features to support higher level
primitives so that we can edit POV, VRML, etc without destroying those
primitives will be very important - but the classes that we need to
derive in order to do that won't be useful to the usual audience of
SSG users - so an Aux library for SSG is important.
One nasty issue that raises is how you'd load (say) VRML files
without linking in the Aux library if your game didn't WANT to
see spheres and cubes and things as anything other than
a bunch of tristrips...Hmmmmm.
--
Steve Baker HomeEmail: <sjb...@ai...>
WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
|
|
From: Joel U. <joe...@ya...> - 2000-07-30 06:05:52
|
Steve Baker wrote: > > Joel Utting wrote: > > > > "Vallevand, Mark K" wrote: > > > > > > Steve, are you planning on collecting some neat stuff into PLIB? An > > > auxiliary library of stuff. I have a few small, useful classes that > > > someone else might find handy. The auxiliary library would be a good > > > places to put collections of textures, wav files, mod files and models. > > > > When you get back, Steve, > > I'm back. I have 1900 emails in my home account - and I'm scared to > look into my work account! SigGraph was *exhausting* - I may sleep > for a couple of days. Ha ! I thought my email was bad... > *LOTS* of great new ideas to try though. I want to get into texture > synthesis from image samples and stuff...I may also have a new game > project to start - I'm VERY excited about that because it's going to > solve the artwork problem...but it's not firmly agreed yet and I can't > say more. Sounds interesting...but I can't comment more... > > > I wonder about something like this for the > > more complex primtives for PPE - sphere/cylinder that sort of thing. I > > think that they might be better in an auxillary library to ssg, which > > builds onto the features of ssg. > > > > Just a suggestion to save all this continual adding to ssg simply for > > PPE. > > Yes. I agree 100%. PPE (NIV100) features to support higher level > primitives so that we can edit POV, VRML, etc without destroying those > primitives will be very important - but the classes that we need to > derive in order to do that won't be useful to the usual audience of > SSG users - so an Aux library for SSG is important. Great ! > One nasty issue that raises is how you'd load (say) VRML files > without linking in the Aux library if your game didn't WANT to > see spheres and cubes and things as anything other than > a bunch of tristrips...Hmmmmm. This wouldn't be a problem, would it - if its your game you'd simply use PPE to convert those primitives to tristrips before putting the models into the game. The only thing is if a game wanted to load random models from the users hard disk - but surely you'd only do this in some kind of editor anyway (?) not in an actual finished game. In either case if you wanted to use the more advanced features of VRML and SSG you could include the aux library anyway. Bye - Joel. |
|
From: <Va...@t-...> - 2000-07-30 12:16:56
|
Steve Baker wrote: > > One nasty issue that raises is how you'd load (say) VRML files > without linking in the Aux library if your game didn't WANT to > see spheres and cubes and things as anything other than > a bunch of tristrips...Hmmmmm. All 'complex primitives' like spheres and cubes need a way to convert themselfs to tristrips. First they need it to be able to be displayed and secondly anyone who doesn't like these primitves in his scenegraph would convert them and dump them. So anyone who needs to be able to read VRLM needs to use the Aux library - and if it is only for converting the primitives ASAP. I don't think that that limitation is a too big. Esp. as you could convert the models to something else before loading them if you don't like the bloat of an Aux library. CU, Christian |
|
From: Steve B. <sjb...@ai...> - 2000-07-31 04:58:13
|
Christian Mayer wrote:
>
> Steve Baker wrote:
> >
> > One nasty issue that raises is how you'd load (say) VRML files
> > without linking in the Aux library if your game didn't WANT to
> > see spheres and cubes and things as anything other than
> > a bunch of tristrips...Hmmmmm.
>
> All 'complex primitives' like spheres and cubes need a way to convert
> themselfs to tristrips. First they need it to be able to be displayed
> and secondly anyone who doesn't like these primitves in his scenegraph
> would convert them and dump them.
We talked about this at length on the PPE list a while back.
I think that what we should do is to derive a class from ssgRangeSelector
to implement these objects.
As the file is loaded, it could have various polygonal versions created
as leaf nodes by default - at various levels of detail. We might perhaps
want some global 'error metric' control for the creation of those things...
but perhaps not in the first version.
Thus, programs that don't know about VRML would be able to traverse
the scene graph without needing to know about spheres and cones and
such like. Programs that do care can take appropriate action.
When the model is written out, a VRML or POV file writer need
only to look at the type of that node to realise that it shouldn't write
out the underlying geometry - but instead to emit a simple sphere, cone,
etc. Writers for formats like AC3D that don't have higher level primitives
would simply write out the underlying geometry in the normal way - which
is the best you can do under the circumstances.
The bottom line is that a typical game can still read VRML files without
having to worry about high level primitives - there is no realtime
penalty to using them - and yet programs like modellers can still identify
those nodes and do more sophisticated things.
> So anyone who needs to be able to read VRLM needs to use the Aux library
> - and if it is only for converting the primitives ASAP.
I suppose so.
> I don't think that that limitation is a too big. Esp. as you could
> convert the models to something else before loading them if you don't
> like the bloat of an Aux library.
Yes.
--
Steve Baker HomeEmail: <sjb...@ai...>
WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
|
|
From: Steve B. <sjb...@ai...> - 2000-07-29 22:29:56
|
"Vallevand, Mark K" wrote:
>
> Steve, are you planning on collecting some neat stuff into PLIB? An
> auxiliary library of stuff. I have a few small, useful classes that
> someone else might find handy.
Yes. I certainly plan to do that...and quite soon too.
Curt's 'instant sky model' code is an excellent example (with a couple
of function calls, you get a properly updating sky with clouds, stars,
sun, moon, planets, etc - with a little more effort, you get correct
time-of-day rendering - and it even reproduces eclipses and such
automatically).
I haven't quite decided on the directory layout yet. Should there
be an 'aux' library for each PLIB component (Like 'libGLU': SSGU, PUIU,
SLU, etc) or one gigantic utility library (PLIBU)? Should each little
suite of stuff be in a separate lib (SSG_sky, SSG_fractals, etc) ?
Should there be one directory for all utilities or a separate directory
under each of the existing library levels? Do we want to distribute
all that stuff along with PLIB or as a separate download?
> The auxiliary library would be a good
> places to put collections of textures, wav files, mod files and models.
Hmmm - I think that 'Artwork' belongs somewhere else. I'm greatly
enthusiastic about such collections since good freeware artwork is hard
to find - but I just don't think it belongs with PLIB since other packages
like CrystalSpace can also make use of it.
Software that creates textures, etc would be appropriate though - if
you wrote (say) an ssgTexture derived class that made fractal textures
or Perlin noise or something - then that would be a useful thing to add.
There are lots of existing repositories of free and semi-free art out
there. Check out (for example) 3DCafe. Perhaps contributing this stuff
there makes more sense.
It's awfully tempting to make "yet another texture repository" though.
If you want to do this, getting another sourceforge account to dump it
all into would be very easy...and I'd certainly want to link to it from
the PLIB site.
Too many of the existing repositories have no information about the
license under which these objects are distributed. We need a place
where it's clearly stated that ALL content is under (say) the Xfree
license or something.
--
Steve Baker HomeEmail: <sjb...@ai...>
WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
|
|
From: Dave M. <dp...@ef...> - 2000-07-29 22:49:58
|
> > Steve, are you planning on collecting some neat stuff into PLIB? An > > auxiliary library of stuff. I have a few small, useful classes that > > someone else might find handy. > > Yes. I certainly plan to do that...and quite soon too. > <snip> > I haven't quite decided on the directory layout yet. Should there > be an 'aux' library for each PLIB component (Like 'libGLU': SSGU, PUIU, > SLU, etc) or one gigantic utility library (PLIBU)? Should each little > suite of stuff be in a separate lib (SSG_sky, SSG_fractals, etc) ? > Should there be one directory for all utilities or a separate directory > under each of the existing library levels? Do we want to distribute > all that stuff along with PLIB or as a separate download? > i kind of like how SDL manages games, apps, demos, and libraries that have been created around their *core* library. they have each in a seperate download. this keeps the *core* plib very low level and clean. http://www.libsdl.org/libraries.html http://www.libsdl.org/demos.html http://www.libsdl.org/apps.html http://www.libsdl.org/games.html right now, http://plib.sourceforge.net has a few links to the more prominent projects that use plib. it would be interesting and useful to see more in a format like http://www.libsdl.org/games.html. i would certainly be interested in adding my own project there. as for directory structure in cvs, i think the following might work: plib - core library apps/ssg_viewer apps/ssg_converter apps/mod_player demos/tux_example demos/fnt_example libs/ssg_sky libs/keyflier libs/particle_engine other, *large* projects like ppe and tux_kart, of course, would have their own cvs source repositories like now. -- Dave McClurg |
|
From: Steve B. <sjb...@ai...> - 2000-07-30 04:08:32
|
Dave McClurg wrote: > i kind of like how SDL manages games, apps, demos, and libraries that have > been created around their *core* library. they have each in a seperate > download. this keeps the *core* plib very low level and clean. > > http://www.libsdl.org/libraries.html > http://www.libsdl.org/demos.html > http://www.libsdl.org/apps.html > http://www.libsdl.org/games.html Well - yes - but I find SDL to be one of the WORST libraries to keep track of. I'm forever trying to build applications that demand SDLmixer version x.y.z and SDL version p.q.r - I just can't keep track of all the minor revision numbers of all the stoopid little components - some of which in turn only work with some specific version of the base package. There have been MANY SDL-based packages that I just can't keep running together because they all demand mutually exclusive versions of one sub-library or another. SDL is a nice enough package - but the way it's distributed SUCKS - IMHO. I just wish they'd release ONE bundle with everything self-consistantly up to date - even if that means that SDLMixer 1.2.3 is actually identical to 1.3.0. The thing that I like about our present approach with PLIB is that all the component libraries are released together - you install it and you have everything you need at that same revision. > right now, http://plib.sourceforge.net has a few links to the more > prominent projects that use plib. it would be interesting and useful > to see more in a format like http://www.libsdl.org/games.html. i > would certainly be interested in adding my own project there. Hmmm - cute. If you'd like to me to add something you are working on - I'd be very happy to do so. I'd like a small logo/icon to use with it also. We should certainly think about doing something like the SDL list though. > as for directory structure in cvs, i think the following might work: > plib - core library > apps/ssg_viewer > apps/ssg_converter > apps/mod_player > demos/tux_example > demos/fnt_example > libs/ssg_sky > libs/keyflier > libs/particle_engine Yes - although changing the present structure is a pain because CVS won't let you delete directories. Hence we are somewhat stuck with 'src' for the PLIB sources and 'examples' and 'doc' for the examples and documentation. I don't have a problem with adding 'apps' and 'auxlibs' for the applications and auxiliary libraries. Perhaps 'tools' would be better than 'apps' if we are talking about viewers, players, convertors and such like. When we come to make a release though - I'd like to bundle the aux libraries in with the main PLIB libraries so that people who just want to install PLIB in order to get a game running don't have to download and install a dozen separate components. Minimising dependencies is VERY important. Examples and tools/applications that are not going to be needed by 'Joe Public' should be distributed separately to keep the file size to a minimum though. Only developers ever need those things - and developers are increasingly becoming a minority as PLIB gets more popular. > other, *large* projects like ppe and tux_kart, of course, would have > their own cvs source repositories like now. CERTAINLY! -- Steve Baker HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://web2.airmail.net/sjbaker1 Projects : http://plib.sourceforge.net http://tuxaqfh.sourceforge.net http://tuxkart.sourceforge.net http://prettypoly.sourceforge.net |
|
From: Dave M. <dp...@ef...> - 2000-07-30 05:41:48
|
> Yes - although changing the present structure is a pain because CVS won't > let you delete directories. > *pain* is the right word. i feel like we must be missing something. do other projects just *live* with this problem as well? or can we just email somebody at sourceforge and get him to take care of it > Hence we are somewhat stuck with 'src' for the PLIB sources and > 'examples' and > 'doc' for the examples and documentation. I don't have a problem with > adding 'apps' and 'auxlibs' for the applications and auxiliary libraries. > > Perhaps 'tools' would be better than 'apps' if we are talking > about viewers, > players, convertors and such like. > ok. so we add 'tools' and 'auxlibs'. auxlibs/ssg_sky auxlibs/ssg_particles tools/ssg_viewer etc... just don't let me add the folder in windoze. :) lol > When we come to make a release though - I'd like to bundle the > aux libraries > in with the main PLIB libraries so that people who just want to > install PLIB > in order to get a game running don't have to download and install a dozen > separate components. > > Minimising dependencies is VERY important. > makes sense. > Examples and tools/applications that are not going to be needed > by 'Joe Public' > should be distributed separately to keep the file size to a > minimum though. Only > developers ever need those things - and developers are > increasingly becoming a > minority as PLIB gets more popular. > really? the plib-users mailing list doesn't get much traffic --Dave |
|
From: Steve B. <sjb...@ai...> - 2000-07-30 06:17:35
|
Dave McClurg wrote:
>
> > Yes - although changing the present structure is a pain because CVS won't
> > let you delete directories.
> >
>
> *pain* is the right word. i feel like we must be missing something.
> do other projects just *live* with this problem as well?
> or can we just email somebody at sourceforge and get him to take care of it
It's a *WELL* known problem it seems.
All sourceforge offer as help is:
1) Use the -P (IIRC) option to not create directories on your local
machine if they are empty - hence you don't have to see the redundant
directories.
2) Periodically wipe out the entire CVS directory and recreate it.
This erases all the dead directories - but also wipes out all your
accumulated revision history.
> ok. so we add 'tools' and 'auxlibs'.
>
> auxlibs/ssg_sky
> auxlibs/ssg_particles
> tools/ssg_viewer
> etc...
>
> just don't let me add the folder in windoze. :) lol
Yep. I've just committed those :-)
Do you actually have specific tools and auxlibs that you want
to commit? If so, I'd better create the directories for
those too.
> > Examples and tools/applications that are not going to be needed
> > by 'Joe Public'
> > should be distributed separately to keep the file size to a
> > minimum though. Only
> > developers ever need those things - and developers are
> > increasingly becoming a
> > minority as PLIB gets more popular.
> >
>
> really? the plib-users mailing list doesn't get much traffic
There are more users - and about the same number of developers - so
the proportion of users to developers is certainly increasing.
The lack of traffic on plib-users could just mean that people aren't
having many problems with it...but I suspect the reality is that
application developers are mistakenly using the PLIB-devel list - when
that's really intended for developers *OF* PLIB rather than developers
*USING* PLIB.
Application developers should really be considered *users* of PLIB
and hence post to plib-users.
Anyway - all the traffic is low (except for the odd mailbombing :-)
so I don't really care.
--
Steve Baker HomeEmail: <sjb...@ai...>
WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
|
|
From: Dave M. <dp...@ef...> - 2000-07-30 06:46:49
|
> > ok. so we add 'tools' and 'auxlibs'. > > Yep. I've just committed those :-) > thanks! > Do you actually have specific tools and auxlibs that you want > to commit? If so, I'd better create the directories for > those too. > not yet. i'm cooking a few things and i'll ask for help when i need new directories. any idea when we might see the sky code in auxlibs? --Dave |
|
From: Steve B. <sjb...@ai...> - 2000-07-30 07:13:23
|
Dave McClurg wrote:
> any idea when we might see the sky code in auxlibs?
Well, Curt's code is in his own SimGear package - and still
needs to have a little pruned out (or faked in) to make it
work with non-SimGear packages (We certainly don't want to
add a dependancy on SimGear withing PLIB). On the other hand,
having removed that stuff, the new ssgSky would be no use to
programs needing the sophisticated ephemeris stuff - FlightGear
for example.
That implies putting a fork in Curt's sky code development...
which is a really nasty thing to do - two completely separate
copies of the code being maintained and developed - FlightGear
users having two copies of essentially the same code lying around...
YUK! I can't help feeling that there must be a way to resolve that -
but until I've had a chance to rummage around in that stuff, I
can't say how hard that will prove to be.
I think that the major remaining issue is that the position
of sun, moon and stars comes from a sophisticated astronomical
model. 99% of applications won't need that - so something
*really* simple like azimuth/elevation for sun and moon and
random positioning for stars will be plenty. I don't want
the astronomy code inside PLIB - it's wildly "off-topic"...
but SimGear NEEDS that sophisticated interface.
Ultimately, games will want to have sky models with green
clouds and a purple sky with a blue sun and orange stars...
there will need to be hooks to do crazy stuff like that too.
Meantime, if anyone needs Sky code - just grab a copy of SimGear.
Right now, I'm giving PPE my undivided attention - so looking
deeper into the sky stuff will just have to wait. I have a little
hack to put into the SSG file format loader/saver so we can use it
for 'UNDO' in PPE - but that's all I plan to do to PLIB for a
few weeks.
--
Steve Baker HomeEmail: <sjb...@ai...>
WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
|
|
From: <Va...@t-...> - 2000-07-30 12:16:24
|
Dave McClurg wrote: > > right now, http://plib.sourceforge.net has a few links to the more > prominent projects that use plib. Does Majik3d still use PLIB? They had an anouncement that they are using a commercial 3d library now... CU, Christian |
|
From: Steve B. <sjb...@ai...> - 2000-07-31 04:31:19
|
Christian Mayer wrote: > > Dave McClurg wrote: > > > > right now, http://plib.sourceforge.net has a few links to the more > > prominent projects that use plib. > > Does Majik3d still use PLIB? They had an anouncement that they are using > a commercial 3d library now... Really? They didn't mention anything about that to me. I'll check it out. -- Steve Baker HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://web2.airmail.net/sjbaker1 Projects : http://plib.sourceforge.net http://tuxaqfh.sourceforge.net http://tuxkart.sourceforge.net http://prettypoly.sourceforge.net |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X