- User Since
- Oct 9 2017, 1:18 AM (71 w, 5 d)
Thu, Feb 14
The bug tracker isn't a support system. A better place to troubleshoot this will probably still be with the addon author - try contacting him again. For instance, your second picture clearly indicates an old set of files attempting to be installed -- beyond the "upgrade to 2.8x required" message, the error message itself references "scene_update_post" which is no longer in 2.8 and is no longer in the addon developers git repository at that location either. Double-check where you got your zip from.
Wed, Feb 6
The lack of AA, right now at least, is due to reverting to the old way of drawing lines since there were so many complaints about wireframe (like on devtalk).
Thu, Jan 31
No repro with today's git. Seems this was fixed shortly after your build. Try again with the Feb 1 build, which should be available later tonight when it drops.
Wed, Jan 30
The top row of tabs (called Workspaces) will automatically switch into the appropriate mode (pre configured for them). Modeling and UV Editing will auto switch to edit mode for example. Sculpting will auto switch to sculpt mode etc.
Jan 22 2019
Jan 16 2019
Yes, you would have to implement a do_version converter if you went with my proposal to handle older files automatically. Maybe percentage makes more sense I guess? I'll leave it to you folks to make final determination; just sniffed weird at first glance :)
Rando comment: For UI ranges controlling values which have no obvious unit or real life equivalent, should the convention be to have a slider between 0 and 1 in most cases? I ask because having something like Bloom intensity stop at 0.1 (even though the input allows higher numbers) would almost feel like a bug that someone would end up reporting. Why not scale accordingly and map ui 1.0 == 0.1 behind the scenes etc?
Jan 10 2019
I thought Brecht changed the default to 1.0 as part of c1d82e58492?
Jan 7 2019
Try running blender with the --factory-startup command line option and see if that solves the problem. If it does, you should remove the 2.80 directory under "%APPDATA%\Blender Foundation\Blender"
Jan 5 2019
This is a duplicate of T58748
I can repro with today's git. Here are the steps
Jan 3 2019
It looks like some changes to the default startup.blend in recent builds has changed the Auto Perspective default to OFF -- is that by design?
Seems to still be an issue for the buildbots:
Dec 26 2018
This is due to distance between your near/far clip plane distances. It ranges from 1 millionth of a meter to 1000 meters in your video -- even 2.79 did not handle this distance (other visual issues) and 2.80 is even more sensitive to it. A more appropriate range will be centered around the type of object you're modeling.
Dec 21 2018
Most likely a duplicate of T59608
Most likely a duplicate of T59608
Dec 15 2018
Confirmed with a build from today.
Dec 14 2018
Dec 8 2018
Just like in 2.79 this is controlled by the User Preferences -> Interface -> "Auto Perspective" option. The only change is that this is now enabled by Default in 2.8
Dec 7 2018
I believe this was fixed as part of 4c41f8e9ad3 and f40a88a4ba9
Dec 5 2018
This can be easily observed with the default cube.
Nov 27 2018
It still flipped to the top for me after an install with most recent git pull. Can anyone else still repro?
Nov 26 2018
Nov 7 2018
Might be a duplicate of T57620 (or at least heavily related?)
Oct 30 2018
I seem to be able to repro here -- indeed it looks related to snapping.
Oct 29 2018
Perhaps related/duplicate of T57485
Oct 20 2018
Confirmed here as well. Looks like it's the same cause as T57312
Oct 15 2018
Rebuilt from scratch after my previous comment to know for sure. But I can repro OP's issue when using a Debug build (compiled from source) which allows the assert to hit. I was also unsuccessful in creating a repro .blend; the act of saving and then re-loading the .blend seems to fix the issue. Perhaps the mesh loop/normal data is not being updated correctly after one of the operators but is being updated on .blend load?
Oct 10 2018
Some things I've noticed that probably fall into this category of fixups:
Oct 9 2018
That card may not be fully OpenGL 3.3 compliant according to its specs: https://www.geforce.com/hardware/desktop-gpus/geforce-gt-120/specifications
Sep 26 2018
Duplicate of T56011 probably
Sep 11 2018
Here's a gif showing the flicker in case a repro is hard to see -- happens on my 2 Win10 machines, 1 with nVidia Quadro and 1 with AMD fire pro
Sep 7 2018
The spec sheet for that graphics card only lists OpenGL 2.1 (which is below the minimum that 2.8 requires which is 3.3): https://www.geforce.com/hardware/desktop-gpus/geforce-9500-gt/specifications
Mar 6 2018
The option would be system wide, and called something like "Remember previous operator settings: True/False". You would Ctrl+B and confirm whatever you want. After that, each time you Ctrl+B you get the values that were confirmed prior. No additional button required, just Ctrl+b, Ctrl+b, Ctrl+b etc. etc. It's system wide since this would work with the Inset operator too, and probably others.
Oct 30 2017
Yup, same crash with using the, very slow, opengl32.dll
Oct 9 2017
I'm away from my laptop, however, I can reproduce the problem on my office desktop as well -- same crash using the vc14 builds. System is Win10, nVidia Quadro 600 this time.
Ok, I tried again, here's some more interesting information: