I'm glad you found a workaround! The canvas size shouldn't matter; it would just take longer to calculate.
However, you mentioned using tilemaps. In case you're using Aseprite's built-in Tilemap layers, that seems to be the cause of the crash. I have had this on my to-do list for my other plugin, but I haven't gotten around to looking into it yet.
I will put it as a disclaimer into the description :)
I just tested version 1.2.1 on Aseprite 1.3.14.4 on macOS Sequoia 15.6 and didn't run into any issues. So the public beta may be the reason; however, I can't update to the public beta at this point because it's a work laptop.
I tried various combinations of settings for the extension. Could you maybe share yours?
Also, have you tried it with a different sprite? Try using a super basic 32x32 canvas with one diffuse, one normal, and one output layer.
Further, are you using any additional plugins? If so, could you try disabling them and then checking if it still causes a crash? Maybe by enabling them step by step, it could lead us to the root of the issue.
Hey! Yes, it should work with isometric pixel art, assuming the normal map handles the directions of the texture properly. I've written a more detailed reply to your post on my other extension regarding that :) https://mooosik.itch.io/normal-toolkit/comment
I forgot to mention that, generally, isometric textures often have lighting "baked" in (your tree is already in shadow on the right). This will inevitably make the right appear much darker than the left (because it uses darker colors by default.
You could try making the texture flat/forward-facing and introducing the isometric direction solely through the normal map. However, this is entirely up to you as the artist :)
Currently, the extension does not support isometric textures as it assumes the "default" direction is forward and does not know the intended direction in which your parts of your texture are facing.
If you are trying to work with this in a game engine, you could paint a very rough secondary normal texture serving as a directional vector for your texture. You could then calculate the correct direction using a TBN matrix (https://learnopengl.com/Advanced-Lighting/Normal-Mapping). I will keep this in mind as a feature for the future.
However, if you're using this simply for artwork, I would recommend drawing the texture by hand for now, using left/right-facing values for the corresponding parts of the texture. That might be easier :)
In my opinion, the grayscale technique works best when you're using just 2-3 shades of gray, as not all detail has to come from the normal map; It can come from the underlying colors themselves.
I've never considered that selection-based generation may be useful, thank you for the suggestion! I'll make sure to include this feature in the next update :)
For now, the only workaround would be to split your texture manually.
Hi! Yes, this extension is meant to be used for testing & using normal maps. You can generate Normal Maps using the Normal Toolkit: https://mooosik.itch.io/normal-toolkit
I did a little more digging and found this video. It seems like they built the whole game as a 3d environment and placed everything precisely to make it look just right when looked at from the front through an orthographic camera :o
Hi, while I haven't played Eastward, looking at a few trailers I don't think the game uses Normal Maps. You may be able to achieve a similar look using just 2D lighting, there are plenty of tutorials for that, but one I used in the past was this tutorial by Brackeys for Unity. It essentially boils down to making the scene dark by default and only adding color where there is light, depending on the intensity and color of the light itself.
Normal Maps are not required for lighting in 2D, but if you want your textures to be affected by light based on its direction, you need normal maps. There is another Unity tutorial by Brackeys that goes into normal maps.
If you do want to use Normal Maps, you can try out my Normal Shading extension. It adds basic lighting to Aseprite and allows you to get an idea of what your texture will look like with a normal map applied :)
Well that's probably where the issue comes from. 1.3 adds alot of features to the aseprite api and I've potentially used some of them. I will look into this asap.
I personally never had any issues with the 1.3 beta, so if you don't rely on plugins only compatible with 1.2.4, I'd recommend you give the beta a shot :)
Hey, thank you for your comment! Regarding your feedback:
1. This was actually already supposed to work but I somehow didn't notice it when releasing the extension. I've uploaded a fix just now
2. This is a feature I haven't even considered yet, thank you for the suggestion. I'm a little busy with other work right now but I'm going to look into this as soon as I can
If you notice any issues with the new version, please let me know :)
