A Theory for peoples decals not showing.

[Randombeef]

So, a few peoples liveries have not been showing and it may be due to the program you are using to convert svgs. I just uploaded a nismo.tv decal and showed up fine in-game.

I then tried uploading an image with this website https://www.online-convert.com/result/2ccf6fd4-a7b8-4aa4-ba58-7069852a69f8 which a few users have been using. The gran turismo website wouldn't even upload it, so I don't know if it would appear in-game but due to other peoples experiences I doubt it would. Using these online converters may be your issue but i'm not sure. Sorry if im wrong!

 

[Varg83]

Hey, I figured it out. Some converters are making bad files. This one fixes your .svg files

 

[atteiros]

Also make sure the SVG files do not contain text. Convert to path before saving the SVG. If you are using an SVG converter, make sure it supports text to path. Avoid complicated gradients and effects like fading colors and shadows. Although you might be successful in uploading, if the SVG features in GT Sport do not support the fade/effect, it can screw up the svg in game.

 

[TerryLabonte44]

Also anyone know why that site is making the logos black when I ask it to convert with color?

 

[TeWheke]

Also anyone know why that site is making the logos black when I ask it to convert with color?

The converter can't detect the colour on the logo, basically any converter can generate unpredictable results which is why it's better to create hyour own svg files (but much more time consuming obviously).

 

[Varg83]

The converter can't detect the colour on the logo, basically any converter can generate unpredictable results which is why it's better to create hyour own svg files (but much more time consuming obviously).

Yeah, I sat down trying to learn Inkscape this weekend, but meeting the size limit with color svg files is challenging.

 

[akira3d]

Up until this weekend, I've been uploading .svg decals (created in Illustrator CS6 / CC 2018 and optimized via svgomg) without any issue, but lately I am having difficulty making ones that render correctly within the game. And all of these decals look correct when I view them within a web browser (even after being uploaded to the gran-turismo website).

Sometimes, the decal appears cropped arbitrarily and offset from center...sometimes shapes or points appear shifted / transformed randomly within the decal...sometimes the entire decal does not show up at all. The one thing that is consistent is if I create a small enough .svg directly within Illustrator, it will show up correctly in game, but, as many of you probably know, Illustrator does not make the most efficient .svg files.

I noticed that svgomg must have recently updated with more optimization options than it used to have, so I've been trying to isolate which feature(s) may be causing the issue (I am assuming that it is the root of problems, not the solution in my case). What's helped is using RemotePlay to connect to my PS4 from my .svg authoring PC and have the Livery Editor open while I upload different attempts to make one work...will report back if I learn anything.

 

[BLiTZ]

Up until this weekend, I've been uploading .svg decals (created in Illustrator CS6 / CC 2018 and optimized via svgomg) without any issue, but lately I am having difficulty making ones that render correctly within the game. And all of these decals look correct when I view them within a web browser (even after being uploaded to the gran-turismo website).

Sometimes, the decal appears cropped arbitrarily and offset from center...sometimes shapes or points appear shifted / transformed randomly within the decal...sometimes the entire decal does not show up at all. The one thing that is consistent is if I create a small enough .svg directly within Illustrator, it will show up correctly in game, but, as many of you probably know, Illustrator does not make the most efficient .svg files.

I noticed that svgomg must have recently updated with more optimization options than it used to have, so I've been trying to isolate which feature(s) may be causing the issue (I am assuming that it is the root of problems, not the solution in my case). What's helped is using RemotePlay to connect to my PS4 from my .svg authoring PC and have the Livery Editor open while I upload different attempts to make one work...will report back if I learn anything.

SVGOMG did indeed receive an update late last year and stopped SVG's showing in-game. After trial and erroring each of the toggles I found that 'Round/rewrite numbers' caused the game not to show the decal (it shows fine on the website, but just results in a spinning wheel in-game).

