search

EmiOnGit / warbler_grass

A bevy plugin for creating 3d grass in your game
Apache License 2.0
120 stars 11 forks source link

Remove unnecessary clamp #18

Closed janhohenheim closed 1 year ago

janhohenheim commented 1 year ago

Hope I'm not missing anything here, otherwise I'm glad to learn :) The examples at least look the same to me, but I didn't check all of them.

EmiOnGit commented 1 year ago

It does make a difference. mix(c1,c2,lambda) internally is just calculated as (lambda c1 + (1-lambda) c2).

If lambda is outside of the range of (0,1), the resulting color can be weird, as it is not in between the colors.

Look at the alternative mesh in swap_grass_mesh where points of the mesh can be lower than in the default mesh. You'll see that the bottom part will becomes black. ( even though the bottom color is dark green)

janhohenheim commented 1 year ago

Ah, I see. Could one then divide by the grass blade height to normalize it?

EmiOnGit commented 1 year ago

Yes, already tried that. The problem is that we don't know the highest point of the grass mesh. (at least when a custom mesh is used)

EmiOnGit commented 1 year ago

However you are right. The color gradient should be normalized over the blade

janhohenheim commented 1 year ago

Aaaah I see! Also, minor point I just noticed: the code right now colors over the y axis. This wouldn't work in a game like Super Mario Galaxy, where we have round planets. This is why generally in my 3D code, I pass an up vector that is defaulted to Vec3::Y instead :) But that is quite a niche demand.

Closing this PR because of the discussion above

EmiOnGit commented 1 year ago

I see. This is true, however when using heightmaps in the future there is no way we could support round planets anyway ( I guess) If you see something like that you can also open a small issue, this way we can keep track of things like that for the future. (I tend to always forget something like that after a couple of days :smile: )