1. Why it doesn't use the 30% you have set in render properties might be the primary bug here. Manually shrinking your initial dimensions to 2100x5400 works
2. It's odd why blender eats up resources and typically needs to be manually killed in this instance... still needs investigated I suppose
3. It may never be able to render at that 18000 dimension (100%) in any case. OpenGL GL_MAX_TEXTURE_SIZE limits on my AMD FirePro W2100 card is 16384 and I'm not aware of any implementation that allows higher than that.

Can you try pulling down from git again. A large eevee refactor was reverted due to some other issues. See if you have better luck after.

Agree with the comment about color due to said issues. Try a different shape (diamond?) as you'll never find a good set of colors to differentiate.

It was never removed and is in nearly an identical spot - Did you mean something else? If not just follow these steps:

• N (to open the N-panel just as before)
• Click the View tab (similar to the old View sub panel)
• Click "Lock Camera to View"

Yeah, I seem to hit it when I scrub the smoothness value back and forth and that usually triggers the above after some time. I sometimes have to stop the scrub and play with the cut # too and then go back to smoothness scrubbing (and repeat) for it to hit.

I can repro, I think, but it took a long time of playing around to hit it -- So sadly I don't have a better simplified set of steps but I do have a stack:

This bug is probably the reverse of what's stated. The "Knobs" object has its "hide_render" visibility setting enabled -- use the Outliner filter to show the render visibility state.

Re-testing now since lots of time has passed. Good news is that the collection issue and the mesh separation issue seem fixed for some simple cases I've tried. Bad news is that the modifier issue still remains and can still be repro'd with the above blend and script.

Try running blender with the --factory-startup command line option. Your blender is new but your userpref.blend file is very, very old. There may be some incompatibility with it and --factory-startup will let us know.

Probably needs a style guide change as well. Just in these messages there's "Look Dev", "LookDev", and "look development"

Yes, it seems that "Dolly View" (Shift Ctrl Middle Mouse, and other forms of Dolly View) switches out from ortho. That's a fair bug I think.

Try using the build from today that came out <1h ago -- hash 16639c6f1a31

This is most likely a duplicate of either T59333 or T60733

Probably the same as T60733 as well as T59333. The model in question here has several faces with >170 vertices (massive n-gons).

It changed to bpy.ops.preferences.addon_enable a few days ago. Docs just haven't been updated for it yet.

This is not a bug right now, but rather the feature isn't coded yet and is a known limitation: https://wiki.blender.org/wiki/Reference/Release_Notes/2.80/EEVEE (see the Limitations section at the bottom)

CTRL+B in edit mode is Bevel -- and the build yesterday had a crashing issue with Bevel for a few hours. A new build was released a few hours later -- can you try redownloading and trying again now?

A new build with a fix for this issue was just built. Give it another download/try now.

A new build with a fix for this issue was just built. Give it another download/try now.

A new build with a fix for this issue was just built. Give it another download/try now.

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.

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).

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.

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.

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?

I thought Brecht changed the default to 1.0 as part of c1d82e58492?

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"

This is a duplicate of T58748

I can repro with today's git. Here are the steps

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:

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.

Most likely a duplicate of T59608

Most likely a duplicate of T59608

Confirmed with a build from today.

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

I believe this was fixed as part of 4c41f8e9ad3 and f40a88a4ba9

This can be easily observed with the default cube.

It still flipped to the top for me after an install with most recent git pull. Can anyone else still repro?

Might be a duplicate of T57620 (or at least heavily related?)

I seem to be able to repro here -- indeed it looks related to snapping.

Perhaps related/duplicate of T57485

Confirmed here as well. Looks like it's the same cause as T57312

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?

Some things I've noticed that probably fall into this category of fixups:

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

Duplicate of T56011 probably

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

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

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.

Yup, same crash with using the, very slow, opengl32.dll

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: