Personally I prefer simply Walk Navigation (where you can also fly with TAB) which is in Blender.

Since there is a discussion now and a hopeful horizon I would like to add that since we're talking about cameras it would be great to have Exposure & Contrast controls.

I am sorry Eddie I am not sure what that means?

@Simon Ashby (Oooklout) could you try with the newest builds if the issue persists?

Closing this as archived for long inactivity.

Closing this as archived as it seems like hardware related issue (not sure about your CPU - is it 2 cores, 4 threads?)

Archiving for long inactivity and also because this is an issue on the side of Huion software "gamer" mode which causes the issue in the first place.

Archiving this for long inactivity also necessary to get more information how this now works in 2.80.75 or 2.81.16

Not really my kind of bug to fix as I don't have problems with fbx.

Archiving this for long inactivity.
also related to: T62456

Fixed in T67637

Archiving this for long inactivity.

I think the best solution is to use US or other international keyboard layout when using blender. It solves lots of issues.

What you can try to do is create a new file and append everything from this through File -> Append if that solves the issue.

Not sure what this can be, but you can update to Windows 10 anytime from Windows 7 with this tool: https://www.microsoft.com/en-us/software-download/windows10
It is really worth it in the end

You need to hold CTRL while placing (to toggle snapping on/off with ctrl) or enable snapping (Shift+TAB) or at the top of 3D view there is a little magnet tool you can enable and choose which elements to snap to (vertex - edge - face etc).
Either way I checked in 2.81.16 and it works now:)

I am afraid this is one of those "This isn't a bug" while in reality it's a massive and scary Scarabeus. It's the sort of bug that acts like it isn't one from the technological viewpoint but from the user perspective you delete your stuff.

Closing this as resolved. Thanks for the reply!

What is the name of the image you're trying to import? Or better: entire path to it.

There used to be occasional crashes in LookDev but I think this one you were experiencing in particular is gone in latest build.

Can't reproduce here either. @eldee smith (eldee) if you want the issue fixed I think you need to put together that test script.

Those two boxes are linked together. The lower one is only more detailed description. Closing this as invalid.

I can confirm it doesn't work for the old .blend file that is uploaded above however the issue has been fixed since and it works fine if I append the objects from the file above and essential recreate the scene.

I don't think this is a bug and more of a technical limitation.
The reason for the weird cuts is floating point imprecision. As your faces are laid exactly on top of each other the operator struggles determining what's crossing what.

To me it also seems practical as often I have Irradiance Volume in it's own collection and use the irradiance spheres visibility toggle to check stuff.

It's a shame though because in 99% of cases I really don't want to divide only the cm part..

@Dariusz (Dellishia) if you update your nvidia drivers to the newest version, does it still happen?
Can't reproduce this on the 5 computers I have access to. I think it must be something with that specific GPU.

Check T69603 for further information when it comes to Edit Mode / Snap Cursor to Selected. These problems are highly likely linked.

Archiving this as duplicate of T69603
Even though it's Object vs Edit mode the problem is identical for both.

Can confirm that cursor doesn't respect quad orientation on randomly rotated mesh that has applied rotation.

Please use https://devtalk.blender.org/ for these kinds of suggestions.

The behavior of "Copy visual location of Bone Middle to exact location of Bone Left", is working wrong due to the Constraint affecting bone Middle to copy bone Left (Loc,Rot,Scale).

I think this one is to be closed by @Campbell Barton (campbellbarton) or remain open forever.

Can confirm, think it should respond to Optimal Display settings etc.

Problem here is that actual size of the mesh (how far away from each other the vertices are in a matrix - how many values are between them) and scale (just a number to scale the size of mesh with) are 2 different things.

Tried in 2.81.8 and the issue is gone.

I can confirm this, here is the test .blend file

You need to attach a blend, this is not happening on 99.9% of meshes. Ideally if you left the exact selection you've had there.
I tried it for a while and couldn't get Blender to crash.

I am afraid this is rather considered as user feedback and not a bug. Try to reach out through https://devtalk.blender.org/
Also the time it spends on those is rather minimal.

Well it's not how it used to work in the old Mapping Node and also more importantly it's not how Blender 2.81.8 itself updates the files that are loaded with the old Min Max utility used.
It actually rearranges the nodes exactly as on the second screenshot where everything is black.

This patch rewrites the Mapping node to support dynamic inputs. The
Max and Min options have been removed. They can be added as Min and
Max Vector Math nodes manually.

Not reproducible here on Win10, 1070M Blender 2.80.60. Tried all textures, never crashes.

In T60038#669341, @Temirlan Tauzhanov (tauzhanovt) wrote:

Glad to hear someone replied. I had to remove the original UV and rewrap it to solve my problem.

Closing this because it is intended behaviour. It might be useful to use the arrow keys right next to numpad to change frames etc.

Hi there is indeed something wrong with the UV map but after recreating it (and even moving it out of bounds) everything seems to be fine. Odd thing was that the center of transformation for UVs was somewhere in infinite lower-bottom part of the UV map space when you selected with B. But if you singularly clicked out all triangles and scaled the transformation center was where expected to be. There was no triangle hidden in lower left part, I was checking.

