> all the replies
Thanks. That answers my main suspicion, that it is actually broken and
not something I missed.
Fixing OpenJPEG is well outside the scope of my project, but the KDU
patch will at least allow me to see if the LLTextureCtrls are functional.
__
You might want to use my modified version of OpenJPEG v1.4.0.635 (that is
included in the Cool VL Viewer source and built in-tree with the viewer)
instead of any later versions that got utterly broken for SL usage...
My version includes the needed security fixes from v1.5+ as well as some
crash bu
Try with an openjpeg version build from this repository:
https://bitbucket.org/NickyD/p64_3p-openjpeg
https://bitbucket.org/NickyD/p64_3p-openjpeg/commits/9c2e80ac43f67040ee8870a92ac9f05ee00c2020
Is probably fixing your issue
On Mon, Feb 11, 2019 at 11:15 AM Kadah wrote:
> I'm working on a thi
Is this related to
https://jira.phoenixviewer.com/browse/FIRE-22342
The problem there was with 5-channel images. SL has a few of those;
in some old format, eyelash length was encoded as an extra JPEG
color channel. Those resulted in crashes where the fast cache
decoder didn't have a case for a
Graham worked on a fix for this which is an improvement but still has some
loading issues:
https://bitbucket.org/lindenlab/viewer-tco
You'll need to build it with -DUSE_OPENJPEG:BOOL=TRUE to test that path
anyway, the TC-built version assumes KDU.
On Mon, Feb 11, 2019, 5:15 AM Kadah I'm workin
I'm working on a thing (some of you know what) and I've run in to a
rather annoying issue that's sunk most of the day as it was starting to
make testing difficult.
None of my ReleaseOS viewer-release builds are able to load textures.
I've found that it's fine if I patch in KDU. While that is a
