- User Since
- Feb 19 2010, 6:04 PM (465 w, 3 d)
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.
Jun 3 2016
Aug 29 2015
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 28 2014
Jul 12 2014
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.