- User Since
- Feb 19 2010, 6:04 PM (499 w, 5 d)
Tue, Aug 27
"What you see inside a directory then, is a list of that directories' contents. If the directory contains 7 items, you see 7 items, not 8 items as you'd currently do. Right now you always have to do a mental subtraction of one to get the correct number of items."
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 (..):
Thu, Aug 22
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.