Can't reproduce this here. Win10 1070M drivers 417.22

Closing this as resolved because the issue is gone in 2.80.60

Next time try rendering into FFmpeg video with container matroska or mp4 or as others have suggested either jpg or png and then assemble the file later differently.

@Mike Aspinall (dmkmedia)
Could you download the latest build from https://builder.blender.org/download/ and try it again?

Closing this as invalid because it related to hardware limitations and render settings issue.

@Steffen Dünner (SteffenD) Yes that looks like the same issue. Hopefully the fix is straightforward.

Hi, for me everything works blazing fast. I think you need to try to track down the problem somehow.

Can you try to increase thickness and distance on contact shadows but also decrease bias and increase exponent on the Sun Lamp?

I noticed there are FaceMaps now which are not only useful for animators but really for any modeller who wants to save certain face selections (some checkerboard selections weren't possible with vertex groups).

Not sure but for me it looks still the same? Maybe it's because I'm using the 2.79 instead of newest builds?

Yeah it looks similar but after watching the video I don't think it's the same.

Hi again,

Yeah it looks like the speed is linked to font size. So what Bastien noted in the first comment might be the cause - loading huge amount of glyphs.

@Stephen Pflanze (megasoid) Question for you ^

@Dong-Hyun Kim (temeddix) if you read all the comments you'd realize it's actually not a simple problem. It's really not helpful to call problems simple and urging people to fix them. It's good to bring the issue up and ask if there has been some progress but try to steer clear of the "can't believe this still hasn't been fixed" or "such a simple problem". Let me be clear though that I've done both in the past but I wish I hadn't.

@Alma Talp (AlmaTalp)
All this doesn't take from the fact that 2.8 wireframes do a lot more heavy-lifting and provide much more clarity in many scenarios that aren't extreme.
For example if you only work on one floor at a time it gives you much much much better understanding of what you actually see, although everything is dithered.
2.79

@William Reynish (billreynish) That's great news. Amazingly great news^^ Application template ready. So does this mean we could change color per icon if needed?
I will probably tune mine in Properties menu to corresond with the current general set of colors / greys.

AFAIK unless you start changing materials you don't break anything. It would be fine to have a warning but this issue kind of resolves itself with 2.8 materials being synchronized across renderers.

Not sure here but have you trying holding ALT before clicking into the number field and then typing it? There is sort of a hidden feature in Blender that if you hold down ALT the action gets performed for all selected. But that does not work completely consistently (probably why it's hidden) so it might not work here.

Closing this as duplicate of: T57320

Can the icons be scaled up and have more white space between keys? Asking more as a UI question if icons can scale together with text tbh (are vector). Or are the icons bitmap? Good job this looks great now just the interpolation with the curves, that would be a massive help with motion graphics.

In T53840#505679, @Andrzej Ambroz (jendrzych) wrote:

1. in real use, icons are apposed in UI in small bunches that are contextual. Colour ain’t that much needed here. Honestly, some of current icons pop out too much because of their colour, attracting user’s attention to particular parts of interface. It would be good to incorporate some colour codes though - in File Browser, Asset Manager or Outliner. In every place, where one has to manage big lists of items.

Sorry but this website is in English.

In T55162#543383, @Paul Kotelevets (1D_Inc) wrote:

Current Blender Keymap Inconsistencies:
V - Merge vertices
Alt+V - Rip verices
have horrible defaults

Doesn't happen here. Also you should not have to work on 500k+ mesh in Edit Mode. It's something to avoid at all costs.

I don't recall reading there is a rule not to reopen tasks from others when they are still valid.

Reopening this to raise awareness after 5 months as many many materials rely on NodeGroups with inputs.

@adam earle (adamearle) It needs to be reproducible every time.

Check here for more info on the process of how this was thought out: T55162

Sorry, opened again as I see it's a Patch and can't judge the code^^ Still a good idea to further discuss this on devtalk or mailing lists.

This is mainly a bug tracker so closing this.

Could you try if this happens with the latest 2.8 builds too?

When it comes to "visual" issues it's always best to attach images describing it well. In this case maybe even editing how you think it should look.

Don't think this is an issue but you're not using the modifier right.

@adam earle (adamearle) could you please change the name of the task and it's description so that it's clearer?

Don't think there is a problem with reflection but there is an issue with refraction.

Guessing from your hardware specifications this is just the way it is and is most noticable on slower computers.

Can confirm this issue.

In D3788#86520, @William Reynish (billreynish) wrote:

@Adam Preisler (Alphisto): Yikes, I don't think that will work in practice. That's way too information dense and will just look like visual noise. You have to understand that these icons will be displayed really small and there will be loads of them.
To be useful, this feature has to be simple and clear to the user, otherwise it's just visual noise and random shapes.

@William Reynish (billreynish) I had a go at it and figured something out.. but question remains how it works in the dope sheet UI and also how it feels during work..
I noticed that different handle types use different colors for their handles in 2.79b at least. That is not too bad, but the problem is that for example aligned and auto-clamped use almost the same shade of pink. So maybe long dashed and dotted could be introduce to ease this up a bit.

It's not that easy because the mesh doesn't have volume data for material assignments.