WIP: Experimentation with a generating headless frames in a loop. #116
No reviewers
Labels
No labels
bug
dependencies
documentation
duplicate
enhancement
good first issue
help wanted
question
rust
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
ArkForgeLabs/BlueEngine!116
Loading…
Reference in a new issue
No description provided.
Delete branch "hydra/headless_loop"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hi, i tried out BlueEngine today and had some success, but was met with quite a few failures too.
This PR shows the changes I made in order to create a
headless_loopexample.However, there were issues:
update_loop, I fixed this by adjusting the return type of the closure that's passed toupdate_loopso it returnsControlFlow, thus there was no way to exit gracefully from the application.log (from raspberry pi 5):
log from Windows 11 (AMD 5950X + NVidia 4090)
I'm providing this feedback in the form of a draft PR, I don't expect you to merge this directly, since addtional changes are required - feel free to fix this up or make other changes.
Damn, crazy PR, very good work. And I would say the issue of object disappearing is partially happening in this loop. Potentially related to the bind group logic. The other potential issue would be the culling used by
wgpuhiding the triangle, but I doubt that.Amazing work! Thank you so much, I really appreciate this!
Gipson is right, the wgpu usualy culls backface by default hence why when triangle is rotated backwards, it disappears. This can be set in ObjectSettings, I'll look into it myself too since I was planning for an overhaul to them.
About the cube not moving, that is a good point, I should look into that. Thank you!
I should look into colors as well. The colors are passed directly, but it could also have been texture color formats as well causing it 👀
I see that this is a breaking change by default since it requires a ControlFlow return. It may do good to have it optional instead. Let me investigate
After a lot of investigating, the best way in my opinion would be to remove it from the return type and rather set it in the engine as a field instead. This helps both not break backwards compatibility, but also allows users to not require to set it on every loop as well.
Closest thing that would've worked as return would've been a struct with From<()> implemented, but even then it'd require ().into() to be called every time.
github.com/AryanpurTech/BlueEngine@679410d15dAlso fixed the triangle not displaying issue
Maybe it's kind of stupid, but why not making it possible for everyone, be it headless or not, to break from the update loop? Why should it be restricted only to headless mode? What if I wanted to do it on a game? It wouldn't be that much of an issue to allow it globally
non headless mode already has it, with engine.window.should_close I believe.
There are many reasons as to why theres a difference, but simplest reason is that the windowed version's loop is controlled by winit, hence why it is based on window to close itself
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.