Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - tlaik

Pages: [1]
I'm curious why such option (backporting / saving in compatibility mode) doesn't exist in Substance Painter. Sure, new features are being added in new version, but the main .ini files, texture and .sbsar formats in the SPP archive probably aren't changing that fast?

The reason being, it becomes a real pain in more than one area when you need to work with several clients, who might be stuck on different - and older - versions of Painter. Right now, the best course of action would be to use the lowest version of Painter of them all (sometimes going back as far as 2017 for me), missing out on all the new features.

I just wonder how much effort would it take to implement such option. Is it something we can look towards in future versions?

Substance PainterSubstance Painter - Discussions - SPP File Size
 on: August 09, 2018, 09:02:22 am 
For as long as I've been using Painter, I were puzzled by this ancient mystery dating back eons.
How does the several gigabyte size come about? Is this a mistake? A cunning plot to dominate our hard drives? Or a real necessity by any means?

Excuse my temper, but the sheer volume of space occupied by SPP files seems preposterous. It is often well in the realm of dozens, if not hundreds of uncompressed bitmaps packed together.

I have always been an avid fan of demoscene, and admired the great effort and ingenuity shown through most stunning visuals unraveling from a mere 64k package. Now, I fully understand that these are often purely procedural, while Painter needs to keep several bitmaps, whether from baking or manual load. Naturally, there's also the mesh being worked on.

These, however, may tally up to 100 to 200 megabytes in my typical 2048x2048 project, perhaps 300 in more complex cases - and even that comes from measuring uncompressed images, not any kind of lossless compression which yields much smaller sizes. What eludes me is the origin of the remaining one or two gigabytes.

My only guess would be the history of strokes - seeing how the file grows steadily over time, but should it really take that much? Does it have to? And judging by Painter's ability to adapt strokes to small changes in mesh, they must be saved in some vector form, rather than by-pixel changes.

And whether it's the history or something else, it would be highly convenient to have an ability to purge that extra data, if the user is certain they won't need it anymore.

While on topic of size - memory management also seems to have its fair share of troubles. Left overnight, or even for several hours of inactivity, Painter keeps consuming more and more until there's barely any free memory left. Inexplicably going from 2 Gb to 6-7 over few hours is a sure sign of a significant memory leak.

Substance DesignerSubstance Designer - Showcase - 3D Wood material
 on: September 28, 2017, 03:49:55 pm 
Made this one while experimenting with Pixel Processor effects. Added several groups of controls for convenience.

It's not as fine-grained and detailed in color as some 2D wood materials, maybe I'll figure out a (fast enough) way to do it later on.

SBSAR on Share:
SBS file:


Saves current file and makes a numbered back-up copy (filename_autosave_1/2/3.spp) in the same folder. Cycles through several numbered backups.

Autosave delay and number of backups can be configured via Plugins -> autosave_tl -> configure.

Windows-only restriction is due to dependency on a small file copying utility I wrote for this plugin. If Painter's plugin API ever gets a file copy method (right now it only has read/write methods), the plugin can be easily made platform-independent. As an alternative, someone with access to Mac/Linux dev tools could port the autosave_manager utility for these platforms.

Tell me if there are any issues.

Pages: [1]