It looks fine.
As you already noticed, you could look up for tutorials about
" UV mapping "
Even if those surfaces were exactly what you wanted, UV mapping might be necessary to directly export the .blend file into another format for some other posing program or game development environment.
Of course, whoever is able to bend those bow via lattice or skeleton or skin can add them themselves, and i guess the same is true for who wants to render them to create icons.
It's not my field, so i can't test the alignment myself, but i noticed a thing that can create confusion: The sidebar is too narrow. Even if an array of accessories is named just... IDK Cape1; Cape2; Cape3, or CapeA; CapeB; CapeC... It might become a little confusing for the end user to evaluate the options by counting the position in the array by pointing their finger at the monitor while scrolling up.
About the RAM or virtual RAM limit, it is pretty simple: Beside the limitation of 16384 frames, even if we talk about bigger frames, it looks like i can't put together on a PC a spritesheet so big that your script can't trim on the very same PC, but if i can put a sheet together on Aseprite, then your script can create a GIF.
There is objectively no position decay at all. It is possible that black background affects the outline differently than any other color, for reasons connected to the fact any factor multiplied by 0 gives 0 and this is why i ran different tests expecting different results.
Actually, if there is an apparent shift in the image, it would happen on not-black background, because, judging by the time the computer chews the procedures, it is when background isn't black that dithering becomes esoteric.
However: A slip of the finger (I.E. an height of 155 instead of 156) is always a possibility, but it would have produced a shift of 43-1 (First row won't get shifted) pixels in the end, in this particular spritesheet.
The Gif below has been obtained by typing 155 on purpose, and as expected, every 30 frames, the image shift down by 1 pixel. (Every self-respecting scientist/researcher deep down loves explosions and breaking stuff on purpose. )
When i code stuff myself, i work with sequences.
Somebody told me they understand spritesheet better than sequences but don't have the tools or know how to make spritesheets from sequences and therefore i started providing raw spritesheets, but i'm not familiar with spritesheets.
Sorry for doing all the talking... Looks like i've hit some limit.
So this class off komato ranks will be divided in 2 submissions.
The good news is: it is the heaviest class.
I don't feel like dividing into guys and dolls, so i'll go with "1 to 28/38" and "29 to 38/38"
It looks fine.
As you already noticed, you could look up for tutorials about
" UV mapping "
Even if those surfaces were exactly what you wanted, UV mapping might be necessary to directly export the .blend file into another format for some other posing program or game development environment.
Amazingly clean!
Perhaps 18 triangles wouldn't weight too much.
Of course, whoever is able to bend those bow via lattice or skeleton or skin can add them themselves, and i guess the same is true for who wants to render them to create icons.
Looks like a very quick and versatile tool.
It's not my field, so i can't test the alignment myself, but i noticed a thing that can create confusion: The sidebar is too narrow. Even if an array of accessories is named just... IDK Cape1; Cape2; Cape3, or CapeA; CapeB; CapeC... It might become a little confusing for the end user to evaluate the options by counting the position in the array by pointing their finger at the monitor while scrolling up.
It might be simple, but it is strangely captivating... For sure it reminds me of the good old days.
BTW, i don't see any rope on the bows.
BTW: This class (Komato security) is composed by 51 ranks, in 17 collections. (or submissions) 16 are OpenGL, one will be Iray.
About the RAM or virtual RAM limit, it is pretty simple: Beside the limitation of 16384 frames, even if we talk about bigger frames, it looks like i can't put together on a PC a spritesheet so big that your script can't trim on the very same PC, but if i can put a sheet together on Aseprite, then your script can create a GIF.
There is objectively no position decay at all. It is possible that black background affects the outline differently than any other color, for reasons connected to the fact any factor multiplied by 0 gives 0 and this is why i ran different tests expecting different results.
Actually, if there is an apparent shift in the image, it would happen on not-black background, because, judging by the time the computer chews the procedures, it is when background isn't black that dithering becomes esoteric.
However: A slip of the finger (I.E. an height of 155 instead of 156) is always a possibility, but it would have produced a shift of 43-1 (First row won't get shifted) pixels in the end, in this particular spritesheet.
The Gif below has been obtained by typing 155 on purpose, and as expected, every 30 frames, the image shift down by 1 pixel. (Every self-respecting scientist/researcher deep down loves explosions and breaking stuff on purpose. )
Almost forgot:
When i code stuff myself, i work with sequences.
Somebody told me they understand spritesheet better than sequences but don't have the tools or know how to make spritesheets from sequences and therefore i started providing raw spritesheets, but i'm not familiar with spritesheets.
Pages