Re: [Flightgear-devel] Re: [Plib-devel] Texture border (ATI performance issue)
Andy Ross wrote: Again, read the specification. The texture border (or border color, if there is no border) is *always* supposed to be sampled at the texture edges when using GL_CLAMP. But look at the pictures in the RedBook - they clearly show the texels from the edges of the map being repeated out to the edge of the polygon. That's with GL_CLAMP. Steve Baker - HomeEmail: [EMAIL PROTECTED]WorkEmail: [EMAIL PROTECTED] HomePage : http://web2.airmail.net/sjbaker1 Projects : http://plib.sf.nethttp://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Plib-devel] Texture border (ATI performance issue)
Andy Ross wrote:
I've been playing with the new ATI linux drivers recently. It turns
out that they have a performance problem that gets tickled by plib.
Plib allows you to pick wrapped or clamped texture borders when you
create your ssgTexture. To get the clamping, it uses the original
GL_CLAMP mode, instead of OpenGL 1.2+ GL_CLAMP_TO_EDGE.
The problem is that the original OpenGL texture border behavior, as
specified, isn't implemented by any consumer hardware. It requires
that the border color (or texture border) be sampled at the edge of
the texture. Most drivers (at least NVidia's and DRI) actually cheat,
and treat GL_CLAMP as a synonym for GL_CLAMP_TO_EDGE.
I think you have it wrong.
EVERY card implements GL_CLAMP because all that it requires is that
the texture coordinates are clamped to the range 0..1.
Very few cards implement GL_CLAMP_TO_EDGE - it was added to OpenGL
because it does a better visual job of stitching together the edges
of textures. However, it's extremely messy to implement in hardware,
so it's very frequently kludged. At least one OpenGL card actually
doubles the dimensions of your texture map in order to kludge a
solution to GL_CLAMP_TO_EDGE.
I don't believe that ATI don't have an efficient implementation of
GL_CLAMP mode...nearly every software package out there uses it.
I think the problem is in texture borders - but PLIB never uses
texture borders because (as you sortof understand) they are either
not implemented, inefficiently implemented or flakey and with weird
restrictions.
Since Plib doesn't provide control over the texture border, existing
plib applications (at least FlightGear) actually *depend* on this
misinterpretation. Running FlightGear under software Mesa creates
dark lines in the runways where the default black border is sampled
between the tiled textures.
That doesn't happen with GL_CLAMP unless you ask for a texture border
and PLIB doesn't do that. None of my games exhibit that problem under
software Mesa.
In order to access the texture border colour, you have to specify
GL_TRUE as the sixth parameter ('border') of glTexImage2D.
None of the PLIB texture loaders do that...but PLIB *does* allow
the application to load the textures - so it's possible for the
App to screw things up.
There is something deeply fsck'ed up going on here. The basic PLIB
implementation doesn't use anything that every graphics card back
to the Voodoo-1 didn't have.
+#ifdef GL_VERSION_1_2
+# define PLIB_CLAMP_MODE GL_CLAMP_TO_EDGE
+#else
+# define PLIB_CLAMP_MODE GL_CLAMP
+#endif
+
glTexParameteri ( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S,
-wrapu ? GL_REPEAT : GL_CLAMP ) ;
+wrapu ? GL_REPEAT : PLIB_CLAMP_MODE ) ;
glTexParameteri ( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T,
-wrapv ? GL_REPEAT : GL_CLAMP ) ;
+wrapv ? GL_REPEAT : PLIB_CLAMP_MODE ) ;
This is DEFINITELY NOT RIGHT - DO NOT COMMIT THIS PATCH.
I think this is a FGFS problem. Texture borders are a
notoriously flakey feature.
Search all the places where FGFS loads textures and change the
'border' parameter to FALSE - I think that'll solve all your
problems.
Alternatively - try one of my games (tuxkart for example) and
see if they run really slowly or not. I predict they'll run
just fine.
Steve Baker -
HomeEmail: [EMAIL PROTECTED]WorkEmail: [EMAIL PROTECTED]
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.nethttp://tuxaqfh.sf.net
http://tuxkart.sf.net http://prettypoly.sf.net
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Plib-devel] Compile errors with new ssg
Norman Vine wrote:
The following change allows FlightGear to compile with the PLIB CVS
...yes - but if DummySphereEntity didn't inherit an implementation
of getStats from either ssgLeaf or ssgBranch then it must be derived
directly from an ssgEntity.
That's really a BIG no-no because every time I add something to the
abstract base class 'ssgEntity', FGFS will have to add the corresponding
function into DummySphereEntity and it'll be very hard to keep FGFS working
over more than one version of PLIB.
Inheriting from an abstract base class of code you don't own is considered
to be bad programming practice.
In the SSG documentation, it says:
It is presumed that applications will add new kinds of leaves,
branches, states and textures to customise SSG to their needs.
...it doesn't say anything about adding new kinds of ssgEntity.
What is particularly dangerous is that in many places in SSG, we do things
like:
ssgEntity *e = something ;
if ( e - isAKindOf ( ssgTypeBranch () ) )
{
ssgBranch *b = (ssgBranch *) e ;
...do something branch-like (probably recursively)...
}
else
{
ssgLeaf *l = (ssgLeaf *) e ;
...do something leaf-like...
}
This code will crash if there is a DummySphereEntity in the scene.
There can only be two kinds of node in a tree-like data graph - there
are leaves and branches - there are no other kinds of nodes that you
could possibly imagine.
Hence, your DummySphereEntity really should derive from either ssgLeaf
or ssgBranch. I suspect ssgLeaf is the right choice - but I don't know
for sure.
If there is something wrong with the implementation of either ssgLeaf
or ssgBranch that prevents you from using one of them as the base
class for DummySphereEntity - then let's talk about fixing the problem
at the root cause.
Persisting with the present mechanism will bring FGFS no end of problems
down the line as SSG expands it's functionality.
Steve Baker -
HomeEmail: [EMAIL PROTECTED]WorkEmail: [EMAIL PROTECTED]
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.nethttp://tuxaqfh.sf.net
http://tuxkart.sf.net http://prettypoly.sf.net
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Plib-devel] Antialiased GLUT fonts #2
Andy Ross wrote: Sebastian Ude wrote: What you generated are neither GLUT bitmap nor GLUT stroke fonts (the only place where you usually find *these* fonts is the GLUT sourcecode !), but TXF fonts / textured fonts / font textures. These fonts have hardly anything to do with *GLUT*. Clearly I'm ignorant of the history here. My memory is that Mark Kilgard wrote this library and distributed it along with glut... No - it was never (to my knowledge) distributed with GLUT. Mark had a general OpenGL Hints page when he worked at Silicon Graphics - and it was still up there about a year ago (although since Mark moved to work for nVidia, it didn't get maintained). However, SGI took down their public server that held employee's (and ex-employee's) web sites - and now that site is hosted on www.opengl.org : http://www.opengl.org/developers/code/mjktips/TexFont/TexFont.html from which it got picked up by plib et. al. We only *use* the files that TexFont generates - none of Mark's actual code is employed - we just parse his file format - and I used his tool to generate the sample fonts that come with PLIB/FNT. However with your tool, all this can change. I guess I did (vaguely) know that glut bitmap fonts were a different animal, but I just assumed that all of these formats had been rolled into the default glut distribution. Nope. - Steve Baker --- Mail : [EMAIL PROTECTED] WorkMail: [EMAIL PROTECTED] URLs : http://www.sjbaker.org http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net http://freeglut.sf.net http://toobular.sf.net http://lodestone.sf.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: BGL Loader for PLIB
Jürgen Marquardt wrote: Hi Steve, Hello Flighgear Developers, I followed your projects since quite a long time now.. As I am interested in 3D programming very much but didn't find the time to dig into it, I recently decided to write a BGL loader for PLIB. I reused the MDL loader part of PLIB with the BGL patch of John Tsao as a starting point. From there I enhanced it quite a lot so that by now I am able to load some free BGL sceneries found in the web. Up to now I can load the static part of the sceneries of FS5, FS98 and FS2000 BGL files into PPE and Flightgear with more or less success. The loader is not yet finished but I think it is somehow stable and I feel that it's time to share the patch (against PLIB 1.42) if you're interested. Sure! Sounds like a useful thing to have. I think you should announce this on the plib-devel mailing list and someone will help you get it integrated into the latest CVS version of PLIB. - Steve Baker --- Mail : [EMAIL PROTECTED] WorkMail: [EMAIL PROTECTED] URLs : http://www.sjbaker.org http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net http://freeglut.sf.net http://toobular.sf.net http://lodestone.sf.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Plib-users] LINUXTAG 2002
Alex Perry wrote: I propose that the PLIB project takes a community booth at LinuxTag http://www.linuxtag.org June 6-9 this summer in Karlsruhe Germany. This PLIB USERS booth would be a place for the dozen-odd projects that conspicuously incorporate plib (and any others that join in) to show off their projects, compare notes and have a lot of fun. If you think this is a good idea, please discuss it in the mailing lists of the individual projects and then let _me_ know how many people are interested in turning up. I need an idea of the number of interested people, so I can ask for a sensible-sized booth for us all to occupy (I'll not mention a certain heavily overfull booth last year 8-) Do you think there are enough interested people who could make it to Germany to do this? - Steve Baker --- Mail : [EMAIL PROTECTED] WorkMail: [EMAIL PROTECTED] URLs : http://www.sjbaker.org http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net http://freeglut.sf.net http://toobular.sf.net http://lodestone.sf.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Plib-devel] Nvidia specific drawing and plib/Flightgear
Marten Stromberg wrote: Roman Grigoriev wrote: Guys could you please explain me some state of things 1) plib and vertex arrays Does this feature implement yet in plib or not if not mybe there are some suggestions how to make it As I understand now plib works with display lists this can speed up rendering process but if we use vertex arrays it will be more faster so we can run for example ./configure --with-nvidia-ext as I understand when I load models from 3ds I should get vertexes normals and texture coordinates for separate arrays and locate them to card memory or there are another way? PLIB supports vertex arrays already - but whether the model loaders generate vertex arrays or one of the several other data structures is an open issue. It's hard to make them do what *everyone* wants simultaneously. 2) multitexturing and plib To implement lightmaps for FGFS (light lobes) I need multitexturing The process: 1) read all poligons vertexes,normals,texcoords 2) use multitexturing 3) compute lightmaps 4) apply main texture and lightmaps texture Any suggestions how to make it using plib I don't think PLIB should be taking on the task of generating the lightmaps. But multitexture support is clearly a critical thing we need to implement fairly soon. We have discussed how to implement multitexturing support, and it turns out to be pretty hard to do without causing minor performance penalties for single-textured geometry. To be realistic, I do not think you will se it happen until the next major release of PLIB (but I promise to try and push it the best I can). Well, I'd like to get a minor/stable release done fairly soon so we can move on with some of these major issues. The last time I suggested we do that, a few people said they needed to fix a few items - so I held off from doing that - but we need to re-visit that. What does everyone need to do before we make a new stable release? - Steve Baker --- Mail : [EMAIL PROTECTED] WorkMail: [EMAIL PROTECTED] URLs : http://www.sjbaker.org http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net http://freeglut.sf.net http://toobular.sf.net http://lodestone.sf.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Profiling run
David Megginson wrote: I did another run, with a flight of over one hour on autopilot. Cumulatively, ssgEntity::cull_test and ssgBranch::cull use nearly 20% of CPU time -- that's OK, as long as the framerate improvements justify the work. Yes - that's probably not too bad...but with it narrowed down that closely, you can probably squeeze some performance out of them. Probably, most of that time is actually spent in int sgFrustum::contains ( const sgSphere *s ) ...my Scene graph API that I wrote for use at work is quite a but cleverer about how it does this. The 'contains' test in SG measures the distance from the center of the sphere to each of the four planes of the view frustum. In fact, you can improve on this by remembering which faces of the frustum the PARENT OBJECT SPHERE's passed cleanly and not bother to test against them in future. You end up needing to write about 64 different functions - each hand-optimised to test a sphere against a different combinations of the six faces of the frustum. Then you can compute a number that indicates to objects lower in the tree which version of that function to call when they need to test their spheres. This results in most spheres' not needing to be tested at all - and for those that do need to be tested, most need only one sphere-to-plane calculation. That's quite a lot of typing - but it's not actually that hard to do. I can see room for some easy plib optimizations. For example, the program spent 2.95% of its time in ssgVtxTable::getNumVertices, 1.91% of its time in ssgVtxTable::getNumColours and 1.8% of its time in ssgVtxTable::getNumTexCoords. All of these might be able to be optimized to cache the result, rather than counting through the arrays each time (if they do that currently), and it looks like the saving could be significant. That certainly seems like a VERY big number - but all of those routines are simply fetching a member variable via a pointer. They are declared 'inline' - but since they are probably also 'virtual' that may still result in a function call. The only way I can imagine they are consuming that much time would be if they are called a heck of a lot of times. Probably there are some loops: for ( int i = 0 ; i getNumVertices() ; i++ ) ...whatever... ...so 'getNumVertices' get called (unnecessarily) in every loop. It might be worth copying the value into a variable first or even running the loop backwards to avoid calling the function every time. On our side, the biggest hog is FGHitList::IntersectBranch, with 3.96% of CPU time. I assume that's calculating the ground elevation, but any optimizations might be helpful, if people can think of one. In my experience, there are often some great ways to optimise those kinds of functions. But guys - get this into perspective. If you take a routine that consumes only 1% of the CPU and you make it go 100 times faster, how much faster does the program run? Less than 1% faster. It's not worth the effort to do that unless you think you can get comparable speedups in every single function in the program. All you can possibly do is to optimise things that are up there in the 20% range...and even then, you won't do much to improve performance...you'll never manage to double the speed of the program for example! If you don't see things consuming considerably more than 20% of the CPU, you need to look for major *structural* improvements rather than line-by-line optimisations. - Steve Baker --- Mail : [EMAIL PROTECTED] WorkMail: [EMAIL PROTECTED] URLs : http://www.sjbaker.org http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net http://freeglut.sf.net http://toobular.sf.net http://lodestone.sf.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
