Despite what it may look like, I do still work on GLLara every now and then, and I’m currently preparing version 0.3. It’ll still be some months (maybe I’ll manage to make a blog post about all the changes in it soonish), but if you want to give it a try, here’s a new thing: You can now download automatically built test versions.

These test versions are available at the Github actions page of the GLLara repository. Click on the latest one, then scroll down to “Artifacts”, and you can download it there. Note that Github does not keep them around forever; after ninety days, each version is gone forever.

Warnings

These versions are created automatically whenever I change the code. They may not work at all, or work badly. They may damage your existing scene files by writing nonsense in them. There is literally no checks at all when you download such a nightly build; anything might happen. If that scares you, good.

As a result of all of this, there is no support for these at all. There is no support for GLLara at all anyway, but in particular for these versions, I won’t even try to help you.

As a special note, these are not signed or notarized (meaning Apple hasn’t checked them for malware), because I couldn’t be bothered to implement these things. As a result, Mac OS will try to keep you from running them with lots of scary warnings. If you really want to do this anyway, right-click on the app and select “Open”, then select “Open” in the dialog that pops up.

And finally, GLLara now requires Mac OS 12.3 (Monterey) or higher. I will bump this up to 13 (Ventura) fairly soon after that operating system is released.

Conclusion

I’ve implemented these nightly builds largely to see whether I could. They are useful for really curious people, but don’t rely on such a version. I will write more about the future of GLLara soonish, but in short: It’s still around, as a hobby for me, and I’ll update it whenever I feel like it.

For those of you who have a clone of the repository, please note that I’ve changed the name of the main development branch of GLLara from “master” to “main”. This is something that a lot of open source projects are doing in order to foster a more inclusive environment. While GLLara is not exactly a project with a huge active community that is going to notice, doing the right thing here is easy and doesn’t cost anything.

Note, however, that this means you have to update your local branch if you do have a cloned version of the repository lying somewhere around. You can find instructions on how to do that e.g. here. In general this is a simple operation that doesn’t take long and doesn’t actually change anything about your workflow.

Version 0.2.11 is out and ready for download.

This is another bug fix release, dealing with minor issues I’ve encountered. Both are about loading certain model files.

First of all, the “Shadeless” shader now works again. Previously, any meshes using it would turn out black because I simply forgot about it during some refactoring.

The second one is more interesting from a technical point of view, though for users the only important part is that some TGA files now show up properly.

The issue has to do with alpha blending and how that is stored in textures and in memory. If you have a transparent surface in computer graphics, the texture will contain an “opacity” value, called alpha in technical terms. This can range from 0 to 1 (or 0 to 100%). The formula for calculating the color if you put this over something else is simply:

new color = new alpha * new pixel + (1 - new alpha) * old pixel

for each R, G and B channels. Since you’re always going to compute the “new alpha * new pixel” part, you can actually do that multiplication once ahead of time, during texture loading, and use that as the color value. This is called premultiplication, and with it the formula is simply:

new color = new premultiplied pixel + (1 - new alpha) * old pixel

That is very common in 2D graphics, but far less so in 3D graphics, where you might have reasons for having the alpha channel mean something else, or you want to disable this calculation and just use the original “new pixel” value in some contexts. GLLara, for example, doesn’t use such premultiplied values. One reason, among all the others, is that it supports compressed DDS textures from the Windows world, and those are generally not premultiplied - and since the compression is handled directly by the graphics card (not even the driver), you can’t really premultiply it while loading without a lot of hassle.

For normal image formats, and some weird ones (GLLara supports PDF textures, because I thought that’d be fun), though, GLLara uses Apple’s ImageIO framework, which can load basically any format and give me the pixels. If you can see it with Preview, GLLara can load it, because it’s the same code underneath. That is much simpler than implementing loaders for PNG, BMP, JPEG, TGA and whatever else someone tried to use for some arcane reason. It’s very neat… except for one thing: It always premultiplies the pixel values, and it is impossible to tell it to stop. (I really should file a radar for that)

Thankfully, Apple also provides a different framework which provides functions to unpremultiply (their term) such images, and that’s what GLLara does. It works well, generally speaking, but it’s not ideal, because this premultiplication uses information. Both the image files, and the internal format that GLLara uses for all things, have eight bits per channel, which means the values for e.g. red can range from 0 to 255, where 0 means no red and 255 means all red. Suppose we premultiply this with an alpha value of 50%, meaning we divide everything by two. Then the value 64 becomes 32. But the value 65 also becomes 32, since we can’t have fractional numbers here and we’re always rounding down. If we unpremultiply it, 32 becomes 64, whether it was that before or not. We have no way of telling the difference. We loose color information.

This is more of a problem the lower the alpha value goes. If alpha is at 25%, then 64, 65, 66 and 67 all get turned to 16, and will later get turned back to 64. And then there is of course the worst case: If alpha is at 0%, then all values for red will get turned to 0, and stay there. That’s usually not a problem; most people won’t turn the alpha value to 0% and still expect something useful to happen.

Except some people, apparently, do. I encountered some models that have TGA textures where the alpha value is at 0% for seemingly no reason. That wouldn’t be a problem, because in that particular case, due to the shaders selected, the alpha value is simply ignored. But since we do that premultiply-unpremultiply dance, the resulting texture simply has all zeroes (meaning black) almost everywhere. The model shows up, but is almost all black.

I knew this could happen in theory, I just never expected it to be a problem in practice. The solution is as easy as it is clunky: I don’t use ImageIO for TGA files anymore. At least for uncompressed TGA files with an alpha channel, anyway; I’m happy with letting ImageIO handle the less usual cases.

This problem could, in theory, also appear with other formats, most notably PNG, which is also used for a lot of models. It could also happen that someone uses the weirder TGA formats for some reason. For now I’ve decided to ignore that, but if you find other models with that issue, please file a bug report. You’ll know you have this issue if the texture files don’t show up properly in Preview or Quick Look either.

Finally, I’ve upgraded the minimum supported OS to 10.13, since I don’t have a machine with anything older, and even those are historic already.

Version 0.2.10 is out and ready for download.

The only change in this release is that model files that contain bones that are set as their own parents no longer cause the app to crash; if the bone is marked as “unused”, it is simply ignored. Quite why anybody would create such files is a mystery to me, to be honest, but they do exist.

Doing this release took over a year because I couldn’t upload the file to Apple for notarisation, which was ultimately caused by an old folder existing that shouldn’t anymore. I’m mainly telling you this as a hint in case you ever get similar issues.

Version 0.2.9 is out and ready for download.

The main change here is a fix for a bug that would freeze the entire application under some circumstances. Some annoying debug code is also finally disabled now.

A more basic change is that the app is now notarised by Apple, which means they checked it against known malware and decided it’s clean. This is a requirement to install apps without trouble on future versions of macOS, but it’s also generally a good habit.

There is one tiny new feature after all: You can now open model files by double-clicking or dragging them on the app icon. GLLara will then open a new document with that model file as the only content. This should make it easier to review new models that you downloaded.