Voxelizer Experimental release notes 2019-01-18


We’re continuing the (roughly) weekly schedule of Voxelizer Experimental updates.

Windows: The updates should automatically show up when starting Voxelizer - if they don’t, you can click on Help -> Check for updates or download the Windows installer directly from here.

Linux: install with snap install voxelizer --beta, update automatically or with snap refresh voxelizer

MacOS: Download from here. Autoupdate will probably not work at this point.

Voxelizer Experimental release notes 2019-01-18


  • texturing previews now have much better quality and are independent of chosen voxel resolution
  • textures applied to objects are now shown in a separate list below the color list
  • all texture mapping parameters are now defined per-object and not per-texture
  • various speedups related to texturing
  • it’s now possible to uniformly scale external textures
  • it’s now possible to rotate external textures in three axes
  • available mapping types has been changed to “One Side” and “Two sides”
  • deforming/cutting/filtering objects that have an internal texture attached should now give sensible results
  • it’s now possible to import .smd and .lxo files (including textures)

Bug fixes

  • image mapping gcode generation should now be much more robust, never causing lines floating in space
  • fix for gcode loading visualization
  • various minor fixes for texturing

Slicing issue with textures

Preliminary feedback when trying the same scenario as before:

  1. I like the 3 axis rotation, makes sides, top, etc. redundant. “Sides” might not be the best name for it anymore since with rotation you can make it come out to be top, bottom, or wherever you want. Is two sides essentially just tiling the x axis of the image twice? If so wouldn’t it be better to just allow you to set your own tiling for the x and y axis of the image?

  2. I get a crash currently whenever I hit apply for the same usecase I previously posted. Certainly let me know if the crash logs aren’t enough info for you to be able to reproduce.


Went through the vertex color flow again. It’s much improved but somethings with still seem to have issues screens/comments below.

  1. Mapping went fairly smoothly, I used a low poly model with only 6 vertex colors (no ranges hard colors). The auto placement of the circles to drag around could be refined. They tend to like to hide or stack on one another. On the two boxes for mapping I almost think clicking on the left one should highlight it’s circle and even x ray through the render so you can find it. I also still think clicking the right box should let you pick from colors you already have defined to save time.

  2. As you can tell from the post slice screen something still doesn’t seem right. Mapping and the second main tab matches 100% but after slicing you can tell that it doesn’t match. There are several errors especially the blue on the roof and the fender.

  3. For vertex color I definitely also think a “take the values from the model” mode should be added as well so no user mapping needs to take place (same for the internal flow). A lot of times all the colors would be all achievable, and even when not the closest linear achievable is going to be the swap that is wanted to be made. I get that you probably want to guard against a model with 1000’s of colors, especially with your artifact slicing, but setting a sensible limit (16,32, or whatever you think average computers would be able to crunch in a few minutes) and popping out a warning if exceeded saying the artifact is being turned off would make sense to me. When you have tons of colors they tend to be for lighting/shadows with really close shades of the same color next to eachother and only the hard transitions are going to need the artifact. Without an artifact there isn’t really a computational penalty as it’s just one extra gcode line before each extrusion for setting the mix.


I’ve already partly replied in my other answer to your feedback. Regarding this one:

Currently the algorithm doesn’t take care of the flat parts. For these you should set an appropriate infill color from the Tree structure panel.


The fender instead is indeed an error. Is it still happening? If so could send me the model so that I can have a look at it?

Well this is what happens now with the option “Find key colors”. It will take colors from the model and it will return the mixing that will generate the (theoretical) closest possible match to them.

Did you encounter any other crash or some spectacular fail lately?


Ran it again on latest build and the non flat parts of the fender are now correct. Regarding the flat parts, the top of the fender and the top of the roof shouldn’t be the same color, so the workaround doesn’t really work. I’m assuming you are looking on getting flat parts into the algorithm correct?

No the key colors part requires you do define a number of colors and also map them. Taking values from the model would simply place the M567 or equivalent into the gcode from the model (or closest linear match). For vertex colored models that have only a few colors what you have is fine. But when a model starts having 16, 32, 64, etc. that window is going to fall apart. As I said if you are guarding against computational slicing time turning the artifact off in that scenario would alleviate that. This is especially useful for models with subtle variations in color that really help it’s effect and don’t need artifacts. Think something like a leaf where it’s pretty much green with a lot of variation from yellow green to darker green but the colors are all really close to one another. If you looked at the vertex colors it could easily be 100+ shades of green and there is no way you are going to be able to use that window to get what you want.

On the latest build not yet, I’ll certainly let you guys know if I do.


Yeah, somehow we will have to do it :smiley:

But we still need to move from color space to extruder ratios, which is what is happening with key colors. The only difference would be to automatically set the number of gradients. I will add this to the list of propositions.



Yes changing from RGB to CMYW (4 extruders) or CMYWB (5 extruders) still needs to occur but I would assume that’s not the bulk of your processing time since that’s a straightforward algorithm. I could certainly see your pathfinding for slicing the gcode taking forever if you had artifact on and 100 different variations of green, but with artifact off that shouldn’t be a problem.