- User Since
- Jun 24 2014, 10:28 AM (371 w, 11 h)
Jun 2 2021
Sep 11 2020
Sep 10 2020
Okay maybe just be a little more specific that you just want the .blend file to avoid the download.
Sep 9 2020
The .blend file is already included in the .ZIP file attached to this report. "Link to existing report" ... not sure what you mean, you're already here. But here is the link....
Sep 4 2020
This video only consists of glossy letters on a black background. Using ANY other format for video output, played at 3840 x 2160, creates horrific white splotches all over the background. AVI Raw is the only format that will generate an output file that displays cleanly at full screen resolution, 3840 x 2160.
Apr 10 2020
Ngons can be okay if you don't feed them after midnight and never, EVER let them get wet.
Apr 9 2020
I will divide and conquer so that no face has more than 4 vertices. Clearly this is Trump's fault.
Apr 4 2020
Oct 14 2019
Smaller worked. This was an obvious pointer overflow within Cuda. The texture size crossed the limit of positive values for a 31-bit integer (bits 0-30 being the value; bit 31 being the sign bit). With bit 31 set, pointers were being treated as negative numbers. Why are they using 32-bit ANYTHING with today's cards? Oh well. Now it's known that limit exists. This is why I hate high level languages.
Sep 25 2019
Jan 16 2019
I feel terrible about making stupid mistakes like this ... you people are plenty busy and you don't need somebody reporting their own mistakes as bugs, wasting your time. You are not here to correct my idiot mistakes. I apologize profusely. From this point forward, before I report something as a bug I will post in one of the Blender discussion forums to be sure it isn't my own mistake.
Jan 15 2019
Jan 5 2019
Dec 18 2018
Dec 11 2018
Dec 10 2018
Floating point values by nature are imprecise. Blender has to do so much manipulation of values, especially where zoom is concerned, that the tiny amount that values are off as you get closer to bit 0 in a floating point value is going to amplify and amplify. You could move to double precision floats if you're not already using them but that's a major rework. At any rate little can be done about it. IEEE specifications for floating point format inherently allow for the kind of drift being seen. If I knew that was the issue, I would not have submitted this as a bug.
Dec 7 2018
I'll try those changes. But that wasn't the primary issue - the primary issue was object / vertex / line selection.
I am adding something I absolutely should not be adding to a bug report: this entire version 2.8 is AWESOME, it is unbelievable, and the EEVEE engine is a miracle. Why would anybody use anything else????? Okay ... my .blend file was added to the original bug report. I drag/dropped in the wrong place, sorry. Use wireframe mode. There is a lot hidden so use alt+H to unhide it but you shouldn't have to.
The problem is omnipresent and requires no research to reproduce. I could dump a whole bunch of time into uploading a .BLEND file that is too large to upload, and mess around with screen shots, but it won't help. The problem occurs on all files, all the time. Click anyplace that is "busy" - not someplace with a single vertex off by itself. This is why I didn't get more specific: the problem is so obvious and so widespread, just get on a 3840 x 2160 monitor, set your user preferences to display scale 1.25, load any Blender file in the universe, and start clicking where a lot of vertices are relatively close together.
Oct 2 2017
Sep 28 2016
Dec 10 2015
KILL THIS - NOT A BUG. Object was inadvertently caught up in a parent relationship (the camera). Problem solved when this was cleared. Pilot error. Stupid user. Not a bug. Many apologies!!!
Jun 24 2014
If I get a real video card like I *NEED TO* I won't have this problem anymore LOL! Thank you!!