rclark559 / mupen64plus

Automatically exported from code.google.com/p/mupen64plus
0 stars 0 forks source link

Fog bug in Rice Video #30

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
The following bug was reported on Emutalk:

 * when polygons cross the near-Z clipping plane, they change to a solid
white or gray color
 * fog is being miscalculated for very close polygons, and washing out the
color
 * this can be seen in many parts (including the intro) of Zelda: OOT

Original issue reported on code.google.com by richard...@gmail.com on 29 Mar 2008 at 6:33

GoogleCodeExporter commented 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

GoogleCodeExporter commented 8 years ago
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:

GoogleCodeExporter commented 8 years ago
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:

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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