- User Since
- Mar 27 2016, 6:39 PM (168 w, 4 d)
Apr 13 2017
Good point and good example. Deviations of the preview renderer from the final render should be optional and explicit exceptions rather than the default though - in sensible cases like the one you describe.
Apr 12 2017
Thank you - that has been pointed out to me by now. :)
It basically boils down to the question:
Do users expect/want the Cycles preview to behave more like the viewport or more like the final render (except for sampling)?
My assessment is that the more desired/expected behaviour is for the Preview/Viewport Renderer to resemble the final render as closely as possible, which is also the route every other production renderer I'm familiar with (Arnold, V-Ray, MODO, Redshift) takes.
I understand that it may not be a code bug because it may work 'as intended' but I do think it very well qualifies as a design/UX bug in that its functionality is not consistent with how most users would expect this to work based on the paradigms and terminology laid out by Blender.
Apr 11 2017
Mar 31 2017
I like and agree with both those suggestions - the edge opacity relative to their length on screen, and the grid opacity based on camera angle!
An infinite grid becomes most visually distracting towards the horizon line. This seems like it might be a nice solution without too many dependencies on stuff in the scene and magic numbers.
Mar 22 2017
I like the fading - looks great.
To be honest, I find a fading grid a lot more attractive and visually clean than an infinite grid. There's really no tangible benefit to see grid lines into infinity, on the contrary - at low viewing angles it just clutters up the view towards the horizon line.
Mar 21 2017
Great mockups! I'm very much in favour of grid fading and resizing grid density as well.
MODO does both and it's quite elegant.
Maya does neither.
Sep 10 2016
Click the demo GIF images to show their full animation.
(The preview thumbnails are just static images it seems.)
May 22 2016
Awesome, thank you. I edited my previous comment.
Didn't see the commit at first, sorry for the confusion.
Sorry but why was this set to "Resolved" without any further comment?
@Campbell Barton (campbellbarton): Did you check the project file I attached?
May 20 2016
May 13 2016
Yeah, in that case I'd prefer to have clean solid squares, maybe half-transparent, and the letters cut out of them (i.e. the letters form negative space). In any case I think it should be antialiased so that the manipulator looks more legible and modern.
May 12 2016
Nice idea, I like it.
May 4 2016
I disagree that it's a bad example and suggest that, like in Maya and other industry standard applications, a layer's visibility setting should override the one in the Outliner for a given object if it's invisible.
May 3 2016
Apr 30 2016
I agree that the eye icon isn't great in general but I think consistency throughout the application is more important.
So getting one single icon for all "viewport visibility" toggles implemented throughout all aspects of Blender should be the first step. Once this is done, this icon could very well get replaced by a less dated/legacy one in the future if one can be agreed upon that communicates the purpose as clearly as the widely used eye icon.
I see. I'm just wondering if there isn't a way to retain a single "visibility" icon (the *eye*) for all purposes where a toggle changes "viewport visibility".
Which layer-specific visibility icons currently in the interface are you referring to?
The check boxes on the right side in the Render Layers list?
Aren't those essentially just "Render on/off" toggles and shouldn't they therefore be represented by the photo camera icon used to toggle if something is "Renderable" or not that's used everywhere else?
I see. Thanks for the explanation. Sounds good to me.
And what are the Toggles on the left meant for? :)
As I suggested here, I think colour coding would be the best way to keep the header quick layer workflow. Let the user give every layer its own colour which then gets represented in small header icons.
Apr 15 2016
- Blender 2.77a
- Windows 10 Pro 64-bit
- NVIDIA GeForce GTX 980 Ti | Driver version: 364.72
- After starting the latest build from the buildbot and trying around with different settings, it turns out this error only shows up when MultiSample is set to 16. Every lower MultiSample setting works without problems. But MultiSample 16 causes the drawing issue every time the cursor leaves the UV Editor.
- Placing the opengl32.dll inside the blender folder had no effect on the behaviour. MultiSample 16 still showed artifacted edge drawing in the UV Editor when the cursor left the view.
Ah, I see. Apologies. Elsewhere it has been recommended to me to change the Window Draw Mode to "Full" because otherwise I was getting ugly drawing of edges in the UV Editor whenever my cursor left the UV Editor view, as shown in this GIF. Setting Window Draw Mode to "Full" fixed that issue.
Apr 11 2016
Apr 4 2016
I use an NVIDIA GTX 980 Ti. After reading T45093 and noticing that setting the tile size from 64x64 to 160x120 reduced my render time from 2:16min to just 57sec, I searched for a data-driven addon for determining optimal tile sizes.
Just tried this add-on here out and it falls short of the seemingly optimal 160x120. Rendering the same scene with Auto Tile Size on takes 1:23min.
So I was wondering:
Apr 2 2016
Without trying to derail the discussion about the visual design - how is it planned that the new universal manipulator widget will be triggered/activated?
Is it going to be by SHIFT+clicking the SpaceView3D.transform_manipulators icons in the 3D view's header, like you currently do in Edit mode when combining different selection modes by SHIFT+clicking on the vertex/edge/face selection icons?
Apr 1 2016
Aah, I see. How about having three shapes at the center, like in the MODO cyan ring example? A square for uniform scale (square signifies scale), then inside that a ring for free form rotation (if that is considered necessary) (ring signifies rotation) and inside that a triangle for free form (screen space) translation (triangle signifies "direction")?
Ah, awesome! Thanks for getting back to me as well as fixing the bug so quickly. :)