Thread: Re: [Plib-devel] Texture and blend modes (Page 2)
Brought to you by:
sjbaker
Menu
▾
▴
plib-devel
|
From: Curtis L. O. <cu...@me...> - 2000-08-21 18:05:47
|
Steve Baker writes:
> glPushAttrib/glPopAttrib ?
>
> Call one in pre-draw and the other in post-draw.
Those are nifty little calls, when did they get added? :-)
So you are saying I could do something like the following:
static int predraw( ssgEntity *e ) {
glPushAttrib( GL_ENABLE_BIT | GL_DEPTH_BUFFER_BIT );
glDisable( GL_DEPTH_TEST );
glDisable( GL_FOG );
return true;
}
static int postdraw( ssgEntity *e ) {
glPopAttrib();
return true;
}
This unfortunately yields rendering problems ... can you see anything
obvious that I am doing wrong or misunderstanding here?
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: Norman V. <nh...@ca...> - 2000-08-21 18:40:12
|
Curtis L. Olson writes:
>
>So you are saying I could do something like the following:
>
> static int predraw( ssgEntity *e ) {
>
> glPushAttrib( GL_ENABLE_BIT | GL_DEPTH_BUFFER_BIT );
Maybe Try
glPushAttrib( GL_FOG_BIT | GL_DEPTH_BUFFER_BIT );
>
> glDisable( GL_DEPTH_TEST );
> glDisable( GL_FOG );
>
> return true;
> }
>
> static int postdraw( ssgEntity *e ) {
> glPopAttrib();
>
> return true;
> }
>
|
|
From: Curtis L. O. <cu...@me...> - 2000-08-21 18:58:35
|
Norman Vine writes: > Maybe Try > glPushAttrib( GL_FOG_BIT | GL_DEPTH_BUFFER_BIT ); Yes, I tried that ... 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-21 23:08:44
|
"Curtis L. Olson" wrote:
>
> Steve Baker writes:
> > glPushAttrib/glPopAttrib ?
> >
> > Call one in pre-draw and the other in post-draw.
>
> Those are nifty little calls, when did they get added? :-)
Erm - was there an OpenGL before 1.0 ? :-)
> So you are saying I could do something like the following:
>
> static int predraw( ssgEntity *e ) {
>
> glPushAttrib( GL_ENABLE_BIT | GL_DEPTH_BUFFER_BIT );
>
> glDisable( GL_DEPTH_TEST );
> glDisable( GL_FOG );
>
> return true;
> }
>
> static int postdraw( ssgEntity *e ) {
> glPopAttrib();
>
> return true;
> }
Yes - exactly...although pushing and popping ALL the enable bits is
perhaps a tad drastic...
There is a 'gotcha' here. Since the pre-draw callback is called BEFORE
ssgState::apply() is called, your 'pop' will also have undone any glEnable
or glDisable's that ssgSimpleState may have done. Since ssgSimpleState
doesn't know that you did that, it'll assume that whatever it enabled
or disabled is *STILL* that way when the next state is applied - and since
it's lazy - it won't re-enable anything that it *thinks* is already
enabled.
So you need to either be rather surgical and save only exactly the
things that need saving (and I'm not sure if the granularity of the
attribute stack allows you to be that precise)...OR you could do an
if ( e -> hasState () ) e->getState()->force() ;
...just AFTER your glPopAttrib - or (more obscurely - but more
efficiently) an
if ( e -> hasState () ) e->getState()->apply() ;
...just BEFORE your glPushAttrib.
Either of these *should* fix up any problems you might have in a
clean manner.
> This unfortunately yields rendering problems ... can you see anything
> obvious that I am doing wrong or misunderstanding here?
Well, apart from the slight subtlety I explain above, as I mentioned
before - Mesa has bugs in glPush/Pop attrib (or at least *had* - past
tense - I havn't played with recent versions).
--
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...@in...> - 2000-08-22 02:39:26
|
Steve Baker writes:
> > So you are saying I could do something like the following:
> >
> > static int predraw( ssgEntity *e ) {
> >
> > glPushAttrib( GL_ENABLE_BIT | GL_DEPTH_BUFFER_BIT );
> >
> > glDisable( GL_DEPTH_TEST );
> > glDisable( GL_FOG );
> >
> > return true;
> > }
> >
> > static int postdraw( ssgEntity *e ) {
> > glPopAttrib();
> >
> > return true;
> > }
>
> Yes - exactly...although pushing and popping ALL the enable bits is
> perhaps a tad drastic...
>
> There is a 'gotcha' here. Since the pre-draw callback is called BEFORE
> ssgState::apply() is called, your 'pop' will also have undone any glEnable
> or glDisable's that ssgSimpleState may have done. Since ssgSimpleState
> doesn't know that you did that, it'll assume that whatever it enabled
> or disabled is *STILL* that way when the next state is applied - and since
> it's lazy - it won't re-enable anything that it *thinks* is already
> enabled.
Let's see if I understand ...
I am (by definition) not tweaking any states that ssg normally would
manage. But, since these states are grouped, and doing a
glPushAttribute() saves a whole slew of states, I may unwittingly
alter a state that ssg *does* manage as a side effect of my
glPopAttribute()
> So you need to either be rather surgical and save only exactly the
> things that need saving (and I'm not sure if the granularity of the
> attribute stack allows you to be that precise)...OR you could do an
>
> if ( e -> hasState () ) e->getState()->force() ;
>
> ...just AFTER your glPopAttrib - or (more obscurely - but more
> efficiently) an
>
> if ( e -> hasState () ) e->getState()->apply() ;
>
> ...just BEFORE your glPushAttrib.
>
> Either of these *should* fix up any problems you might have in a
> clean manner.
Urrrggggg ... brainnn ... can't ... quite .... reach ...
Hold on, let me find a stool.
Ok, that's better ...
I'll give it a try in my sky code ...
Here's what I get now:
no matching function for call to `ssgEntity::hasState ()'
no matching function for call to `ssgEntity::getState ()'
A check of ssg.h indicates that these are indeed not members of
ssgEntity.
But, the compiler lets me get away with this ... sound reasonable?
ssgLeaf *f = (ssgLeaf *)e;
if ( f -> hasState () ) f->getState()->apply() ;
I'll play around with this some more. I'm still having a touch of bad
luck with GL_DEPTH_TEST, but I'm forcing this in other places in my
code too. Could be that I'm entering the code with it off and since
the sky code is actually preserving the state rather than turning it
[back] on when it is done, I could be exiting they sky rendering
section with the state set different now.
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: Curtis L. O. <cu...@me...> - 2000-08-22 21:06:50
|
Steve, Does plib provide any facilities for drawing or not drawing an object based on relative view angle? I'm pondering how I might impliment directional lights such as VASI for runways ... lights that change color depending on your relative angle to them. Thanks, 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-22 22:35:41
|
> Steve,
>
> Does plib provide any facilities for drawing or not drawing an object
> based on relative view angle? I'm pondering how I might impliment
> directional lights such as VASI for runways ... lights that change
> color depending on your relative angle to them.
Hi, I'm not Steve but I think you could use the predraw callback to do this.
Something like:
int myCB ( ssgEntity *entity)
{
/* Get the camera position */
sgVec3 camPos ;
ssgGetCurrentContext () -> getCameraPosition ( pos ) ;
/* Get the objects position */
sgVec3 objPos ;
sgSetVec3 ( objPos, entity -> getBSphere () -> getCenter () ) ;
/* Work out the angle between the two objects, and based on that either
change the colour of the light ... */
sgVec4 *col = (ssgLeaf *) (entity) -> getColour ( blah) ;
sgSetVec4 ( *col, 1.0f, 0.0f, 0.0f, 0.5f ) ;
/* etc, you could also use getState() and alter that */
/* Choose to draw the object by returning TRUE to FALSE */
return TRUE;
}
Does that do the trick?
Sam
|
|
From: Curtis L. O. <cu...@in...> - 2000-08-23 01:25:41
|
Sam,
Thanks for the response. I'm not sure if the specifics of what you
describe will work, but perhaps the general approach would.
The view direction doesn't really affect the choice I want to make.
The object position and view position produce one vector, but that
needs to be compared to a vector defining the optimal view direction
of the object.
Perhaps we would need to derive a new ssgSelector type class that
saves this directional vector and some tolerance and then does the
comparison when the scene graph is traversed.
Curt.
Sam Stickland writes:
> Hi, I'm not Steve but I think you could use the predraw callback to do this.
> Something like:
>
> int myCB ( ssgEntity *entity)
> {
> /* Get the camera position */
> sgVec3 camPos ;
> ssgGetCurrentContext () -> getCameraPosition ( pos ) ;
>
> /* Get the objects position */
> sgVec3 objPos ;
> sgSetVec3 ( objPos, entity -> getBSphere () -> getCenter () ) ;
>
> /* Work out the angle between the two objects, and based on that either
> change the colour of the light ... */
>
> sgVec4 *col = (ssgLeaf *) (entity) -> getColour ( blah) ;
>
> sgSetVec4 ( *col, 1.0f, 0.0f, 0.0f, 0.5f ) ;
>
> /* etc, you could also use getState() and alter that */
>
> /* Choose to draw the object by returning TRUE to FALSE */
>
> return TRUE;
> }
>
> Does that do the trick?
>
> Sam
--
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-23 04:34:13
|
"Curtis L. Olson" wrote:
> Does plib provide any facilities for drawing or not drawing an object
> based on relative view angle?
Nope. You could add it as a new ssgSelector node type I suppose.
> I'm pondering how I might impliment
> directional lights such as VASI for runways ... lights that change
> color depending on your relative angle to them.
I could get *shot* for revealing a trade secret here - so get your
brain nice and comfortable - and I'll just say two words...
"Environment Maps"
...'nuff said? No? Well think harder!
VASI lights have to change colour gently BTW - they go through
a definite 'pink' phase between the red and white light colours.
A sudden 'blink' between the two colours is VERY distracting at
*just* the time when distraction would be "A Bad Thing" :-)
--
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-24 18:25:46
|
Steve, In ssg is there a way to control whether a texture is set to "repeat" or not? As I start working on runways I'm starting to notice some artifacts. I want to slap a texture down on top of a specific area and have the texture cover it completely ... texture coordinates of lower corner are (0,0), upper corner are (1,1), etc. Now, what I'm finding is that if I have a texture that is all black along one edge and all white along the other edge, I get some bleed across to the opposite edge ... i.e. some of that white on one edge scrolls around and shows up on the opposite edge and visa versa for the black ... this makes it really ugly to piece together adjacent textures because you always can see the joint because of this bleed across. I'm assuming this is because the ssg textures are by default set to repeat, right? Do you have any strategies you can share for avoiding this problem? Thanks, 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: Amit B. <am...@de...> - 2000-08-24 19:25:36
|
Try moving your texture coordinates in by 1/2 a texel. So if your texture is 256x256, instead of using (0,0)-> (0,1) use ( 0.5 / 256 , 0.5 / 256 ) -> ( 0.5 / 256 , 1.0 - 0.5 / 256) etc. You get the idea. -Amit ----- Original Message ----- From: "Curtis L. Olson" <cu...@me...> To: <pli...@li...> Sent: Thursday, August 24, 2000 11:25 AM Subject: [Plib-devel] texture repeating > Steve, > > In ssg is there a way to control whether a texture is set to "repeat" > or not? > > As I start working on runways I'm starting to notice some artifacts. > > I want to slap a texture down on top of a specific area and have the > texture cover it completely ... texture coordinates of lower corner > are (0,0), upper corner are (1,1), etc. > > Now, what I'm finding is that if I have a texture that is all black > along one edge and all white along the other edge, I get some bleed > across to the opposite edge ... i.e. some of that white on one edge > scrolls around and shows up on the opposite edge and visa versa for > the black ... this makes it really ugly to piece together adjacent > textures because you always can see the joint because of this bleed > across. > > I'm assuming this is because the ssg textures are by default set to > repeat, right? > > Do you have any strategies you can share for avoiding this problem? > > Thanks, > > 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 > _______________________________________________ > plib-devel mailing list > pli...@li... > http://lists.sourceforge.net/mailman/listinfo/plib-devel > |
|
From: Curtis L. O. <cu...@me...> - 2000-08-24 22:10:10
|
Amit Bakshi writes: > Try moving your texture coordinates in by 1/2 a texel. > > So if your texture is 256x256, instead of using (0,0)-> > (0,1) use ( 0.5 / 256 , 0.5 / 256 ) -> ( 0.5 / 256 , 1.0 - 0.5 / 256) > etc. You get the idea. Hmmm, this seems to help on the higher mipmap levels but not when I get further from the object, the bleed through starts showing up again. I wonder if it is the ssg mipmap generation routine that is doing this (assuming the texture will be tiled this is what you want) but assuming the texture isn't going to be tiled, you don't want this. Steve, is there anyway to control this aspect of mipmap generation in ssg? Thanks, 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-25 02:21:21
|
Amit Bakshi wrote:
>
> Try moving your texture coordinates in by 1/2 a texel.
>
> So if your texture is 256x256, instead of using (0,0)->
> (0,1) use ( 0.5 / 256 , 0.5 / 256 ) -> ( 0.5 / 256 , 1.0 - 0.5 / 256)
> etc. You get the idea.
No - that's not the right answer. Check my previous post.
--
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-25 02:20:15
|
"Curtis L. Olson" wrote: > In ssg is there a way to control whether a texture is set to "repeat" > or not? Sure - that's the second and third parameters of ssgSimpleState::setTexture(). > I want to slap a texture down on top of a specific area and have the > texture cover it completely ... texture coordinates of lower corner > are (0,0), upper corner are (1,1), etc. Yes - that's correct. > Now, what I'm finding is that if I have a texture that is all black > along one edge and all white along the other edge, I get some bleed > across to the opposite edge ... A classic problem - which setting non-repeating clamps will cure completely. > i.e. some of that white on one edge > scrolls around and shows up on the opposite edge and visa versa for > the black ... this makes it really ugly to piece together adjacent > textures because you always can see the joint because of this bleed > across. Joining two textures is a harder problem...for which I wrote a FAQ: http://web2.airmail.net/sjbaker1/tiling_textures.html > I'm assuming this is because the ssg textures are by default set to > repeat, right? Yes - by default they repeat because that's what most people want. > Do you have any strategies you can share for avoiding this problem? Check out the FAQ...I just re-read it and I think it covers everything. It's all rather disappointing for the purist though. -- 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-25 03:52:04
|
> "Curtis L. Olson" wrote:
> > In ssg is there a way to control whether a texture is set to "repeat"
> > or not?
Steve Baker writes:
> Sure - that's the second and third parameters of
> ssgSimpleState::setTexture().
Ahah, your a genius! Whups, make that "you're".
> A classic problem - which setting non-repeating clamps will cure
> completely.
Yes, setting the wrapu / wrapv to FALSE totally fixed this particular
problem. But it didn't help with the mipmap bluring when viewing my
runways from edge on ... or the problem where different sections of
the runway with different textures can't always have the same ft/pixel
ratio so the mipmapping choices don't always blend nicely from one
section to the next.
Runways are hard to get looking nice ... :-(
FYI, here's what I've got so far (as viewed from a mipmap friendly
vantage point)
http://www.menet.umn.edu/~curt/fgfs/Gallery/Link/kmsp-runway.html
> Joining two textures is a harder problem...for which I wrote a FAQ:
> http://web2.airmail.net/sjbaker1/tiling_textures.html
It's probably obvious to everyone (and now to myself as well) that you
also need to have a consistant ft/pixel ratio along the edge you are
matching... this could be something worth mentioning in the FAQ.
> It's all rather disappointing for the purist though.
This whole mipmapping scheme sucks for edge on runways which is the
view you see them at 95% of the time ... generating "squat" textures
(more resolution cross-wise than length-wise) helps a lot but still
leaves a *lot* to be desired. :-(
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: Gil C. <g.c...@ca...> - 2000-08-25 06:00:42
|
At 11:53 PM 8/24/00 -0500, Steve wrote: <snip> >At work, we don't use texture for runway markings - but in the absence >of antialiased polygon edges, you don't have a whole lot of choice... >although I've been playing with antialiasing on the GeForce cards - and >it looks pretty good...*almost* identical to SGI's ONYX in quality - >perhaps even slightly better at some angles. A chance for me to pick Steve's brains :-) Runways are the classic application for anisotropic texture mapping aren't they? Angus Dorbie's demos for Performer show it pretty nicely at http://www.sgi.com/software/performer/brew/anisotropic.html Interestingly, Cass Everitt from nVidia has recently posted a whitepaper on anisotropic texture mapping in OpenGL (in MS Word format of course...) at: http://www.nvidia.com/Marketing/Developer/DevRel.nsf/bookmark/9944854B211F6FC98825691F005C7EEF plus a simple demo showing GL_EXT_texture_filter_anisotropic on nVidia hardware. Source is available, and I think it's just a GLUT application so it might build under Linux. Would anisotropic texturing help Curt's problems in Flightgear? Thanks, Gil |
|
From: Steve B. <sjb...@ai...> - 2000-08-25 04:48:55
|
"Curtis L. Olson" wrote: > Yes, setting the wrapu / wrapv to FALSE totally fixed this particular > problem. Good! > But it didn't help with the mipmap bluring when viewing my > runways from edge on ... or the problem where different sections of > the runway with different textures can't always have the same ft/pixel > ratio so the mipmapping choices don't always blend nicely from one > section to the next. > > Runways are hard to get looking nice ... :-( Yep. The most critical object in the scene - drawn at the worst possible angle at a place in the scene where the polygon count is largest and where we can least tolerate poor frame rates. Then the white lines on black tarmac are the highest contrast thing in the scene and the thin side-stripes are most inclined to alias. It would be hard to pick a nastier case. At work, we don't use texture for runway markings - but in the absence of antialiased polygon edges, you don't have a whole lot of choice... although I've been playing with antialiasing on the GeForce cards - and it looks pretty good...*almost* identical to SGI's ONYX in quality - perhaps even slightly better at some angles. > FYI, here's what I've got so far (as viewed from a mipmap friendly > vantage point) > > http://www.menet.umn.edu/~curt/fgfs/Gallery/Link/kmsp-runway.html I would add a tarmac-to-grass blend into the texture at the edges of the runway to avoid the polygon aliasing along the outer edges of the white stripes. > > Joining two textures is a harder problem...for which I wrote a FAQ: > > http://web2.airmail.net/sjbaker1/tiling_textures.html > > It's probably obvious to everyone (and now to myself as well) that you > also need to have a consistant ft/pixel ratio along the edge you are > matching... this could be something worth mentioning in the FAQ. I guess - I kinda thought it was obvious - but it's hard to argue that ANYTHING is obvious in a FAQ answer. > > It's all rather disappointing for the purist though. > > This whole mipmapping scheme sucks for edge on runways which is the > view you see them at 95% of the time ... generating "squat" textures > (more resolution cross-wise than length-wise) helps a lot but still > leaves a *lot* to be desired. :-( The answer is definitely 'RIPmapping' - but it's disappointingly implemented only rarely on 'real' hardware. -- 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-25 12:50:09
|
Gil Carter wrote: > > At 11:53 PM 8/24/00 -0500, Steve wrote: > > <snip> > > >At work, we don't use texture for runway markings - but in the absence > >of antialiased polygon edges, you don't have a whole lot of choice... > >although I've been playing with antialiasing on the GeForce cards - and > >it looks pretty good...*almost* identical to SGI's ONYX in quality - > >perhaps even slightly better at some angles. > > A chance for me to pick Steve's brains :-) > > Runways are the classic application for anisotropic texture mapping aren't > they? Angus Dorbie's demos for Performer show it pretty nicely at > http://www.sgi.com/software/performer/brew/anisotropic.html Yes - hence my comment about the applicability of RIPmapping. That's the simplest form of anisotropic mapping - and it would be pretty easy to implement on modern 3D hardware (but AFAIK, they are NOT currently designed to do that...although Cass's paper suggests that maybe nVidia DO have the relevent hardware). Angus' implementation is also in OpenGL - but entails picking the appropriate map in realtime. There are other (and better) ways to do anisotropic mapping - but all the other alternatives (that I'm aware of) do very bad things to pixel fill rates. But it's all rather academic - these things are not implemented - so we are somewhat screwed. > Would anisotropic texturing help Curt's problems in Flightgear? Yes - it would help the 'texture going fuzzy on approach' problem...although whether it's worth the effort *just* for the nVidia cards....? -- 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-25 14:55:53
|
Steve Baker writes: > Yes - hence my comment about the applicability of RIPmapping. That's the > simplest form of anisotropic mapping - and it would be pretty easy > to implement on modern 3D hardware (but AFAIK, they are NOT > currently designed to do that...although Cass's paper suggests that > maybe nVidia DO have the relevent hardware). > > Angus' implementation is also in OpenGL - but entails picking the appropriate > map in realtime. > > There are other (and better) ways to do anisotropic mapping - but all the > other alternatives (that I'm aware of) do very bad things to pixel fill > rates. But it's all rather academic - these things are not implemented - so > we are somewhat screwed. > > > Would anisotropic texturing help Curt's problems in Flightgear? > > Yes - it would help the 'texture going fuzzy on approach' problem...although > whether it's worth the effort *just* for the nVidia cards....? Steve, I notice that the X-Plane flight sim (www.x-plane.com) gets around the mipmap bluring problem by completely turning mipmapping off. The tradeoff is the class pixel mishmash ... Just for fun, is there an easy way to turn off mipmap generation in ssg? Perhaps for lower end cards I could just give the user a chance to choose their poison ... 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: Amit B. <am...@de...> - 2000-08-25 17:34:09
|
> Just for fun, is there an easy way to turn off mipmap generation in > ssg? Perhaps for lower end cards I could just give the user a chance > to choose their poison ... > > Curt. Curt, I was under the impression that mipmapping does in fact speed up the rasterization of "far away" textured objects. This is due to the cache misses a full size texture would have when the texel/pixel ration gets high. In fact you'll see some drivers that auto-generate mipmapped textures agains your will ( some NVidia drivers do/did that under Win32 ). |
|
From: Steve B. <sjb...@ai...> - 2000-08-25 18:35:58
|
Amit Bakshi wrote:
>
> > Just for fun, is there an easy way to turn off mipmap generation in
> > ssg? Perhaps for lower end cards I could just give the user a chance
> > to choose their poison ...
> I was under the impression that mipmapping does in fact speed up
> the rasterization of "far away" textured objects.
That's true under certain circumstances.
However, GL_LINEAR_MIPMAP_LINEAR requires you to read EIGHT texels
for every pixel on the screen where GL_NEAREST requires only one -
and perhaps the cache benefit vanishes under those circumstances...
so it depends somewhat on which mode you pick.
Anyway, Curt's concern is more as a way to try to control
the blurriness that's evident with MIPmapping of polygons that are
edge on - and which have strong features in the direction of foreshortening.
> This is due to the cache
> misses a full size texture would have when the texel/pixel ration gets high.
Yes - exactly. The smaller MIPmaps come closer to fitting into the texture
hardware's cache. For some devices (eg the Intel I810 cards that store
textures in main memory and fetch them via AGP) the effect is dramatic -
for others (like the older Voodoo's that don't have texture cache), there
is no effect.
> In fact you'll see some drivers that auto-generate mipmapped textures
> agains your will ( some NVidia drivers do/did that under Win32 ).
Hmmm - that's unacceptable IMHO.
--
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-28 01:30:32
|
At 07:54 AM 8/25/00 -0500, Steve Baker wrote: <snip> > > Would anisotropic texturing help Curt's problems in Flightgear? > >Yes - it would help the 'texture going fuzzy on approach' problem...although >whether it's worth the effort *just* for the nVidia cards....? Good point. I've done a little searching around, and discovered that anisotropic filtering is also supported by the ATI Radeon and Matrox G400 (and presumably on the upcoming G800). It's not on the Voodoos or TNT/TNT2 or the Rage series, so it's definitely not going to be something everybody can use. Gil |
|
From: Steve B. <sjb...@ai...> - 2000-08-25 16:52:54
|
"Curtis L. Olson" wrote: > I notice that the X-Plane flight sim (www.x-plane.com) gets around the > mipmap bluring problem by completely turning mipmapping off. The > tradeoff is the class pixel mishmash ... Yep - an aliasing nightmare - I don't regard that as an acceptable solution. Aliasing is *evil*. > Just for fun, is there an easy way to turn off mipmap generation in > ssg? Perhaps for lower end cards I could just give the user a chance > to choose their poison ... Sure - this is like the discussion we had the other day about changing texture parameters. Any of these shoulf work: * Create the texture yourself - pass the GL texture handle to ssgState, since the filter mode *is* a part of the binding, it'll be set how you need. * Let SSG load an ssgTexture - then do an 'apply' of the ssgState (so the texture will be the currently bound one) - change the glTexParameteri - and it'll stay changed when the ssgState is re-applied...or just: ssgTexture *tx = new ssgTexture ( "whatever.rgb" ) ; glBindTexture ( GL_TEXTURE_2D, tx->getHandle() ) ; glTexParameteri ( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR ) ; glTexParameteri ( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR ) ; glBindTexture ( GL_TEXTURE_2D, 0 ) ; * Write a derived class of ssgTexture that sets different glTexParameters. * Add it into ssgTexture and offer it back as an SSG enhancement. I don't think you'll like the results though. -- 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-25 18:05:20
|
Steve Baker writes: > Yep - an aliasing nightmare - I don't regard that as an acceptable > solution. Aliasing is *evil*. Ok, I made the appropriate changes to ssg, but I agree, this sort of aliasing is evil ... I could reduce the effects by lowering the contrast of markings vs. surface but yuck ... Would you like the changes for ssg anyway ... they are pretty minimal ... > Sure - this is like the discussion we had the other day about changing > texture parameters. > > Any of these shoulf work: > > * Add it into ssgTexture and offer it back as an SSG enhancement. > > I don't think you'll like the results though. Ok, I'm offering if you want the changes, but you are right ... the results in this case are not acceptable. 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-25 18:57:09
|
"Curtis L. Olson" wrote:
>
> Steve Baker writes:
> > Yep - an aliasing nightmare - I don't regard that as an acceptable
> > solution. Aliasing is *evil*.
>
> Ok, I made the appropriate changes to ssg, but I agree, this sort of
> aliasing is evil ... I could reduce the effects by lowering the
> contrast of markings vs. surface but yuck ...
Old Evans&Sutherland image generators didn't have MIPmapping and used
'contrast clamping' to manage aliasing - it didn't work all that well,
but it was certainly better than doing nothing. They altered the texture
contrast as a function of range and orientation.
I'm not sure that helps.
> Would you like the changes for ssg anyway ... they are pretty minimal ...
Yes please.
> Ok, I'm offering if you want the changes, but you are right ... the
> results in this case are not acceptable.
There *are* cases where disabling MIPmapping and linear-blending is
useful though (the Icons on the bottom of the TuxKart screen and
the text in PLIB/FNT are two examples).
--
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