- User Since
- Feb 19 2010, 6:04 PM (584 w, 5 d)
Thu, Apr 22
Sun, Apr 18
Dec 20 2020
Absolutely. Like I said, if a solution can be found to freely manipulate the pivot point without losing the selection, that would certainly solve this. Until then however, removing the current workflow would be a regrettable downgrade.
That just abuses the fact that cursor placement is not currently undoable. And using undo as part of a forward action is a much worse UI problem than the current Active/Selected situation.
This just means that you're using some object as the 3D cursor. I'm wondering if it's worth the confusion of having active-but-not-selected as possible state. Why not just snap the cursor to whatever reference position you want to use?
Nov 6 2020
Sep 14 2020
I think your ideals are clouding your judgement on matters of practicality.
Sep 13 2020
I think the live sharp update and normal calculation is an excellent feature for low poly modelling (that is to say virtually all modelling before the model gets complicated), and I wouldn't like to see it go - until you hit the several-thousand-vertices threshold when performance starts to chug anyway.
Sep 6 2020
Aug 1 2020
I most emphatically agree with Kenn. Categorizing brushes by tool only makes a certain sense from a programmer perspective. For the sculptor, the brush is the first class citizen, not the tool, and users ought to be able to group and categorize their brushes freely.
Jul 12 2020
Jul 7 2020
Jun 28 2020
Look, it's not helpful to call this *just* a visual glitch. Unlike on a monitor, in a VR session, visual glitches cause considerable discomfort, especially when it's a discrepancy between eyes.
May 28 2020
Apr 15 2020
Apr 14 2020
Apr 8 2020
Feb 22 2020
Jan 25 2020
Jan 24 2020
Jan 17 2020
Jan 16 2020
Jan 15 2020
Multires for sculpting is good, and baking vector displacement is also good, but one vital use case that is important in Blender (and not important in other pure sculpting apps) is sculpting on a rigged, posed, animated mesh. This is important for animating muscles and such. Blender has no alternative solution for this such as a muscle system or a robust system for rigging physics-simulated objects.
Dec 26 2019
If only selection was on another mouse key!
Dec 10 2019
You have also set max subdivisions to 1 in the render properties, which prevents the adaptive subdivision from dicing the mesh finer than that.
You have two levels of non-adaptive smoothing that are getting applied first. Disable the 'adaptive' checkbox on the modifier to see and set it to zero, then turn adaptive back on. You'll get your 32px subdiv.
Dec 3 2019
Emulate MMB is just indispensable with any kind of pen input devices. Buttons on pens are generally unreliable - in that you can't rely on it that they exist at all, and how many.
Nov 22 2019
Nov 13 2019
I have no words for how bad this is.
Nov 6 2019
i think that bake jobs is the better option. in that jobs you indicate.
- the lowpoly objects (maybe with collections or other)
- The highpoly objects (with other collection)
- The UV map
- The Material Filter
- The passes
And inside the passes
- If the objects must to use multires to bake (not like now that you indicate it out)
- if the objects must to bake only same name meshes
Probably the option to implement that is inside Image editor or a new editor. I know that it's strange tell that, but I don't see why bake must be inside properties of an object.
Oct 14 2019
Oct 12 2019
Aug 27 2019
Dots are not an "old" MS-DOS concept. They are a filesystem concept in active use wherever you use relative paths. This is bread and butter for anyone who has ever written a script, an html page, or linked in a texture.
I don't see how that's an argument against the dots. There's nothing wrong with opening the parent directory on doubleclick.
A note on the dots (..):
Aug 22 2019
Aug 20 2019
Aug 13 2019
I think you're overcomplicating it. There's plenty of space in the file dialog since it's fullscreen anyway, unlike most system file browsers. Just keep the options visible and consistent.
Aug 1 2019
I think @Erick Tukuniata (erickblender) brought up a fair point though. The cost/benefit of a separate mode strongly depends on the level of automation we can expect from the new tools. If the target is excellent manual retopo, then going with improvements to Edit mode would be much preferable. If the devs are more ambitious and are going for something semi-automatic, like described in Data Driven Interactive Quadrangulation, then a new mode would definitely be the way to go.
Also regarding Workflow point 4, source "objects" only rarely consist of only one actual object. So storing the retopo mesh reference per object is not great. Instead maybe store source object collection per retopo mesh?
The mesh display in the third picture is not very good either as there is no way to judge at a glance whether any given pixel is above or below the surface of the source mesh. I'd suggest at least drawing an outline of where they intersect, or maybe drawing the portions above the source mesh in a slightly different shade.
This is a feature. ;)
Jul 31 2019
I'm not going to put myself in either camp, but if you're going to make a new mode, please give some thought to this important consideration:
Jul 26 2019
Yeah, I agree, Overscan ought to be a generic thing independent from the render engine. It makes no sense to restrict it to Eevee.
Jul 25 2019
The operator settings on the bottom left sometimes contain only a few items, but particularly for exporting, they have the potential to contain dozens of different settings. We often see these bunched up into a tiny area, with its own tabbed interface even. This is not good. Settings should be presented to the user proudly and be visible at a glance.
Jul 17 2019
Jul 4 2019
Jun 30 2019
Jun 23 2019
Jun 21 2019
Jun 20 2019
Jun 8 2019
Jun 6 2019
If you're going to put yet another obscuring floating element in the content area, at least make it movable please, and provide a non-obscuring alternative, like printing that info in the status bar.
Apr 10 2019
Mar 11 2019
I see. That is unfortunate.
Thanks for looking into it. This is a pretty severe problem without an artist-side workaround, so is there any chance an alternative algorithm might be implemented down the line?
Jan 30 2019
My apologies, i should have posted a screenshot from the beginning.
Jan 29 2019
Nov 23 2018
Both xray and wireframe modes, while useful for some tasks, are distracting and busy, and annoying to have to switch to each time you want to select through. As a user, I'd like a select-through mode that isn’t visually compromised by backfacing geometry and could be left on for extended periods.
Jun 7 2018
Regarding mode switching, I'd just like to point out that Mode switching occurs frequently, yes, but definitely not so frequently that SIX precious prime real estate left side keys should be wasted on it. Just add a pie menu to the Tab key instead. Or just a plain old horizontal menu if pies aren't kosher for some reason. Instead, dedicate the number keys to whatever makes sense in a given mode. In Edit, that might be switching between submodes. In Sculpt, Texture Paint, Weight Paint, Vertex Paint that might be brushes. In Object mode they might be used for some of the newly-modal tools from the T-panel, like Cursor or Border select. Using all those keys just for mode switching would be a huge waste when the single old Tab key can do the job just fine on its own.
Jun 5 2017
Are you sure?
Jun 4 2017
Sep 4 2016
In this particular file, sure, "both" works.
Jun 8 2016
Regarding the design, we'd optimally want to have both solutions - to have the checkbox method, but also have a button next to it that creates the custom data layer. I realize this is the most work of course. YAVNE's functionality is generally very useful and shouldn't IMO be relegated to an obscure addon.
Aug 26 2015
Dec 30 2014
@Sergey Sharybin (sergey) In my particular case, I'm working on a baking addon. I have to prepare a scene before baking - merge/split objects, adjust UVs, modify shaders, run a compositor tree on the result once it's baked, etc. Lots of destructive stuff, which is why I'm doing it in a temporary scene. Since in the end I have to call bpy.ops.object.bake, and that relies on context, I don't think I can avoid setting it?
Dec 29 2014
Aug 17 2014
Simmer down guys. It will be fixed when it's fixed. Rome wasn't built in a day. It's a pretty serious problem, yes, but I don't think anybody's taking it lightly.
Aug 6 2014
@Thomas Dinges (dingto): tested - sbrown's file still takes 2.87GB with 4cf531f.
Aug 1 2014
Jul 29 2014
I don't get it. What does the highpoly[i].pixel_array represent? Why is there an image being stored for each hipoly object? That doesn't seem to make much sense. Rendering from the camera doesn't do that.
Jul 5 2014
Jul 2 2014
I'm still experiencing crashes with 5898abe (buildbot), Windows 7 64bit.
Jun 26 2014
May 7 2014
I see. Positive would have been more practical in the course of making shaders, I think. But fair enough, it's not a big deal.
Feb 24 2014
Works great now, thanks Sergey :)
Feb 21 2014
Previously the triangulation was confined to the immediate intersection are and so it was reasonably easy to clean up. The current behavior will sneakily triangulate quads in unrelated areas. I'd hardly call that more predictable, except in the sense that it's predictably dangerous to use. If the bug can't be resolved, the previous behavior, which was not great but at least it was manageable, should be rolled back. The new behavior is not an improvement.
Dec 16 2013
@Brecht Van Lommel (brecht): Thank you so much. :)
Removing X is ridiculous. The delete and dissolve (ctrl-x) functions are often used in bursts where you press them every couple seconds interlaced with other operators. This would very quickly cause fatigue and annoyance while editing meshes.