UltiMaker Hackathon '25: Slice-ID/Print-ID project #2241
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ion-plane. (WIP) Wanted: Print-ID (or failing that), Slice-ID -- Let the user draw on the model where a label should be applied wiht an unique ID per slice (or maybe even per print if we can also manage firmware involvement...) part of UMH-2025
…de -- but not any ID yet. (WIP) One the one hand, a lot got done, on the other, this commit is about 90% FIXME's an TODO's by weight -- What is done here is that you can see that it applies a gcode offset where the label is to be printed (for the slice ID), and it alters the gcode (with a comment) as well (for future use in the firmware hopefully). It's just that at the moment, no actual ID is 'printed' so it doesn't function as a slice-ID yet, and the gcode may be commented, but not with the UV's from the ID-label (not to be confused with the paint-texture) so it can't function as a print-ID yet. -- Furthermore, I think I only got the projection 'working' on one side of the cube, and even then it projects it scrimped in the horizontal direction on the opposit side -- to say nothing of the IdFieldInfo properties that've been set up in the previous commit (and should be altered anyway) but that isn't even properly used yet either. part of UMH-2025
This caused issues when the next point (that's actually part of the label) is then inset, as the line before the label will then slope inwards toward the label. -- Hackathon 2025: Slice-ID or Print-ID. part of UMH-2025
…int one works.) At least the integer multiplication one works as expected now. Necesary for Hackathon '25 -- Print-ID/Slice-ID. done as part of UMH-2025
… label-uvs). WIP At least they're there now -- now 'all' that's needed is to map the feature-texture UV's to ID-label-texture UV's (and for the Slice-ID specifically, generate a message, to pixels, then get the relevant pixel from that -- Print-ID should be done on the printer of course, hence the gcode changes) -- leave the other TODO's and FIXME's for now -- Necesary for Hackathon '25 -- Print-ID/Slice-ID. part of UMH-2025
…a-tex-UV coords. That _should_ take care of the 'Cura-part' of the print-ID (minus all the FIXME's) -- Image is still random at the moment though, that should be the next step for the Slice-ID -- Necesary for Hackathon '25 -- Print-ID/Slice-ID. part of UMH-2025
…z-coord input being 0 all the time). (OK,) That (really) _should_ take care of most of the 'Cura-part' of the print-ID (this time) (minus all the FIXME's) -- Image is still a checkerboard bitfield at the moment though, that should be the next step for the Slice-ID -- Necesary for Hackathon '25 -- Print-ID/Slice-ID. part of UMH-2025
There's an enourmous amount of FIXME's and TODO's, but if you paint one of the sides of a basic cube it should now a) print a timestamp in the designated area, b) (also) save the correct label-UV's via/in gcode -- Necesary for Hackathon '25 -- Print-ID/Slice-ID. part of UMH-2025
It's hackathon code, but we won't have that much time afterwards to make it production-ready, so clean up _just_ a little before things become permanent. part of UMH-2025
commit 430e9fc519be284911942c49bc72fc654dd95655 Author: Remco Burema <[email protected]> Date: Sat Jul 19 12:30:44 2025 +0200 Clean accidentally committed files. commit 7dc6a5c6cc2b077178d9127d29a54db048ce9158 Author: Remco Burema <[email protected]> Date: Sat Jul 19 12:26:19 2025 +0200 Slice-ID/Print-ID: Fix (not-really-)arbitrary label projection axis issues. Hackathon '25 -- It's not really 100% there yet, but at least the primary and secondary axes are orthagonal to the normal and properly use their spans to project now. part of UMH-2025 commit 5c22ac642bd0b118408dbb0d6e17005ec3bc5d23 Author: Remco Burema <[email protected]> Date: Sat Jul 19 01:26:10 2025 +0200 Slice-ID/Print-ID: WIP move away from (too) 'fixed' projection-axii. Hackathon '25 -- Plesae see the previous commit if you want something that has a chance of actually working (but this'll be better in the long run). part of UMH-2025
There was a problem hiding this comment.
Pull Request Overview
This pull request implements a Slice-ID/Print-ID system for the UltiMaker Hackathon, which embeds timestamps directly into 3D prints. The system generates timestamp labels that can be "painted" onto print surfaces either by offsetting path points inward to create visible text (Slice-ID) or by embedding UV coordinates in G-code for printer-side texture generation (Print-ID).
- Implements font rendering system with 8x8 bitmap font for timestamp generation
- Adds 3D coordinate projection system to map world points to label UV coordinates
- Integrates label processing into the slicing and G-code generation pipeline
Reviewed Changes
Copilot reviewed 27 out of 27 changed files in this pull request and generated 9 comments.
Show a summary per file
| File | Description |
|---|---|
| src/utils/LabelMaker.cpp | Font rendering system that converts text strings to bitmap buffers |
| src/utils/IdFieldInfo.cpp | 3D coordinate system analysis for mapping world points to label UV space |
| src/ExtruderPlan.cpp | Path modification logic to apply label effects during extrusion planning |
| src/FffGcodeWriter.cpp | Integration of timestamp generation and label texture creation |
| src/LayerPlan.cpp | G-code output modifications to include UV coordinate comments |
| src/gcodeExport.cpp | G-code export extensions for inline comments and UV data |
Comments suppressed due to low confidence (1)
|
|
||
| #include <range/v3/view/enumerate.hpp> | ||
|
|
||
| // TODO: put 'font8x8' into config file instead |
There was a problem hiding this comment.
Large hardcoded font data should be externalized to a configuration file or resource system for better maintainability.
Contributor
…linux compilation). part of UMH-2025 -- hackathon '25
Done for the UltiMaker Hackathon '25 -- Slice-ID/Print-ID project. part of UMH-2025
This gets rid of the awkward '99% of cases then handle the 1% with a different algorithm' thing, _but more importantly_ it sets the stage for properly using that class (in the next commit(s) hopefully) to get 'lines' of UV-coordinates that match up with the lines across face(s). The previous approach was adequate if you just wanted to know of a corner what UV-coords it had and didn't care which face it 'choose', because the paint would overlap the entire corner anyway (such as with the seam). However, since the UV-textures may be disconnected along the face-borders, and the points we're using _likely match up with the face corners_, this repressents a problem if you have to have a line across a face, as the function can only return one of the (maximum of) two possitbilities (an edge is part of at most 2 faces), and currently does so arbitrary -- I mean it still does kinda, but like I said, stage set for next steps. part of (Hackathon '25 project Slice-ID/Print-ID) UMH-2025
(Needed for the 'segments by point' strucute, which will be needed to do face-adjacency if we want to search by spans instead of single points, in the latter which case we didn't really care about what face, as long as the point is correct, but for spans of UV-pixels, we _do_ case.) -- As line-grid doesn't really have a proper way to access the elements, move the storage (back) to a vector and make the elements pointers instead. part of (Hackathon '25 Slice-ID/Print-ID project) UMH-2025
Tried to fix a few things bit mostly diagnosed where the problems still are. Besides all of the fixme/todo's that're already in the code, the biggest problems are: - reliably getting from 'real-world' points to usable UV coordinates, as we need _lines_ and not indivisual points, it starts mattering from which UV-face we pull those coordinates - this should be _really_ simple actually -- but the 'sliding window' over the path-points/polygon doesn't do the last leg -- but if I add it forcefully, it adds an extra line that was the UltiMaker Hackaton '25 Slice-ID/Print-ID project -- we hoped you liked flying with remco airlines -- UMH-2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Paint on a Slice-ID 'field'/label where the print is going to have a timestamp for the moment of slicing 'baked in'. At time of writing(0) this is done by (inserting to and) offsetting the path-points inwardly anytime a character (of the timestamp) is supposed to be visible.
For the Print-ID, the position, and the path-points of the Slice-ID are re-used, but instead of(1) offsetting the points, the UV-coordinates of the (inserted) path-point is saved to the gcode, so the printer can make it's own timestamp texture, and 'do something'(2) to the points corresponding to
(0:) At leas it works that way for when the timestamp isn't on a z-aligned plane, so the message can be printed in the skin. The case for when it is z-aligned (on the first layer for example), still needs to be implemented.
(1:) Well, at the moment in addition to, but there's presumably going to be a setting to choose between the two if both stay implemented.
(2:) Left as an exercise for the reader, or more pertinent; the firmware implementor.
Cura fronted doesn't need much (at the moment), but in order to use this, it should have a 'label' feature added to the texture; as in this PR: Ultimaker/Cura#20776