May you tell us how the depicted case could be easily avoided in linear/dense geometry?
Also, official Maxon channel (that guy just have more views)
Could, but won’t. I doubt that knowing would transition your company from blender 2.79 to Maxon.
Thank you anyway though.
(We actually use Nemetschek software, just not as the main because it disallow to reach the necessary amount of a workflow speed, so any help would be appreaciated)
3dsmax have similar issue (the entire LCS approach have it at the concept level, where selection picking and gizmo activating are in direct conflict), so originally max devs assigned hiding gizmo to X key, similar to Alt+D in C4D.
As a result there were lots of accidental keypressings, people were losing their gizmos and reinstalling the software at the time before the internet became widespread.
So In latest versions of 3dsmax the X key assignment was replaced.
Just wanted to mention that gizmo problems is quite typical for cg applications, and different software solves it differently, and it is not possible to avoid tradeoffs.
For example, to resolve short grip problem C4D users enlarge gizmo, but as a result it pickblocks even more geometry, and so one…
2 Likes
@thorn I don’t think we are on the same page. Selecting something behind the gizmo is a crucial and fundamental issue in 3dsmax and as I see in cinema 4d too and it’s not only a simple case scenario. I came from 3dsmax where this was a horrible thing. In blender was the same shit. But finally I switched to RCS, and it was “a miracle”. Selecting and moving things became so easy. I still use RCS, even though in newer versions of blender (after 2.79) with LCS the issue is resolved.
try selecting a vertex shown in the picture below with LCS. and this is a simple case, imagine yourself a dense organic mesh or a bunch of objects close to each other.
It’s unfortunate that some have selection issues when a gizmo is present, and fortunate if you find RCS solves the problem.
And again, this wasn’t even the issue that Eobet was bringing up. They were discussing world vs local coordinates, and RCS was just tossed in as hyperbole.
1 Like
Can you please clarify how exactly it was resolved? Afaik in 4.3 gizmo still pickblocks on LCS setup everywhere, including active tools (especially something like Extrude Region which have especially large gizmos)
UPD, Aw, I’ve got what you mean - the “threshold click” solution, which works at the cost of a speed limitation and providing jamming behavior.
By the way, in 2.8 devs just put click on all the LCS picking actions, basically ruining their behavior.
It took a year to get it resolved for simple picking selections, but the other actions that require picking (loop/ring selection, shortest path, etc) are not resolved for the last 5 years and are still jamming by default.
It is too much parabolic though, since RCS is a solution to a widespread problem and Parenting problem is the opposite.
They are also doesn’t belong to the same magnitude, since RCS is animation-friendly and Parenting problem was the opposite (for a long time there were even no “Keep transform without Inverse” option).
world vs local
Speaking of that at the time I tried to point out to developers that different types of parenting are poorly depicted. For example, it would be nice to have different type of a parenting line display to distinguish type of a parenting visually.
Did you read what he was actually talking about?
Had absolutely nothing to do with RCS and what parent links look like and problems with picking a thing.
1 Like
MartinZ already replied to him
@1D_Inc, I opened blender 4.3, loaded factory settings, made a cube as in the picture above or similar cube with less subdivision, set the view that one of the arrows covers a vertex, and selected it without problems. Tried many times on different vertex and views, clicking with mouse select the vertex, click with drag moves the vertex and it works suprisingly good.
1 Like
Hope this can fit this thread:
oh how I wish it was possible to have displacement without bump in EEVEE. Currently, displacement introduces this artifact, which is caused by the fact that bump mapping is always enabled when using it:
What makes me ache is the fact that a patch to fix this and add bump-less displacement exists but has been stuck for seven months: https://projects.blender.org/blender/blender/pulls/122397
This makes EEVEE really bothersome for making game assets previews (or anything, really, in fact), as you can’t do closeup renders without the horrible artifacts. AAAAAAAAAH!
Perhaps you already know, but this looks like stairstepping from an 8-bit texture, might be possible to fix right now by converting to 16-bit and do some oversampling (size up, blur, size down)
1 Like
I wish it was that, but I don’t think that is it, in this case! The texture is a 16-bit float exr texture 
Here is another test with a 32 bit float voronoi texture applied to a Suzanne:
I’ve spoken with Clem once about it (might have reported it as a bug too some time ago), and he told me it is not a bug, but it is caused by how bump mapping is implemented in EEVEE. The only solution is to do what the patch does, and displace with the height map while overriding the normals with a texture and avoid bump mapping entirely (which is what other real time game engines do).
The ironic thing for me is that EEVEE Next was doing that before May. I reported as a bug a mismatch between how Cycles calculates the normal and EEVEE. The solution to that mismatch created the current behavior. I hope eventually the Cycles side of that patch is solved, so that it can be merged. Until then, when I use EEVEE, I cannot do close-ups when I use displacement. 
Oh, wow, that’s unexpected. Yeah I suppose if Eevee could do displacement without bump you wouldn’t have a problem here
If displacement in eevee is entirely dependant upon the existing geometry and doesn’t create new geometry like with cycles adaptive sampling, couldn’t you instead preview the displacement entirely with the displacement modifier or geometry nodes and remove the eevee material bug from the equation?
Yes, that’s a workaround, but the difference in performance is great. Shader displacement performs vastly better, as it all happens in the GPU.
Anyway, that UX was always weird to me, why on earth: vertex and pixel displacement and normal inputs in blender are merged into one “Displacement” socket, with option to where actually connect it?
Why one have to set some setting in other place, or use weird additional notes instead of making two outputs (or just one, since every bsdf already have normal input, so why there are duplicated inputs in the first place?)
Wouldn’t straight forward solution like in game engines be better?
If You wanna affect position You just connect it to position, if for some super weird reason You wanna both affect position and pixel with same data You just connect it to both outputs.
4 Likes
And, to add to this, bump mapping done through the node or through the Displacement output seems to produce different results 
1 Like
I also think that render time displacement in Cycles is long overdue. Not sure why Cycles requires such convoluted hoops to jump through when just about every other render engine out there can handle a simple connection to the displacement input and handle the rest from there.
1 Like
That is not supposed to be Bump, Normal socket.
That is supposed to be Displacement socket rendered as Displacement for optimal quality / Bump for low quality render / Displacement and Bump for coherence (to avoid to replug map elsewhere).
Bump maps, Normal maps are supposed to be connected to Normal of shaders.
Those sockets are blue, because blue means vectors. But they are not named the same, because they are not supposed to be confused.
I don’t know where else to put this but:
- Solidify and bevel propagates the vertex group to newly created vertices (something which is undesirable if you want to re-use an existing vertex group for multiple modifiers).
- Decimate and weld does not propagate vertex groups to newly merged vertices (rather you get a very undesirable random assignment to one group).
Manual merging of two vertices from two different vertex groups also doesn’t assign the result to each one.
I wish this behavior would be consistent (but preferrably also user controlled).