You may have gotten it 6 months ago, but that gpu is it's over 13 years old at this point.

locations for the profiles folders on all supported operating systems can be found here

• fix casing in comment.

All lower case filenames for assembly names
Option to disable bundling of the crt

• Merge remote-tracking branch 'origin/master' into tmp_crt_bundle2

cleaned up WITH_GL_PROFILE_ES20 however a bunch of the EGL stuff seems somewhat dependent on WITH_GLEW_ES so i left that in place for now.

• Merge remote-tracking branch 'origin/master' into tmp_angle_cleanup
• remove WITH_GL_PROFILE_ES20

Not sure how much i can add to this review honestly, I can validate that it builds on windows, seems to work and it's not calling any windows API's in a bad way, so based on that i'll happily accept the patch. However given it's an UI change the UI team has to have the final say here.

WM_MOUSEWHEEL is what we currently use

i'll have to revisit this one once the manifest stuff is done, all lowercase will be fine though.

Looking under properties of the 2.81 installer there is a Digital Signatures tab which shows a signature from "Stichting Blender Foundation" that the 2.80 installer doesn't have.

Maybe this issue should be reopened?

the documentaiton for glGenTextures say you need to feed it integers , feeding it a short buffer is asking for trouble

updated windows libs are available in svn ( rBL62323 )

will do!

Preliminary Windows libs are available.

You're most likely missing the svn libs, they changed a while ago so be sure to grab a fresh copy of those.

as mentioned on the page you used to file this report

wrong link, the correct link is https://download.blender.org/release/Blender2.81/release281.md5sum (website is missing the sum bit at the end)

Samples != tiles , that being said, this is still not a place for user support.

While we don't ship it anymore, the people at https://upbge.org/ are keeping it alive in a fork

set(WITH_X11_XINPUT          ON  CACHE BOOL "" FORCE)
set(WITH_X11_XF86VMODE       ON  CACHE BOOL "" FORCE)
set(WITH_GHOST_XDND          ON  CACHE BOOL "" FORCE)

still show up in the full profile so these can probably be moved into a platform specific guard as well

pretty sure the combinations of gpu's is not the issue, rtx support needs driver 435 or higher

The optix code path only supports hardware RTX capable cards, the GV100 is not one of them, however the cuda codepath should work just fine for this card.

In D6287#145956, @Sybren A. Stüvel (sybren) wrote:

USD: Build improvements

• Removed external_python from USD dependencies, as we don't use USD's Python interface.

relevant bits are in D6287

you'd have to sort that out with the ubuntu people, we have no control over their packages.

We do not maintain the fedora rpm you'd have to take this up with the fedora people.

• update with feedback

Update with feedback

Thanks for the report, but the issue reported here is a request for modified/improved behavior and not a bug in current behavior. Closing as this bug tracker is only for bugs and errors.

thanks for the report but, it is already fixed in rB67fa8d2307a6b41c5bbbbfc79f96af6135c360fe

Static version gave issues: they depend on getting notifications of new/terminated threads though dllmain, which will work for a shared lib, but won't work so great if you statically link that lib into your exe.

I have done nothing to fix it neither can i, no idea why it is doing this and i'm on a single monitor system.

• Fix: unmodified tbb header doesn't work for C code.

Package Compatibility
Windows Python MSVC compatibility.
In the past, Blender's Python was built with a different MSVC version, making binary modules incompatible.
Is this still an issue?

• update error message on how to resolve missing libs.

Couple of things that stick out:

1. there's a bunch of functions with wchar in their name that take a char_32t type, a better name will have to be picked for those.
2. for memory allocations sizeof(wchar_t) is still used here and there in the char32_t codepaths which with allocate a too small buffer as a result.

wchar_t is 32 bit on gcc, so yeah you wouldn't see the issue there.

Not my area either but what you call unicode_array is essentially UTF32, so naming isn't great and leaves a rather large amount of ambiguity what type these variables actually are.

Yeahhh this is a mess....

Correct: blender cmakelists.txt should have an option to build with or without openxr if people want, however the deps builder only should have options for things that have not yet landed in master (such as embree)

Once these patches land in master, XR will no longer be an optional dep, I'd perhaps wrap it with an if (WIN32) to single out platforms that support it, but it shouldn't require a WITH_XR option.

sizeof(wchar_t) is implementation dependent and cannot be changed for some implementations, C11 added char16_t and char32_t types for if you have size requirements.

2017 since i'd like to support the last 2 versions of msvc (this implicitly means 2015 will be dropped), the backward compatibility story is pretty great (ie libs made with 2017 will link flawlessly on 2019) in recent VS versions however i'm unsure if the other direction is equally great, and i don't want to take the risk there.