Bram Stout

GitHub - BramStoutProductions/MiEx: A modern Minecraft and Hytale Exporter A modern Minecraft and Hytale Exporter. Contribute to BramStoutProductions/MiEx development by creating an account on GitHub.

TIL there's now a modern Minecraft world exporter that has a bunch of optimization settings, built-in LOD support, and exports USD files. It's by @stoutnl.bsky.social . This thing is super awesome!

github.com/BramStoutPro...

Screenshot from Blender showcasing texture overlays, part of Connected Textures, that were exported out using MiEx with UltimaCraft as the resource pack

Screenshot from Blender showcasing texture overlays, part of Connected Textures, that were exported out using MiEx with UltimaCraft as the resource pack

Screenshot from Blender showcasing texture overlays, part of Connected Textures, that were exported out using MiEx with UltimaCraft as the resource pack

I improved support for Connected Textures in MiEx, my Minecraft world exporter.

Here are some screenshots using UltimaCraft as the resource pack and imported into Blender.

The latest release is available here: github.com/BramStoutPro...

Some operations require associated alpha in order to produce correct results and other operations require unassociated alpha in order to produce correct results.

A rule of thumb that I typically go by is; If it's light, use associated alpha. If it's an object's colour, use unassociated alpha

I don't really do any game stuff, instead I do CG animation and VFX. And, when doing compositing for it, it is very normal to constantly switch between associated and unassociated alpha based on what operations we need to do. It's one of the first things you'd learn when learning compositing.

And in that context, unassociated alpha does become logically inconsistent and inferior. But only because they compare the two as if they represent colour in similar ways, which they don't.

Associated alpha could be painted in a similar way, by placing it in a context that's natively unassociated.

They just represent colour in fundamentally different ways.

Most of the times when I read texts where people compare associated and unassociated alpha, they look at them as if they represent colour in similar ways, often from the perspective of blending which is about light, thus associated alpha.

I disagree. Opacity is very much a real thing and rooted in physics. For a given area, opacity is the percentage of that area covered by the "object". A better term would probably be "presence".

Associated and unassociated alpha are both equally valid and equally logically consistent.

because associated alpha can represent additive blending naturally. But that is only true if the colour stays in associated alpha mode during all operations. The moment that it gets converted to unassociated alpha (either explicitly or implicitly by an operation), then that benefit goes away

Most operations are "natively" a specific alpha mode. They can easily be rewritten for another alpha mode by having it implicitly convert the colours to their native alpha mode on input and back to the original alpha mode on output

Associated alpha does seem like an upgrade over unassociated alpha,

diffuse colour maps that are unassociated alpha. But the issue here isn't with unassociated alpha, it's with providing an operation colours in a different alpha mode than that operation was designed for. Blurring and mipmap generation can easily be modified to properly support unassociated alpha.

PBR surface materials deal with the colour of an object, so unassociated alpha would make more sense. But particle effect materials often deal with light, so associated alpha would make more sense.

Blurring and mipmap generation, by default, assume associated alpha, leading to issues with...

so as long as you keep track of the alpha modes of colours and use the correct version of operations for those alpha modes, then it *should* all be fine no matter what alpha mode you go with.

Both modes do have their advantages and disadvantages outside of how they represent colour.

Give an operation, that assumes associated alpha colours, unassociated alpha colours and it'll produce incorrect results. Same the other way around.

Colours can be converted between alpha modes and operations can be rewritten for different alpha modes,

Unassociated alpha looks at RGB as the colour of an object and A as the opacity of that object.

So, whether a colour should be associated or unassociated alpha depends on what that colour is meant to represent.

The important part is that colours are in the right mode for the specific operation.

The way that I look at it is that associated (premultiplied) alpha and unassociated (straight) alpha are both equally valid, but they both represent colour in fundamentally different ways.

Associated alpha looks at RGB as emitted light and A as occlusion of light behind it.

Tried doing it with ParcelJS, but couldn't get it to work how I wanted it to, so rather than trying it again with other build systems, I just wrote my own basic one

For background, I have a project folder with multiple "modules". Each module contains TypeScript and other files. I just want a build system to build each module as their own thing and then package them together into one folder to get served by a local HTTP server.

Screenshot of the build script run by the custom build system. Code shown: import build.build as build build.Package( name="...", version="0.1.0", dependencies=[ build.Dependency( packageName="..." ) ] ) build.addFolder("...") if __name__ == "__main__": build.buildAllPackages()

Spent the first half of my day setting up a project with an existing build system.

Spent the second half of my day writing my own build system in Python...

Rewriting the UVs so that it's a value for each face-vertex and the index buffer is just 0,1,2,3,4,5,... fixes it. That does cause it to take up more memory, but at least it's opening up those scenes in a reasonable time.

Could something like that be happening for you?

Turned out that when it's loading in meshes, if the UVs are indexed and so UV points are merged aggresively, causing the UV topoly to not match actual topoly, Maya decides it has to check the UVs with some algorithm that takes a very long time to run

I've recently come across an issue with Maya where geo generated by an external program and imported in via USD, would cause Maya to take minutes to half an hour to open up any scene file with that geo in there. While it should've taken only a few seconds

A screenshot of Blender with a Minecraft world exported from MiEx that shows off the ambient occlusion calculated by MiEx, exported out as a vertex color set, and applied to the diffuse color in the material

Also, did you know that MiEx can calculate MC-style ambient occlusion and export it out as an extra vertex colour set? This is EEVEE with just ambient world lighting, no shadows or GI

#minecraft

Release MiEx v2.0.0.experimental-6 · BramStoutProductions/MiEx This is an experimental release of MiEx v2.0.0. This release is not production ready and provided for people who want to test it out. New features aren't yet documented and breaking bugs may exist....

Just released a new experimental version of MiEx 2.0.0 that fixes a bunch of bugs. I've also been rewriting some of the mesh handling to allow "shader" support in MiEx where you can calculate custom vertex colours

github.com/BramStoutPro...
#minecraft

screenshot of blender topology

*slaps npole*

this baby can terminate so many edge loops

Raw assembled pizza on a pizza peel, ready to he put into the oven. Home-made pizza dough, using a preferment and sourdough-powder. Slow-fermented. Topped with crushed tomatoes, basil, olive oil, parmigiano reggiano, mozzarella, ham, and bacon

Home-made pizza just put into my wood-fired stone pizza oven

Pizza in pizza oven, almost ready to come out

Finished pizza

Pizza?

If the number of colors are limited (or it's black and white) then a GIF should work nicely. As long as all colors can fit inside of a 256 element color palette, it should compress losslessly. A zoomed in area scaled up via nearest neighbor helps as well. A second GIF of just specular component also

Also, here's my page of cat pictures, because every hobby photographer needs one

bramstout.nl/en/photograp...

Photograph of Loch Doon in Scotland

Photograph of a hiking trail in Galloway Park, Scotland, in the middle of nature, but with a sign on a tree that says that there are CCTV cameras installed

Picture of Scottish landscape in Galloway Park, near Fort Carrick

Close up of some plants on a stone wall in Mugdock Castle, Scotland

I recently went to Scotland for a week and brought my camera with me

I've put the rest of the pictures on my website:
bramstout.nl/en/photograp...

#photography #scotland

Previously, people had to manually set things up to load in the Element pipeline and since it ran inside of their default Maya installation, it limited what we could do with the pipeline.

Now people just have to create a shortcut to the launcher and run it

This way, I can fully customise and control Maya (including custom plugins), without it affecting freelancers' default Maya installation.

If they launch Maya normally, they get Maya without anything Element. Launch via this launcher and they get Maya with the Element pipeline