Looking for other anime decal creators and tips

  • Thread starter Zonin59
  • 18 comments
  • 4,512 views
13
United States
United States
Zonin59
Hey all, brand new to the forum but I did some digging here and in GTS forums before making this thread.

I'm interested in creating my own itashas and decals in GT7, but it seems like waifu decals are about as complex as decals get in this game. I already know how to use Inkscape and the basic tips about how to optimize SVGs and editing conservatively, but I would like to get some tips from people who specifically know how to upload full waifu decals under 15kb.

For instance, the most popular Asuka Langley decal in GT7 is fairly detailed and it is all contained in one SVG:

1648664869905.png

If anyone has any specific tips about how this was accomplished, I would love to hear them! For reference I am attaching the Hitagi Senjougahara SVG I am currently working on optimizing (both the full versions and the minimal/totally optimized version). Both do not include facial features yet, but as you can see even the totally stripped down minimal SVG is still 37kb:

1648664832603.png

Obviously this is far less detailed than the Asuka one above, so I am probably doing something very wrong.

I'm not asking for anyone to create the SVGs for me, I would just like to learn from other decal creators here. Any advice is appreciated!

quick edit: For reference I am doing everything by hand here without converting any elements into Inkscape. I am just tracing the source image myself.
 

Attachments

  • Hitagi Full.svg
    967.1 KB · Views: 21
  • Hitagi Minimal.svg
    37.7 KB · Views: 17
Last edited:
You are getting absolutely battered by using linear gradient fills. This is from the minimal file... I don't even see any gradient fills.

1648722821652.png


edit:

Also,

