three.js
three.js copied to clipboard
DecalGeometry: Decal projections without distortions.
Describe the bug
The decal gets replicated when splatted. This happens when you try to splat just around the corners; you can then clearly see the partial/full replication (just once) of that decal on the adjacent side to the face you have splatted on.
To Reproduce
Steps to reproduce the behavior:
- Go to https://threejs.org/examples/?q=decal#webgl_decals
- Click on bottom part of the model's shoulder
- You can see the decal being replicated partially on the adjacent side
Expected behavior
The decal should only be present on the side splatted on
Screenshots
Platform tested on:
- Device: [Desktop]
- OS: [Windows, MacOS, Linux]
- Browser: [Chrome, Firefox]
- Three.js version: [r125]
This is a limitation of the used approach. More information here:
https://discourse.threejs.org/t/distorted-decal-texture/18442
Instead of using a planar projection to compute texture coordinates, it might be conceivable to use a different approach in DecalGeometry
. However, the current code is easy to understand and compact. I would not vote for a solution that noticeably increase the complexity of DecalGeometry
.
The model is also problematic. May be better to just change the model.
Shouldnot a more efficient solution be in place with good documentation instead of a simple solution that does not work at places ? :)
@ManishJu Definitely ! Would you like to work on that ? :)
Instead of using a planar projection to compute texture coordinates, it might be conceivable to use a different approach in
DecalGeometry
.
what if you use vertex normal to intersect a sphere of certain radius around the decal box center, and use the intersection point to assign a uv as if decal texture was mapped on this sphere in an eyeball-like way? does this make sense to anyone, lol
on 2nd thought, that would probably stretch it a bit in the middle
Sidenote: I actually don't find it so great how the decal texture wraps around. Right now, it is stretched but even if you fix it this particular behavior would be questionable. I like how the Source engine used to handle Decals.
Decals are "sprayed" from a location and mark every surface in their path. For instance, a decal applied downward onto a staircase would cascade down onto the top (but not front) of each step.
Would be interesting to have a flag or enum that controls how textures are projected onto the surface.
what would be the best way to tackle this problem ? Any papers to look into for implementation ? @Mugen87 does source engine's implementation handle complex surfaces ?
what would be the best way to tackle this problem ?
First, study the related work and find an existing algorithm that can implement the requirement.
A paper would be the best resource but I'm not aware of one. The other option is to study an existing solution and try to figure out a port. Although this can be quite time consuming. And it's not guaranteed to have something workable at the end. And it's important to honor the respective license and other potential clauses (e.g. a solution might be protected by a patent).
BTW: It seems Unity devs have/had similar problems π :
https://forum.unity.com/threads/any-better-alternative-to-decal-projector-for-decals.742424/
/cc @spite
Yes, it's a limitation of the way the geometry is generated. ThatΒ΄s why the decal volume has a parameter to define its dimensions, in order to mitigate this kind of problems. A solution for this specific use case would be to project a single quad, but that solution has the problem of having "shadow holes": i.e. some parts of the geometry in theory covered by the decal would have no texture.
Another potential solution is to add an attenuation factor for the texture along the projection axis, but this would have its own set of problems and edge cases.
Any updates on this issue? There is a paper about Interactive Decal Compositing with Discrete Exponential Maps. Has anybody implemented this approach in three.js? We are planning to implement this. π€
http://www.unknownroad.com/publications/ExpMapSIGGRAPH06.pdf
No updates so far but the linked paper actually looks promising. It seems an implementation would solve the distortions mentioned in this issue.
I see. Thank You. Let's see if we can implement the paper or not. I am still trying to understand. π€ π€ As with most of the research papers, things look harder to understand.
For anybody interested here is the full thesis : http://www.dgp.toronto.edu/~rms/pubs/PhDThesis10.html http://papervideos.s3.amazonaws.com/RyanSchmidtPhDThesis.pdf
@ManishJu Awesome Thank you. π I haven't fully started to implement the algorithm but generating uv coordinates through matlab implementation and plugging in the coordinates. I was able to achieve something like shown in the video.
https://user-images.githubusercontent.com/8201857/193405501-e8940cd1-6948-4da1-86bc-c8952f298bb1.mp4
@ManishJu Awesome Thank you. π I haven't fully started to implement the algorithm but generating uv coordinates through matlab implementation and plugging in the coordinates. I was able to achieve something like shown in the video. custom-texture-shader.mp4
Do keep us up-to-date, looks great so far!
@cptSwing Sure. After some playing with the algorithm, I have found the algorithm mesh dependant and if there are not enough triangles the algorithm wont work properly and there will be clipping. I think even after implementation, it wont be usable for all the cases but after some tinkering with mesh I have found it usable for my use case. I have started implementing the algorithm (writing some js code πββοΈπ€) after testing.
I will keep on updating about the progress.
PS: There are performance impacts during start up as well because of distance calculation that is needed to be done during start up (one time process). π€
maybe someone can port this to three https://www.babylonjs-playground.com/#9BVW2S#15
@RGdevz it is pretty much the same:
I found that rotating the model (not the camera) completely eliminates this. I wonder how the camera position contributes to the issue.
@troisiemeoeil Any chance you can create a jsfiddle of that so we can investigate?
@cptSwing Sure. After some playing with the algorithm, I have found the algorithm mesh dependant and if there are not enough triangles the algorithm wont work properly and there will be clipping. I think even after implementation, it wont be usable for all the cases but after some tinkering with mesh I have found it usable for my use case. I have started implementing the algorithm (writing some js code πββοΈπ€) after testing.
I will keep on updating about the progress.
PS: There are performance impacts during start up as well because of distance calculation that is needed to be done during start up (one time process). π€
but if we are dragging decal in real time, the distances need to be recalculated, right?
@dipeshdulal did you get this to work? Would you mind sharing your code? Would love to test it for my use case.
@karmacod3r I shared some part of expmap code over in this thread. π https://discourse.threejs.org/t/threejs-decalgeometry-alternative/39205/28
@ManishJu Awesome Thank you. π I haven't fully started to implement the algorithm but generating uv coordinates through matlab implementation and plugging in the coordinates. I was able to achieve something like shown in the video.
custom-texture-shader.mp4
Hi Can you tell me is the solution? How can we use it?
Instead of using a planar projection to compute texture coordinates, it might be conceivable to use a different approach in
DecalGeometry
. However, the current code is easy to understand and compact. I would not vote for a solution that noticeably increase the complexity ofDecalGeometry
.
Hi now is 2024. Is this problem solved? OR Is there any other way to show images on our models for 3d configurations like t-shirts?