Thread: [Plib-devel] Work outstanding.
Brought to you by:
sjbaker
Menu
▾
▴
plib-devel
|
From: Steve B. <sjb...@ai...> - 2000-08-10 04:50:22
|
OK - so we have LOTS of enthusiastic new developers signed up to
lighten my load.
I just trawled back through the list of 'pending' things in my mail
queue. If you have a yen to pick up one or more of these, please
mention it by email so we don't get duplicated work.
* Dave said that he thinks the bug in _ssgShareState seems to
have 'gone away' - and found that he could put it back into the
code without breaking TuxAQFH.
It needs to be tested - and someone needs to look through the
email archives to find out why it was originally commented out.
* Curt Olson has a nifty 'sky' model class in 'SimGear' that is really
just *begging* to go into an SSG Utilities library in a form that
frees it of it's remaining FlightGear heritage. Just about every
program I write at home would benefit from that.
http://www.simgear.org/Docs/SGSky/
Check out the email thread 'SGSky class'
* FlightGear discovered that if you set *insane* values for
pitch (207.44) and volume (30.1289) on their engine sound,
SL would *crash*. Obviously those are silly values - but
SL shouldn't crash because of it. That also came from Curt.
* John Fay <fa...@tc...> contributed some
patches to PUI to make it work better with multiple
windows. Sorry John - I didn't get time to try them.
Check the archives for the message entitled:
[Plib-devel] PUI 1.3.0 in Multiple Windows
Mon, 17 Jul 2000 15:31:41 -0500
* Dave Lawrence posted a 'frame rate limiter' routine
that may be usefully added as a feature to ulClock. His
original code isn't much use - but take the idea of noting the
time at some point - then a bit later saying - sleep/spin
until at least some number of milliseconds has elapsed.
* Darrell Walisser contributed a number of MacOS patches.
Sorry Darrell - I didn't have time to commit these. Look for the email thread:
[Plib-devel] Mac Updates/Patches (Tux too!)
Thu, 03 Aug 2000 16:20:49 EST
* Dave has been worrying about ssgSelector nodes with more than 32 children,
and how to time ssgTimedSelector in *realtime* instead of frame-time.
I maintain that you need both options - either as a flag inside ssgTimedSelector
or as a derived class that does realtime timing.
This really does need to be done soon because it's holding up some of the
loader work. What's tricky (with the >32 kids problem) is keeping it
backwards compatible. Notice especially the need to have MULTIPLE children
selectable at one - which is needed for some derived classes.
* There have been some comments about the need to delete PUI nodes during
their own callback functions. This turns out to be incredibly useful - but
it's not legal C++ to delete a class object whilst inside a member function
that belongs to that same object. There is an idea for a fix for this but
it's very tricky. Read the thread:
[Plib-devel] listbox and filepicker
Fri, 4 Aug 2000 10:51:38 -0700
* Dave has shelved his Blender-VRML loader for a while and asks for help with
continued development. If this 'Blender-VRML' subset is the best interchange
format between Blender and PLIB then we'd better write an exporter too so that
Blender and PrettyPoly can exchange files too.
* Leath Muller sent me 'lwload.cxx' and 'lwload.h' files which he says would make
a good starting point for a 'LightWave' loader. It would be nice to investigate
that. (If you want to attack this, let me know and I'll email you the files).
* The new ssgVtxArray class could be made more efficient (especially for GeForce
cards) if we added the option to pass Normal arrays as 'short' or 'byte' and
Colour arrays as 'byte'. At present, we have both of those as 'float' - so
to send a vertex to T&L hardware like GeForce or Radion is taking ~48 bytes.
If we could cut the precision, we'd only send ~27 bytes. Since data transfer
to the card is very often the limiting factor with hardware T&L, we could perhaps
double performance on those cards without harming non-T&L cards. The loss in
precision doesn't matter because normals are pretty much only used for lighting -
which in the end produces an 8 bit result - and colours are hardly every more
than 8 bits - even with 32 bits per pixel frame buffer depth.
(Notice that for *environment mapping* you may need more precise normals).
* Multiple textures per polygon.
* Enhance ssgState to allow for some of the more common/useful extensions
to OpenGL.
* Sam Stickland posted a patch to allow PUI menu's to be resized. I havn't
had time to deal with that (sorry Sam)...but since he now has CVS access, I
guess he can do it himself now.
* Documentation - this is especially problematic for SSG which has undergone
a TON of changes since 1.0.5-ish (which is the last time I did a serious
sync-up between the code and the manual). The other libraries aren't
too far out of date - but they could probably be read against the header
files to be sure that every public function is explained for every class.
(as a minimum).
Well, welcome to my hell!
--
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: Gil C. <g.c...@ca...> - 2000-08-10 06:13:17
|
> * Dave has shelved his Blender-VRML loader for a while and asks for > help with > continued development. If this 'Blender-VRML' subset is the best > interchange > format between Blender and PLIB then we'd better write an exporter > too so that > Blender and PrettyPoly can exchange files too. That sounds like me... I'll have a look at where Dave's up to with this loader tonight. I assume it's somewhere in the CVS repository? I might as well throw a couple of my future ideas into the ring before they even make it to the design stage (true vapourware!) to see if they're of interest to others. (These ideas come _after_ the VRML loader, I promise!) puTrace ~~~~~~~ Basically a benchmarking and information library which developers can link against during development for timing and rendering stats. I'm influenced by Performer's perfly program here, so the kinds of things I'm thinking of are: * app/cull/draw times * frames per second - peak and averaged * number of tris in view frustum * tri strip lengths * textures loaded * state information * toggle rendering between different modes - flat, shaded, wireframe etc * lighting on/off * lots of other things too! puTrace would be a library in addition to the main PLIB core, and would look after measurement and display of all of these parameters. Using the right #if directives, the trace can be left in the source, but compiled out for release versions of software. As a possible extension, the display of puTrace information might be available on a networked machine - in other words, the main app links in puTrace to do the measurements, and the results are sent over a TCP/IP connection to another machine which then displays them. The secondary display application will also be a PLIB app, set up to receive and display the stats. This way, the main machine's rendering is "untouched" by puTrace, and the second machine can do much more in terms of logging results without affecting the main app under test. Since puTrace will already have the HUD code built into it for local hosting of debug info, writing a remote version is almost a no-brainer. puFly ~~~~~ *Very* similar to perfly - IOW, a program which can load and display any type of PLIB compatible model, but allows interactive display of rendering stats and a graphical display of the scene graph. Obviously, this package will link puTrace in, and make heavy use of it. In fact, my plan for testing puTrace is to write puFly anyhow, so it's almost going to fall out as by-product. (Gee, is the phonetic pronounciation for puFly "POO-fly"?) puFly would be a possible replacement for the current "tux on a box with panning camera" demo, and would allow a showcase of the features of PLIB. Hopefully. For a rough idea of what perfly can do, have a look at this page which I've quickly cobbled together. http://www.powerup.com.au/~gcarter/plib/perfly.html It shows a couple of screenshots from perfly running on my O2 and displaying a simple model. Perfly also runs on the Linux distribution of Performer if you've got it installed. > * Documentation - this is especially problematic for SSG which has > undergone > a TON of changes since 1.0.5-ish (which is the last time I did a serious > sync-up between the code and the manual). The other libraries aren't > too far out of date - but they could probably be read against the header > files to be sure that every public function is explained for every class. > (as a minimum). I'd *really* like to help with this. Documentation is a pretty vital part of getting newbies running, so I'll see what I can do in this regard. I'm thinking of HTML page per class, with member variables and methods documented. Ideally, a code fragment also, but that relies on having a lot of little code fragments! The Java guys use a neat system called Javadoc, which allows comments embedded in code to be cross-compiled into documentation. You need to use some special tags in the comments for the parser to find, but it works really nicely if people do it as they go. Assuming that the comments are up to date, a documentation update is as simple as running the Javadoc parser through the source. http://java.sun.com/products/jdk/javadoc/ if you're interested. There are a number of packages which do the same thing for C++, and I was going to have a look at Doxygen, which seems to be quite popular - http://www.stack.nl/~dimitri/doxygen/ I'll post some findings about this; the last thing I want is to suggest other developers use some weird commenting system which most people will just ignore. It has to be easy enough to use that it's almost no effort. As some more general reference material, I'd also like to reference some other papers - mostly from SGI - about real time rendering issues. Eric Haines' website at http://www.realtimerendering.com also has a treasure trove of good information. These links plus other local docs would form some basic self help for people who land at the PLIB project without enough background in realtime 3D to be able to just jump in and start using PLIB. Comments? Gil |
|
From: Wolfram K. <w_...@rz...> - 2000-08-10 07:19:07
|
Gil wrote: >puTrace Sounds great! Obviously, the more info on bottlenecks there is, the better. For example, it would be GREAT to know how much texture-swapping there is going on, but I doubt this can be done portably? I think the first step should be simply to measure all the things. Displaying and(or sending them via TCP/IP is of secondary importance. >puFly Why not use PPE? It has several windows, a hierarchial view, great viewing via mouse or keyboard or commands (for example, "view everything"). It allows you to edit the model while seeing the performance. Of course PPE can load all plib stuff, since it is build on plib. We could create a new window for puTrace output. >I'd *really* like to help with this. Documentation is a pretty vital part >of getting newbies running, Yes. >[autmatical docs] I am not against them. But I think we need a handcrafted doc for the users of plib as well. For example, you have to give an overview of plib.This fits nowhere in the code. >Gil Bye bye, Wolfram. |
|
From: Gil C. <g.c...@ca...> - 2000-08-10 07:42:00
|
At 09:25 AM 8/10/00 +0100, you wrote: >Gil wrote: > > >puTrace > >Sounds great! Obviously, the more info on bottlenecks there is, the >better. For example, it would be GREAT to know how much >texture-swapping there is going on, but I doubt this can be done >portably? Over to Steve for this one, but I suspect that with a little user assistance (eg. "How much texture memory does your board have"), we can probably have a stab at guessing how much texture swapping from main memory to texture memory is occurring. Anybody know if you can monitor AGP transactions to pick this kind of thing up? >I think the first step should be simply to measure all the things. >Displaying and(or sending them via TCP/IP is of secondary importance. Agreed. > >puFly > >Why not use PPE? It has several windows, a hierarchial view, great >viewing via mouse or keyboard or commands (for example, "view >everything"). It allows you to edit the model while seeing the >performance. Of course PPE can load all plib stuff, since it is build >on plib. Well, the attraction with perfly is that it really doesn't do anything apart from load and display models. Perfly's ability to change the rendering parameters is very nice, and keeping it as a simple but powerful program means that the source stays compact - compact enough to go with the standard examples tarball for PLIB. The real win with this is that people can build puFly and load up models very easily. The code will be compact enough that people can see how to not only use the loaders, but also exercise all of the rendering methods. Hopefully, puFly will have enough in it that people can use it as a basis for their own first tinkerings - I know I'm still using the original tux-on-a-box program as my starting point for experiments! >We could create a new window for puTrace output. I hadn't thought of puTrace being used inside PPE. Given that PPE is a modelling package not a gaming engine, is this something you would really need to do? Obviously it's possible, but I'm not really clear on what you would use it for; I'm open to comments on this. >[autmatical docs] >I am not against them. But I think we need a handcrafted doc for the >users of plib as well. For example, you have to give an overview of >plib.This fits nowhere in the code. Very true. I guess you can draw the distinction between a programmer's guide and an API reference - the API reference is automagically updated from source comments, while the programmer's guide is a more static document which gets updated when major new features get added. I'm a big fan of nice docs, and I'm more than happy to put the effort into them provided other people can point out my errors :-) Gil |
|
From: Wolfram K. <w_...@rz...> - 2000-08-10 09:59:36
|
Gil wrote: >>Why not use PPE? [...] > >Well, the attraction with perfly is that it really doesn't do anything >apart from load and display models. [...] Hopefully, puFly will have >enough in it that people can use it as a basis for their own first >tinkerings Ok. But I still think it should take as much from PPE as possible. For example, I think the viewing can be used 100%. With other features, we could modularize the stuff that puTrace or puView or however you would call it into seperate files so that there is no duplication of effort. >I hadn't thought of puTrace being used inside PPE. Given that PPE is a >modelling package not a gaming engine, is this something you would really >need to do? Obviously it's possible, but I'm not really clear on what you >would use it for; I'm open to comments on this. So am I ;-), I unfortunately never had the opportunity to use something like perFly. But I asumed that it is something for the developer or artist, not the end user? Probably it would be best to have the performance monitor both in the engine and the modeler. In the engine for the developer, so that he can see the performance where it matters, with sound and ai etc going on. In the modeler, the developer can quickly make changes, for example that car model is too slow - lets try it with opaque windows. >I'm a big fan of nice docs, So am I. >and I'm more than happy to put the effort into them >provided other people can point out my errors :-) Ok, thats no problem :-). >Gil Bye bye, Wolfram. |
|
From: Gil C. <g.c...@ca...> - 2000-08-11 03:40:42
|
> >I hadn't thought of puTrace being used inside PPE. Given that PPE is a > >modelling package not a gaming engine, is this something you would really > >need to do? Obviously it's possible, but I'm not really clear on what you > >would use it for; I'm open to comments on this. > >So am I ;-), I unfortunately never had the opportunity to use >something like perFly. But I asumed that it is something for the >developer or artist, not the end user? Developers, not artists. Most people seem to use it to check that their own apps aren't doing something silly when rendering, or to see how different rendering method looks in practice or is implemented in source. It's also a nice sanity check that your build environment works, and it's a whizzy little demo app which comes free with the distribution. >Probably it would be best to >have the performance monitor both in the engine and the modeler. >In the engine for the developer, so that he can see the performance >where it matters, with sound and ai etc going on. >In the modeler, the developer can quickly make changes, for example >that car model is too slow - lets try it with opaque windows. Ok, but keep in mind that you're not just measuring how long it takes to render your car - you're really benchmarking the performance of PPE as well. Even though PPE is underpinned by PLIB, if you're developing models for a game, your game engine is really the place to benchmark. Maybe PPE could have a "preview" mode which goes fullscreen with no menus, and just renders the current model with trace enabled to give you an idea of what type of performance you'll get in a standalone app. There are issues of still having all of the other OpenGL resources consumed to keep PPE alive in background, but at least you're not rendering four views of the model plus the user interface at each frame :-) Gil |
|
From: Steve B. <sjb...@ai...> - 2000-08-11 04:56:47
|
Wolfram Kuss wrote:
>
> Gil wrote:
>
> >>Why not use PPE? [...]
> >
> >Well, the attraction with perfly is that it really doesn't do anything
> >apart from load and display models. [...] Hopefully, puFly will have
> >enough in it that people can use it as a basis for their own first
> >tinkerings
>
> Ok. But I still think it should take as much from PPE as possible.
> For example, I think the viewing can be used 100%.
> With other features, we could modularize the stuff that puTrace or
> puView or however you would call it into seperate files so that there
> is no duplication of effort.
But why? Wouldn't you just use PPE for viewing models? Why would I
want a separate program.
> >I hadn't thought of puTrace being used inside PPE. Given that PPE is a
> >modelling package not a gaming engine, is this something you would really
> >need to do? Obviously it's possible, but I'm not really clear on what you
> >would use it for; I'm open to comments on this.
>
> So am I ;-), I unfortunately never had the opportunity to use
> something like perFly. But I asumed that it is something for the
> developer or artist, not the end user?
Perfly is about four things rolled into one - which is the entire
problem with it:
1) It's a viewer. You built a model and want to see what it
looks like in Performer - then you load it into Perfly and
you can twirl it around using the mouse - turn wireframe,
texture, lighting, etc on and off, etc.
2) It's a sample program - designed to teach newbies how to
use Performer.
3) It's a starting point for projects that use Performer.
4) It's a test suite for debugging Performer. When you find
a bug in Performer, the first thing the developers say is
"Can you reproduce your bug by adding some of your code
into Perfly?"
...however, because of these things, it's become too bloated
to serve as a useful teaching program - too complex to help
much with debugging - too hard to use to make a good viewer -
and WAY too nasty to make a good starting point for new
projects.
1) I contend that PPE is our viewer - you can already use it
for that with GREAT success. It's a done deal.
2) Sample programs need to be written - lots of little ones,
each showing off just one or two features at most.
3) We need one good 'skeleton application' that has all the
things a basic application needs.
4) Right now, I don't think we need a test suite because
PLIB is OpenSourced - and we rather hope that "with many
eyes, all bugs are shallow".
> Probably it would be best to
> have the performance monitor both in the engine and the modeler.
It'll *have* to be in SSG because that's where the statistics
are gathered. We might want to do as Performer does and write
a fancy graphics statistics display function and dump that into
our 'SSG Utilities' library. That way, you gather stats using
a standard SSG library call - and either display them yourself
or call 'ssguDisplayStatistics ( ssgStatistics *stats )'.
Making it that easy will allow PPE to show stats WHILST the model
is being built...and for games to show stats to the developer with
a minimum of fuss. You can also write them to disk - use them to
drive fancy load-balancing routines, etc, etc.
--
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-08-11 04:55:05
|
Gil Carter wrote:
>
> At 09:25 AM 8/10/00 +0100, you wrote:
> >Gil wrote:
> >
> > >puTrace
> >
> >Sounds great! Obviously, the more info on bottlenecks there is, the
> >better. For example, it would be GREAT to know how much
> >texture-swapping there is going on, but I doubt this can be done
> >portably?
>
> Over to Steve for this one, but I suspect that with a little user
> assistance (eg. "How much texture memory does your board have"), we can
> probably have a stab at guessing how much texture swapping from main memory
> to texture memory is occurring.
Well, there isn't a direct way to do either of those things.
You can ask OpenGL if a texture is resident though - so you could
start loading 1k x 1k textures and asking each one whether it's
resident or not - and when they stop being resident - you have a
*reasonable* idea of how much memory there is. However, real hardware
can be VERY subtle - and the question may not actually be answerable.
* On SGI ONYX machines, there are two BANKS of texture. When a map
loads, the odd numbered MIPmaps go in one bank and the even numbered
into the other. It's possible to run out of texture memory in one bank
and still have plenty in the other - so although *theoretically* you have
free texture memory, your map won't be resident on the hardware.
* 3D hardware may have on-chip texture cache, on-board texture RAM, AGP
texture RAM and main memory texture RAM. These represent a continuum
of performance. When you ask "how much memory is there" - you really
need to ask "how much memory is there that can be accessed at better
than 150 nanoseconds"... Some Intel i810 boards have NO TEXTURE MEMORY
AT ALL...getting it all from AGP and using a tiny texture cache. How
many bytes should they return as texture memory size?
* Some cards (GeForce, Voodoo-5 and S3 for example) have texture compression.
Since you don't know in advance how much your map will compress, there is
no way to answer the question "how many texels will my card hold?"
Since this question is unanswerable in a portable manner, OpenGL doesn't
attempt to answer it.
As for swapping, what I've done in the past is to check the glAreTexturesResident()
function to find out what textures are resident from frame to frame - if the
answer ever changes then you are swapping textures...but if it doesn't change,
that doesn't tell you that it *didn't* swap because something may have
swapped out and then swapped back in again a dozen times during the frame!
So, these are NOT good questions to ask!
> Anybody know if you can monitor AGP transactions to pick this kind of thing
> up?
Nope - and in any case, that wouldn't be portable because not all cards
use AGP - and lots of things other than textures go across the AGP.
> > >puFly
> >
> >Why not use PPE? It has several windows, a hierarchial view, great
> >viewing via mouse or keyboard or commands (for example, "view
> >everything"). It allows you to edit the model while seeing the
> >performance. Of course PPE can load all plib stuff, since it is build
> >on plib.
I agree. PPE has everything you could possibly need in a viewer.
> Well, the attraction with perfly is that it really doesn't do anything
> apart from load and display models.
Neither does PPE right now! :-(
But seriously - if you are not actually in the process of editing a model,
all PPE does is to call ssgCullAndDraw in a tight loop on your model. It's
perfect as a perfly equivelent for PPE.
> Perfly's ability to change the rendering parameters is very nice...
PPE can do that. Turn on and off lighting, shading, texture, wireframe, etc.
> and keeping it as a simple but powerful
> program means that the source stays compact - compact enough to go with the
> standard examples tarball for PLIB.
Well, I don't think it would be all that much of a stretch to assume that
since PPE is free, it'll become as ubiquitous as (say) GIMP - so everyone
who uses PLIB will already have it. If that's the case, why bother with
another tool? It's just a waste of disk space.
Having said that, you could write such a thing very easily and dump it
into PLIB-examples if you wanted to. I don't feel a strong need to do
that.
> The real win with this is that people can build puFly and load up models
> very easily. The code will be compact enough that people can see how to
> not only use the loaders, but also exercise all of the rendering
> methods.
That's why we have example programs - certainly.
However, Perfly is a mess because it's had anything and everything
slurped into it. A bunch of simple single-function examples is
generally more instructive IMHO.
If you really want an example of how to put something together using
all the tools, just download TuxKart - it's only 4,000 lines of code.
> Hopefully, puFly will have enough in it that people can use it as
> a basis for their own first tinkerings - I know I'm still using the
> original tux-on-a-box program as my starting point for experiments!
Yep.
Michael Jones (one time manager of the Performer project) told me that
he quite regretted making Perfly *so* complete because everyone just
hacked Perfly instead of writing appropriate programs from scratch.
You'd be amazed at the number of commercial Performer applications that
are just Perfly with a few hundred lines of code added.
> >We could create a new window for puTrace output.
>
> I hadn't thought of puTrace being used inside PPE. Given that PPE is a
> modelling package not a gaming engine, is this something you would really
> need to do? Obviously it's possible, but I'm not really clear on what you
> would use it for; I'm open to comments on this.
Well, I'm not sure 'puTrace' is the right name here. 'ssgStatistics'
might be a better thing to imagine. Having good rendering statistics
would be a VERY good thing for PPE.
> >[autmatical docs]
>
> >I am not against them. But I think we need a handcrafted doc for the
> >users of plib as well. For example, you have to give an overview of
> >plib.This fits nowhere in the code.
Yes, I agree.
> Very true. I guess you can draw the distinction between a programmer's
> guide and an API reference - the API reference is automagically updated
> from source comments, while the programmer's guide is a more static
> document which gets updated when major new features get added. I'm a big
> fan of nice docs, and I'm more than happy to put the effort into them
> provided other people can point out my errors :-)
Yes.
I dislike documentation embedded in code files because it makes the code
VERY hard to read...it's hard to see the three lines of code for the 30
lines of documentation. Also, good documentation contains examples - and
I *really* hate having code buried inside comments inside *real* code
because it makes it virtually impossible to 'grep' code and search for
things without tripping over the stoopid examples.
Finally, the order of items in (say) a header file is the order that
makes sense when programming - that's rarely the order that makes for
a readable document.
And all of this is for what? To avoid having two files?
I'm not very convinced.
--
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: Wolfram K. <w_...@rz...> - 2000-08-11 13:55:31
|
Steve wrote: >> >For example, it would be GREAT to know how much >> >texture-swapping there is going on, but I doubt this can be done >> >portably? >> >However, real hardware can be VERY subtle Yes, I know. Generally speaking, I loved optimizing till about 10 years ago. Until then, you could pretty much tell beforehand whether a change would speed up the program. But with several caches, pipelines that are filled by compilers, branch prediction etc it has become much harder and sometimes when I optimized something for speed I ended up making it slower :-(. >Since this question is unanswerable in a portable manner, That's what I feared. >So, these are NOT good questions to ask! Ok, I realize that there is no portable way to measure things, no one answer (after all, not all users have the same hardware), its not clearly defined etc. But I still think a ballpark figure could help enormously. I think it can still happen that large parts of the time per frame is spent in texture swapping. But in PPE speak NIV10 ;-))), meaning, this wont be the next thing that is implemented. > >> Well, the attraction with perfly is that it really doesn't do anything >> apart from load and display models. > >Neither does PPE right now! :-( Lol. But PPE makes a nice 3D object converter once all those loaders/writers work. BTW; there is a "conv3D" on SourceForge, but I am not impressed and it seems to be deeply asleep. But maybe they could help, for example with a *simple* POV reader/writer? Bye bye, Wolfram. |
|
From: Gil C. <g.c...@ca...> - 2000-08-17 22:56:10
|
<snip> >You could write a function that could monitor the frame rate and >automatically try replacing texturing to look for swapping but I >think that's about as far as you can go. I seem to recall people on the OpenGL Gamedev list talking a while ago about manually adjusting the MIP map level bias so that you can force the hardware to use smaller versions of the textures if you're swapping too much. IOW, if your maximum texture size is 1024x1024, you drop back down the MIP tree to use the 128x128 or 64x64 version temporarily to keep the framerate up while your renderer gets settled again. I guess that this idea can also be applied to having objects in the view frustum which are distant but visible. For example, if your game has a "god monster" as the final challenge for the user to overcome, the model for that monster may well be very complex and heavily textured. If the user can see the monster in the distance, it would be nice to be able to load the lo-res versions of the model textures at first, and defer loading of the more detailed levels in the MIP tree until you're getting close enough to start using them. (Hmm... Better get the real story here... Digs back through archive of OpenGL messages...) Aha, here's the basics of it, courtesy of Tom Forysth and Sean Palmer, posted September last year: "I remember Jan Svarovsky from Muckyfoot talking about something like this at GDC99 - he called it "Just Too Late" caching :-). For older cards, where he had to do manual texture management, he always kept all the visible (according to the frustum) 16x16 mipmaps around - they don't take up too much memory, so they can all be loaded onto even the most modest card. But he would swap around the larger texture maps at the start of every frame according to heristics like "how big do I need this" and things like that. However, sometimes the prediction heuristic fails, and you end up drawing a large polygon, but you haven't got the properly detailed mipmap levels loaded." "Rather than interrupt the polygon drawing to load the texture (stalls the pipeline badly, especially on older cards), he just drew the poly with the 16x16 texture (always resident), and loaded the proper high-detail mipmap level next frame. So for one frame, the image was blurry, but it sharpened up the next frame. He said it was very rare to see any big problems - you really had to pick pathological situations to see the artifacts. And the performance boost was good." "I suspect this priority scheme would produce similar effects - sounds plausible and cunning. (of course, the Permedia3 doesn't need any of this stuff anyway - so I can probably safely adopt the role of netural IHV :-)." Tom Forsyth, DirectX Team, 3Dlabs email: Tom...@3D... On Tuesday, September 28, 1999 6:13 AM, Sean L. Palmer [SMTP:sp...@po...] wrote: > > You mean like I am doing right now? The only extra thing I need to handle > > this stuff is more control over the mipmap stuff, such as giving some > > textures a lower priority -- which then should (IMHO) directly relate to > > what mipmaps are loaded. If a texture has a low priority, and I have > > extra texture memory, then the lower priority texture should have a low > > level mipmap loaded in. > > > > Is this a reasonable thing to ask for? I don't see why it shouldn't be. > > Even if we need an extra extension for mipmap priorities on top of the > > current texture priorities. > > How about if smaller mip levels automatically get 2x the higher mipmap's > priority? So to completely unload a mipmap chain, set top-level priority to > 0. If you set top-level priority to 1, then for a 256x256 texture the > following priorities would be generated down the chain: > > priority size > 1 256x256 > 2 128x128 > 4 64x64 > 8 32x32 > 16 16x16 > 32 8x8 > 64 4x4 > 128 2x2 > 256 1x1 > > Thus, teensy mipmaps would generally always be loaded, so no matter what, > you'd at least have *something* to draw with. If you were out of memory and > tried to load a similar texture with top-level priority of 16, it could then > free the top 4 mip levels of the priority 1 texture, giving enough room for > all but the highest mip level of the new texture. > <snip> >Anyone know of any opengl texture management articles that cover scaling >back the textures in use automatically? Have a look at http://vterrain.org/Textures/ground_textures.html for a general discussion of this topic. In fact, the whole Vterrain site is a good read for topics relating to this. Rgds, Gil |
|
From: Steve B. <sjb...@ai...> - 2000-08-18 02:17:17
|
Gil Carter wrote:
>
> <snip>
>
> >You could write a function that could monitor the frame rate and
> >automatically try replacing texturing to look for swapping but I
> >think that's about as far as you can go.
>
> I seem to recall people on the OpenGL Gamedev list talking a while ago
> about manually adjusting the MIP map level bias so that you can force the
> hardware to use smaller versions of the textures if you're swapping too
> much. IOW, if your maximum texture size is 1024x1024, you drop back down
> the MIP tree to use the 128x128 or 64x64 version temporarily to keep the
> framerate up while your renderer gets settled again.
OpenGL 1.2 allows you to clamp the texture map so it doesn't try to use
a MIPmap level that you havn't used.
Also, there is (IMHO) an error in the OpenGL specification for how the
hardware picks which MIPmap to use - which results in a small amount of
texture aliasing at some scales and orientations. Several OpenGL
implementations allow you to 'bias' the chosen MIPmap level by some
small amount in order to allow you a non-standard mapping function that
will remove that last vestige of aliasing.
> I guess that this idea can also be applied to having objects in the view
> frustum which are distant but visible. For example, if your game has a
> "god monster" as the final challenge for the user to overcome, the model
> for that monster may well be very complex and heavily textured. If the
> user can see the monster in the distance, it would be nice to be able to
> load the lo-res versions of the model textures at first, and defer loading
> of the more detailed levels in the MIP tree until you're getting close
> enough to start using them.
That should be simple enough to do - but the amount of storage for a
level boss will never be all that large to warrant the hassle.
Where it *is* useful is in things like flight simulation where you
need to be able so render low detail terrain out 50 miles or more - but
couldn't possibly afford to keep 2,500 square miles of terrain in
memory at any one time.
For texture mapping though, it's not a bad idea - but pretty hard to
implement in a general manner.
--
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: Sam S. <sa...@sp...> - 2000-08-18 09:28:22
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 How are these specified in ssg? I'll take a wild guess that ssg doesn't manage texture environment modes (GL_MODULATE, GL_DECAL etc.) at all, and it only cares whether blending is on or off. So, do I set the required mode in a predraw callback function? Sam -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com> iQA/AwUBOZ0BcNoVH1DfwTXWEQJU1wCfbAm1G6GeVVQU0nvLZIR4uxOW0l4AniFA QbeblgJYqToI4YvwNmHxEQHG =rjd4 -----END PGP SIGNATURE----- |
|
From: Steve B. <sjb...@ai...> - 2000-08-18 18:17:09
|
Sam Stickland wrote:
> How are these specified in ssg? I'll take a wild guess that ssg
> doesn't manage texture environment modes (GL_MODULATE, GL_DECAL etc.)
> at all, and it only cares whether blending is on or off.
Well, when you add a texture into an ssgSimpleState, you can either
pass it an 'ssgTexture' or an OpenGL texture handle - or even a
filename (which will result in an ssgTexture being constructed on
your behalf).
Hence, there are really just two options - ssgTexture or do-it-yourself.
ssgTexture does indeed only specify GL_MODULATE - it's hard-wired in
the constructor function with no way to change it.
> So, do I set the required mode in a predraw callback function?
You have (at least) five options:
1) Derive a new class from ssgTexture (say ssgDecalTexture) that
does GL_DECAL instead of GL_MODULATE.
2) Load the texture yourself, do the glBindTexture, set GL_DECAL
using glTexEnvi, pass the texture handle to SSG.
3) In a pre-draw callback, set the glTexEnv to GL_DECAL.
4) Use ssgTexture to load the texture and do either a ssgSimpleState::getTextureHandle()
or an ssgTexture::getHandle() to get the texture handle. Then you can
glBindTexture(handle) and change the glTexEnv setting.
5) Edit the SSG source code to add 'setEnvMode/getEnvMode' methods to ssgTexture - then
contribute your change via CVS and earn fame, the recognition of your peers, etc, etc.
While you are about it - add Mag/Min filter and texture wrap options.
People who know me well soon realise that I ALWAYS put my most favored option
at the end of a list of choices. :-)
--
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: Sam S. <sa...@sp...> - 2000-08-18 18:58:16
|
----- Original Message ----- From: "Steve Baker" <sjb...@ai...> To: <pli...@li...> Sent: Friday, August 18, 2000 6:38 PM Subject: Re: [Plib-devel] Texture and blend modes > Sam Stickland wrote:-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ----- Original Message ----- From: "Steve Baker" <sjb...@ai...> To: <pli...@li...> Sent: Friday, August 18, 2000 6:38 PM Subject: Re: [Plib-devel] Texture and blend modes > Sam Stickland wrote: > > > How are these specified in ssg? I'll take a wild guess that ssg > > doesn't manage texture environment modes (GL_MODULATE, GL_DECAL > > etc.) at all, and it only cares whether blending is on or off. > > Well, when you add a texture into an ssgSimpleState, you can either > pass it an 'ssgTexture' or an OpenGL texture handle - or even a > filename (which will result in an ssgTexture being constructed on > your behalf). Oh wait, I'll look lame for saying this but I genuinely thought that glTexEnv didn't get caught up in the glBindTexture bit? The results from glTexEnv depend on what surface you render onto, not just the texture so I thought it effected the "global" rendering mode - - hence I believed this sort of stuff was planned for: glBindTexture(blah); glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE); /* Render surface */ glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_DECAL); /* Render another surface */ Oh well.. > > 5) Edit the SSG source code to add 'setEnvMode/getEnvMode' methods > to ssgTexture - then > contribute your change via CVS and earn fame, the recognition of > your peers, etc, etc. And Beer? > While you are about it - add Mag/Min filter and texture wrap > options. > > People who know me well soon realise that I ALWAYS put my most > favored option at the end of a list of choices. :-) Guess I'll do this one then. :) Oh, how do you set the glBendFunc ? (Meant to ask this in the original email but forgot). Thanks, Sam -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com> iQA/AwUBOZ2G59oVH1DfwTXWEQJ/aQCfR8CBuFXWfx7pYZ/J5Y3rjtdfOpsAoOV5 HpjkfLnKO/vlY+1sx3SXmioi =U5l/ -----END PGP SIGNATURE----- > > > How are these specified in ssg? I'll take a wild guess that ssg > > doesn't manage texture environment modes (GL_MODULATE, GL_DECAL etc.) > > at all, and it only cares whether blending is on or off. > > Well, when you add a texture into an ssgSimpleState, you can either > pass it an 'ssgTexture' or an OpenGL texture handle - or even a > filename (which will result in an ssgTexture being constructed on > your behalf). Oh wait, I'll look lame for saying this but I genuinely thought that glTexEnv didn't get caught up in the glBindTexture bit? The results from glTexEnv depend on what surface you render onto, not just the texture so I thought it effected the "global" rendering mode - hence I believed this sort of stuff was planned for: glBindTexture(blah); glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE); /* Render surface */ glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_DECAL); /* Render another surface */ Oh well.. > > 5) Edit the SSG source code to add 'setEnvMode/getEnvMode' methods to ssgTexture - then > contribute your change via CVS and earn fame, the recognition of your peers, etc, etc. And Beer? > While you are about it - add Mag/Min filter and texture wrap options. > > People who know me well soon realise that I ALWAYS put my most favored option > at the end of a list of choices. :-) Guess I'll do this one then. :) Oh, how do you set the glBendFunc ? (Meant to ask this in the original email but forgot). Thanks, Sam |
|
From: Steve B. <sjb...@ai...> - 2000-08-18 21:11:16
|
Sam Stickland wrote:
>
> > Well, when you add a texture into an ssgSimpleState, you can either
> > pass it an 'ssgTexture' or an OpenGL texture handle - or even a
> > filename (which will result in an ssgTexture being constructed on
> > your behalf).
>
> Oh wait, I'll look lame for saying this but I genuinely thought that
> glTexEnv didn't get caught up in the glBindTexture bit?
Well, you certainly don't look lame for thinking that - in fact, you've
inserted a little doubt in my mind too. I hardly every use anything
other than GL_MODULATE - so I could *easily* be wrong.
In fact, I just grep'ed every line of OpenGL code on my hard drive,
and every single glTexEnv call I can find uses GL_MODULATE! I can
distantly remember using a TexEnv other than modulate on an SGI machine
once - but the mode we used was a non-standard one associated with
an OpenGL extension that I havn't seen on a PC yet.
The OpenGL manuals are really un-clear about what is and isn't saved.
The nearest thing I could find is where the 'RedBook' says:
"Subsequent calls to glTexImage*, glTexSubImage*, glCopyTexImage*,
glTexParameter* and glPrioritizeTextures store data in the texture
object"
Yikes! ...no mention of glTexEnv*. It looks like you are right after all.
But then, in the example program that follows. They set the glTexEnv
when the texture is initially created - and not after every glBindTexture
as you might expect.
That would mean that either the example program has a bug in it - or
the definition of what goes into a texture binding is wrong.
So, I think you *may* be right.
It'll probably take an experiment to be sure.
> The results from glTexEnv depend on what surface you render onto, not
> just the texture so I thought it effected the "global" rendering mode
> - - hence I believed this sort of stuff was planned for:
>
> glBindTexture(blah);
> glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
> /* Render surface */
> glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_DECAL);
> /* Render another surface */
Maybe you are right.
...in which case, the TexEnv needs to be an attribute of the ssgSimpleState
and NOT an attribute of the ssgTexture...and come to think of it,
in Performer they have a separate pfTexture and pfTexEnv - so I bet
you *are* right.
Ack! I *hate* adding things to ssgSimpleState - especially things
that hardly anyone will ever use - because it adds to the time taken
to determine whether the state has changed and that's a per-leaf-node
cost.
> Oh, how do you set the glBendFunc ? (Meant to ask this in the
> original email but forgot).
Same deal - I don't bother to track it in ssgSimpleState - I only
turn it on and off.
The deal is that the function 'ssgSimpleState::apply' is called for EVERY
leaf node that passes the cull test.
It contains lots of nasty branch instructions (bad for performance) - but
it's absolutely critical to minimise the amount of costly OpenGL state
change.
The question is - which state elements really change frequently enough to
warrant going into ssgSimpleState (and thus causing more branching) - and
which are better handled with Draw callbacks in the application. That
choice is rather arbitary - and somewhat application dependent.
I chose to include only those things that I thought a 'typical' game might
need - and to omit everything that seemed that you'd be unlikely to want
to change often.
By my judgement, glBlendFunc doesn't cut it because glEnable/Disable(GL_BLEND)
lets you turn it on and off quickly for opaque and transparent polygons - and
changing the actual blend function is a pretty rare event. Hence, it's better
to suffer the penalty of a costly (non-lazy) state change done in an application
draw-callback than to burden every leaf node with testing for a condition that'll
probably never come up.
Similarly, glTexEnv doesn't cut it either - I certainly don't want to add an
extra conditional for every triangle strip for a feature that hardly anyone
uses!
Finally, I'd point out that 'ssgSimpleState' is so named because it is the
simplest imaginable lazy state handler. I had in the back of my mind that
we might sometime need to create 'ssgComprehensiveState' that would deal
with every single bit of OpenGL state...but S-L-O-W-L-Y.
However, it turns out that by the very nature of being a lazy-evaluation
system, it has to store the current state in some kind of static storage - and
that makes adding an 'ssgComprehensiveState' class rather tricky unless
ssgSimpleState *also* checks all the state elements.
Well, it's not for nothing that SSG is "SIMPLE" Scene Graph. :-)
Simplicity comes at a price.
--
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: Curtis L. O. <cu...@me...> - 2000-08-18 21:39:01
|
Steve Baker writes: > ...in which case, the TexEnv needs to be an attribute of the > ssgSimpleState and NOT an attribute of the ssgTexture...and come to > think of it, in Performer they have a separate pfTexture and > pfTexEnv - so I bet you *are* right. > > Ack! I *hate* adding things to ssgSimpleState - especially things > that hardly anyone will ever use - because it adds to the time taken > to determine whether the state has changed and that's a > per-leaf-node cost. Hmmm, yes, for flightgear, there are a couple things I'd like to see added to ssg's lazy state evaluator ... > > Oh, how do you set the glBendFunc ? (Meant to ask this in the > > original email but forgot). > > Same deal - I don't bother to track it in ssgSimpleState - I only > turn it on and off. > > The deal is that the function 'ssgSimpleState::apply' is called for EVERY > leaf node that passes the cull test. > > It contains lots of nasty branch instructions (bad for performance) - but > it's absolutely critical to minimise the amount of costly OpenGL state > change. > > The question is - which state elements really change frequently enough to > warrant going into ssgSimpleState (and thus causing more branching) - and > which are better handled with Draw callbacks in the application. That > choice is rather arbitary - and somewhat application dependent. Let me jump in here and say that I'm not exactly 100% pleased with handling these things via a call back function. The call back has no way to know the initial state of the element you are interested in changing. So, how do you reliably restore the value? How do you know if you need to actually change the state or not? You are back to all the problems associated with randomly changing state at random points in your program ... these are the sorts of problems ssgSimpleState was designed to fix. So I suppose I could hack in my own tracking variables and sort of parallel what ssgSimpleState is doing ... this leads to either reimplimenting something very similar to ssgSimpleState, or coming up with an extention to it that tracks different, less common elements? Or more likely yields an application specific mess that is more likely to break things in the future than work. IMHO this extra state tracking would be best done inside ssg ... maybe with an ssgExtendedState class or something? It would be *really* nice if ssg had the ability to track and control some of these less popular states. > I chose to include only those things that I thought a 'typical' game might > need - and to omit everything that seemed that you'd be unlikely to want > to change often. > > By my judgement, glBlendFunc doesn't cut it because > glEnable/Disable(GL_BLEND) lets you turn it on and off quickly for > opaque and transparent polygons - and changing the actual blend > function is a pretty rare event. Blend function changing happens every frame in flight gear so we can draw the moon with the proper phase against a changing/gradient sky. :-) > Hence, it's better to suffer the penalty of a costly (non-lazy) > state change done in an application draw-callback than to burden > every leaf node with testing for a condition that'll probably never > come up. But using a callback introduces more than just performance penalties. You also run the risk of leaving the element in some unknown state that hoses the rest of your program ... and as you well know, these sorts of global state changes can be hard to debug if you add something that breaks because of a mistake you made 18 months ago or any permutation there of ... I'm still trying to eradicate these sorts of problems from FlightGear, but I end up being forced to put scary stuff back inside of callbacks... I wouldn't be surprised if the simgear sky code breaks (or is broken by) just about every application that tries to use it for this specific reason. It has to use call backs to change these less popular states, and thus by definition doesn't play nice with any application it may be dropped into. > Similarly, glTexEnv doesn't cut it either - I certainly don't want > to add an extra conditional for every triangle strip for a feature > that hardly anyone uses! Can we have perhaps have an ssgSuperExtendedSimpleState that does include these extra things for applications that need them? Or perhaps something similar to ssgSimpleState that tracks all the things that you don't want to track in ssgSimpleState? > Finally, I'd point out that 'ssgSimpleState' is so named because it > is the simplest imaginable lazy state handler. I had in the back of > my mind that we might sometime need to create > 'ssgComprehensiveState' that would deal with every single bit of > OpenGL state...but S-L-O-W-L-Y. I think we need something ... hopefully implimented in some way that doesn't completely tank performance. > However, it turns out that by the very nature of being a > lazy-evaluation system, it has to store the current state in some > kind of static storage - and that makes adding an > 'ssgComprehensiveState' class rather tricky unless ssgSimpleState > *also* checks all the state elements. > > Well, it's not for nothing that SSG is "SIMPLE" Scene Graph. :-) > > Simplicity comes at a price. Let me propose the following: We could add a pointer to an ssgComprehensiveState class inside of ssgSimpleState. The ssgComprehensiveState would handle all those states not handled by an ssgSimpleState. If this extra pointer is non-null then the system would evaluate the associated ssgComprehensiveState as well (with the corresponding performance penalties.) We'd also need the concept of a "default" comprehensive state. So if you evaulate a simple state and this extra pointer is NULL, but the previous state's pointer wasn't, you would diff against the default state first. This way you could recover from a state that does things like change glTexEnv or sets up a funky blend function. Curt. -- Curtis Olson Human Factors Research Lab Flight Gear Project Twin Cities cu...@hf... cu...@fl... Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org |
|
From: Steve B. <sjb...@ai...> - 2000-08-18 22:34:24
|
"Curtis L. Olson" wrote:
> Hmmm, yes, for flightgear, there are a couple things I'd like to see
> added to ssg's lazy state evaluator ...
What - specifically?
> Let me jump in here and say that I'm not exactly 100% pleased with
> handling these things via a call back function. The call back has no
> way to know the initial state of the element you are interested in
> changing. So, how do you reliably restore the value? How do you know
> if you need to actually change the state or not? You are back to all
> the problems associated with randomly changing state at random points
> in your program ... these are the sorts of problems ssgSimpleState was
> designed to fix.
Well, that's why you have to decide which things to test before EVERY
leaf node is drawn - and which to set and restore in callbacks.
For things in callbacks, you know the default state because you can
set it before calling ssgCullAndDraw and be sure that SSG won't
mess with it (unless I have an error). Then you have to set it
(unconditionally) to what you want in the pre-Draw and restore it
to the default state in post-Draw.
Whether it's better to use that mechanism or a lazy evaluation
mechanism depends on:
* The cost to test whether the state is already what you need
MULTIPLIED by the number of leaf nodes that DON'T use that
state.
Versus:
* The cost to redundantly set and unset the state MULTIPLIED by the
number of leaf nodes that need that state.
When the number of leaf nodes containing the state is small, it's
better to use a callback and suffer the cost of switching it redundantly.
When the number of leaf nodes containing the state is large, it's
worth paying the penalty to check for it in order to save redundant
state changes.
Now - where that balance lies clearly depends on the application.
Take something like glTexEnv. I have probably used it once - on
one leaf node once during my entire career. For me at least, this
doesn't warrant putting into ssgSimpleState - it's FAR better to
put it into a node callback.
Look at something like glBindTexture though - and every single
leaf node needs to be checked - so it's worth putting into
ssgSimpleState.
Notice also that with draw callbacks, you can put them higher
up in the scene graph - so if you have an entire character in
a game that needs some peculiar glBlendFunc (a Ghost for example),
then you can put the state change up at the root of that
objects scene graph rather than on every leaf node.
The problem here is that SSG is used for a lot of things - and
my personal choice of what things should or should not make it
into ssgSimpleState may not agree with yours...so we should
discuss the matter and see where we should compromise.
> So I suppose I could hack in my own tracking variables and sort of
> parallel what ssgSimpleState is doing ...
That's very hard to do because your post-draw callback can't tell
whether some other leaf node (without a pre-draw callback) will be
drawn next or whether you can safely leave the state at this
new (non-standard) setting ready for the next leaf node that
needs it.
> this leads to either
> reimplimenting something very similar to ssgSimpleState...
Worse than that. You'd have to apply it to EVERY leaf node.
It would be better to derive a new kind of ssgState and either
use your own loaders - or walk the scene graph after loading it
from disk replacing all the ssgSimpleState's with ssgCurtStates.
Yuck.
> or coming up with an extention to it that tracks different, less
> common elements?
Yep. But you absolutely cannot mix ssgSimpleStates with other
state management schemes.
> Or more likely yields an application specific mess that is more likely
> to break things in the future than work.
>
> IMHO this extra state tracking would be best done inside ssg ... maybe
> with an ssgExtendedState class or something? It would be *really*
> nice if ssg had the ability to track and control some of these less
> popular states.
Well, as I've explained, you can't do that because when this ssgExtendedState
leaf node finishes rendering, it mustn't leave the extended state elements
turned on because a subsequent ssgSimpleState doesn't do the testing to turn
it back off again. That's why it's all-or-nothing...and why I don't want to
do this.
I'd be VERY interested to hear which states you think are common enough to
need to be changed lazily and which ones can be set in callbacks. Since
you are building a flight sim - and I'm not unfamiliar with the needs of
such programs :-) ...I can't imagine what you are changing that is so
commonly required.
> Blend function changing happens every frame in flight gear so we can
> draw the moon with the proper phase against a changing/gradient
> sky. :-)
Yes - but that's ONE leaf node (probably). You can't possibly justify
adding another conditional test before every single one of the 10,000
or so other leaf nodes you are probably drawing just to save...well - nothing
actually. You still have to switch to the special blend mode before
drawing the moon - and it would be restored again by the very next polygon
to be drawn - lazy state evaluation would save you exactly nothing in that
case.
If you had (say) 100 moons to draw randomly throughout the scene - then
I might be pursuaded.
This example is a CLASSIC case of why I don't want to put the blendfunc
into ssgSimpleState.
> > Hence, it's better to suffer the penalty of a costly (non-lazy)
> > state change done in an application draw-callback than to burden
> > every leaf node with testing for a condition that'll probably never
> > come up.
>
> But using a callback introduces more than just performance penalties.
> You also run the risk of leaving the element in some unknown state
> that hoses the rest of your program ...
No - you just have to turn the blend mode back to 'normal' in the post-draw
callback.
> and as you well know, these
> sorts of global state changes can be hard to debug if you add
> something that breaks because of a mistake you made 18 months ago or
> any permutation there of ...
Indeed.
> I'm still trying to eradicate these sorts of problems from FlightGear,
> but I end up being forced to put scary stuff back inside of
> callbacks...
I think that this could be attacked in one of two ways:
1) We could add code for all the rarely used states which would
be tested for in one step in ssgState. ie we'd have a "Weird State"
flag that ssgSimpleState would test for. If that flag were to
be TRUE, then it would do a lot of unconditional state changes
and tell the leaf node to call a special restoration function
after the user's post-draw callback was called. That adds two
more conditionals to every leaf node - but we could perhaps
win that back by moving some of the more obscure existing
ssgSimpleState lazy elements into the non-lazy code.
2) Documentation. We need to write down precisely which state
elements SSG chooses to manage - and which ones the application
is responsible for. We also need to write down the default states
of those elements.
Remember about the 'which item Steve prefers in a list' thing? :-)
> I wouldn't be surprised if the simgear sky code breaks (or is broken
> by) just about every application that tries to use it for this
> specific reason. It has to use call backs to change these less
> popular states, and thus by definition doesn't play nice with any
> application it may be dropped into.
That's certainly an issue. But for *just* the moon, I'd toss in a
dirty 'glGet' to find the current blend mode so you can restore it
in post-draw. Once per frame isn't going to kill anyone.
> > Similarly, glTexEnv doesn't cut it either - I certainly don't want
> > to add an extra conditional for every triangle strip for a feature
> > that hardly anyone uses!
>
> Can we have perhaps have an ssgSuperExtendedSimpleState that does
> include these extra things for applications that need them? Or
> perhaps something similar to ssgSimpleState that tracks all the things
> that you don't want to track in ssgSimpleState?
Well, as I explained before, it isn't that simple because if
ssgHyperExtendedState doesn't clean up the wierd stuff it changed
then the next ssgSimpleState that comes along will have to do so.
That's an additional cost for every ssgSimpleState which you can't
justify unless there are a heck of a lot of ssgHyperExtendedState
leaf nodes out there.
> Let me propose the following:
>
> We could add a pointer to an ssgComprehensiveState class inside of
> ssgSimpleState. The ssgComprehensiveState would handle all those
> states not handled by an ssgSimpleState.
>
> If this extra pointer is non-null then the system would evaluate the
> associated ssgComprehensiveState as well (with the corresponding
> performance penalties.) We'd also need the concept of a "default"
> comprehensive state. So if you evaulate a simple state and this extra
> pointer is NULL, but the previous state's pointer wasn't, you would
> diff against the default state first. This way you could recover from
> a state that does things like change glTexEnv or sets up a funky blend
> function.
Well, I *think* that's my (1) above - although maybe not. (1) above
is NOT a lazy evaluation scheme...although you could make it so at
some cost.
The bottom line for me is that this stuff simply isn't common enough
to warrant all the work and complexity.
I need to be convinced that there are enough nasty things that
ssgSimpleState can't handle to make this worthwhile. Right now,
I'm very reluctant to add a single line of code to ssgState
or ssgLeaf or their descendants because doing so slows down every
single SSG application by a measurable amount.
Certainly the FlightGear moon doesn't come even close to meeting
that criteria since all this work would slow *everyone* down a
little - yet providing no speedup at all to FlightGear! To the
contrary - it would actually slow FGFS down some too!
I grant that something in ssgSimpleState is going to have to change - but
the driving force for that change is the growing trend to have multiple
texture maps per polygon without using multipass tricks.
--
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: Norman V. <nh...@ca...> - 2000-08-19 12:43:22
|
Steve Baker writes:
>
>"Curtis L. Olson" wrote:
>
>> Hmmm, yes, for flightgear, there are a couple things I'd like to see
>> added to ssg's lazy state evaluator ...
>
>What - specifically?
>
>> Let me jump in here and say that I'm not exactly 100% pleased with
>> handling these things via a call back function. The call back has no
>> way to know the initial state of the element you are interested in
>> changing. So, how do you reliably restore the value? How do you know
>> if you need to actually change the state or not? You are back to all
>> the problems associated with randomly changing state at random points
>> in your program ... these are the sorts of problems ssgSimpleState was
>> designed to fix.
>
>Well, that's why you have to decide which things to test before EVERY
>leaf node is drawn - and which to set and restore in callbacks.
A slightly different but related question.
Is it possible to design a branch node that does some of this ?
By this I mean that I know that everything below this node
will share a common property. Hence short circuting some state
change tests at the leaf level for all deeper nodes.
This would allow programs such as flightgear that use
a higher level bucketing mechanism then OpenGL primitives
to minimize state changing when traversing the tree
I can envision a similar node type being used for compiled vertex arrays,
simplistically
bucket node ( lock vertices and set transform here when
entering bucket )
/ | \ ( if node passes Bounding Sphere
test )
/ | \
mat1 mat2 mat3 ( set display states here )
/ | \ ( should these nodes have Bounding
Spheres ?)
/ | \
Fan Fan Strip ( set texture coordinates and Fine grained BS
based Display )
Maybe just a 'short-circut-me' bit in the SimpleState
and a would allow this
Does this make any sense ??
Norman
|
|
From: Curtis L. O. <cu...@in...> - 2000-08-19 16:22:03
|
Steve Baker writes:
> > Hmmm, yes, for flightgear, there are a couple things I'd like to see
> > added to ssg's lazy state evaluator ...
>
> What - specifically?
Here are the additional things that the flight gear sky needs to
control:
- GL_DEPTH_TEST (enable/disable)
- GL_FOG (enable/disable) We don't change the fog function,
and the fog parameters are global,
but this might change somewhat if we
want to impliment some sort of extra
"punch through" for lights
- glBlendFunc()
> For things in callbacks, you know the default state because you can
> set it before calling ssgCullAndDraw and be sure that SSG won't
> mess with it (unless I have an error). Then you have to set it
> (unconditionally) to what you want in the pre-Draw and restore it
> to the default state in post-Draw.
>
> Whether it's better to use that mechanism or a lazy evaluation
> mechanism depends on:
>
> * The cost to test whether the state is already what you need
> MULTIPLIED by the number of leaf nodes that DON'T use that
> state.
>
> Versus:
>
> * The cost to redundantly set and unset the state MULTIPLIED by the
> number of leaf nodes that need that state.
>
> When the number of leaf nodes containing the state is small, it's
> better to use a callback and suffer the cost of switching it redundantly.
>
> When the number of leaf nodes containing the state is large, it's
> worth paying the penalty to check for it in order to save redundant
> state changes.
This is all true from a pure performance perspective. Perhaps I
should just give up on the idea of building a completely drop in sky
that will work with any ssg friendly application.
> Now - where that balance lies clearly depends on the application.
> Take something like glTexEnv. I have probably used it once - on
> one leaf node once during my entire career. For me at least, this
> doesn't warrant putting into ssgSimpleState - it's FAR better to
> put it into a node callback.
What I'm arguing for is some sort ssg mechanism that helps the user do
this robustly ...
> Look at something like glBindTexture though - and every single
> leaf node needs to be checked - so it's worth putting into
> ssgSimpleState.
>
> Notice also that with draw callbacks, you can put them higher
> up in the scene graph - so if you have an entire character in
> a game that needs some peculiar glBlendFunc (a Ghost for example),
> then you can put the state change up at the root of that
> objects scene graph rather than on every leaf node.
>
> The problem here is that SSG is used for a lot of things - and
> my personal choice of what things should or should not make it
> into ssgSimpleState may not agree with yours...so we should
> discuss the matter and see where we should compromise.
I'm not opposed to leaving ssgSimpleState essentially as it is, I'm
just wishing that ssg provided some mechanism to thelp the application
robustly handle management of some of these less common states.
> > So I suppose I could hack in my own tracking variables and sort of
> > parallel what ssgSimpleState is doing ...
>
> That's very hard to do because your post-draw callback can't tell
> whether some other leaf node (without a pre-draw callback) will be
> drawn next or whether you can safely leave the state at this
> new (non-standard) setting ready for the next leaf node that
> needs it.
Exactly why it would be nice to have some sort of ssg mechanism to
assist with this.
> Worse than that. You'd have to apply it to EVERY leaf node.
You could impliment a state management extension scheme at the cost of
one extra check per node. If this check indicates there is extra
state info for this node (or the previous node), then you branch off
and do all the extra work to handle it. Or in the case that the
current node has no extra state info, but the previous node did, you
would have to do extra work to restore all the changed items to their
default state.
> Yep. But you absolutely cannot mix ssgSimpleStates with other
> state management schemes.
I'd argue that you could (as described above) at the cost of one extra
check per node.
> Well, as I've explained, you can't do that because when this
> ssgExtendedState leaf node finishes rendering, it mustn't leave the
> extended state elements turned on because a subsequent
> ssgSimpleState doesn't do the testing to turn it back off again.
> That's why it's all-or-nothing...and why I don't want to do this.
You could keep an extra variable around ... something like:
bool last_node_had_extended_state;
If you process a node with extended state you set this to false.
If you process a node without extended state (but this variable is
true) then you do the extra work of restoring the less common states
to their defaults, then you set this variable to false.
> I'd be VERY interested to hear which states you think are common
> enough to need to be changed lazily and which ones can be set in
> callbacks. Since you are building a flight sim - and I'm not
> unfamiliar with the needs of such programs :-) ...I can't imagine
> what you are changing that is so commonly required.
I think we are approaching this from different mind sets.
You are talking in terms of performance and commonly used states.
I am talking in terms of developing robust applications that have some
sensible, reliable scheme to manage all the state changes needed by
the application. It's critical for an application with the scope and
number of participant such as flightgear, that we get a handle on
*all* the state changes and do it in a consistant, robust manner.
Mixing and matching schemes points you straight down the road to
disaster. FlightGear has been dancing on the edge throughout it's
entire existance. I'm searching for a way to resolve these issues.
As it is, I keep having to go back and try to figure out which global
state change in one part of the code is messing up the rest of the
code. This is hard, it is frustrating, it is time consuming, and each
time I have to do it I hate the mess even worse. I want a nice, well
thought out, robust way to deal with this.
The most sensible place to start with this (I believe) is inside ssg.
> Yes - but that's ONE leaf node (probably). You can't possibly justify
> adding another conditional test before every single one of the 10,000
> or so other leaf nodes you are probably drawing just to save...well - nothing
> actually. You still have to switch to the special blend mode before
> drawing the moon - and it would be restored again by the very next polygon
> to be drawn - lazy state evaluation would save you exactly nothing in that
> case.
>
> If you had (say) 100 moons to draw randomly throughout the scene - then
> I might be pursuaded.
>
> This example is a CLASSIC case of why I don't want to put the blendfunc
> into ssgSimpleState.
... and it is a CLASSIC case of why ssg needs some mechanism to handle
these state changes.
What if I want to drop the FlightGear sky module into some application
that doesn't use the default blend function? Now my sky will break
that application, and perhaps do it in a non-obvious way. These
global state screw ups can suck up huge amounts of debugging time for
large complex applications where lots of people have their fingers in
the pie.
Yes, we can (and do) make do with what we have. We find work arounds,
we debug the state screw ups ... until the next time someone needs to
change or use one of these uncommon states at which point we are
plunged right back into the front end of this whole process of
figuring out why our rendering is all screwed up (again).
> No - you just have to turn the blend mode back to 'normal' in the
> post-draw callback.
Which you can't do in the case of my sky code because it doesn't
necessarily know what "normal" is for the host application.
> I think that this could be attacked in one of two ways:
>
> 1) We could add code for all the rarely used states which would
> be tested for in one step in ssgState. ie we'd have a "Weird State"
> flag that ssgSimpleState would test for. If that flag were to
> be TRUE, then it would do a lot of unconditional state changes
> and tell the leaf node to call a special restoration function
> after the user's post-draw callback was called. That adds two
> more conditionals to every leaf node - but we could perhaps
> win that back by moving some of the more obscure existing
> ssgSimpleState lazy elements into the non-lazy code.
>
> 2) Documentation. We need to write down precisely which state
> elements SSG chooses to manage - and which ones the application
> is responsible for. We also need to write down the default states
> of those elements.
>
> Remember about the 'which item Steve prefers in a list' thing? :-)
I don't think we can just document away all the difficulties here. I
prefer the approach I described above which is similar to your (1) but
only costs one extra test per node ... until you hit something that
uses the extended state mechanism. But you, the application writer,
understand that you maybe trading some performance for a reliable
extended state handling scheme. But in the case of flightgear, this
will only happen on a couple nodes per frame so the actual perfomance
cost will be minimal.
> That's certainly an issue. But for *just* the moon, I'd toss in a
> dirty 'glGet' to find the current blend mode so you can restore it
> in post-draw. Once per frame isn't going to kill anyone.
Is this really true? I've never tried it glGet() in the primary
render loop. I'd imagine for current PC consumer cards or Mesa based
drivers this would be fast, but what about higher end system? What
about disrupting the render pipeline? This sounds ugly. :-)
> Well, as I explained before, it isn't that simple because if
> ssgHyperExtendedState doesn't clean up the wierd stuff it changed
> then the next ssgSimpleState that comes along will have to do so.
> That's an additional cost for every ssgSimpleState which you can't
> justify unless there are a heck of a lot of ssgHyperExtendedState
> leaf nodes out there.
Well, it's only one test per node, well more like one if statement:
if ( ssgHyperExtendedState != null || ssgLastStateWasHyperExtended ) {
// process ssgHyperExtenedState
}
processing a null ssgHyperExtendedState would be defined as restoring
(anything that was previously changed) back to ssg defaults.
> Well, I *think* that's my (1) above - although maybe not. (1) above
> is NOT a lazy evaluation scheme...although you could make it so at
> some cost.
>
> The bottom line for me is that this stuff simply isn't common enough
> to warrant all the work and complexity.
And I will argue that it is *important* enough for building *robust*
applications that we do need some mechanism to assist the application
in reliably managing these less used states.
> I need to be convinced that there are enough nasty things that
> ssgSimpleState can't handle to make this worthwhile. Right now,
> I'm very reluctant to add a single line of code to ssgState
> or ssgLeaf or their descendants because doing so slows down every
> single SSG application by a measurable amount.
I have no idea how many hours I've spent trying to chase down state
problems in flight gear. To be fair, some of these have been due to
my own stupidity or lack of understanding of opengl, some of this has
been do to Mesa bugs, but much of this could be saved (or prevented in
the future) by adding some mechanism to help manage these state
changes robustly.
Most of the arguments that led you to develop ssgSimpleState should
apply here to extended states as well. Certainly performance is a
consideration, but so is code robustness and code maintainability for
larger projects. Maybe your typical game is hacked together in a year
or so and has a shelf life of a couple of months ... a few dirty
tricks here or there isn't going to hurt anyone, and even if it does,
six months down the line no one will care. But FlightGear is a *long*
term application ... any hack we do now will come back to bite us
later. I've seen it happen many times already.
> Certainly the FlightGear moon doesn't come even close to meeting
> that criteria since all this work would slow *everyone* down a
> little - yet providing no speedup at all to FlightGear! To the
> contrary - it would actually slow FGFS down some too!
I would honestly pay that price if it meant we gained a sensible way
to deal with all our state headaches.
Sooner or later, (actually just sooner) the flightgear project is
going to need some good mechanism to deal with these less common state
changes. It will have to either go into the FlightGear code, the
SimGear code, or the ssg code.
I vote for putting it into ssg, but perhaps I'll have to settle for
some other place if that's not possible.
Curt.
--
Curtis Olson Human Factors Research Lab Flight Gear Project
Twin Cities cu...@hf... cu...@fl...
Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org
|
|
From: Sam S. <sa...@sp...> - 2000-08-19 20:11:36
|
Well it's nice to know that there was a simple answer, and I didn't open a can of worms or anything :) |
|
From: Steve B. <sjb...@ai...> - 2000-08-11 08:43:31
|
Gil Carter wrote:
> >Probably it would be best to
> >have the performance monitor both in the engine and the modeler.
> >In the engine for the developer, so that he can see the performance
> >where it matters, with sound and ai etc going on.
> >In the modeler, the developer can quickly make changes, for example
> >that car model is too slow - lets try it with opaque windows.
>
> Ok, but keep in mind that you're not just measuring how long it takes to
> render your car - you're really benchmarking the performance of PPE as
> well. Even though PPE is underpinned by PLIB, if you're developing models
> for a game, your game engine is really the place to benchmark.
PPE (when not actually being given mouse clicks or key events) simply
calls PLIB's SSG "ssgCullAndDraw" in a pretty tight loop.
If you set it up with the same clip planes, FOV and resolution as the
game, then it will produce identical timings for those graphics that are
done in SSG...obviously, the game's own menu's and icons won't get
timed.
That's as close as a separate application could possibly be.
So, that's why ssgStatistics needs to be a simple class you can add to
your game *as well* as in PPE. In PPE it'll give the artist a good 'first
look' at the kind of performance he can expect. Not perfect - nothing can
be - but since it saves him saving the model, shutting down PPE, starting the
game, playing through to the desired spot and *THEN* turning on the stats,
it's MUCH more likely that he'll actually check performance frequently.
I think that's a valuable tool - even if it's "off" by 10%.
> Maybe PPE could have a "preview" mode which goes fullscreen with no menus,
...the menu's don't redraw unless you click on them or something changes.
They impose no load just be 'being there'...hence no need to get rid of them.
> ...and just renders the current model with trace enabled to give you an idea
> of what type of performance you'll get in a standalone app.
Once 'gotcha' is that the very act of measuring stats costs time (a kind of
Heisenberg uncertainty effect!) - so you NEVER can get perfect statistics!
> There are
> issues of still having all of the other OpenGL resources consumed to keep
> PPE alive in background, but at least you're not rendering four views of
> the model plus the user interface at each frame :-)
PPE can run happily with a single 3D window. The four-view mode is optional.
You aren't re-displaying the GUI each frame - only if it changes.
--
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: Sam S. <sa...@sp...> - 2000-08-10 12:44:33
|
Hi, > I'd *really* like to help with this. Documentation is a pretty vital part > of getting newbies running, so I'll see what I can do in this regard. I'm > thinking of HTML page per class, with member variables and methods > documented. Yes, the advantages of having the functions (and variables) documented in the source code can't be under estimated. I was first introduced to this when programing on the Amiga (all the public OS functions were documented in this way). It's _very_ useful. It means that if someone adds a function they can document before the cvs commit, and the documentation automatically gets updated. And you won't believe the number of bugs you catch when you start documenting functions individually :) > Ideally, a code fragment also, but that relies on having a lot > of little code fragments! > > The Java guys use a neat system called Javadoc, which allows comments > embedded in code to be cross-compiled into documentation. You need to use > some special tags in the comments for the parser to find, but it works > really nicely if people do it as they go. Assuming that the comments are > up to date, a documentation update is as simple as running the Javadoc > parser through the source. http://java.sun.com/products/jdk/javadoc/ if > you're interested. This is from the Javadoc FAQ: ---- A10. Can I run javadoc on source files from other languages, such as C, C++ or VisualBasic? No. Javadoc runs only on Java source code. See the previous question for the explanation. However, other vendors have worked on such documentation tools. They are listed at the bottom of this page. ---- > There are a number of packages which do the same thing for C++, and I was > going to have a look at Doxygen, which seems to be quite popular - > http://www.stack.nl/~dimitri/doxygen/ I'll post some findings about this; > the last thing I want is to suggest other developers use some weird > commenting system which most people will just ignore. It has to be easy > enough to use that it's almost no effort. I've used doxygen for my current project and it's very easy to use - I was going to suggest it for plib before this post. It's along the lines of: /** * Brief class Description * @author Me! * @bug Doesn't work - at all! * Long class description - HTML tags are <B>allowed</B> */ class MyClass { public: int score; // Current score // I know Steve hates the // comments - you can also do this: /** * Current damage */ int damage; /** * Brief function description * @param x x offset - must be >0 * @param y y offset - must be > 0 * @return a new y position * Long description here * @see AnotherFunction() */ int GenNewY ( int x, int y ) ; }; Etc.. It actually understands a fair amount of comment formats, so you don't have to use the styles above (although I would suggest we pick a style and stick to it). The documentation (for functions), be with the prototype or the declaration. It will generate it's documentation in HTML, man page format, RTF, and LaTeX. It will even convert embedded HTML tags into the man, LaTeX and RTF formats. It will embed PDF-style links into the LaTeX file so it can be converted to a PDF with hyperlinks intact. It also automatically generates inheritence diagrams, and also (in the later versions) collaboration diagrams! If you use doxysearch on the site you can site the documentation online. This is quite useful as you can search for bug or todo and get a list of functions back. IMHO doxygen is fantastic, and I wouldn't hestitate to recommend it. You can look at the generated documentation for my project (spacething) at: http://www.spacething.org/development/docs/ An example of the graphical inheritence diagrams is at: http://www.spacething.org/development/docs/inherits.html (scroll down the page a bit) and an example collaboration diagram: http://www.spacething.org/development/docs/class_enobject.html It's a bit of a mess (code and structure wise), but you should be able to see what doxygen is capable of. On my site it's set up so that the documentation is automatically regenerated whenever a cvs commit is completed (well actually twenty minutes afterwards). A similar autogeneration can be set up on sourceforge (apparently - I haven't tried it yet, but they tell me it's possible). I've never had any trouble _what__so_ever_ when using the development versions of doxygen - the author has a very high standard. Since the development release has many more features than the stable, if you choose to use doxygen I'd go with that one. > Comments? I really would like to suggest doxygen. :) Sam |
|
From: Joel U. <joe...@ya...> - 2000-08-10 17:00:31
|
Sam Stickland wrote: > > > Comments? > > I really would like to suggest doxygen. :) I tried doxygen, and five other packages, many seemed very buggy - doxygen crashed. I was impressed with it up to that point (!) But I couldn't get it to generate docs for me. I didn't spend too long on it - eventually deciding on using perceps. It is an 80k perl script which does autogenerated docs. Its used by the ClanLib project. I don't think it does some of the nifty things the latest doxygen does (from your sample pages) but it is easy to ship inside your source package, therefore not adding any dependencies. It also uses style templates to generate its html - so you can make the manual pages all have the same look of your choosing. I agree very much with inline docs - javadoc is lovely (I just started using it at Uni 2 weeks ago), and with an api as changing as SSg is right now... Whatever you choose, I'd be willing to comment any of the ssg classes in the required style, from the current manual. Bye - Joel. |
|
From: Sam S. <sa...@sp...> - 2000-08-11 14:44:51
|
----- Original Message ----- From: "Wolfram Kuss" <w_...@rz...> To: <pli...@li...> Sent: Friday, August 11, 2000 2:55 PM Subject: Re: [Plib-devel] Work outstanding. > Steve wrote: > > >> >For example, it would be GREAT to know how much > >> >texture-swapping there is going on, but I doubt this can be done > >> >portably? > >> > > >However, real hardware can be VERY subtle > > Yes, I know. Generally speaking, I loved optimizing till about 10 > years ago. Until then, you could pretty much tell beforehand whether a > change would speed up the program. But with several caches, pipelines > that are filled by compilers, branch prediction etc it has become much > harder and sometimes when I optimized something for speed I ended > up making it slower :-(. > > >Since this question is unanswerable in a portable manner, > > That's what I feared. > > >So, these are NOT good questions to ask! > > Ok, I realize that there is no portable way to measure things, no one > answer (after all, not all users have the same > hardware), its not clearly defined etc. > But I still think a ballpark figure could help enormously. I think > it can still happen that large parts of the time per frame is spent in > texture swapping. Here's an idea. You could still take a stab at the amount of texture memory _consumed_ even if not the amount _available_. It's still not all the simple since you'd need to know which mipmap levels are in use - I'm not sure you can do that. But what would be useful would be a list of all the textures currently in use by the ssg scenegraph (even if they are culled/never textured with), and by clicking on them you could replace that texture with the dummy red/white check pattern. If you notice a sudden increase in frame rate then you know that on this particular hardware, with this scene-graph, looking in that direction from that viewpoint that texture swapping is happening.. Heh, not get I suspose but it would be a useful UI. "Hey, this model is rendering really slowly let's try turning that texture off". You could write a function that could monitor the frame rate and automatically try replacing texturing to look for swapping but I think that's about as far as you can go. Would it be practical to have some kind of playback/record mechanism in ssg or is that too much work, or too much of an impact in performance? Anyone know of any opengl texture management articles that cover scaling back the textures in use automatically? Sam |
|
From: Steve B. <sjb...@ai...> - 2000-08-19 20:28:13
|
"Curtis L. Olson" wrote: > > Steve Baker writes: > > > Hmmm, yes, for flightgear, there are a couple things I'd like to see > > > added to ssg's lazy state evaluator ... > > > > What - specifically? > > Here are the additional things that the flight gear sky needs to > control: > > - GL_DEPTH_TEST (enable/disable) I bet you are turning this off for the same reason that I used to - which is the advice in the RedBook (which I may actually have passed on to you) that says that you should try to keep the far-clip plane as close as possible to the eye. It turns out that this was poor advice (although strictly speaking not incorrect) - a fact which is explained here: http://web2.airmail.net/sjbaker1/love_your_z_buffer.html There are *still* some circumstances where turning of Z-test is good - but there are a lot less of them than there ought to be. > - GL_FOG (enable/disable) We don't change the fog function, > and the fog parameters are global, > but this might change somewhat if we > want to impliment some sort of extra > "punch through" for lights We could add a Fog enable/disable fairly cheaply since ssgSimpleState tests all the enable/disable flags in parallel. > - glBlendFunc() That's one of the things that I'd prefer to avoid. > This is all true from a pure performance perspective. Perhaps I > should just give up on the idea of building a completely drop in sky > that will work with any ssg friendly application. Yikes! If pursuasion fails - use bribery! :-) > You could impliment a state management extension scheme at the cost of > one extra check per node. If this check indicates there is extra > state info for this node (or the previous node), then you branch off > and do all the extra work to handle it. Or in the case that the > current node has no extra state info, but the previous node did, you > would have to do extra work to restore all the changed items to their > default state. Yep - that's basically what I suggest in my non-preferred solution. > You could keep an extra variable around ... something like: > > bool last_node_had_extended_state; > > If you process a node with extended state you set this to false. Well, it could be another flag in the flags field that ssgSimpleState currently maintains. > I think we are approaching this from different mind sets. > > You are talking in terms of performance and commonly used states. Yes. > I am talking in terms of developing robust applications that have some > sensible, reliable scheme to manage all the state changes needed by > the application. It's critical for an application with the scope and > number of participant such as flightgear, that we get a handle on > *all* the state changes and do it in a consistant, robust manner. > Mixing and matching schemes points you straight down the road to > disaster. FlightGear has been dancing on the edge throughout it's > entire existance. I'm searching for a way to resolve these issues. > As it is, I keep having to go back and try to figure out which global > state change in one part of the code is messing up the rest of the > code. This is hard, it is frustrating, it is time consuming, and each > time I have to do it I hate the mess even worse. I want a nice, well > thought out, robust way to deal with this. > > The most sensible place to start with this (I believe) is inside ssg. Well, basically, there is some messiness to handle - and it could rest in the application or inside SSG. The relative benefits depend on the frequency of usage again. If it's something that every application needs - then clearly SSG is a good place for it. If only one application wanted it - then obviously SSG is not the right place. This problem falls somewhere between those two extremes. The entire reason that SSG has callback functions in DRAW is to allow application-specific extensions. Some Scene Graph API's have taken the conscious decision to COMPLETELY hide OpenGL from the application (OpenSG for example takes this philosphy - I was talking to it's author at the SigGraph Papers' party and contrasting this behaviour with SSG's). I don't think you'd like that. SSG takes the approach that Performer takes which is NOT to attempt to be all things to all men - but to at least provide enough hooks to make anything possible - with some effort on the application side at least. > What if I want to drop the FlightGear sky module into some application > that doesn't use the default blend function? Now my sky will break > that application, and perhaps do it in a non-obvious way. These > global state screw ups can suck up huge amounts of debugging time for > large complex applications where lots of people have their fingers in > the pie. Yep...but moving that debugging into SSG doesn't help that. If it's a feature that most applications will use, you are saving most people that debugging effort - but moving bugs down into a layer where you can't see them doesn't help where just one or two applications are concerned. > Yes, we can (and do) make do with what we have. We find work arounds, > we debug the state screw ups ... until the next time someone needs to > change or use one of these uncommon states at which point we are > plunged right back into the front end of this whole process of > figuring out why our rendering is all screwed up (again). I think the majority of your (and my) problems with debugging state management has been because Mesa is/was broken. Various push/pop attrib commands weren't working, the ambient lighting code was broken, etc, etc. Since I've started using the nVidia drivers, I've not had a single state management problem. > > No - you just have to turn the blend mode back to 'normal' in the > > post-draw callback. > > Which you can't do in the case of my sky code because it doesn't > necessarily know what "normal" is for the host application. glPushAttrib/glPopAttrib ? Call one in pre-draw and the other in post-draw. > > That's certainly an issue. But for *just* the moon, I'd toss in a > > dirty 'glGet' to find the current blend mode so you can restore it > > in post-draw. Once per frame isn't going to kill anyone. > > Is this really true? I've never tried it glGet() in the primary > render loop. I'd imagine for current PC consumer cards or Mesa based > drivers this would be fast, but what about higher end system? What > about disrupting the render pipeline? This sounds ugly. :-) It certainly does cause a pipeline flush on SGI machines - but it doesn't kill performance on nVidia drivers or any of the software T&L setups that I know of. Hoever, glPushAttrib/glPopAttrib are pipelinable - I already use them in PUI. > > Well, as I explained before, it isn't that simple because if > > ssgHyperExtendedState doesn't clean up the wierd stuff it changed > > then the next ssgSimpleState that comes along will have to do so. > > That's an additional cost for every ssgSimpleState which you can't > > justify unless there are a heck of a lot of ssgHyperExtendedState > > leaf nodes out there. > > Well, it's only one test per node, well more like one if statement: > > if ( ssgHyperExtendedState != null || ssgLastStateWasHyperExtended ) { > // process ssgHyperExtenedState > } > > processing a null ssgHyperExtendedState would be defined as restoring > (anything that was previously changed) back to ssg defaults. Yes - I guess so. > > The bottom line for me is that this stuff simply isn't common enough > > to warrant all the work and complexity. > > And I will argue that it is *important* enough for building *robust* > applications that we do need some mechanism to assist the application > in reliably managing these less used states. Well, as I said, *I* don't want to spend the effort to do this. If you can cause minimal impact to performance, I'll accept a change to ssgSimpleState to handle complex state changes - but I don't have the time (or the inclination) to go to the hassle of writing and debugging such a thing myself. > I have no idea how many hours I've spent trying to chase down state > problems in flight gear. To be fair, some of these have been due to > my own stupidity or lack of understanding of opengl, some of this has > been do to Mesa bugs, but much of this could be saved (or prevented in > the future) by adding some mechanism to help manage these state > changes robustly. Well, I know that essentially ALL the hours I've spent doing this have been a complete waste because ALL the bugs were eventually shown to be in Mesa - every one of them. I think the ssgState code in the very first revision of SSG was in fact perfect! > > Certainly the FlightGear moon doesn't come even close to meeting > > that criteria since all this work would slow *everyone* down a > > little - yet providing no speedup at all to FlightGear! To the > > contrary - it would actually slow FGFS down some too! > > I would honestly pay that price if it meant we gained a sensible way > to deal with all our state headaches. I think if you simply employed an appropriate glPushAttrib in your pre-draw callback and a glPopAttrib in post-draw and did your 'special' state setting there, you'd have no problem - except for those in Mesa that you can't fix with any of these mechanisms. You'd have a couple of special state hacks in the sky model - but that's really about it. You need to spend 8 years arguing with the Performer team to gain some perspective on what level of perfection to expect if you still want performance! -- 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