You could probably get away with turning down the decimal precision in 4 d.p.s might be excessive (though I don't have that much experience with Inkscape)

1648722953900.png


edit 2:

If the Asuka character decal is in GT Sport post a link, and it will be easier to do a comparison.
 
Last edited:

Cheers, I'll have a look.

@Zonin59

I can't actually open your files properly anyway, that's a problem my end I think... but...

The minimal file still contains the bitmap images you're tracing over, obviously always remove those before looking at the file size...

.. but that aside, it looks like you can still do a bit of work on optimising your nodes too... as an example...

1648723779067.png


The left image is the hairline from your file, the middle image has had a few nodes removed (CorelDraw will do this automatically for me, I don't know if inkscape does the same, but in any case, you can just pick nodes that you think might be superfluous yourself and delete them, if the line seems to move, Ctrl+Z and try another). That's 11% less nodes which has a direct bearing on file size and as you can see if I overlay the two, there's no real difference.

edit:

Okay, this is an extract from the Asuka file from the first post...

1648724094600.png


... notice max 2 digits per node... compare this to

that extract from your file...

1648724192033.png


up to 6 characters per node.


SVGOMG will round these numbers for you when you run the file through it, so perhaps you don't have to focus too much on this, but each digit/character is a byte... so it's crucial to understanding how people make complex looking files.

Also...

The Asuka file uses only 2 gradient fills, and it writes them really neatly... see... the gradient is defined in the <defs> and then it's called in the <path> tag, it's simply called "a". It's a 4 colour gradient, so it looks a little more involved than a simple fade...

1648724439309.png





.. your inkscape file makes little sense to me (as I said, I don't use inkscape, so... )... but there's MASSES of what seem to be redundant gradients in your file. You need to check how you're filling objects. Also, consider that calling a gradient "a", is literally 20 times more efficient than the auto generated name "linearGradient107963".
 
Last edited:
The objects are also grouped rather then combined, So styles have to be called multiple times instead of once.
The gradients dont make sense as you cannot see them and also because as they are they would not render in GT as they are linked, They would need to be unique by duplicating the gradient and asigning seperate instances.
The golden rule for gradients is that they are done dead last in construction as altering nodes will create transforms which can be a pain to remove, I usually only add them after already running them through SVGOMG.

A fair amount of nodes can be removed by hiding the ugly bits under other objects rather then being neat with borders, 1648725949227.png
Get rid of the gradients for now, Combine objects with same fill/strokes, Svgomg for decimal trims.
 
A fair amount of nodes can be removed by hiding the ugly bits under other objects rather then being neat with border
Yup, this.

The files getting borked when I open it..

1648727794259.png


But...


You've done a bit of simplification by the looks of it, but to expand on Vectra's example for the sake of any other people trying to get advice from the thread...

1648728310894.png
 
Last edited:
First of all, thanks for all the replies everyone!
You are getting absolutely battered by using linear gradient fills. This is from the minimal file... I don't even see any gradient fills.
So I am not purposefully adding any linear gradients to my file, do you know how exactly these gradients could be getting added to my fills? @Vectra4 if you have any input here I'd appreciate it too. The process I use for creating and filling objects is here:

1648744795939.png


The darker colors in the above object (at the tips of the hair) were created the same way, I just mistakenly added them to that layer. If that process couldn't possibly add gradients, how could I go about removing them from my project? I'm sure I'm making some fundamental mistake here, I just can't figured out where it is.
You've done a bit of simplification by the looks of it, but to expand on Vectra's example for the sake of any other people trying to get advice from the thread...
Thanks for the visual example here. I had cut the face out to "fit" into the hair like a puzzle because I anticipated having to upload the face as a separate SVG since my optimized filesizes were so high. I figured it would be easier to piece together on the livery if I shaped it that way, but it was probably contributing a lot to the size.

... notice max 2 digits per node... compare this to

that extract from your file...

1648724192033.png


up to 6 characters per node.


SVGOMG will round these numbers for you when you run the file through it, so perhaps you don't have to focus too much on this, but each digit/character is a byte... so it's crucial to understanding how people make complex looking files.
Would you mind giving a brief overview on how to round my numbers down to 2 digits as I draw the object? Or pointing me to somewhere where I could learn how to do this? If this is something that I can just do in SVGOMG after completion then it's not a huge deal, but if I can somehow use only 2 digit numbers while creating the SVG it would make things much easier.

Again, thanks everyone for all the advice here. I really appreciate the detailed responses.
 
Also, I have been working on optimizing my shapes a lot more (in terms of using less nodes). Here is the project file for the one I was working on after learning from that first SVG if anyone wants to compare the two. I am able to get this one much smaller with saving as optimized SVG and SVGOMG, but obviously it is still nowhere near as efficient as that first Asuka.
 

Attachments

  • Hood Hitagi.svg
    799.2 KB · Views: 14
Thanks for the visual example here. I had cut the face out to "fit" into the hair like a puzzle because I anticipated having to upload the face as a separate SVG since my optimized filesizes were so high. I figured it would be easier to piece together on the livery if I shaped it that way, but it was probably contributing a lot to the size.
This is a sensible approach. For what you want to do, you should definitely pursue learning what the best you can do is, but... in practice, sometimes you'll just look at a decal find it's better to break it down. I use another approach (it's easy in CorelDraw, but needs an extension IIRC in inkscape), whereby I draw the image as best as I can, then lay a grid of boxes over it, and use an intersect tool. It cuts the image up according to the grid of boxes, I use the original drawing to make a template by using an outline tool, I lay the template on the car, then just go through and overlay all the pieces. It's a bit fiddley, but it makes drawing the decal up in the first place easier. One drawback is you can't use any stroke colours or thickness... that messes it up...

My Z4 was the most effor I've put into drawing characters...

1648746258470.png



Would you mind giving a brief overview on how to round my numbers down to 2 digits as I draw the object? Or pointing me to somewhere where I could learn how to do this? If this is something that I can just do in SVGOMG after completion then it's not a huge deal, but if I can somehow use only 2 digit numbers while creating the SVG it would make things much easier.
I think it's this screen, but it's changed since I last used inkscape...

1648745733389.png
 
Last edited:
My Z4 was the most effort I've put into drawing characters...
Awesome, good to see this example too. I was just piecing it together the other way because that's how I'd seen it done in some decals before, but I may need to think outside the box like this.

Just to confirm for the numeric precision, would this be the correct setting to get the coordinates to round to 2 numbers?

1648746670141.png


Also, does the "size" of my canvas have anything to do with how difficult it is for the SVG to round up/down to whole numbers? I'm not sure how exactly it determines the coordinates, but my canvas is currently set to 512x512px in that Hood example. If I were to up it to 1024x1024, is it more likely that a given coordinate will round to a more accurate whole number since there are more pixels on the canvas? I know that logic probably only applies to rasterized images but I'm just spitballing here lol. I'm just not sure why the coordinates in that Asuka file are like "24, 34, 56" etc and mine are smaller numbers like "1.3726, 3.3202, 5.2166" etc.
 
Last edited:
What I do for stuff that is way too big for one decal is to save the whole thing once so Illustrator creates the boundaries around it, or whatever it's called:
1648747210662.png
These only appear when the file is re-opened.
Once those are there I remove individual parts of the decal and "save as..." them into individual files.
Through that method I get decals that I can then just need to place one piece of the decal and all other parts of it align themselves through duplicate/replace.
 
Last edited:
Also for the numeric precision, would this be the correct setting to get the coordinates to round to 2 numbers?
I think so, best to try it and see. You can 'preview XML' in inkscape, or just open the SVG in Notepad, or Chrome and 'View Source'.

It's worth keeping in mind that big part of how SVGOMG reduces file sizes, is in rounding all numbers to less decimal places, so even if you don't do this in inkscape, you can retrospectively to it in SVGOMG.
Also, does the "size" of my canvas have anything to do with how difficult it is for the SVG to round up/down to whole numbers? I'm not sure how exactly it determines the coordinates, but my canvas is currently set to 512x512px in that Hood example. If I were to up it to 1024x1024, is it more likely that a given coordinate will round to a more accurate whole number since there are more pixels on the canvas? I know that logic probably only applies to rasterized images but I'm just spitballing here lol. I'm just not sure why the coordinates in that Asuka file are like "24, 34, 56" etc and mine are smaller numbers like "1.3726, 3.3202, 5.2166" etc.
I'm not sure that's how it plays out in practice. There probably are techniques to get cleaner numbers in the first place, but not one I've mastered! Between those settings in Inkscape, and OMG SVG you should be able to get it nice and compact.
 
I think so, best to try it and see. You can 'preview XML' in inkscape, or just open the SVG in Notepad, or Chrome and 'View Source'.

It's worth keeping in mind that big part of how SVGOMG reduces file sizes, is in rounding all numbers to less decimal places, so even if you don't do this in inkscape, you can retrospectively to it in SVGOMG.

I'm not sure that's how it plays out in practice. There probably are techniques to get cleaner numbers in the first place, but not one I've mastered! Between those settings in Inkscape, and OMG SVG you should be able to get it nice and compact.
For sure, thanks for pointing me in the right direction here. Only thing I need to troubleshoot is how exactly I am ending up with so many linear gradients in my files lol.

edit: I might have just found the answer to my linear gradient problem:
1648749676459.png


I have been using swatches to fill as well. It looks like swatches might automatically be saved as single-color gradients. This makes absolutely no sense to me but that thread is the closest thing I could find to a replication of my issue, and it's from over a decade ago.
 
Last edited:
Also I seem to have made my numbers problem worse, assuming I am looking at the right thing here. As long as SVGOMG is optimizing them down to 2 digits though, it seems like it's not a big deal.

edit: Jk I just realized that changing the numeric setting will likely only apply to future paths that I make rather than retroactively applying to all previous paths.
View attachment 1131804
 
Last edited:
I apologize for the multiple bumps here, but I was having issues formatting edits with quotes and whatnot so this will be my last post about the numbers issue, because I figured it out. Documenting it here just in case anyone else stumbles on this thread in the future.

In my previous post I mentioned
but my canvas is currently set to 512x512px in that Hood example. If I were to up it to 1024x1024, is it more likely that a given coordinate will round to a more accurate whole number since there are more pixels on the canvas? I know that logic probably only applies to rasterized images but I'm just spitballing here lol.
I was half correct. The numeric values of the nodes are being taken from their coordinates on the canvas in millimeters, not in pixels. My canvas was set to something like "133.20394mm" wide and high by default, as you can kind of see by the ruler in the screenshot in my last post. So I was getting all these messed up decimal values because essentially I was only working with a 133x133mm space, and that's all the values my nodes had to work with. So without rounding them to 2 places each (as shown here):
correct setting to get the coordinates to round to 2 numbers?
I was ending up with super long decimal values due to the intricacy of placing many nodes in a 133x133 space, and rounding them all up/down to whole 2 digit numbers afterwards resulted in everything being shifted around too much. Here's an example of the XML from just a small line in my previous 133x133mm canvas with the numbers being rounded to 8 places:

1648751136752.png

And here's an example of an ellipses being placed on a 1000x1000mm canvas rounding to 3 numbers:

1648751231994.png


So the answer seems to be that I should make a larger mm canvas while rounding the numeric values to 3 numbers to get the most efficiency/precision out of my nodes. That seems more or less like what the creator of that initial Asuka pic did.

I'm sure this exact solution has been mentioned in SVG threads here before, but thanks everyone who posted for helping me to figure out both the numbers issue and the gradient issue!
 
Last edited:
I usually work on a 500x500mm canvas :lol:
Too bad AI doesn't allow to set node precision :(
 
Posting here again just for an update on progress. I got 2 full body SVGs done once I nailed the process. Attaching my most recent one here, along with the 2 minimized parts I uploaded to GT7. Thanks again to everyone who chimed in ITT, couldn't have done it without your help!
 

Attachments

  • Hitagi Sitting FULL SVG.svg
    75.7 KB · Views: 24
  • Hitagi Senjougahara Sitting (1 of 2).svg
    14.9 KB · Views: 25
  • Hitagi Senjougahara Sitting (2 of 2).svg
    14.3 KB · Views: 22
Back