Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CSGPolygon3D using Path does not follow medium sized path well #69507

Closed
NathanielEssenberg opened this issue Dec 2, 2022 · 3 comments · Fixed by #69239
Closed

CSGPolygon3D using Path does not follow medium sized path well #69507

NathanielEssenberg opened this issue Dec 2, 2022 · 3 comments · Fixed by #69239

Comments

@NathanielEssenberg
Copy link

Godot version

4.0 beta 7

System information

Windows 10, mobile renderer, RTX 2070

Issue description

When I create a Path3D that is not especially large (but in my opinion not extremely tiny either), the CSGPolygon3D set to Path mode seems to have trouble sticking to the Path3D's Curve3D. It was not particularly good at following it in 4.0 beta 6, but it got a lot worse in 4.0 beta 7.

Please note that I am new to Godot after working with Unity and UE4 for years, so it is technically possible that I misunderstand the expected behavior of these nodes. But at the same time I am not new to programming/scripting or working with game engines.

The curve I created in this example has 3 points, going from (-0.5, 0.0, 1.0), through a point at (0.119, 0.433, 1.07) to the end at (0.5, 0.0, 1.0). I placed the tangents to create a sort of looping shape just to keep things interesting.

It appears to me that the extrusion might at some point use absolute distances, since it works a lot better if I multiply the curve point coordinates by 10, for example. However, I believe that my original coordinates are not unrealistically small, and it should work.

Also note that, if Path Simplify Angle is exactly 0, the mesh does get enough subdivisions, but they do not actually follow the path. If the Simplify Angle is > 0, there are no subdivisions whatsoever (as in the screenshot below).

image
image

Steps to reproduce

  • Create an empty 3D scene in a mobile renderer project
  • Place a Path3D with 3 curve points at (-0.5, 0.0, 1.0), (0.119, 0.433, 1.07) and(0.5, 0.0, 1.0)
  • Adjust the tangents at all 3 points to create a nice curved path
  • Create a CSGPolygon3D as child of the Path3D
  • Set the mode to Path, assign the Path3D, path interval mode Distance, with path interval 0.01
  • I used a square profile between (-0.02, -0.02) and (0.02, 0.02)

Minimal reproduction project

PathExtrude.zip

@Calinou
Copy link
Member

Calinou commented Dec 2, 2022

#64212 was already included in 4.0.beta6, so the regression is most likely due to #69043 which was only included in 4.0.beta7.

cc @xiongyaohua

@NathanielEssenberg
Copy link
Author

I have been playing a bit with sampling the baked curve myself, and it seems like this curve sampling might actually be the underlying problem, not the mesh generation. I will try to add some screen captures later, but I think the problem might be in functions like sample_baked() and sample_baked_with_rotation() of the Curve3D...

These functions have a parameter 'cubic', which defaults to false.

  • If I keep cubic = false, I get similar results as with the CSGPolygon3D when sampling manually; it behaves pretty much linearly.
  • If I set cubic = true, the sampling tries to stay more curved, but still seems wrong (there is some jumping as well if I animate the middle point a bit)

I tried putting bake interval on the Curve3D to 0.01 (because the documentation mentions this is a distance in meters between baked cached points, which sounds to me like it might not be relative), but it does not seem to make any difference.

I would understand that it could be intentional that sampling the curve with cubic = false gives a linear result. But in that case, why does it seem to work and be smooth if the curve points coordinates are simply 10x as large?

@xiongyaohua
Copy link
Contributor

This bug is caused by a typo (size_t instead of real_t) in the Curve3D::_bake_segment3D_even_length(), which means the bake interval is actually an integer, which is always larger than 1.

It was fixed by #69239 as a by product of fixing #69220.

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants