2D can be a big responsibilty.
I'm finding it hard to manage large scenes, but then I have to appreciate that all this hard work.
The residential area is big, but I didn't realise the implications until I started cropping them. The workflow is that I must frame the entire environment in one camera view. I render off the image and then I subsequently crop them. The cropping process adds a metadata file that indicates the cropped images original position in the entire camera's canvas.
This process had worked fine for small and medium scenes. But in large scenes, the cropping process takes a bit of time.
This is compounded by the large number of elements that the scene is comprised of. My near-future worry is that I have to revise the look and the naming of the objects, and add/remove elements accordingly.
I think I have to step back, and instead of examining my workflow, I think I have to examine myself first.
There's a certain impatience that is creeping along my spine. I think that waiting for renders, or an automated cropping process is a good thing. It's also ok to make mistakes in the workflow or in the pipeline and revise it.
I don't have solid plans on how to tackle this, but given my moving targets, both game scope and unknown aesthetics, this should not be a surprise to me. But I should calm down, and be patient, and take in things more deliberately and carefully.
It is easy enough to say, but when I'm faced with questions of what I should do now, I often don't have any answers.
I want to redo the residential area again because I feel it's too big. That's fine.
But I also want to try to learn something from this, to see whether my Krita pipeline actually works. Again, I'm working on a scene that might be a throwaway, part of yet another 'prototype'; an unending series of tests.
One of the big things I'm trying to work out is the new Krita workflow in aid of sorting and final placement of the art before it goes into Godot. This replaces what Tiled Editor did for my older Construct 2 workflow.
I am utilising my own kind of sprite sorting, which allows me to sort my moving characters on sprites that are arbitrarily sized and don't sit squarely on isometric tiles. I call this sorting collision-based sprite sorting because I use collisions to detect whether something should be in front or behind.
This method has many advantages, but its main problem is the need to manually sort the sprites themelves according to how they might be layered in a composite. The method of how I sort those elements is one of the problems that have been plaguing me for months. IfI had made bigger scenes earlier I would have spotted the problem, since the techniques I had b een using were not actually scalable.
In the last iteration of the sorting workflow, I was sorting in Maya, and what tedium it was. The sorting workflow requires me to group meshes that could be treated as a single element that any moving character could be composited over or behind.
After this step, I parented elements to others depending on their sort relationship. The children were the ones in front of the parents.
This worked, but the process was extremely tedious. However, the main issue was that it was error prone. Trying to correct a mistake took more time than if you were to do it correctly the first time, and I was disheartened by this because I realised it wasn't a very good idea to begin with.
I explored other ideas within Maya, including dragging objects within the Outliner to denote their order, and then running a script that lets their position in the Outliner drive a custom z-index attribute. This attribute would get exported as a metadata file along with the EOBJ, and it would be passed throughout the pipe until the game engine.
The metadata itself is useful because it is the DCC that dictates the z-index. But the process in Maya was prone to error, and slow.
What I wanted, actually, was a 2D application, like Tiled Editor, to author my scene from 3D renders, and get that into Godot. Tiled Editor, however, was not fit for purpose. In the first place, it wasn't very good at selecting images based on cursor on pixel. Selecting an image by touching its pixel was the top thingI needed a 2D image application to do because my rendered images were of varying sizes and shapes.
I looked at other applications such as Affinity Photo, but its lack of scripting made it useless for my special requirements. Then I remembered Krita had a Python API. Soon, I installed it and started writing a few test scripts to see whether things could work.
After playing around with it for a week, I felt that, with some serious development work, Krita could fill in the role of Tiled Editor. Krita could be used to assemble not only rendered images, but any image I want to put in, and then export the layout and all the needed metadata for Godot consumption.
But even with that promising addition to the pipeline, I still feel bogged down by the 3D bit mainly because there's so much at stake at the first go; revisions seems hard to carry over to the final image.
Part of the problem is the naming; when I 'sketch model' the scene, my names are generic, like 'group', or 'cube', etc. When those are exported they are named as such and they go into LW and registered into Janus as those names. But if i want to change the names (even if I don't change the geometry), the LW side would need to clean up the newly non-existent object that is now represented by another name.
The revision workflow isn't as flexible as I wished it would be. But this is where my old school sentiments are clashing: in times past, not everyone had the shiniest tools, or the best way to do things. I feel like I need to show myself I can do a project smoothly, without kinks, without bends, without hurting too much. You know what I mean?
I think the tools I have are actually sufficient, and if I have problems, I should 1.) reduce complexity, or 2.) live up to my own aspirations.
By the way. grid crop took 51 mins! I should reduce the scene size.