- User Since
- Jun 27 2019, 9:55 PM (156 w, 2 d)
Tue, Jun 21
May 16 2022
May 8 2022
Size gizmo is fixed but now Look at manipulator doesn't work. 🤔 Should I create a new bug report? It seems like was broken by the fix that @Campbell Barton (campbellbarton) committed.
Apr 28 2022
Apr 12 2022
Apr 8 2022
Mar 14 2022
Feb 18 2022
There is no broken .dxf file because this is an issue with exporting. If export fails, .dxf file is not created.
I can only provide .blend file that is set up in a way that causes the error.
Feb 17 2022
Feb 9 2022
Yes, please add Cycles module. This is primarily an issue with Random per Island input and affects all meshes.
The fact that geometry nodes does something weird with smooth shading only makes the problem more visible, but it's not the cause. So it can't be fixed on GN side.
Feb 8 2022
Does this mean that indexing should be working for end user already? Because I'm not seeing any improvement compared to earlier builds.
Feb 4 2022
I'm also getting severe slowdown in image editor (nvidia gpu as well). It seems that gpu acceleration doesn't work for hi-res images. For example, if I load a small 500x500px image, then gpu utilization is 30-40% and panning is very smooth, but with 4k image gpu usage is only few percent and panning is really slow (2-3fps). Also cpu is getting maxed-out on 1 thread.
Jan 31 2022
I'm seeing a slightly different behaviour, but I think the cause might be related. For me World cavity still works but "Valley" effect (or AO) disappears once samples go over 18. Whereas "Ridge" effect gets progressively weaker with more samples and is basically invisible at 500 samples.
Jan 16 2022
Jan 13 2022
Jan 10 2022
Here's the file. As you can see it happens with Poly splines as well.
And you're right, there's some interpolation going on, I'm just not sure if it's intentional. According to the manual, Curve to Points node should return a proper normal at each generated point instead of some interpolated value from the control points. Or at least there should be a way to control when this interpolation happens.
Dec 31 2021
Dec 28 2021
Dec 1 2021
One useful option when saving linear EXR images would be to apply scene exposure. That would save one extra step of having to match exposure in external compositor. Full Exposure and Gamma sliders are probably an overkill, just a checkbox would be enough.
Nov 26 2021
Hi, @David (Accelero), thank you for doing this.
Having user-friendly config is really helpful and ACES is a huge improvement over standard Filmic luts, especially with very bright saturated lights. Now rendering sunset with Nishita sky doesn't look like a toxic apocalypse anymore :) Also most image textures get correct color space assigned automatically, so there's no hassle opening and converting old scenes. Except for HDR images, where color space dropdown is just empty. Is this just a visual bug? Which transform should I use for HDRIs?
Also I noticed that the image gets quite a bit darker in the shadows when using Filmic transform with this config, compared to standard Blender. Is this intentional?
Nov 23 2021
Nov 19 2021
Just tried the build and it works great for translating objects. The new indicator to show the average of multiple snap points is a nice touch as well.
However rotating and scaling doesn't actually benefit that much from picking a single reference point ('snap source' in this case), since the transform center is still set to object origin. This means that the user still has to manually move the object origin or place the 3d cursor at the desired transform center, like shown in the example of an impractical use in task summary. It would be much better to implement a proper 3-point reference transform for scale and rotate.
Here's what I mean:
Scaling would use the same principle: first 2 clicks set scaling center and initial dimension, then 3rd click sets final dimesion.
Also, could you add a toggle somewhere in the snapping menu to enable source picking by default? So that pressing G, for example, would go straight into interactive mode. That would be a huge timesaver for certain tasks.
Nov 12 2021
I think enabling base point snapping should work the same way as snapping in general. You can toggle it on to work all the time or use CTRL for a temporary action. So an additional checkbox in the snap menu should be enough.
Although this wouldn't work with transform gizmos, as you would still need some shortcut to pick a basepoint. Does this task address gizmo transforms or just modal operations?
Oct 24 2021
Dashed Lines Opacity slider is configured backwards. When opacity is 1, dashes should be fully visible.
Oct 20 2021
Oct 18 2021
I tried today's build (452c78757f44) and the problem is still there.
It also happens when using CPU to render, so it's probably unrelated to GPU drivers or something like that.
Oct 15 2021
Oct 7 2021
@David Kozma (kynu) You can right-click on an asset to quickly open the .blend file it's on. It's quite handy to change a few assets, but if you need to move hundreds of them, that's not gonna help much.
Oct 4 2021
As a design principle, Blender is not allowed to touch .blend files that are not the currently opened
Oct 1 2021
However, this will only work in the "Current File" asset library, since that is the only library that allows changing assets
Sep 28 2021
Regarding the the G, G shortcut for edge slide, I'd rather have a generic edge constraint mode that works for both transforming methods. It would also make life easier for modal operators, because double-tapping G gets really tedious after you have to do it 20 times in a row.
Sep 27 2021
It's okay, man. You were trying to solve a problem that shouldn't be there in the first place, we appreciate the effort.
Although that warning was really easy to miss amongst all the text. It would be best to also add a warning to the addon description inside of blender for things like that.
Yea, for me as well. Although I could only reproduce the issue in 3.0 if I loaded earlier userpref file that was corrupted. So just enabling the addon might not cause the problem right away, making it harder to detect.
Sep 20 2021
No, I cannot reproduce this issue with 3.0 build. But recently I had a similar problem where Lock Interface would turn on whenever I did a render. I could still uncheck it, but it was really annoying to toggle it all the time. So I deleted 3.0 folder in AppData to get a fresh start, therefore I don't have all add-ons installed. I'll try to reinstall them gradually and watch if Lock Interface starts acting up again.
Sep 16 2021
Jul 1 2021
I was able to reproduce this bug from scratch on 3.0 alpha.
Jun 21 2021
Apr 14 2021
I just wanted to clarify that this is not limited to vertex colors. Thanks to a recently added feature, custom attributes created in geometry nodes can be used directly in Cycles without the need for vertex colors: https://developer.blender.org/rB3a6d6299d
Maybe the fix will apply to GN as well, but I think it would be good if you could modify the name or description of this task to indicate that it also affects geometry nodes, since you closed my task.
Apr 13 2021
It's still present in the latest version. To reproduce the issue, you have to use Cycles render engine, and attribute name has to be the same as one of the hardcoded attributes, like "density", "flame", "color", etc. Eevee doesn't have this bug for some reason, even though it doesn't even support custom attributes yet.
Apr 10 2021
Apr 3 2021
Mar 13 2021
Looks like this is caused by a corrupted userpref.blend file in AppData\Roaming\Blender Foundation\Blender\2.93\config\. Doing a factory reset fixes the issue but after a few days it appeared again for me, so it would be great to have a proper fix, because resetting and reconfiguring everything from scratch is quite a lot of work. Wouldn't want to do it every time. Please look into the file, maybe you'll find the cause of this bug. Note that simply opening this file doesn't cause setting to lock up, you have to put it into Blender\2.xx\config\ directory. Another strange thing is that Blender 2.91 seems immune to this bug. If I replace the original userpref file in 2.91 directory with corrupted one, the Lock Interface setting doesn't get stuck, whereas for 2.92 and 2.93 it does.
Mar 4 2021
Feb 25 2021
It seems that this bug is somehow caused by adaptive sampling and the exact number of samples when these artefacts start appearing is dependent on the total number of render samples, but they do appear eventually.
Feb 22 2021
Feb 18 2021
Feb 15 2021
Feb 8 2021
Feb 7 2021
Feb 1 2021
Jan 23 2021
I also have some variant of this bug:
Jan 21 2021
This seems like the best option for now. Don't let perfection be the enemy of good, or something like that.
Lasso tool should have the same visual feedback for consistency. But I don't really understand the point of this clockwise/counter-clockwise thing as it would only make lasso selection more complicated and difficult to use. As I said before, selection type should be determined only by the initial direction over the first few pixels (horizontally), and not by the winding direction of the whole movement. Directional selection relies on muscle memory to quickly pick selection type without thinking, so Lasso should works in the same way. Also that's how CAD applications work.
Jan 19 2021
If drawing a darkening fill is not possible for Lasso selection, then drawing a 2 pixel dark/light border seems like the best option. Without full support for Lasso selection this patch probably won't get accepted.
But why would there be a problem? What I described only adds a little visual indicator for picking the base point, that doesn't interfere with selecting in any way. The only thing that changes is that you have to hover your mouse over a desired base point before pressing G.
@Eugene Du (APEC)
Your idea could be optimized even more if base point is picked before the move command. When snapping is enabled, simply hovering over a point marks it as a potential base point, and pressing G picks that base point and enters transform mode in one go. So the sequence of actions is hover - G - move. I think this would be the fastest way to snap with base point.
Of course at this point it would be best to release this feature as-is and modify it later if needed.
Jan 17 2021
Yeah, I just realized that current selection has a subtle light overlay, so a dark fill for other selection type seems like a natural opposite to that.
But why do you think it wouldn't work for lasso? If it's about determining which selection type the user wants, then I think only the initial movement should be sampled. Directional selection works like a shortcut that you don't have to press. By dragging left or right I choose one selection type and I don't want to it change mid-selection, no matter what kind of shape I'm drawing with the lasso.
@Harley Acheson (harley)
The problem, as you stated above, is that selection border as a solid white line becomes invisible on a light background. With a bit of a fill, selection area becomes visible in any colour scenario. So that's indicator for one type of selection. Other type is indicated by a dashed line, which is always clearly visible and may or may not have a fill.
I think the best solution is to add a transparent fill to the selection area. That way the boundary would be clearly visible with any combination of dark/light background and foreground elements. Fill itself could be controlled in the theme settings.
Another thing to make it even more clear is to dynamically highlight elements that would be selected, while you drag the selection.
Dec 1 2020
Sep 26 2020
Sep 24 2020
So it's for simulating natural effects, like Snell's window. Pretty cool, I didn't think of that.
And the "proper" workaround for back faces is to use Fresnel node and plug 1/[ior] into the IOR slot? I guess it could work, but there's almost no chance that new users could figure out how to use Fresnel falloff correctly without a full explanation. I've already seen it used wrong in a couple tutorials.
Sep 23 2020
Aug 27 2020
The "enumerate" button should initiate this functionality upon single click selection in case there are multiple objects behind the cursor
You can call up the enumerate menu by alt-clicking on overlapping objects, so what's the point to have a button for that in the UI?
Aug 20 2020
First of all, I think you should change "select backfacing/frontfacing" to "select visible/select through" in your proposal to avoid confusion. Backfacing/frontfacing refers to the normal direction of a face in relation to the camera and this terminology is already used for specific things like "Backface Culling". This task is about selecting occluded geometry in solid shading, irrespective of its normal direction. There is also a separate issue with backface selection that needs to be fixed, so it's important not to mix up these terms.
Aug 18 2020
So how exactly is this operator going to work? Is it "hold the keyboard shortcut and click on object with the mouse" or "hover over an object and press the shortcut"? If it's the latter, then there shouldn't be any issue with right-click select.
Jul 26 2020
Jul 22 2020
I think the option in the snapping menu was added for better retopology workflow - to prevent accidental snapping to backfacing geometry with solid shading. But if "Backface Culling" in enabled in shading menu but disabled in snapping menu, it gets confusing. In my example I can see the cube but can't snap onto the front facing geometry, because the plane in front is treated as a primary snapping target, even though it's technically invisible. So maybe backface culling should be silently enabled for snapping if it is enabled in the shading menu? That would create a more intuitive behaviour.
Jul 21 2020
Jul 13 2020
Jul 11 2020
Hi @Lukas Sneyd (lcas) , nice to see some progress on this task. I've tried your build so here's my feedback:
Jun 14 2020
do we need industry standards occluded selection or do we need in fact just autoxray selection (no industry standards, blender only)
Internally occluded selection should be implemented to work with any shading mode and then autoxray could be added as an additional option, purely for visual feedback.
However, I think our proposal is pretty much solid.
It's mostly solid, but you should add one more condition and try to find a solution.
Jun 13 2020
3Dsmax, which uses a small checkbox for backface selection indication lost somewhere in UI, and everybody are ok even with that kind of a solution all this time
Eh, that's debatable. 3ds max is not exactly a shining example of a 3d app that is beloved by its users. I've been using it for a long time (too long), and noticed that I have to toggle wireframe mode very often to check what I'm selecting, so I'm hoping that Blender could be an improvement in this regard. The way Cirno's addon works is a great example: switching to x-ray while you drag a selection allows you to see what will be selected, without having to push any extra buttons. Only improvement I would make is to switch only the active object to x-ray, instead of the whole scene, which can be jarring.
This is the way Blender got that much condensed UI.
I just hope that GSoC project for custom menus is completed successfully, and we don't have to depend on one-size-fits-all approach of the default blender UI.
Jun 11 2020
if user checks on face centers, it should be visible in all modes that draw faces. This toggle should change how faces are selected.
This sounds all good and reasonable for drag selection modes (box/lasso/circle), but how would you pick individual faces in wireframe without facedots? There would be no way to distinguish between overlapping faces. There could be an option to disable facedots in x-ray/wireframe for people who don't want to use them at all, but there also needs to be an option to enable area selection even if facedot overlay is on.
May 26 2020
I would simply kill the whole Xray and face dots thing and have one, proper, consistent selection mode.
And what would that one, proper, consistent selection mode, that can satisfy everyone, be?
Regarding X-Ray, maybe it could be merged with Wireframe into a unified see-through mode, that is enabled with the same shortcut/button. And with the X-Ray slider you could set it up to look like a simple wireframe or an x-ray shading that we have now, based on your preference.
But getting rid of facedots is unrealistic, since they are used to reliably select faces that are overlapping each other in wireframe/x-ray.
That's why our proposal consists from a single ui button and several overlay options
Single ui button works well for controlling select through/occluded, but tying facedot selection to the overlay is flawed. If I want to use area selection with x-ray do I have to forego the ability to accurately select individual faces? Why can't I do both? These two modes don't interfere with each other.
May 25 2020
Abscense of facedots in witeframe can clearly visually split face area mode for non-picking selection types
I think it was mentioned in this thread by a developer, that facedots in Wire/X-Ray are used to indicate face selection mode, so they can't even be disabled. Besides, combining those 2 modes would help to save quite a few clicks: you could use area selection for selecting multiple faces, and then immediately pick a specific face by a facedot, without having to switch to facedot selection mode.
May 23 2020
But I am not sure what is the reason to see facedots, but not select by facedots in xray/wireframe.
This "Select by Facedots" toggle only applies to Box/Lasso/Circle, but you still need to use facedots to pick a specific face, with a single click. Otherwise you would need to click multiple times to select a face that's behind other geometry. That's how it works in 3ds max and it's always frustrating.
Also, this header will apply to the entire selection as a whole, even if it is assigned to each selection tool separately
What do you mean "separately"? As I said these settings would work as a global toggle, so that selecting is always consistent across all tools, including modal selection that's activated with a keyboard shortcut.
May 20 2020
It does not make sense to split modes per tools
Ok, perhaps I didn't explain this properly in my proposal, but options that are placed in the tool settings are synchronized across all tools that share those options. Take a look at Drag option for example: if you set the Drag action to be Select Lasso, all tools will do a Lasso Select. So it's not tool-specific, but a global toggle. Select Through (or any other selection-related option) would work the same way. Here's how it would look like placed in the header:
Since Select Through is something you might want to toggle more often, depending on situation, it gets a separate button (which also works as a visual indicator, solving one of the design goals). Whereas Facedot selection is more of a general workflow preference, so it can be hidden in a drop-down menu. This is a simple and concise solution, that doesn't complicate selection process in any way, but places useful options always within reach in case you need them.
It will be a bugfix of a a very ancient problem, that breaks "you can select what you see" paradigm all this time.
It's not that simple. Even with Backface Culling enabled, only the solid shading of polygons is disabled, but vertices and edges are visible. So you can still select what you see, without braking any paradigm. I think it's better to take the same approach as with this task and clearly decouple selection behaviour from the shading mode.
May 15 2020
Modal selection can have the same features available as the selection tool, the only difference is that they are controlled with shortcuts, like these:
Default configuration would be synchronised with tool setting so it would work in the same way.
The problem is that right now there is no place in Blender's UI for global selection settings (because there are no setting, just hardcoded stuff like Facedot selection in X-Ray). So tool settings looks like the only area where multiple options could be put in one place. And it could be made to work globally across Blender. Of course a dedicated space would be even better.
Ludvik's proposal to put selection-specific options in the area used for shading and overlays seems like an ad-hoc solution. It works well in this specific case, but cannot be expanded to accommodate additional options. For example, if Backface selection toggle is added in the future, where should the option be located? Next to 'Backface Culling' in Shading menu? I guess it depends on what kind of long term approach devs want take for selection tools - if all setting should be in one place or scattered around the UI.
May 13 2020
all selection modes
What do you mean?
This is quite a discussion for such a simple and uncontroversial feature :) Anyway, here's my attempt to summarize it and add some suggestions.
Apr 26 2020
Tab + mouse click should work fine, because pie menu is triggered only if the mouse is moved a certain amount. If a drag threshold is set high enough it shouldn't be a problem.
But whatever the default shortcut ends up being, it should be editable in the keymap and not hardcoded in some way.
Apr 24 2020
I think this feature would work well in any of the 6 editing modes, the way Pablo is doing it in sculpt mode (hover and click). The only issue is that there isn't a convenient shortcut that is empty in all different modes. So I think it would be best to add it as a menu item without a shortcut and leave it up to the individual users to decide what shortcut to use, or if they need this feature at all in a specific mode. Blender is really flexible in this aspect, because you can use different shortcuts in different modes for the same action.
Apr 13 2020
Feb 19 2020
So it's not a bug and not an issue with a specific normal map, but a limitation with the box projection? Then maybe it should be mentioned somewhere in the documentation, because it took me quite a while to figure out why my materials look so wrong when I use normal maps.
Feb 18 2020
Are you talking about texture coordinates or setting the normal map to "Object Space"? Because for me normals gets flipped with all the different texture coordinates, but setting the Normal Map node to "Object Space" does appear to help. But it's not a real solution, because if the object is rotated away from 0,0,0, the shading gets completely messed up:
I think that standard normal maps for PBR materials have to be applied in tangent space to work correctly.