Closed GoogleCodeExporter closed 8 years ago
This is a classic problem of not keeping the projection and model view
transforms
separate. http://www.opengl.org/resources/faq/technical/projection_abuse.php
Original comment by sknau...@wesleyan.edu
on 3 May 2008 at 11:38
I have the same problem and I think I know how to avoid this.
Some vertices on these polygons get negative fog coords, which the OpenGL fog
coord
extension doc say should be avoided. When I force all negative values to 0.0,
the
problem dissapears. I'm attaching a patch.
Original comment by j...@molb.org
on 19 Oct 2009 at 9:16
Attachments:
Ok, there's more to this problem. My previous patch just made it less obvious
that
something's wrong.
First of all, the flickering is due to my r300 dri opengl driver's wierd
behaviour
when it encounters negative fog coords. Doing glFogfCoordEXT(f) on my machine is
equal to glFogfCoordEXT(fabsf(f)). This means there is too much fog whenever a
negative fog coord is encountered.
Setting the fog coord to zero in these cases looks nicer, but unfortunately is
also
incorrect and in most situations results in not enough fog being displayed.
On a driver that supports negative fog coordinates (like mesa software rendering
seems to), this should not be done because it is incorrect and looks worse. On
my
driver this looks better, but I guess it would be better to change this in the
driver
then.
I cannot think of an easy workaround for this problem. I think the glide64
plugin
avoids this by clipping all triangles at the near z-plane, which means all fog
coord
values should be positive, but this is not that easy to implement.
Also, the rice plugin already does _sometimes_ (but not always) replace
negative fog
coords with zero (like my previous patch does always). I have no idea if this is
intentional, but this results in the above mentioned wrong renderings in some
situations.
(Look for objects that look foggier then their background for example in
Majora's
Mask, initial cutscene, and compare with glide64.)
I'm attaching a one-line patch that removes this "feature", so on graphics
cards,
where negative coords work, the fog rendering should look correct. With the r300
driver it flickers even more of course, but I think people with this driver
should
just disable fog for now.
Original comment by j...@molb.org
on 21 Oct 2009 at 1:36
Attachments:
does this trouble was fixed in SVN revisions?
2 j...@molb.org :
your 2st patch not work for me (it did worst), but 1st patch work very good,
big thank.
Original comment by Virusma...@gmail.com
on 19 Jan 2010 at 6:44
I've tried a few configuration options with this.
in mupen64plus.cfg:
==========================================
[Rice-Video]
EnableFog = True
# this, by itself, is ok.
FogMethod = 0/1/2
# 0 disables fog, 1 (auto) leaves it up to the software and 2 forces fog.
===========================================
1 results in the worst texture flickering/disappearance.
2 is slightly better than 1 but still flickers a lot.
0 is the same as "EnableFog = False"; no fog, no flicker, no awesome.
Original comment by saicanek...@gmail.com
on 20 Jan 2011 at 7:08
To be more precise:
1 - let the n64 emulator choose (this is the default).
The "mode 2" (force) have been created for some users that experiments fog
probs (some objects without fog appear in the fog wich is sometime ennoying)
Original comment by dorian.f...@gmail.com
on 20 Jan 2011 at 6:06
Fixed in the main repo:
https://github.com/mupen64plus/mupen64plus-video-rice/commit/b04c8953d09e33210b5
2dd418bb289c55dda2e55
Original comment by dorian.f...@gmail.com
on 10 Dec 2014 at 1:18
Original issue reported on code.google.com by
richard...@gmail.com
on 29 Mar 2008 at 6:33