Add cone, make cylinder special case of a cone

[torsteingrindvik]

Objective

Bevy is lacking a cone mesh type.

Solution

Copy the cylinder implementation into a Cone type and split the single radius into top- and bottom radii.
Step this radius when iterating over the cone/cylinder rings.

Make cylinders a special case of a cone where the radii are equal.

Changelog

Added

• Cone mesh added with configurable top and bottom radii. Cylinders are now implemented in terms of cones with equal radii.

[torsteingrindvik]

cones.mp4

Here are a few examples. Changed material to unlit for visual clarity.

The cones in the video are defined as follows:

        meshes.add(
            shape::Cone {
                top_radius: 0.0,
                bottom_radius: 0.4,
                resolution: 32,
                ..default()
            }
            .into(),
        ),
        meshes.add(
            shape::Cone {
                top_radius: 0.9,
                bottom_radius: 0.8,
                resolution: 16,
                ..default()
            }
            .into(),
        ),
        meshes.add(
            shape::Cone {
                top_radius: 0.9,
                bottom_radius: 0.3,
                resolution: 16,
                segments: 10,
                ..default()
            }
            .into(),
        ),
        meshes.add(
            shape::Cone {
                top_radius: 1.0,
                bottom_radius: 0.0,
                resolution: 32,
                height: 0.5,
                ..default()
            }
            .into(),
        ),

[alice-i-cecile]

It would be nice to comment on the tip and face geometry (especially the UVs).

[torsteingrindvik]

Assuming this is resolved via your commit, let me know if not.

[alice-i-cecile]

Nope, I'd like much more detail, ala what HackerFoo was requesting below.

[torsteingrindvik]

I've been thinking a bit about how I would go about making some diagrams or similar, but I feel making it in an ASCII editor will be messy.

I see there is some precedent for having images in docs: https://github.com/bevyengine/bevy/blob/main/assets/docs/Mesh.png
But that is only linked to and not shown directly via rustdoc.

Should I just create an image?

[torsteingrindvik]

Also I noted other programs (Godot, Blender) have other features and optimizations such as choosing if caps should be generated, making top/bottom a single point (when zero radius) and more, but I thought this might be a good start.

[alice-i-cecile]

Also I noted other programs (Godot, Blender) have other features and optimizations such as choosing if caps should be generated, making top/bottom a single point (when zero radius) and more, but I thought this might be a good start.

Yep, we can merge it without those, but making good-first-issues for follow-up work like that would be much appreciated.

[HackerFoo]

Could you please add an image of the cone tip with smooth shading and a 0.0 tip radius, and no intermediate rings? I've only found one way to get this to work properly: #5891 (comment)

(TL;DR use a single vertex for the tip with the normal set to zero, and normalize interpolated vertex normals in the fragment shader.)

Also, a diagram would be useful, indicating the top & bottom radius, height, resolution, and segments.

Note that, with a radius of 0 at the tip, half of the triangles surrounding the tip are degenerate if using quads, since two of the vertices will be at the tip, forming a line to the other vertex. If you omit the degenerate triangles, the normal resolution is cut in half at the tip, resulting in visible creases from the base to the tip.

[HackerFoo]

Also see this discussion, linked in #5891: https://stackoverflow.com/questions/15283508/low-polygon-cone-smooth-shading-at-the-tip/37187730#37187730

[torsteingrindvik]

Yep, we can merge it without those, but making good-first-issues for follow-up work like that would be much appreciated.

Happy to do so when this gets merged. I have a few follow-up tasks I can think of.

Could you please add an image of the cone tip with smooth shading and a 0.0 tip radius, and no intermediate rings?

Video: https://github.com/bevyengine/bevy/assets/52322338/c3a96842-5113-4fcd-8fa4-8fc77309f266
Smooth-shaded default cylinder alongside a default cone.

I guess these are the creases you mentioned @HackerFoo?

At first I tried doing a single-vertex optimization when a radius is zero, but the barrel body UV mapping got very ugly so I assumed I had to keep all the vertices in order to preserve the mapping.
I didn't realize keeping the vertices had the downside of these creases.

Should this be resolved in this PR or later?

EDIT: After reading #5891 and #5666 a bit more it seems there might not be a solution right now that isn't at odds with:

Morten Mikkelsen clarified that the world normal and tangent must be normalized in the vertex stage and the interpolated values must not be normalized in the fragment stage.

Perhaps @superdump could provide some insight?

EDIT 2: Hm, I think my PR is lacking adding a Y component to the normal vector based on the inclination between the radiuses. I'm hoping the creases are fixed if that is added. Trying to figure out the math now.

EDIT 3: I think the normal Y should get a (c.bottom_radius - c.top_radius) / c.height value, but the creases are still visible.

[HackerFoo]

I guess these are the creases you mentioned @HackerFoo?

Yes, that's what I expected. I don't think there is a solution other than normalizing in the fragment shader, or something similar e.g. weighted vertices.

[torsteingrindvik]

I was also curious as to how Godot did theirs and I found this:

Both have similar heights and radii, but:

Default (behind) cone:

• 64 radial segments
• 4 rings

Less geometry (front) cone:

• 16 radial segments
• 1 ring

So it seems the effect is present there but masked by having more geometry in the defaults.

I adopted those defaults now, looks like so:

cone_3d_shapes.mp4

Putting into draft since I'm unsure how to diagram it properly yet.

[torsteingrindvik]

Added an illustration done in draw.io as well as the .xml source for it such that it can be further edited in the future.

Also added some more docs.

[HackerFoo]

So it seems the effect is present there but masked by having more geometry in the defaults.

The effect should still be visible when zoomed in on the tip of the cone. A cone with a zero normal tip vertex doesn't have this problem.

In my case 20x-1 vertices (4x radial segments, 4x rings, another ring instead of a single vertex at the tip) would affect performance, but I'm not using Bevy's shapes.

[alice-i-cecile]

I would definitely like to fix this problem directly, rather than mask it with more geometry :) Defaults should be both correct and free of odd performance footguns.

[torsteingrindvik]

I'd need to delve a bit deeper to understand the implications of

A cone with a zero normal tip vertex doesn't have this problem.

and I want to work on other things right now, so putting this PR up for adoption.

[Jondolf]

FYI, I'm implementing this as a part of adding mesh creation support for the new primitive shapes (see #10569).

I have a working implementation of the cone with a single vertex for the tip and a zero normal:

Note: Unlike this PR, my implementation's default UVs map to polar coordinates (which Blender also uses). For example, a traffic cone with a white line going through it would be similar to Target's logo, which feels relatively intuitive to me.

However, this requires #10905, because the vertex normals need to be normalized in the fragment shader and not in the vertex shader. Otherwise, the NaN values will produce a black mesh.

Also, if we're going to be mathematically correct, the cone in this PR isn't actually a real cone because it doesn't always taper to a single point:

A cone is a three-dimensional geometric shape that tapers smoothly from a flat base (frequently, though not necessarily, circular) to a point called the apex or vertex.
- Wikipedia

Instead, it's a conical frustum, a truncated cone where the truncation plane is parallel to the base. Coincidentally, there is a ConicalFrustum primitive already, so I managed to easily copy your code over to use that:

TLDR: I'm working on this, and the code here is very useful for the conical frustum implementation. PR(s) should be ready soon after #10905 hopefully gets merged!

[torsteingrindvik]

@Jondolf Very cool! Glad to hear you found something that will work well in all cases.
Since this PR was up for adoption anyway I'll close this.