I am not sure if I understand you correctly. I am talking about new snap to change front, back, top etc with middle mouse?
Having “auto perspective” on will make you go to ortographic views every time you go to top/front/etc, including when you do it with the new alt+mmb drag method.
I posted on Devtalk, feel free to participate
About the Gizmo, when the positive axis points towards you in front perpendicular to the plane of the screen (for example, numpad 3, 7). Do you think it is correct that it shows with color off (negative) in the center? It is even strange that when you barely get out of one of those views when you orbit a bit, the center immediately shows positive in front.
I do not know why, I find it strange and not intuitive (of course, I can be wrong)
Will they fix AA in viewport?
What issues are you having with it?
It works when the picture is static, but when you start rotating-panning the view wireframe turns into jagged mess, vertexes are blinking and everything looks nasty. There is no such issue in 2.79
If you refer to viewport, while you move the view the samples configured for viewport are not reached. When you stop, the samples configured for viewport are reached and it looks better while the view is static. If you set up viewport samples to 1, surely viewport will not look good even in static image, but you will have less flicker while moving.
I’m not sure if this can be improved with low sample values.
I think I’ve misunderstood, I thought you were talking about Eevee. Sorry.
no it’s not related to evee
here how it looks:
But in what shade mode?
What I said about viewport samples is valid for LookDev and Eevee.
Solid mode should work as in 2.79. Do you notice the problem in Solid mode?
You are right, I can see the problem in Solid mode as well.
Your video isn’t working for me, but it sounds like the temporal antialiasing (taa)
This allows smooth movement, while putting multiple samples to smooth out the still image.
It’s not a bug, its a feature!
if its true its a crappy one i must say) its not a big deal if you look at this messy blinking stuff for a few minutes but it’ll make your eyes bleed after a few hours)
Here is what I meant by how sampling influences lookDev and Eevee:
In solid mode that problem that I show does not appear. But it is true that I have also been able to reproduce what you show in Solid mode.
Clement added backface culling for Workbench, I thought it was already there, but apparently not https://developer.blender.org/rBa185bf3b856846b2e300542bacdca3bc119e1bdc
Well now it is !
Sounds like the code wasn’t near as optimized as we first would’ve thought, meaning there should be plenty of room to boost the performance of the viewport in both object and edit mode.
That gives a bit of hope regarding the current speed regressions.
Yes, this is absolutely a feature. And it’s a good one. I guaranty you that if it was not there people would cry and beg for it. it’s basically a simplified version Adaptive Degradation. It’s what allows you to navigate the viewport with a reasonable frame rate while maintaining all the bells and whistles in Eevee. I think the value is maybe a little less in some of the less demanding viewport modes though.
I have a feeling all they would need to do it implement a minimum and maximum viewport sampling setting. That way, you decide if you want to sacrifice smooth movement for antialiased edges. Right now, it drops down to 1 sample while navigating. But if you had a setting, you could set it for something like 8 or 16 while navigating. Then, you could have a smooth looking rendering but it would stutter as rotated/moved the view.
There’s probably no way around something being degraded though.
I tried different samples 4, 8, 16 in prefs and the result was the same - jagged wire lines and blinking dots.
Here what Brecht said:
As I said before, Sampling settings in render Tab does not seem to influence Solid mode. I’m not sure if we can choose sample rate for Solid mode from somewhere else.
Anyway, I tested again 2.79 and jagged edges were always there, even in static view. So perhaps in 2.8 it is more noticeable because one can see the variation of jagged edges when there is movement, and when the edge gets better in static view.
Ok, User Preferences > System > Viewport Quality. Set the value=0 and you will always get jagged edges in Solid mode, even in static view. So I suppose that with a high value of quality, the time it takes for jagged edges to display well may take longer in slow graphic cards, and therefore it will be more annoying.
I’m not sure if you’re understanding me. I’m saying, the way it is now, you can’t change the fact that it drops down to one sample. But that’s useful for quick navigation.
There needs to be a setting to control the minimum samples while navigating and the maximum samples when stopped. Currently, it’s hard coded to 1 sample while navigating.
Hmmm. I see what you’re saying but I also think it still makes sense when you think about how things are handled in each engine. Random walk SSS for instance is only available in Cycles. There are no rays in Eevee so any of the things you might set up in Cycles involving light paths would be invalid in Eeve. There are still nodes that only work with Eevee like that material output node… is that what it’s called? Can’t remember. Anyways I think there will always be a need to have separate material settings beteen them but still retail a common environment.
Also, I see a point where some people could have renders that are made up of elements that are rendered with Eevee and some with Cycles and then comped together. I think this just helps facilitate the ability to pick and choose the right time for the right situations.
Example: a character is shaded for Cycles and Eevee separately and slightly differently to help match the look better. In some scenes the character is front and center and rendered with Cycles. In other scenes they are in the background and rendered with Eevee. Maybe even with GI and AO baked in.