been working with the cylinder primitive without end caps (topClosed & bottomClosed = false) and noticed the vertex normals for the verts at the open ends seem to be getting calculated as if the end polygons are still there instead of just averaging the 2 adjacent face normals

The cylinder primitive has recently been refactored to solve some issues with the vertex normals being shared between the cap and the sides (which is not desirable in the first place.) Are you using the latest version off of GitHub? If you are, please post a screenshot of the issue and file a bug in the GitHub issue tracker.

Cheers
/R

Hi Richard, yeah I just did a fresh git pull and the issue is still there. I don’t have a screenshot that demonstrates the issue, but it’s easy to verify with a cylinder with segmentsW = 4 and topClosed & bottomClosed = false. The first vertex is an upper corner and lies along the x-axis. The vertex normal should then be 1,0,0 but the vertexNormalData is showing .7071, .7071, 0 as if the normal is computed including an end cap face normal

Hey Choons,

I don’t understand what the problem is. Had a quick look to the primitive without end caps and everything looks normal to me. Could you explain a bit better, perhaps with some images illustrating the problem?

yeah a vertex normal is supposed to be an average of the face normals of the adjacent faces that contain the vertex. For a cylinder without end caps in the default position with its medial axis aligned on the y-axis, all vertex normals (and face normals) should only have horizontal components (no y component). The vertexNormalData for verts that are at the top and bottom edges of the cylinder are showing y-component values when topClosed & bottomClosed = false. That would be correct if there were end caps, but isn’t right when there’s not

Thanks for insisting Choons

I’ve fixed the issue: http://www.lidev.com.ar/tests/away3d/cylinder_normals/

coolio. yeah just one of those little things. Thanks, Li

EDIT: just checked it out. The vertex normal looks correct now for direction, but I think it needs to be normalized into a unit vector?

Thank you once again Choons, fixed, keep at it with the sharp eye!