- User Since
- Feb 14 2019, 7:12 PM (87 w, 4 d)
Tue, Oct 6
This one comes and goes. It was annoying me plenty and I was able to restart Blender, load up the startup file, and record it using OBS. It was very consistent and predictable that day, but sometimes it's just not there at all. I haven't figured out how to make it appear consistently. I thought I'd post it anyway in case it was a common problem.
Tue, Sep 29
Sat, Sep 26
Wed, Sep 23
I thought this was affecting only the viewport but I'm getting these artifacts on some of my renders as well. Will try to make a demo file that shows that.
For me the z location goes to -110317169690857735127223106535424 m. Cool. Default cubes are faster than the speed of light.
With a little trial and error I've found that the bug will appear with a setting of Auto and a Resolution Scale >= 1.19
I'm only getting the bug with Thick.
This bug only appears for me when the Thick setting is used. Thin and Auto do not show the bug. Also note that when the bug appears the axis thickness is scaled by zooming. You can zoom in and have the axis line cover your entire view for example. This makes doing simple operations like moving an object next to impossible.
Mon, Sep 21
They're certainly less editable, but the outline color is there so I can see the objects to transform them and do stuff with them. Dimming a highlight colour negates the entire purpose of highlighting. When you have a scene with a hundred or more collection instances this is a big deal. I want the objects I've selected to be visible. That the code for dimming is already there is unfortunate but it's doing something completely counterproductive. Use it to put in another color. Make it a dashed outline. Just do something that makes it so I can still see what I've selected.
Dont get me wrong either, that link https://wiki.blender.org/wiki/Reference/Not_a_bug also explains why it is not possible to to implement every inconsistency we might come across.
The collection instances only highlight with the dimmed 'active' colour, whether or not they're just selected or active. Also, please run this past someone who uses collection instances a lot. As I said I have scenes entirely filled with these objects and outline highlighting is nearly useless. I set the highlight colour to bright yellow and I can't see it most of the time because it blends right into the background. This is making it hard to work in my scene. I've even considered not using collection instances until this is fixed.
This is NOT a feature request. I only would like a feature that exists, outline highlighting, to work properly. I need to SEE the objects that I have selected. I have a scene filled almost entirely with collection instances. If you want to use outline highlighting for some other purpose such as communicating object type then do it through another colour in the themes panel, not by DIMMING the HIGHLIGHTING. I hope I haven't come across as rude
I feel this is a bug because I want to see the object outline highlighted amongst a bunch of other objects. That's its purpose. Not to communicate something I already know, which is that I'm using collection instances. Knowing what objects are selected and which is the active seleected object is far more important than than being reminded yet again that my object is a lesser object citizen - the collection instance.
With 'nothing' selected Blender exists in a weird state where you have an object semi-selected. Some parts of the UI treat the object as selected, such as the origin dot, and others, such as the outline selected don't show. Tools don't function on the semi-selected object but it's still up in the properties panel. I'm not even sure what Select None really does, because there's almost always an active selection of some kind. This goes against most other software that I've ever used.
So only the origin dot tells us this, which is often turned off in overlays so it's not exactly helpful. The Active Object outline doesn't show that it's the active object when nothing is selected. The whole point of unselecting objects is to NOT have an active object. There is clearly some weirdness going on.
Sun, Sep 20
This has to do with the Preferences - Line Width settings. If it's set to Thick the bug appears.
Open the General startup file. Select the default cube. Hit Tab, or whatever your shortcut is, to go into Edit mode. Is that working?
Sep 20 2020
I'm getting it too. RTX 2080 Ti, Win 64 bit pro. If you're zoomed in on the model the giant axis lines can fill the viewport.
I was having crashes with custom transform orientations today but I didn't have time to reproduce it with the default startup file. Now I see you've managed to do that. Thanks.
Sep 19 2020
So, what are the reasonable limits on model sizes? Either this is a bug or something else is going on. Do I need to scale my model down? Is 146 x 91 x 31 really too big for Blender to handle?
Sep 17 2020
Sep 16 2020
Not sure what you mean by 'default size'. I checked the scales on each object and they're all 1,1,1. I'm using a modified units setting scale of 0.01 but I've built a rather complicated model and this is the largest piece of it by far. None of my units should be considered too small.
Aug 29 2020
I figure the following bug should be captured with this task. I have a second window on a second monitor showing only the properties panel. The dropdown menus don't go behind or on top of other windows. They're actually cut off. That's my black desktop wallpaper by the way.
Aug 22 2020
So I just put the latest version of Blender on my laptop and I get the exact same behaviour. It's running Win 10 Pro 64 bit and has a GTX 1050.
I updated my video drivers. No change in behaviour. The only thing I'm doing in the video is clicking with my left mouse button but I did reset the keymaps and that didn't do anything.
Jul 28 2020
May 28 2020
My experience is that passing around depsgraph objects is painful, prone to error, and difficult to debug. If there's a way to handle this in a more automated fashion then I'm all for that. It would be great if code didn't have to be completely rewritten just because you're rendering an animation rather than a still frame.
It's not a paper cut. It's an oozing chest wound that's starting to smell bad.
May 22 2020
Something working 'as designed' but the design being so unacceptable must be considered a bug. What's the threshold?
May 4 2020
The documentation doesn't even say what AA stands for.
May 3 2020
The Arnold documentation has absolutely nothing to do with this. The samples setting in Blender is called Samples or better yet Render Samples and not AA Samples. This is an easy fix. Documentation should use the language used in the application (Blender in this case) for clarity and simplicity.
Can't clean up anything without cleaning up everything. That's why it stays so messy. If we're ok with having it named different things all over the place then whatever. The vast majority of people aren't using branched path rendering on the CPU. Start changing the documentation and let the coders figure out what to do with their own deprecated names.
As far as I know there's no setting in Blender called AA Samples anymore. If you find it let me know please.
May 2 2020
Without digging into the code it seems that adaptive sampling counts up to your render samples setting but won't change pixels if they're within your noise threshhold. It doesn't stop rendering when each pixel in the tile reaches the noise threshhold, it must keep running noise checks or something on every pixel for every sample.
Try this: With the default cube set the noise threshold to 0.1, minimum samples to 200, and the render samples to 10,000,000. It'll render the noisy tile and then spend minutes not changing the image at all but counting up to the 10,000,000 samples for no reason. Even for tiles that are entirely background. It seems this algorithm doesn't actually stop when the noise threshhold is reached.
May 1 2020
Apr 20 2020
Apr 19 2020
The bug isn't necessarily that there are limitations to the nodes that the developers are aware of. The bug is that the users are completely unaware of them. When a node isn't going to work for an input source there needs to be a warning or it should be greyed out or something to that extent. Maybe even put non-hdr compatible nodes in a different spot in the menu. Anything really to let the users know about the limitation so they don't waste a bunch of time scratching their heads trying to figure it out.
Apr 18 2020
Thank you. :)
Apr 16 2020
Changing the range might be outside the scope of the bug tracker, especially since it'll break existing materials. However, the label is most certainly a bug and is easy to change.
This has NOTHING to do with the Musgrave Texture node in particular. Either Fac outputs are supposed to be in the 0 to 1 range or they're not. Blender nodes have been designed to have a common interface and that was one of the decisions. So if you want to keep the range -1 to 1 then at least call it something other than a Fac output so it's not so damn confusing. If every Fac output had a different range it'd be a mess. This is about consistency and predictability.
The issue I have isn't the range of the Musgrave Node or the shader. It's really the labelling of the Fac output. We're led to believe that ALL Fac outputs have a range of 0 to 1. Blender is moving towards having more and more nodes. If this assumption isn't correct then it should be addressed. I think it's a bad idea to have a hundred Fac outputs limited to 0-1 and then suddenly this one node is different. I was trying to do some math with the output of the node and was scratching my head trying to figure out what wasn't working. So the bug is that the output from the node is labelled Fac. Call it something else if it doesn't behave like every other Fac. Thank you.
We can't do proper math using the output from the Musgrave Texture node. For example, when you multiply two numbers together and the lowest value you're expecting is a zero, a negative number really messes things up. Which would be perfectly fine if the software wasn't LYING to you by telling you that the numbers were strictly in the 0 to 1 range. That's what "Fac" output means. That's its purpose.
Fac inputs and outputs are supposed to be limited to the range of 0 to 1. It's not 'unconventional', it breaks the workflow because it's completely unexpected. We're making assumptions about what our math will do based on the number not dropping below 0.
Apr 10 2020
Feb 4 2020
Also there seems to be no way to reset the zoom for many editor panels
Jan 25 2020
Even setting the grid colour (RGBA) to 0,0,0,0 will only get you close to the axis colour. I can't get a pure red axis to show up on screen. Perhaps there's some other colour management stuff going on there.
I can confirm this. For an easy to see example set the x-axis to red (1 0 0) and the grid to blue (0 0 1). The x-axis will show as a magenta line.
Oct 10 2019
I have to disagree. In all cases, no matter what settings are used, the resulting vertices should be on the existing faces.
Oct 6 2019
Oct 5 2019
I need to comment again on this one because many people don't seem to understand the problem or it'd be fixed by now. Just don't turn off the axis gizmo while using transform tools. That's it.
Here's what the screen looks like with the cube selected. I've circled what I'm calling the axis gizmo:
Oct 2 2019
I can get it to load the startup file but as soon as I open one of my current projects it locks up.
Blacklisting is fine but don't give an "everything's great" message by default. It's ok to say "This GPU/driver combination's support level is unknown".
Sep 29 2019
I find it disappointing every time someone says something like "can't be solved". "No parametric input, can't be solved"? Seriously? If it can be done with the 3D cursor method it can be done without the 3D cursor. We're not re-inventing the wheel, we're just bypassing the step of moving the 3D cursor and then moving an origin to the 3D cursor. At this point most people would accept simply automating these steps a bit more.
The transform box in the sidebar should operate only on the origin when in this mode. Otherwise there's no way to place the origin by keying in coordinates, other than the old method of keying in the 3d cursor coordinates and then moving the origin to the 3d cursor. I also don't think that gizmos and snapping should be the only way to complete a transformation. There should always be a spot where you can key in precise values.
Sep 28 2019
I'm having the same error. Every time I make a connection a connecting line somewhere else vanishes. This version does not have the bug: blender-2.81-b043bef000e9-windows64. This version (and all after) has the bug: blender-2.81-b962aca8003d-windows64. That's as close as I can get because I don't have versions in between
Mar 21 2019
I can't believe we need to convince devs that dealing with huge UI issues is worthwhile. If many had their way Blender would be a command-line tool only.
Mar 12 2019
UI elements disappearing and reappearing while you're working seems pretty on-topic to me. I was going to post this as a new bug but found that it's been identified already. No bug comes anywhere close to being as annoying as being brushed off by the developers though. We're not whining. We're beta testing. I show my praise as well by donating to the development fund. Bug reports will always seem like a bunch of whining though, and there's nothing I can do about that.
Mar 11 2019
This bug is annoying me constantly. Every time I hit G to move something I look for the axes gizmo in the top right corner to see which axis I should be moving along and the gizmo is gone. Then I hit escape, look at the gizmo, decide the direction, then hit G again. It just kills the workflow when you're up close with something and aren't sure which way you're facing.
Mar 10 2019
A note in a tooltip doesn't make this any less broken.
So there's no way to disable the grid in orthographic view unless you hide ALL overlays. Broken by design. Gee thanks.
Mar 9 2019
Mar 8 2019
Feb 27 2019
Invalid. Seriously? Setting the origin transforms the collection. That's clearly a bug. Also having the origin be set in a completely different way than everything else is a bug as well. Don't just close this out. Set it to a lower priority but to call this behaviour Normal is an insult.
I tried using the openGL32.dll. It still renders my normal mapped objects as black, just very very slowly. I'm on Windows Pro 64 bit with a GTX 1050.
Feb 26 2019
Is this fix in the latest build because I'm still seeing an x-ray view of edges in orthographic mode with x-ray turned off?
In the sidebar check your View->Clip start and End settings.
Feb 25 2019
Feb 20 2019
This is happening to me today in the 3D viewport with build 9315cc443b1d, windows pro 64 bit, GTX 1050. I noticed that no matter how I resize the sidebar any region underneath it won't capture my pan and rotate view commands.