From this trial and error I found that the only controls that really have any major impact on size (aside from the optimizer's general house keeping) are the Precision slider and 'Round/rewrite paths' toggle. The others will shave the odd bit here and there but those two do all the heavy lifting and can shave 10's off the size.

I also found that setting the quality to 2 or less results in the scrambled logos that you mention. Again they display fine on the website but turn to mush in-game. Sometimes low precision is required to get the size under 15kb. One workaround for this is as follows:

Step 1 - Take your freshly made SVG and run it through SVGOMG and get the size under 15kb
Step 2 - Save it to your computer
Step 3 - Close SVGOMG and reopen
Step 4 - Reopen the saved SVG and now turn to the precision up to max (The size should remain under 15kb)
Step 5 - Try uploading and viewing in-game.

If this fails try opening the sub-15kb SVG in your editor of choice and resave. The file may grow again but not by as much so shouldn't require as much quality loss.

The issue here is that PD never intended people to upload such complicated and intricate decals and using all these optimizers is just messing the files up and creating issues like this that we're having to work around.

 

[Mugo123]

Yeah, I sat down trying to learn Inkscape this weekend, but meeting the size limit with color svg files is challenging.

Colour shouldn't make that much difference to be honest, it's only a few words of text in the xml. The really killer is quantity of node points, this is what you need to be concentrating on reducing.

 

[MatskiMonk]

Somethings to bear in mind...

This is all an over simplification as I'm ignoring the nature of the path or shape, and the number of paths across which the nodes are spread... but the principle is the same.

Generally speaking, for more complex decals... Number of nodes × decimal accuracy of nodes = majority of file size

100 nodes at 5 dp accuracy = 700 characters
100 nodes at 2 dp accuracy = 400 characters
50 nodes at 5 dp accuracy = 250 characters
50 nodes at 2 dp accuracy = 200 characters

Each character in the SVG = 1 byte.

SVGOMG will not remove nodes, it will just reduce the accuracy of them (it CANNOT add this accuracy back once you've closed it, or reloaded the file).

Simplifying the path in an application first will remove nodes - or doing it manually (which is the better method)

Auto trace generates ALOT of unnecessary nodes, this is just a fact. Different apps are more effective than others though. The layering fashion that inkscape uses for instance is more efficient than CorelDrawX3 I've noticed.

As a rough figure, the presence of a curve in a line will double the number of characters used, at least. This is another reason why auto-trace is often bad, it seems to want to encode straightlines as curves even when it doesn't need to.

Colours (assuming internal style sheet is used) might take up about 12 characters per colour present and then another few for each instance of the colour being used...

 

[BLiTZ]

Somethings to bear in mind...

SVGOMG will not remove nodes, it will just reduce the accuracy of them (it CANNOT add this accuracy back once you've closed it, or reloaded the file).

I wasn't suggesting it does, but from my testing I found that having the svg saved with the lowest precision setting vs. the same file re-processed and re-saved at the higher setting gave better results. I haven't compared like for like files to see if SVGOMG was leaving some sort of code relating to quality, but I've done the above on a couple of occasions and the process of saving and resaving (including via the editing software, in my case Autodesk Graphic) has worked to resolve file size issues.

 

[MatskiMonk]

I wasn't suggesting it does, but from my testing I found that having the svg saved with the lowest precision setting vs. the same file re-processed and re-saved at the higher setting gave better results. I haven't compared like for like files to see if SVGOMG was leaving some sort of code relating to quality, but I've done the above on a couple of occasions and the process of saving and resaving (including via the editing software, in my case Autodesk Graphic) has worked to resolve file size issues.

Fair enough, I'd only meant to clarify the technicalities. Out of interest, when you say "gave better results" do you mean in terms of quality vs. file size, or, getting less errors?

Clearly a lot of peoples problems stem from how PD's server interpret the SVG at their end. As such, things we're doing in editors and optimisers might be totally legit, and still not work, and they're clearly tweaking it without any notification because the uploader has responded in a different way to the same files in the past.

 

[akira3d]

each of the toggles I found that 'Round/rewrite numbers' caused the game not to show the decal (it shows fine on the website, but just results in a spinning wheel in-game).

That's what I figured...given that it was the last switch I wanted to turn off given that, along with precision, it produced the greatest optimization for my more complicated decals.

I haven't had time to try any more adjustments since I posted. In the meantime, I "discovered" a better version of one of the three problem decals I have. It's just good to know the cause moving forward so I don't waste time.

 

[BLiTZ]

Fair enough, I'd only meant to clarify the technicalities. Out of interest, when you say "gave better results" do you mean in terms of quality vs. file size, or, getting less errors?

Clearly a lot of peoples problems stem from how PD's server interpret the SVG at their end. As such, things we're doing in editors and optimisers might be totally legit, and still not work, and they're clearly tweaking it without any notification because the uploader has responded in a different way to the same files in the past.

Generally less errors/whacky shapes in-game.

Tell me about it, I spent a day setting up an N24h number board, spent ages getting the size down only to find the following week when I tried to do another one for another car that it was either not showing or went all goofy. It seems the game's rendering of SVGs is less forgiving than most web browsers.

Not sure if it's doing it's own thing and applying some sort of optimisation itself post-upload or what?! But I noticed little things like transparencies not being displayed properly in the discover/collection screens despite showing fine on the car.

 

[akira3d]

I feel like I am chasing a bug around with one of the remaining decals I haven't been able to push through svgomg without issues in game. The graphic is pretty basic, mostly text,converted from a fairly decent resolution png. The text is black, but with white outline on an orange backgruond. I usually convert such logos to have overlapping shapes since outlines increase the number of control points. From Illustrator, the svg outputs at around 30Kb, so I bring it into svgomg. I have to use some of the rounding features in svgomg (Round/Rewrite Paths appears absolutely necessary in this case). In all cases, the output svg works fine in browser, but not in game.

After the first attempt, the black text and graphics render fine. The white shape underneath mostly works except for under a few of the letters and under a steering wheel graphic...where some points of the white backing shoot off into no man's land. It got the point where I completely regenerated the white backing (using a simply path offset of the black text and graphics in Illustrator). Same problem continues to manifest itself, but in slightly different configurations with each effort. So, I decide to remove the white backing. The output svg from Illustrator is still 19Kb....so back into svgomg it goes. The resulting svg still works in browser, but now the black text and graphics in game exhibit the same issues that were previously isolated to the white underlying paths.

I'm so confused.