Adding Raycast3D custom debug shape thickness and color

[jmb462]

Bugsquad edit: master version of #49726.

What is the problem solved by this PR and use cases ?

During the development of a game with my teammate @fabriceci, we had a hard time with the "debug shape" of Raycast3D.
A Raycast is a bit special, because contrary to CollisionShape, they don’t “cover a mesh” which you can easily refer to.

This leads to make difficult the debugging of certain Raycast3D :

• the Raycast3D is represented by a white line, it’s often hard to see it (collapsed by the grid, aligned with the axis...)
• if we have multiple Raycasts on a Node, it’s hard to make the distinction between them. For example, a ball rotate/cube and you want to keep track of all directions with Raycast3D, you can’t.
• If the background is white or bright, the Raycast become nearly invisible.
• You can't see the direction of the ray
  

How does this Pull Request fix these problems ?

This PR is done in the simplest way possible by: adding 2 optional parameters to be able to set a per Raycast3D custom color and / or thickness.

By default, the behaviour is the same as now, the thickness is set by default to 1 which draw a line and default color is the same as current default color.

The goal is to allow highlighting some chosen Raycast3Ds in order to make debugging easier.
When the thickness is more than 1, a parallelepiped is drawn, instead of the line, with a bit larger base than the target point to show the direction.

raycast1280.mp4

[Calinou]

Related to #40123.

[pouleyKetchoupp]

The idea is great, I think it will improve readability a lot.

I've left some comments on the implementation, let me know if anything is not clear enough.

In general, I wonder if we could just always set things with a thick shape, since the single line is very difficult to see. It could be simpler in this case, we could even get rid of setting the thickness and just always set things the way it is with a thickness of 2 right now, I think it would look great.

[fabriceci]

It could be simpler in this case, we could even get rid of setting the thickness and just always set things the way it is with a thickness of 2 right now, I think it would look great.

@pouleyKetchoupp There is one edge case where a line is better than the parallelepiped: when the camera is far away:

We assumed it was normal as lines thickness are not shrunk by the camera distance, contrary to a mesh (are we misunderstanding something !?).

If we want to make this shape the default, we need to overcome this. We thought to solve this by drawing a line AND a mesh. (OR using camera distance (if possible) to adapt mesh thickness with the distance)

What is your opinion on that? Is there a better solution?

[pouleyKetchoupp]

@fabriceci I didn't think about camera distance, and it does make sense that a line would render better in that situation.

Doing both a line and a mesh might help. I wonder if it would make the code over-complicated though. Feel free to try if you want, and if it's easy enough and looks ok with transparency it would be great.

Otherwise you can keep the thickness parameter like you did, it would be fine. Let's just make at least 2 the default value since it would look better in common cases.

[pouleyKetchoupp]

It looks good with what you did with rendering both the line and the parallelepiped, so it's almost there!

[pouleyKetchoupp]

I've made comments on a few more things, mostly details and things I've missed before.

Once the last changes are done, please squash your commits using this workflow:
https://docs.godotengine.org/en/stable/community/contributing/pr_workflow.html?#the-interactive-rebase

And then it should be good to go :)

Changes done.

[akien-mga]

Thanks!

[jmb462]

A big thanks to @Calinou and @pouleyKetchoupp for their precious help !
We (@fabriceci and me) have learned a lot working on this PR.