Megapahit's fork of the Second Life viewer. https://megapahit.org/viewer.git/atom?h=26.3 2026-06-22T03:25:21Z 2026-06-22T03:25:21Z Erik Kundiman erik@megapahit.org 2026-06-22T00:34:39Z urn:sha1:ee87dd9f21e0dcd5a2f3a78586e5ae5d2ba592d5 Still uses prebuilt GLU, could be improved by using the glu shared module. Still uses prebuilt OpenAL, could be improved by separating the ALUT dependency (which isn't available on the runtime) from it, so we could use runtime's OpenAL. Still uses prebuilt LibXML2, could be improved by separating the Minizip & ColladaDOM from it (which aren't available on the runtime) from it, so we could use runtime's LibXML2 but have ColladaDOM built against it (and a still non-runtime Minizip). Still uses FLTK 1.3, when I tried using 1.4, it still had linking errors (might need to just add Cairo libraries to the target_link_libraries). VLC plugins are installed in vlc/plugins path relative to the vlc & vlccore libraries, the way they are in the distro I got the binaries from (Debian), cause I think it's the libraries that are compiled with that path. Still uses prebuilt dependencies in general, could be improved by having them as modules to be built. _FORTIFY_SOURCE needs to be skipped to avoid redefinition cause Flatpak build system already defines it. The conditionals for deciding installation paths need to be reorganised to accomodate installation that doesn't require an encapsulating namespace (because the installed files are already encapsulated in the app sandbox). The library directory naming scheme used here is lib64. The libGLESv2.so & libvulkan.so.1 installed are still copies, not links yet, because I'm still not familiar yet with the runtime hierarchies (they might reside just in /usr/lib/x86_64-linux-gnu). 2026-05-29T01:37:54Z Erik Kundiman erik@megapahit.org 2026-05-29T01:37:54Z urn:sha1:0e2711f8f76b372f5766734c86f8ddc9e07d3ab3 2026-05-26T10:38:42Z Erik Kundiman erik@megapahit.org 2026-05-26T10:16:38Z urn:sha1:4989aa911c5bfa39ab056e1481cde4190db3ae8e This includes files of WebRTC, Discord, VLC & CEF and their media plugins & resources. This is so they won't clash just in case some other packages install files with the same names in system library directories. Furthermore, this seems to prevent Dullahan/CEF from breaking in general. The path to this encapsulating folder needs to be added as a runtime path to especially dullahan_host & libmedia_plugin_cef.so so they can find libcef.so etc, also for the viewer to find libllwebrtc.so & libdiscord_partner_sdk.so. And that's why `patchelf` needs to be made sure it's installed. 2025-10-01T08:56:56Z Erik Kundiman erik@megapahit.org 2025-09-29T08:29:19Z urn:sha1:a954d290674db08ecaf3c1e6484a0cb6647b88b5 2025-09-12T00:54:32Z Rye rye@alchemyviewer.org 2025-09-12T00:54:32Z urn:sha1:452c8e0ea40da1de684c80b84ffa9ec712f72ed2 * Remove GLM sse flag from cmake that was moved to llpreprocessor.h * Further reduce performance loss of HDR and Sharpening on bandwith-constrained gpu by combining gamma correction into tonemap/sharpening shader passes * Update SSE2NEON to 1.8.0 to fix random render nans * Fix occasional startup crash from LLCachedControl being declared in global scope 2025-08-22T07:32:02Z Rye rye@alchemyviewer.org 2025-08-22T07:32:02Z urn:sha1:a46d4f0f6923080d7c6e7d5267206e8c8d7a6ff9 2025-06-22T22:36:22Z Erik Kundiman erik@megapahit.org 2025-06-22T22:24:33Z urn:sha1:f5de250c3e74ecc8eb658d0b070c0884616f041d This reverts commit 75012c4f0c0b852c8bfa0b5632bf82c82f240754. I realised I was in the wrong direction after I avoided the offending lines by setting GLM_FORCE_XYZW_ONLY, and then by setting GLM_FORCE_CXX_UNKNOWN, to end up with the same 16 __m128-related "too many initializers" errors, which I believe were just obscured by the 160 syntax errors, which are to be fixed in the next commit. I had already mentioned SSE2NEON being responsible for translating __m128, but I had forgotten that it was a different package from GLM, obviously, that __m128 was never GLM_FORCE_NEON's responsibility. 2025-06-19T09:48:03Z Erik Kundiman erik@megapahit.org 2025-06-19T09:48:03Z urn:sha1:75012c4f0c0b852c8bfa0b5632bf82c82f240754 though there are still so many compile errors, but it should be in the right direction, cause firstly we can't let it use GLM_FORCE_SSE2 otherwise it would include x/emmintrin headers, and secondly, if none of the GLM_FORCEs is used then the errors are much fewer but related to __m128 which should be translatable by SSE2NEON (that's why I believe GLM_FORCE_NEON should be ON for Windows arm64 too). 2025-04-27T11:06:11Z Erik Kundiman erik@megapahit.org 2025-04-27T11:06:11Z urn:sha1:690545276f452055742a34e61d6e2a6222baecb1 2025-04-19T12:21:46Z Erik Kundiman erik@megapahit.org 2025-04-19T12:21:46Z urn:sha1:ad9c801edb13568657c0964ebfb74257da6d9e00 Media plugins enabling not yet. OpenXR is disabled for now (it hasn't been used anyway). perl-FindBin is needed to be able to build OpenSSL on Fedora aarch64. Setting the C standard to 90 when building cURL is needed, otherwise it would fail at configure time with a misleading error of not finding link/run time requirements for dependencies (such as nghttp2 and zlib), at least on Fedora (and macOS too back then, I remember). GCC treated SSE2NEON warnings as errors on so many files, so -Wno-cpp is added globally. The same Linux CPU frequency calculation needs to be out of the x86 scope, otherwise the viewer would complain about not meeting the requirements at launch time.