1.21.8 port

[imreallybadatnames]

meow

[BraveCaperCat2]

build the 1.21.8 version for us who don't know how to build mods
PLEASE!
@imreallybadatnames

[Noaaan]

That isn't really a good idea. As an initial port it still likely needs changes.
Isometric Renders is also built on the Worldmesher library, which needs to be finished and published first before this is mergeable

[BraveCaperCat2]

That isn't really a good idea. As an initial port it still likely needs changes.

How is anyone going to find out what changes the port needs if you can't test it?

Isometric Renders is also built on the Worldmesher library, which needs to be finished and published first before this is mergeable

Just use the port for that as well.

[imreallybadatnames]

That isn't really a good idea. As an initial port it still likely needs changes. Isometric Renders is also built on the Worldmesher library, which needs to be finished and published first before this is mergeable

To the extent of my testing, which is testing a bunch of various things for all the /isorender commands and batch render keybind, everything is fully functional. It is an initial port specifically because it needs a code review from an authoritative developer, since I have far less knowledge about how this port should be architected than e.g. glisco or Noaaan.
There will be no further development of this PR besides minor nits and fixes until a code review is submitted. I am currently waiting patiently for one.
The same applies to the Worldmesher port, which arguably needs a code review much more because it has some unported functionality for which I have no concept as a replacement.

[imreallybadatnames]

This is the main reason why this PR is NOT a draft. Because, functionally, it is more or less done.

[BraveCaperCat2]

This is the main reason why this PR is NOT a draft. Because, functionally, it is more or less done.

You know, I was told by a wiki admin (for a minecraft-related wiki) to build the 1.21.8 port of this mod, so that we can update our STFR stabilizer images, among other things. Then I realised that I hadn't built a mod in a long time - and never for 1.21.x or fabric.

So, can you please build the mod for us?

That isn't really a good idea. As an initial port it still likely needs changes. Isometric Renders is also built on the Worldmesher library, which needs to be finished and published first before this is mergeable

To the extent of my testing, which is testing a bunch of various things for all the /isorender commands and batch render keybind, everything is fully functional. It is an initial port specifically because it needs a code review from an authoritative developer, since I have far less knowledge about how this port should be architected than e.g. glisco or Noaaan. There will be no further development of this PR besides minor nits and fixes until a code review is submitted. I am currently waiting patiently for one. The same applies to the Worldmesher port, which arguably needs a code review much more because it has some unported functionality for which I have no concept as a replacement.

Ok.

[imreallybadatnames]

Building this should be as simple as downloading my fork of the repo and running gradlew build in the folder.
If you are sure you are truly unable to build the mod: May I get a contact to send it directly? I'd rather not do it over this GitHub PR.

[BraveCaperCat2]

I'm having some issues with the actual renders. They're all completely black.
This is one of them:

@imreallybadatnames

[imreallybadatnames]

Note: after extensive communication, I have concluded this to be a mystery issue. As exporting works perfectly fine on various MC setups on my machine, broader investigation is needed.

[BraveCaperCat2]

Huh

[OpenBagTwo]

I'm also getting completely black renders for my build off of this branch. For diagnostic purposes: I'm using an AMD 9070XT on Linux (have tried both a Wayland and an X11 environment)

[BraveCaperCat2]

I'm also getting completely black renders for my build off of this branch. For diagnostic purposes: I'm using an AMD 9070XT on Linux (have tried both a Wayland and an X11 environment)

I'm not sure what that "Wayland/X11" thing is, but I have an intel CPU, Nvidia GPU and am using windows so it's probably not brand specific or anything.

[ByteZ1337]

I'm also getting blank renders. I have the mod set up in Intellij if you need any debug info. I sadly don't have any experience with opengl/blaze3d so that's kinda all I can offer to help.

[imreallybadatnames]

Exporting simply works on my end, and I couldn't figure out any potential causes, so I just don't know what to tell you.

[ByteZ1337]

I managed to fix it by adding

RenderSystem.getDevice().createCommandEncoder().clearDepthTexture(framebuffer.getDepthAttachment(), 1.0f);

after the framebuffer init in drawIntoTexture

[OpenBagTwo]

@ByteZ1337 your fix works when rendering one at a time, but not for batch renders, which results in messes like:

or

[ByteZ1337]

@OpenBagTwo That works fine for me. I'm guessing these are gpu specific issues. Did you try just clearing the color texture like I did with the depth texture at the same place? Something like

final var framebuffer = new SimpleFramebuffer("Isometric Renders RenderableDispatcher.drawIntoTexture Framebuffer", size, size, true);
final var commandEncoder = RenderSystem.getDevice().createCommandEncoder();
commandEncoder.clearDepthTexture(framebuffer.getDepthAttachment(), 1.0f);
commandEncoder.clearColorTexture(framebuffer.getColorAttachment(), 0x000000);

Edit: I just noticed there's also a clearColorAndDepthTextures method so no need for 2 calls.

[imreallybadatnames]

I managed to fix it by adding

RenderSystem.getDevice().createCommandEncoder().clearDepthTexture(framebuffer.getDepthAttachment(), 1.0f);

after the framebuffer init in drawIntoTexture

That's interesting, considering that the created depth texture is supposed to be already cleared, which is the case on my machine. I would've never guessed that, especially given how I was not provided with conclusive information on this issue.

[OpenBagTwo]

@ByteZ1337 That did it! Thanks so much!

[imreallybadatnames]

I'm guessing that, on other machines, the created textures are not guaranteed to be blank and are instead filled with undefined data. Though fixing this myself is probably a fool's errand considering it just works on my end, and I don't have any other developers knowledgeable in OpenGL helping currently, especially those who can reproduce that issue on their own machines.

[imreallybadatnames]

Though, I guess the currently proposed fix would suffice. I'll add it to this PR soon.

[ByteZ1337]

considering that the created depth texture is supposed to be already cleared

I'd think so as well but the current 1.21.4 implementation does the same thing

isometric-renders/src/main/java/com/glisco/isometricrenders/render/RenderableDispatcher.java

Lines 104 to 105 in f5f5941

	framebuffer.setClearColor(0, 0, 0, 0);
	framebuffer.clear();

[imreallybadatnames]

This elusive issue has been driving me crazy. Genuinely, thank you so much @ByteZ1337