| Age | Commit message (Collapse) | Author |
|---|
|
|
|
A workflow dispatch has been added in an attempt to not only manually trigger this workflow but to also test this from a different branch without having to first merge to develop.
Also steps have been added to allow this workflow to run on mac runners when added. Mac runner info currently commented out.
|
|
|
|
|
|
|
|
|
|
|
|
For now it's random, needs more consistent coverage
|
|
I don't expect it to fix the problem. Just making things more explicit
in places of most frequent crashes.
|
|
|
|
|
|
* updateImageDecodePriority - Avoid Long Face Loop
To avoid running a long loop on thousands of faces, some textures were being set to a BOOST level to avoid the updateImageDecodePriority function entirely but this was causing many of them to never be deleted over the course of a user's travels.
Instead of relying on BOOST, this commit changes the logic of the texture channel loop such that the face loop will only run if the number of faces is below the threshold.
To do this, we move the face_count incrementing outside of the face loop into the channel loop and increment it using the getNumFaces function instead.
We then check the face_count against the maximum number of faces we want to check and if it exceeds the number we set the number of faces for the face loop to check down to zero.
This avoids branch prediction misses and the long face loop issue.
Later, if the face_count is above the threshold, we assign the virtual size to the maximum.
I personally believe the max_faces_to_check should be lower than 1024, but I left that value in for continuity. I use 64 faces as my max on my compiled version of the viewer without any noticeable issues for memory use.
* updateImageDecodePriority - Face Loop Increment Swap
Looks like compilers like knowing the incrementing in the for loop information for optimizations and parallelization.
Sorry for the tiny commit.
* updateImageDecodePriority - Suggested Cleanup
Remove trailing white-space.
Co-authored-by: Andrey Lihatskiy <alihatskiy@productengine.com>
|
|
|
|
KDU is uploading 2k files with 7 and 8 layers which is shifting the location of discard 1 and 2.
To accommodate, this commit adds a max_layer check based on max_dimension and the MAX_BLOCK_SIZE to allow the extra layers for 2k.
Also shifted the starting size to the MIN_LAYER_SIZE instead of MAX_BLOCK_SIZE's area to allow smaller files to be decoded at discard 5 completely.
Finally able to walk around Fantasy Faire without any gray blobs!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Doesn't make much sense, if param is in use it is supposed to be set,
but bugsplat says sculpt_params is null
|
|
|
|
|
|
into 2025.04
|
|
|
|
|
|
|
|
|
|
LLAgent::leftButtonGrabbed() must report TRUE only when an attachment has
**actually grabbed** the left mouse button (accept = TRUE, pass_on = FALSE), like every other ...Grabbed() function below it
|
|
|
|
[#3972] Implemented Texture Panel Repeats per meter improvements and PBR feature
|
|
|
|
|
|
|
|
|
|
texture_stride with '-1' was added in DRTVWR-592 along with
getMetersPerGrid multiplication.
|
|
|
|
|
|
Thanks to Jenni Windrider for the bug report and solution.
On startup, the log gets flooded with:
[0426/150813.911339:ERROR:viz_main_impl.cc(196)] Exiting GPU process due to errors during initialization
[0426/150813.918965:ERROR:egl_util.cc(44)] Failed to load GLES library: /usr/lib/x86_64-linux-gnu/libGLESv2.so: /usr/lib/x86_64-linux-gnu/libGLESv2.so: cannot open shared object file: No such file or directory
doing a ls shows there's indeed no libGLESv2.so:
ll /usr/lib/x86_64-linux-gnu/libGLESv2*
- rw-r--r-- root root 110.39K 18.Mar'25 15:10 libGLESv2_nvidia.so.2
- rw-r--r-- root root 110.39K 18.Mar'25 15:10 libGLESv2_nvidia.so.570.133.07
- rw-r--r-- root root 70.30K 08.Apr'24 10:04 libGLESv2.so.2
- rw-r--r-- root root 70.30K 08.Apr'24 10:04 libGLESv2.so.2.1.0
The package that provides this isn't installed by default:
apt-file search libGLESv2.so
libgles-dev: /usr/lib/x86_64-linux-gnu/libGLESv2.so
So installing libgles-dev fixes that.
|
|
Shorter.
|
|
Simpler.
|
|
The two conditions might not be exclusive for some platforms
(in another branch).
|
|
Same as reason as previous commit, plus the moving of OpenSSL libs
up 1 directory is still needed.
|
|
so there's no need to have the long list of installed files.
openssldir is set to isolate the files so they won't pollute
the packages directory (which could lead to confusion).
|
|
On macOS, it's static library too, now, hence the stream editing is
done out of any platform scope (which it's still needed because
BUILD_SHARED_LIBS is ignored), and the (so)versions don't need to be
set any more.
CMAKE_INSTALL_LIBDIR is also ignored, hence the libcollada14dom.a
moving.
|
|
Same as previous commits, plus reminding CMAKE_BUILD_WITH_INSTALL_RPATH
needs to be set ON otherwise there would be configure error on FreeBSD,
plus the codec executables aren't needed (they would encounter linking
errors on FreeBSD, because /usr/local/lib isn't automatically added as
a header search directory).
By default OpenJPEG installation header directory is "openjpeg-2.5",
hence the renaming.
The 3 non-API headers are copied, still.
|
|
and use ARCH_PREBUILT_DIRS_RELEASE for shortening paths.
|
|
CMAKE_OSX_ARCHITECTURES & CMAKE_OSX_DEPLOYMENT_TARGET won't affect non-macOS.
Settings such as those 2, and CMAKE_BUILD_TYPE, aren't inherited,
so the significant ones should be set explicitly.
Meshoptimizer default installation header directory is without the
encapsulating "meshoptimizer" directory.
|
|
|
|
Notification about inventory change from fetchInventoryFromCapCoro
Looks like floater was closed a moment before receiving inventoryChanged
|
