I don’t think this was reported before. Seems like an easy fix in the existing code, so if the developers were aware of this, I assume it would have been fixed by now.
3 Likes
2.79b also behaves the same with a sphere. Granted, that one doesn’t even have the “on surface” option, but Offset doesn’t start working unless the exact overlap is removed.
Suddenly I am starting to want to infer something…
I did some more testing. The bug is triggered by more than just an identical position:
- Add a sphere, and a plane. Both occupy and share the exact same coordinates. Assign a shrinkwrap modifier to the sphere, and use the plane as a target.
Result: works as expected.
It this issue was caused by merely the two objects sharing the identical positional values, this scenario would fail. But it does not.
- Repeat the steps as the OP demonstrates in the posted video. Scale-up the shell. Or rotate the object by a degree.
Result: the modifier functions as expected.
This proves both objects may share the same coordinates, and a simple transform (scale) fixes the issue. It disproves that the position is the culprit. Something else is the cause.
- Repeat all the steps of the video, and change the origin’s position.
Result: no effect.
If the origin is somehow causing the issue, it would have the same effect as a positional translation. It does not.
- repeat the same steps again, and this time enter edit mode and rotate the mesh shell a couple of degrees .
Result: the modifier works.
This is a telling test, because it should have failed IF the issue is directly related to the object’s position.
Instead, it seems to point at an issue with the vertices being in the exact same position.
- Repeat the same steps once more, and edit the mesh of the shell. Select a single vertex, and move it.
Result: the modifier affects the single vertex, but other vertices remain unaffected.
All in all, the underlying cause seems to be the vertices identical position of both objects. Use a different mesh, and it will work. Transform the shell mesh, either in object or mesh mode, and it will work.
ONLY when the two objects’ vertices share the identical positions will the shrinkwrap modifier fail to function.
I understand now why this hasn’t been noticed yet. A couple of requirements, which generally don’t occur, have to be satisfied before the bug rears its ugly head.
…which is, allegedly, our orator’s exact test case (duplicate + separate), performed on and on on a daily basis, yet all of a sudden “bug creeped in” in 2.81.
This thread by now reeks of typical consumerism, that’s for sure.
1 Like
Agreed. And the modifier will actually function in this case when the Project mode is set to “Above Surface”.
1 Like
But isn’t that different from what the OP wrote?
if you duplicate and separate a shell from an object, you can’t shrink wrap it to the original object or any other one
In other words, I was just curious to understand what’s the case. I’ll do some test later on. I don’t use the shrink wrap much but in case better to be prepared 
Incorrect. I replicated the OP’s video exactly, and it does fail as the OP states in this outlier case.
It will still work when the project mode is set to Above Surface, or the original mesh or shell mesh is rotated a bit, or the shell is scaled. If the original sphere is deleted, and a new identical sphere is added, it will fail again. But add a monkey or any other object, and the shell will wrap correctly.
As long as the vertices of both objects occupy the same position, the issue occurs.
Actually, I discovered this opens up some quite interesting effects when you subdivide the shell, or randomize the vertices a bit.
I tested this in 2.79b, and that version is missing the Projection options which are present in 2.8. In that version the behaviour is identical in nearest vertex mode, and the modifier’s offset will not work either.
In 2.79b the Project option automatically works, because it seems to assume “above surface” by default (this cannot be changed). In 2.8 more options were added to control the effect better.
In short, set the projection to “Above Surface”, and it will behave the same as in 2.79b.
If anything, it is an outlier case, as far as I am concerned. If the OP worked this way in 2.79 and earlier versions, it worked because the OP used Project mode. It will not work in the other modes in the older version either unless the vertices of the shell or original object are transformed a bit.
I am unsure whether this is an actual bug at this point, or an (un)intented result.
What I do know is that in project mode it is easily fixed by project above the surface, and that this is the same behaviour as in older pre-2.8 versions. 2.8 and later expanded the list of options, and I think that it is partly operator error at work here.
I can see use cases where it would be USEFUL to keep the existing behaviour after experimenting around a bit.
3 Likes
What I meant is that the OP stated that one can’t shrink wrap to the original object or any other object whereas in your test it seems that only when the two objects share the vertices in the same position the modifier fails. So, apparently one can still shrink wrap to any other object as long as the vertices are not in the same position.
No, I rechecked his video, and did more testing, and the shrinkwrap modifier:
-
works just like the pre-2.8 version (but the 2.8 version offers more options)
-
as long as the vertices of both objects do not share the exact same coordinates, the modifier works as expected in all modes with offset.
The OP is using a partial duplicate of the original sphere. This causes issues with the modifier.
Then the OP switches the sphere with an icosphere, which obviously does not share any of the shell’s vertex positions, and it works.
Anyway, it is a bit of a “cry wolf” situation. I understand the OP’s frustration, but on the other hand the behaviour has not changed since 2.79 - only additional options were added. In 2.79 the OP would not have to change any other options in Project mode - it works immediately.
In 2.8, however, the “above surface” option must be selected to mimic the same effect.
I assume the OP worked in 2.79 before, and after becoming frustrated with the new 2.8 options, focused on getting it to work in other modes, but, just like 2.79, it will not work with identical vertices occupying the same positions. And became even more frustrated.
Let me be clear: the behaviour is IDENTICAL in 2.79 and 2.8, excepting that the user must turn on one more option in Project mode.
I am still unsure if this is a bug, or not. It is an outlier case.
Perhaps an additional option to force the modifier to offset vertices, even if they share the same position with the parent object, would be a good thing to have, because it is theoretically possible for two vertices of very different objects to share the same position, however remote the possibility - and this might cause strange shrink wrap behaviour, I think…
3 Likes
Reading it with fresh eyes this morning I meant to say implied. English is not my first language and I guess I slipped up. 
Oh well, little use i changing it now.
I am certain you understood what I was saying even if you don’t agree with it. 
Not inferred, and not implied either. I merely summarized, distilled if you’d like, the attitude which @apoclypse described. Like it or not, that is what it boils down to. But whether someone wants to measure themselves against that attitude is up to them.
You, however, outright accused me of ridiculing a person (something I never did), all the while trying to actually justify the above attitude. SMH.
It’s really not a lot of differences of what could’ve been downloaded, tested, and bug reported weeks ago vs. what’s downloaded for release now. I know this is really not the testing stage, sorry for the slack on our behalf. We’ll just continue to help you out as much as we can before release. Good job Blender it’s workable and a more productive flow, I LOVE IT!
1 Like
Hey all I’m experiencing this annoyance in Blender 2.8+
https://streamable.com/uj1x8
So what I have here is a particle system using a shrinkwrap modifier onto a plane with an Ocean Modifier
the settings for the Shrinkwrap is set to Target Normal Project, On Surface but as you can see from the animation above the leaves are being pushed jaggedly across the waves and I’m trying to figure out how to smooth that motion, I’ve deduced it can’t be from the output settings as the grass in the scene is displacing nicely, and this jagged look only occurs when set to On surface, the best look so far is by setting to Inside but then the leaves under the plane don’t get displaced.
Any help in solving this is welcomed!
What I hate about 2.81, is that it doesn’t correctly install itself, like side-by-side with 2.80. The saved projects from 2.81 have no preview, or they can’t be executed, because no Blender installed.
I am already wondering why the setup file is 50Mb bigger than usual?
Something has gone wrong with that release…
I have no issues on a second machine but still!
Download the Portable version and create your /config Folder inside the Blender Folder. Start Blender.
Thats the best way. Portable. Hassle Free.
1 Like
Blender cannot be installed side by side using the installer in windows (at least not since the windows installer was fixed). Even if you change the installation destination, the .blend file association and all the older config files will be translated and/or deleted/disabled to the newer versions.
If you want to install things side by side, use the zip version of Blender, uninstall any version of Blender using the “Programs and Features” or whatever is called nowadays on Windows (I’m on windows, but not english version), decompress to anywhere in the hard drive (or directly in the desktop) and run blender from there. You will loose the .blend file association, but you’ll have complete control over what version you use, not windows.
every time there is a release, there are kinks and bugs.
There are also features that were changed.
Sometimes i dont understand the change, and think its a bug. Most of the time actually.
Then i go berserk, maybe even rage post a bit.
Then I calm down.
But the thing is, this isn’t even a 2.81 bug. Or a 2.80 one. It may even turn out not to be a bug at all. And yet, there it is, let’s get loud and complain, and even play the “I’m otherwise too busy” card. Absolutely shameless.
With 2.81 in file menu you can no longer see shortcut folders.
The file viewer only shows core folders.
Kinda annoying.
Even though it’s a point release it is more packed with new stuff than a full release from other software .
And other companies do yearly releases mostly , so you can always wait for a full year before you jump in, that way you don’t have to rebuild your config a lot?
On a related note I think the Devs need to extend the release cycle until the large backlog of patches is over, so that they have more time to clean bugs right now there is to much features going in and too small a cycle to fix all bugs