Skip to content

Bring back a representation of layers#233

Merged
sophiedeziel merged 6 commits intov3.xfrom
10-16-bring_back_a_representation_of_layers
Oct 19, 2024
Merged

Bring back a representation of layers#233
sophiedeziel merged 6 commits intov3.xfrom
10-16-bring_back_a_representation_of_layers

Conversation

@sophiedeziel
Copy link
Collaborator

@sophiedeziel sophiedeziel commented Oct 17, 2024

Part of #221

There is value into getting a representation of layers like we had before. I brought back the class. The reason is that its is very well suited to hold some information like layer height.

I exposed the layer count as a getter instead of exposing layers themselves. It is an essential affordance for library clients to implement some sort of slider to inspect the inner layers using single layer mode and/or min/max layers.

I had to slightly change it just to replace GCommands by Paths.

@sophiedeziel
Copy link
Collaborator Author

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @sophiedeziel and the rest of your teammates on Graphite Graphite

@github-actions
Copy link

github-actions bot commented Oct 17, 2024

Visit the preview URL for this PR (updated for commit e4442eb):

https://gcode-preview--pr233-10-16-bring-back-a-r-me4yacky.web.app

(expires Mon, 18 Nov 2024 01:53:40 GMT)

🔥 via Firebase Hosting GitHub Action 🌎

Sign: 59bd114ae4847b32c2bba0b68620b9069a3e3531

@sophiedeziel sophiedeziel marked this pull request as ready for review October 17, 2024 01:55
@remcoder
Copy link
Member

How will we handle a gcode file that is incrementally fed to the preview, like when used as a realitime progress of an actual print?

@sophiedeziel
Copy link
Collaborator Author

It will handle it pretty well actually! As long as the same job object is used and appended paths on top of, they will be indexed on the right layer.

Layers are no longer used in the rendering logic (yet), it's a convenience for lib clients. I have plans for the layer height to be calculated from movement and used for the geometries.

To officially support incremental rendering, some logic has to be added to pop back the last path into the current path in case it was not finished. It's reference in the layer is kept. After that, rendering will just work

@sophiedeziel sophiedeziel force-pushed the 10-16-bring_back_a_representation_of_layers branch from d7c8676 to 323befc Compare October 18, 2024 00:24
@sophiedeziel
Copy link
Collaborator Author

I made the changes to make sure progressive rendering works gracefully in all cases

@sophiedeziel sophiedeziel force-pushed the 10-16-bring_back_a_representation_of_layers branch from 323befc to c6e0942 Compare October 18, 2024 01:35
@sophiedeziel
Copy link
Collaborator Author

Turns out layers are already useful with their z and height attributes!

#234

@sophiedeziel sophiedeziel force-pushed the 10-16-bring_back_a_representation_of_layers branch from 52a3949 to e4442eb Compare October 19, 2024 01:52
@sophiedeziel sophiedeziel merged commit 1b32b24 into v3.x Oct 19, 2024
@sophiedeziel sophiedeziel deleted the 10-16-bring_back_a_representation_of_layers branch October 19, 2024 02:15
sophiedeziel added a commit that referenced this pull request Oct 24, 2024
* Remove the code enum (#229)

* Bring back a representation of layers

* No need to expose isPlanar now

* Make layers 100% progressive rendering ready

* Layer number, height and z

* fix the splitting logic
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants