Yet ANOTHER way to introduce more colour #103
hairydalek
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
I’m currently getting this rigged up on my Ender 3. Tests with SuperSlicer and Klipper are promising, but I get errors, so I’m setting up in Cura to see if that makes a difference. This looks like a really simple, but elegant way to achieve the effect. I kind of like the painted feel of the models I’ve seen posted, and this got me thinking.
I’ve been reading some of the comments about colouring models, and it’s nice to see ideas for improving or extending this, so here are my thoughts.
First, some observations:
1 - 3D printing is hooked on STL files. They are obviously handy, but it’s a format that carries fairly little data with it.
2 - Colouring a model requires you to conform to the resolutions and geometry of the model. If you want finer detail, you need to subdivide the mesh, which results in more geometry to wrangle. Ideally, we need to separate the colours from the geometry.
3 - Colour printing as it stands is a real faff, especially if you want more intricate colouring applied. In SuperSlicer, you can separate a single object into its constituent parts, but that can produce a large number of small objects to process manually - assigning the extruder for that element, and so on. This rules out making William Morris patterned boxes.....
I think what’s needed is a reduction in “faffing about” - we just need to figure out how to crunch the numbers so the gcode produces what we want. I’ll put a caveat here - I tinker with programming, but I’m probably not the person to ask to implement my ideas, but I’ll put them here so that others can ponder and give it a go.
There are other image formats besides the .stl that we are all accustomed to. For example, there’s .obj - which slicers can import. The key thing here is that the file contain UV data. For those who do not know, UV data is a way of mapping colours to a mesh. Effectively, give your shader/3D application a 2D image, UV data and some x,y,z coordinates, and you get a colour back. A UV image looks weird, as the object is “peeled”, so you get a rather flattened squashed image.
I think that using this kind of format would be ideal - the data is included in a predictable format already. The actual colours will be on a bitmap (.png for example) which Python can easily read. We know the X,Y,Z coordinates because the Code being post processed has this already.
Now, I know there are some complications here - mostly to do with model orientation and scale, and making sure that what’s being sliced matches up with the data in the .obj file so that colours land in the correct place.
Programs like Blender let you pain models, and will spit out the necessary bit map, so even for those on a limited budget, this is not out of each.
This will separate the colours from the geometry, which I think is the target to get to with this. The idea of mixing colours on the fly (spirit markers are great for this) come to mind too.
Hope my ideas are useful.
Beta Was this translation helpful? Give feedback.
All reactions