Add meshing for Cone

[Jondolf]

Objective

The Cone primitive should support meshing.

Solution

Implement meshing for the Cone primitive. The default cone has a height of 1 and a base radius of 0.5, and is centered at the origin.

An issue with cone meshes is that the tip does not really have a normal that works, even with duplicated vertices. This PR uses only a single vertex for the tip, with a normal of zero; this results in an "invalid" normal that gets ignored by the fragment shader. This seems to be the only approach we have for perfectly smooth cones. For discussion on the topic, see #10298 and #5891.

Another thing to note is that the cone uses polar coordinates for the UVs:

This way, textures are applied as if looking at the cone from above:

[HackerFoo]

Diagrams for positions, normals, and UVs would make the math easier to follow.

[Jondolf]

For now I just added better comments explaining the math and logic. I can maybe try making some simple diagrams too if I can make clean ones, but personally I think text is probably enough here.

[rparrett]

I'm not sure what properties would contribute to this self-shadowing-like effect specifically on the cone shape. Is some shadow code just not jiving well with the tip normal setup? Normals look fine.

Not a blocking comment, but we might want to spin that out into an issue.

[Jondolf]

Yeah, the cone has this weird shadow effect:

I noticed that when originally implementing this too. The weird thing is that normalizing here seems to fix it (in my previous testing at least):

I'm not sure what's causing this. I could add the normalization there to fix it, but it feels like a pretty arbitrary fix, and it'd be good to find the root cause.

[NthTensor]

Someone who understands mikktspace should take a look at this. I have tried and failed to determine the source of the artifacts. If we can't solve it any other way, I suspect adding more loops (or a small loop near the tip) will mitigate the issue.

Would be really nice if we could fix the visuals before merge, because I doubt we will fix them after.

Cones are the worst.

[HackerFoo]

For what it's worth, I don't have this problem in Noumenal, either the released version (based on Bevy 0.8) or the development version (based on somewhere around 0.12).

[HackerFoo]

I reverted #5666 in my branch, though.

[NthTensor]

I can't tell if it's just compression but that still seems to have some form of visual artifact to me. I will take your word for it, it's definitely an issue with mikktspace normalization then.

[rparrett]

Apart from the self-shadowing or whatever, something seems off.

Cone from this PR positioned just above a cylinder:

Same thing exported from blender primitives rendered in scene_viewer.

[HackerFoo]

I noticed that the shadows don’t line up in Noumenal either, so I performed an experiment in real life.

It seems that the lighting is more correct in the first (non-Blender) image. Now I’m tempted to print some shapes to check lighting. Did you look at the scene using Blender’s Cycles renderer?

[rparrett]

Totally possible that I just did the blendering incorrectly. edit: Yeah, blendering is hard. Between all the smooth shading options and the various shading/rendering windows, I must have gotten mixed up. Here's scene viewer / cycles on a high res but flat shaded cone. <img width="1174" alt="scene-viewer-cycles" src="https://github.com/bevyengine/bevy/assets/200550/005571f9-e9d3-4cdc-803f-bb2351c0b8b8">

[rparrett]

None of my feedback is blocking, and IMO the visual artifacts don't seem related to the code in this PR.

[NthTensor]

That's a good point. Let's merge this and open a graphics issue. I think it was a mistake on my part to suggest blocking.