[ quesa-Bugs-907855 ] TriMesh shading wrong when no vertex normals are present

[SourceForge.net <no...@so...>]

Bugs item #907855, was opened at 03/01/04 13:21
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907855&group_id=45158

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Dair Grant (grantd)
Assigned to: James W. Walker (jwwalker)
Summary: TriMesh shading wrong when no vertex normals are present

Initial Comment:
(note, this issue could also be solved by bug 907849, as any 
triangles that shared vertex attributes would push us onto the 
break-down-and-push-into-tribuffer path)


--------------

When rendering a TriMesh with no vertex UVs in Quesa 1.6d16, the 
shading is interpolated across each triangle, as if we had vertex 
normals.  The correct appearance would be for each triangle to 
have a uniform shading, for a faceted appearance.  See attached 
sample 3DMF and picture showing the result in QD3D and Quesa.

--------------

OK, had a quick look at this. The problem is that the triangles in 
the TriMesh share vertices, and we don't correctly handle the case 
where a shared vertex inherits different values from the triangles 
which reference it.

The model was of a box, so if you consider two of the top/face 
triangles like:

        /|         |
     V_______
     |
  /  |
  ---|
  \  |

I.e., on triangle on the top of the box whose normal points up, and 
one triangle on the side of the face whose normal points out.

What happens at the moment is that when we're looking for the 
normal for V, we check to see if V specifies it. It doesn't, so we 
pick the first triangle which references V and use its normal. This 
then means that when the second triangle is rendered, it also 
references V and so ends up with the wrong normal (which 
produces the smoothed off effect).

The general way to handle this is to introduce new vertices into the 
TriMesh when we see that shared vertices have different parents - 
it looks like this is what QD3D was doing, as the same problem 
occurs with colours (e.g., if the top triangle was red and the side 
one was blue, you would get an all-red and all-blue triangle in 
QD3D: but we'll do a red-to-blue fade over the two triangles).


----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 08/15/05 19:00

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: James W. Walker (jwwalker)
Date: 08/01/05 09:05

Message:
Logged In: YES 
user_id=433183

I belieive this is now fixed in CVS for the interactive renderer.

----------------------------------------------------------------------

Comment By: James W. Walker (jwwalker)
Date: 07/27/05 22:51

Message:
Logged In: YES 
user_id=433183

Does this actually refer to vertex normals, not vertex UVs?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=907855&group_id=45158