$12256 / $11500
I would like to introduce Vitruvian (https://vitruvianstudio.github.io/) to you, a proof-of-concept aimed at exploring how to maximize the potential of existing sprites. Despite not being a pixel artist myself, I wanted to contribute to the community in this way.
To achieve this, I attempted to condense (almost) all sprites from Sanderfranken's Universal-LPC-Spritesheet-Character-Generator (https://github.com/sanderfrenken/Universal-LPC-Spritesheet-Character-Gen...) to a maximum of 6 shades per material. This allows users to select their desired color, and the spritesheets are instantly recolored. By requiring only one spritesheet per design (as opposed to one for each color), I managed to reduce the overall size of the sprites to under 20 MB (including credits and some specs). Currently, I am using Eliza's Liberated Palette (https://github.com/ElizaWy/LPC/wiki/Style-Guide#color-palette) for the recoloring process.
For sprites composed of multiple materials (e.g., Bicorne athwart admiral cockade from https://opengameart.org/content/lpc-pirates), it is possible to assign a unique color to each material, leading to 658,503 different combinations for the hat in this particular case. Presently, up to 4 materials are supported.
Additional features include:
- Displaying and playing animations
- Saving/loading settings (in the browser's LocalStorage; however, saved settings are lost after clearing the cache)
- Exporting/importing settings as JSON
- Exporting PNGs per animation as a single sprite or one sprite per layer
All of this functionality also extends to horses, based on (https://opengameart.org/content/lpc-horse-extended). The riding animation is not available yet, as I honestly haven't fully grasped it :)
Currently, not all colors are accurate, but this is, after all, a proof-of-concept. Some sprites are challenging to condense without compromising quality, and adjustments the Z-indices are still needed in some cases. Also I have to check if all credits are set correctly.
The original colors (except for a few exceptions due to the complexity of color settings) are not available, as Sanderfranken's excellent tool (https://sanderfrenken.github.io/Universal-LPC-Spritesheet-Character-Gene...) serves that purpose.
The source code is not yet available, as the code is still very dirty (and possibly buggy at some points) and could use some refactoring and optimization :) but the plan is to release the code soon.
The recolored sprites are pushed to GitHub: https://github.com/vitruvianstudio/spritesheets
I'm eager to hear your thoughts and welcome feedback to shape the future development of Vitruvian.
Best regards
napsio
This website's content is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
This is pretty cool! I like how you've organized the assets, and the layers export seems pretty useful.
I'm looking forward to whenever you release your source code. I've also been working on a new spritesheet generator, so I'm curious to compare how we both approached some of the features.
Very cool, thanks so much for sharing! I am particularly impressed that you managed to/chose to adapt almost every asset in the current generator and that you have maintained the attribution information. Of course standardizing the colors, allowing the generator to make recolors "on the fly" rather than generating them all offline, and breaking apart the animations will all be big improvements for contributors.
Here are some minor issues I noticed when playing around:
- "Walk" animation should start on the second frame in the series; the first frame is just the character standing idle. Adding it to the walk cycle makes their legs splay out and looks unnatural.
- When you first select an object, the first few animation frames flicker
- To that end, it takes a few seconds to render the new animation(s) when you add/change a layer. Any optimizations to that would be welcome
- "Whip" animation uses the wrong frame size, should be 192x192px
Here are some feature requests in no particular order:
- It would be helpful to preview the animation in all directions at once like in the other generator
- For that matter, I think it would be helpful to see all animations in all directions at once
- I would like to see a preview of the item in the drop-down (I know this would require using something more complicated than an HTML <select> element)
- The whole "torso", "torso 2" thing is kind of non-intuitive to me. I understand you probably did it this way so that mutually-exclusive items can be in a single dropdown, but it's not obvious to the user that they should look in "torso" for plate armor but in "torso 2" for jackets. Likewise, I would suggest at least one more torso layer, since you could easily imagine a character with a longsleeve shirt, vest, and jacket. I would also move the armor and vest(s) to "torso 2" and make the jackets and tabard "torso 3." Alternatively, you could label the layers something intuitive like "shirt," "overshirt/armor," "jacket/tabard," etc.
- Same suggestion for "head coverings;" make bandana, hijab, etc. their own layer.
- Consider breaking some of the items within layers into groups. For example, separate the pirate hats from helmets. Even just using <optgroup> within the same <select> would be helpful as right now it's kind of a jumble, especially for categories like hat or hair with lots of assets.
- Allow downloading a file without naming it
- When an object has multiple "palettes" (e.g. the bicorne athwart admiral cockade hat you mentioned), make a tooltip over each palette
- Search function for assets (i.e. search box at the very top where I can type "bow" and see it in the appropriate tab of the UI)
- Mobile support? (on my iPhone 13, the left and right panels almost entirely cover the preview).
And a few questions:
- What method did you use to squash the colors?
- What is going on with the colors of the sprites? In the repo you linked https://github.com/vitruvianstudio/spritesheets/blob/main/clothes/torso/longsleeve/male/walk.png everything shows up as a red blob. If I open in GIMP etc. I can see they are slightly different colors of red but I don't exactly understand what's going on. I'm sure this makes your recoloring code more convenient somehow. I humbly would suggest that it will be much more convenient for contributors and users if the sprites in the repo appeared in some default palette, either as indexed or ideally plain RGB PNGs. Much lower friction to adding and editing sprites. I say this as someone who has spent probably more time than anyone adding and modifying sprites in the current generator.
- I notice in some sprites, like the "Wizard" hat or the "hood" that there are red spots which don't get recolored when you change palette. I presume this is because these assets had too many colors and you couldn't automatically squash them (or, in the case of the wizard hat, you haven't extracted a separate color palette for the stars), is that right?
- Did you use a script to transfer the metadata and attribution from Sander's generator? If so, will that process allow you to port updates relatively easily? I ask because I am in the midst of making several such updates ;-)
Thanks again for sharing!
@BenCreating
Thanks :) I think, that the code will be released in February, so stay tuned :)
@bluecarrot16
Many thanks for your constructive feedback.
Oh, yes. I will cut out the first frame and use the idle frame as a seperate animation (would love to use the new idle animation, but there are no compatible spritesheets for clothes, hair, etc. yet)
Are you using firefox? I've noticed the problem too, but only in Firefox. At the moment I can't figure out what the problem is, but I'll investigate and see if I can fix it or build a workaround.
Optimization is already in progress :)
Will be fixed. It's a stupid bug :/
I have to see how best to do this, as there is little space because of the zoom. But I'm sure I'll find a solution to implement it.
Did you mean the spritesheets or the animated preview?
I think that would be great too, but I still have to find a way to implement it in a resource-saving way without loading a preview file for each item individually.
This is already on the todo list. I haven't had time to sort them properly yet. but it will be done :)
This is already on the to-do list, too and will be done.
Yeah, will be implemented.
Will be impemented.
I'll have to see how best to do that, but I've put it on the to-do list
A mobile version is not planned for now. At the moment I also have no idea what the mobile view could look like :)
That was a mixture of manual and scripted. I have created a python script which writes all used colors into a json file like:
{
"(0, 0, 0, 0)": [0, 0, 0, 0],
"(153, 66, 60, 255)": [153, 66, 60, 255],
"(204, 134, 101, 255)": [204, 134, 101, 255],
"(228, 164, 124, 255)": [228, 164, 124, 255],
"(249, 213, 186, 255)": [249, 213, 186, 255],
"(250, 236, 231, 255)": [250, 236, 231, 255],
"(39, 25, 32, 255)": [39, 25, 32, 255]
}
Than I've set the colormapping and recolored the spritesheet.
{
"(0, 0, 0, 0)": [0, 0, 0, 0],
"(153, 66, 60, 255)": [255, 0, 4, 255],
"(204, 134, 101, 255)": [255, 0, 3, 255],
"(228, 164, 124, 255)": [255, 0, 2, 255],
"(249, 213, 186, 255)": [255, 0, 1, 255],
"(250, 236, 231, 255)": [255, 0, 0, 255],
"(39, 25, 32, 255)": [255, 0, 5, 255]
}
This results from the method mentioned above, but you can consider it a transitional solution. I only did it this way so that I can better see which colors I have mapped and which I have not. The colors are divided as follows:
[255, 0, 0]
The first part is only a indicator and doesn't have any function.
The second part represents the material. 0 for the first, 1 for the second, etc.
The third part represents the index of the color in the palette. 0 (lightest) to 5 (darkest).
Since it is still a proof-of-concept I left it like this, but it will not stay like this. In the data.json for each item I have already set default colors (still have to check if they are all set well). As soon as the beta version is finished I will color all spritesheets with the defined default colors. That means, if someone wants to contribute new items only has to specify in the data.json which colors were used for the spritesheets (the colors must (currently) come from the color palette of Eliza).
Yes, for the "Wizard" hat I forgot to define the material for the stars, so currently there is only one material defined, but the spritesheet itself uses two materials.
The hood is an other problem (also noticed only on Firefox). These spritesheets have very extensive colors with a lot of transparency. Firefox seems to have some problems with transparency. But I will try to fix that.
No, I transfered them manually :/ But I think a script should be possible (with perhaps a little reworking).
I hope I haven't forgotten anything :)
Best regards
napsio
I have made some optimizations. The renderings should now run a little faster.
Some other changes:
- Splitted walk-animation in walk and idle
- Fixed whip size
- Added animation preview in all directions
- Changed spritesheet-view so show all animations at once
- Reorganized the torso items a bit
- Allow export without saving
- Added tooltip to the material-selector-buttons
- Added missing material to "Wizard" hat
- Workaround for red spots for the "Hood" hat
Best regards
napsio
Another small update:
- Added "optgroups"
- Added preview-images in selects
- Reorganized "head_coverings"
- Changed some z-indexes
Best regards
napsio
Thanks for making all those additions, I think it is much improved!
Thanks for explaining about the colors. I think your solution of assigning "default" palette(s) to every item which are discoverable in metadata is a good one.
I am using Safari Version 16.6.1 (16615.3.12.11.5, 16615) and still see the flickering. I don't see the flickering on Chrome Version 120.0.6099.234. Seems to occur the first few times a given animation is played with a given setting. Adding/removing a layer causes it. Switching to a new animation causes it. Switching back to an animation already played does not cause it.
A few other minor issues I noticed:
- Chainmail in the "shirt" layer seems to have too high a z-index (gets drawn over top of all armor)
- Suggest moving the "legion" and "leather" items from the "shirt" group to "overshirt/armor" group
- Slingshot "walk" animation doesn't work.
- Could you increase height (i.e. number of items shown) when a dropdown is opened?
- Could the size of the preview images within the dropdown be increased to 64x64px (seems like they are 40x40px now which results in non-integer scaling and also is a little hard to see)?
- If not too computationally intensive, could you center the non-transparent portion of the image?
- In the (now default) "Preview Multiple" mode, if you zoom in, the character is no longer centered, and scrolling is really jittery/doesn't work (i.e. I scroll down a bunch and the character just wobbles vertically in place. Sometimes eventually scrolls down, sometimes not). I appreciate you have tried to lock the scrolling between the four views which is a great idea, but something there is not working right at the moment.
- Clicking the "center" button doesn't seem to do anything for that matter.
- In the old generator, you could click the animation preview or the spritesheet to toggle between 1x and 2x zoom. This would be a nice feature IMO
- I still would like a view where all directions of all animations are shown at once ;-) It would require scrolling but there's so much whitespace at the moment
Thanks again for working on this, it's really cool and seems like a big improvement in several ways over the current generator!
I have uploaded a new update:
- the spritesheets are now colored in the default colors, which should make adding new items much easier.
- z-indexes fixed for many items
- moved "legion" and "leather" to "overshirt/armor"
- dropdown height increased
- fixed dropdown preview image size and centered the item in the preview image
- fixed zoom, scroll and center button (I guess :) )
- zoomable spritesheet overview
I'm still working on some ideas to improve the animation player (show all at once), implement the mobile version and implement search functionality.
Feel free to contribute at https://github.com/vitruvianstudio/spritesheets and soon https://github.com/vitruvianstudio/vitruvian-web
Best regards
napsio
Hello, your project sounds interesting, but could you upload a few samples of what it can do?. I don´t think many people can make it run just to have a small look at what the result is like. Don´t be shy if it´s still not that beautiful, you are likely to get more help this way.
Hi Danimal,
you don't have to run it yourself. You can try it at https://vitruvianstudio.github.io/
Best regards
napsio
This seems pretty cool, a lot better than the character creators I've made in the past.
Thank you :)
Very cool app, but I think there is something wrong in the format:
[code]
{
"data": {
"anatomy.body.male": {
"colors": {
"primary": "ivory"
}
},
[/code]
This is inconsistent with Object Oriented Programming: "male" is not a property, it is the value of property "body", hence it should be:
[code]
{
"data": {
"anatomy.body" :
{
"type" : "male",
"colors": {
"primary": "ivory"
}
},
[/code]
And I have a suggestion: it would be very useful to be able to upload custom spritesheet for the 4 possible directions of the head: I see that AI text-to-image tools are very good at creating pixelart drawings, and this would allow a big and easy increase of the number of characters which can be created with Vitruvian Studio!