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

In-progress strokes are invisible when the camera is panned too far from the origin. #28

Open
patowen opened this issue Apr 13, 2024 · 4 comments

Comments

@patowen
Copy link

patowen commented Apr 13, 2024

Describe the bug
In-progress strokes are invisible when the camera is panned too far from the origin. I believe the root-cause is related to frustum culling (See additional context).

To Reproduce
Steps to reproduce the behavior:

  1. Zoom out
  2. Zoom in elsewhere
  3. Draw a stroke
  4. See that the in-progress stroke is invisible until you release the mouse (or you've passed POINTS_CHUNK_THRESHOLD)

Expected behavior
The in-progress stroke is visible no matter where the camera is.

Additional context
I believe the root cause is bevyengine/bevy#4294. I was able to resolve this locally by editing make_chalk to add the NoFrustumCulling component to in-progress strokes.

@alepez
Copy link
Owner

alepez commented Apr 15, 2024

Thanks for reporting this issue and a possible solution. I'll try this.

@patowen
Copy link
Author

patowen commented Mar 10, 2025

I have a branch for my personal use (https://github.com/patowen/lavagna/tree/my-preferred-fixes) that contains fixes for some of the issues I've reported (along with unrelated changes based on my personal preference of using stable rust). I'm not really in a position where I'll have time to be a contributor for this project, but I have no qualms against you referencing or using the code I wrote there if/when you decide to work on this.

That being said, please let me know if you would like me to try to polish up some of these fixes and write a PR. This applies to #16 as well.

@alepez
Copy link
Owner

alepez commented Mar 10, 2025

Hey! Thanks for your contribution! I see lyon bug is still there. So, until they have a fix, this workaround can be a solution.

If understand correctly, your branch fixes two bugs, #16 and #28, right? Can you create two separate PRs? Thanks

@patowen
Copy link
Author

patowen commented Mar 13, 2025

Sure! I'll try to polish anything up that needs polishing (especially given that the math in triggers_lyon_bug absolutely needs an explanation) and file a PR when I have time, hopefully soon.

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

No branches or pull requests

2 participants