Displacement mapping a.k.a. bump mapping at the slicing stage (reusing Fuzzy Skin backend code).

[Poikilos]

Is your feature request related to a problem? Please describe.
Lol "I'm always frustrated when" the model I download is dozens of megabytes and runs at 1 frame per 2 seconds because the author had to apply a displacement map to the mesh with automatic subdivision, yet when I decimate it to 1/20 of its original file size the model isn't visibly different but navigation is smooth.

Describe the solution you'd like
I would like to help PrusaSlicer start an industry trend of allowing a displacement map to be applied during the slicing stage similar to the vb_fuzzy_skin branch. It is good for many simple tasks like brick walls, which are popularly uploaded to model sites with displacement maps applied. For example, https://www.thingiverse.com/thing:5190970 makes Blender run at 1 frame per 30+ sec on an old i7 while doing any editing causing 10% more sadness per frame.

Describe how it would work
For each island on a layer, the distance from the center of that island would be used to determine an arc length to map back to the texture using a pixels_per_mm value (that the user could set). For the vertical mapping, the z coordinate of the bottom of the layer + 1/2 of the layer height would be used instead, against the same pixels_per_mm value.

• Using the arc length of a virtual circle it for consistency: It will ensure that the texture mapping doesn't result in moire-like patterns where the model has bumps (where the path has turns that differ on each layer).
• An optional bump-degrees-as-mm mode can prevent texture skewing on models that taper, where keeping pixels aligned vertically is preferred over stretch prevention.

Describe alternatives you've considered

• Adding a displacement map to the model may be more of a standard process and have shared code and respect original UV maps. However, this would only work for models designed with mapping in mind (properly UV mapped models). I know how to add a UV map myself and redo it to be tidy and even, but most people do not. Therefore, doing the process using math is more useful to more people. Doing it at the time of slicing will also save RAM (even in the slicing preview, only more segments not more triangles would be stored, so it would use geometrically less RAM). For use cases requiring accuracy, applying the displacement map in a modeling application is better and fits the use case of a modeling application better than a slicer.
  • If UV mapping could be applied at slice time (optionally), that would be ideal but may be very difficult to implement.
• Decimating models isn't reliable. Though I said "when I decimate it to 1/20 of its original file size the model isn't visibly different," many 3D printable models are made by beginners, so in many cases decimation makes model errors (those identified by Blender's included 3D-Print Toolbox add-on, such as non-manifold edges) more difficult to fix or adds more self-intersecting geometry or visible glitches.

Additional context

• At my displacement_map branch I will try to implement the feature myself before asking for help, by forking from the 2021 vb_fuzzy_skin branch: https://github.com/prusa3d/PrusaSlicer/tree/vb_fuzzy_skin :edit: master.
• The Fuzzy Skin feature was implemented in 4620402 as per issue Fuzzy skin #2010.
• The feature could mitigate Paint on Fuzzy Skin #6988 since painting could be done on a texture, but wouldn't solve that issue since mapping would not be precise.

Tasks:

• fork the master branch using the web interface.

git clone https://github.com/Poikilos/PrusaSlicer.git
cd PrusaSlicer
git fetch -a
git switch displacement_map

• Get PrusaSlicer to compile (and ensure that the Fuzzy Skin feature works).
• Add settings (Simple category except maybe bump-degrees-as-mm in Advanced):
  • fuzzy_skin_displacement_map bump-map-path
  • (use existing fuzzy_skin_point_dist as pixels per mm if map path is not blank) bump-pixels-per-mm
  • (use existing) fuzzy_skin_thickness (default .3) bump-mm (default around 1) and bump-offset (around -.5 so gray means unchanged)
  • cube mapping (on 4/6 sides) to fix tapered objects without skewing (choose "face" based on angle from center of island then use distance from "left" of that face plus all faces from starting face's left to current face's left--this allows textures with something different on each side to work)
    • cube mapping based on normal
  • fuzzy_degrees_as_mm bump-degrees-as-mm to enable cylindrical mapping (0 for square mapping).
• (implemented GetLuma) Load the map and read a pixel's brightness Luma from it, showing test output on the console to that effect.
• Map the texture to the outer wall path of each island separately.
• Ensure fuzz still works with the displacement mapping feature turned off (Implement fuzz on top of the new code if necessary).

Forum topic:

• https://forum.prusa3d.com/forum/prusaslicer/wip-displacement-map-feature/#post-631028

[Poikilos]

Progress!

[Poikilos]

Tasks:

• Fix alignment
  

[Poikilos]

It calculates normals! Cube mapping is complete!

[Poikilos]

With this 1024x1024 texture and large model (The 111x107.87x196 mm model shown), it seems to hang at 90% though the Export option is available (on i7-12000F and 16GB RAM, Fedora 37). After a few minutes it says Exporting.

• https://ambientcg.com/view?id=Bricks076A
• https://www.thingiverse.com/thing:4077316

:edit: It eventually saved correctly, after several minutes.

[adenta]

So what ever came of this?

[Poikilos]

So what ever came of this?

You tell me...It works fine but no one noticed. Recently there was more discussion of this feature not existing here: 3D Print Any Texture You Want! on YouTube (he uses dense meshes, and both the description and comments say it is unfortunate the feature doesn't exist...)

[adenta]

@Poikilos what do you mean noone noticed? Can we bundle this with Orca/Bambu perhaps?

[Poikilos]

Well, I mean I thought more people might find, react, and discuss this issue, and maybe maintainers would put it up for discussion, since people talk about the feature a lot just not on GitHub :)

[adenta]

I want it!

…

On Thu, Mar 21, 2024 at 8:45 PM Jacob Gustafson ***@***.***> wrote: Well, I mean I thought more people might find, react, and discuss this issue, and maybe maintainers would put it up for discussion, since people talk about the feature a lot just not on GitHub :) — Reply to this email directly, view it on GitHub <#8649 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACGUU5UYNHA5DJBRPPYOQLTYZN5KXAVCNFSM553AYQGKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBRGQYTCNRUGMZQ> . You are receiving this because you commented.Message ID: ***@***.***>

[Chocolateandmilkwin]

Sad that there isn't a star feature for issues, this would be such a huge addition for micro detailing.

[Poikilos]

Sad that there isn't a star feature for issues, this would be such a huge addition for micro detailing.

Well, you could react to the original post by clicking emoji then thumbs up, or in this case, click the thumbs up that is already there. Typically people add "thumbs up" on issues on GitHub, so maybe if enough people do, it will get traction.

[Keavon]

@Poikilos I'm excited for the possibility of this feature landing but I'm confused... I don't see a PR linked anywhere in this issue. Did you open one? Shouldn't that be where the discussion and hoping-to-get-noticed-by-maintainers occurs?

[adenta]

There is a formlabs tool that does a half decent job

…

On Thu, Dec 26, 2024 at 3:28 AM Keavon Chambers ***@***.***> wrote: @Poikilos <https://github.com/Poikilos> I'm excited for the possibility of this feature landing but I'm confused... I don't see a PR linked anywhere in this issue. Did you open one? Shouldn't that be where the discussion and hoping-to-get-noticed-by-maintainers occurs? — Reply to this email directly, view it on GitHub <#8649 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACGUU5XOO67MURABJGVKN632HO42DAVCNFSM553AYQGKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TENJWGIZTAOBQGQ4Q> . You are receiving this because you commented.Message ID: ***@***.***>

[Poikilos]

There is a formlabs tool that does a half decent job

That tool has the problem I stated in my issue and I solved: The page "Introducing the Formlabs Texture Engine" says "ensure that the mesh density is high". Many tools can do that (including applying subdivision and displacement map modifiers in Blender). On the other hand, you can run mine on a cube (8 vertices) and only the G-code will contain the displacement. That reduces various distribution and maintenance burdens I described in the original post.

[Keavon]

@Poikilos but do you have a PR open for your implementation?

[Poikilos]

If I added a feature in a pull request I didn't know how well that fits with the expectations here, but if that's the way then fine. It needs to be rebased but I should be able to do that. Or I could just add it anyway and conflicts can be resolved during merge. That may not be enough since the change will probably have to be added to the Arachne code if that is separate.

[Keavon]

I'd highly encourage you to rebase it and open a PR. Since you've already put in the effort to build most of the feature, that is certainly the next step in getting it considered for review in an open source environment. It's no surprise that this issue hasn't been seen by of the maintainers— there are 4.5k open issues compared to just 168 open PRs. I doubt the maintainers are following this one particular issue, but they'd be more likely to look at the incoming PRs which is the avenue for contributing actual code changes (issues aren't). As for Arachne, perhaps it's better to note that in the PR and see what the maintainers propose. I look forward to seeing this move forward via the proper pathways (a PR)!