Huge problems with xrefs, substance shaders and redshift


#1

Working in a team environment, I’m constantly updating a series of XRef’s (object/material change) and asking the larger team to re-load those xrefs multiple times each day.

The project I’m on is Redshift based, uses mostly custom node based shaders, but also half a dozen substance shaders throughout various shots.

As the weeks have progressed, the project files got exponentially more complex to work with; animate; open or save. We assumed they were just heavy files until I went digging for a problem yesterday.

Checking the Substance asset folder in a colleagues work, it appears that each time the xref was reloaded, a new copy of the substance shader came with it. Resulting in over 100 duplicates of the same substance, not to mention a substance cache folder that had grown to around 80gb, that should have perhaps been 100mb.

Using a ‘Remove unused’ or ‘remove duplicates’ from the substance asset folder; kills all substances.
So the solution is to simply bake them down individually and ensure we’re using texture driven mats only.

What I question though, is the how and why on earth this would happen? And whether or not anybody else has experienced something like this with a similar workflow?

It’s a major flaw in C4D or perhaps Redshift, for a Substance to require reloading each time and xreft is refreshed.


#2

Did you tried to search in Redshift forum?


#3

I can absolutely confirm having similar issues when using live Substances in C4D. Generally speaking, I don’t, but only when I have to mock something up quickly and don’t want to fool with proper texturing.

A quick and dirty way to deal with this is to use the live substance material in your scene, but then replace the textures with the cached texture files. From that point on, they are obviously just baked versions of the textures.

The only downside that I see is that if you needed animated parameters within the substance, that is not really doable in this way.

No reason to leave Substances live unless you need them to be editable parameters during your C4D render.

You can also open the substance materials in the substance viewer and export bitmaps from there. Using this method, you could alter parameters and output several different versions for variations.


#4

That’s exactly what I had to do. Save scene and assets, manually reassign mats in Redshift, configure without the plugin… Tedious stuff, but almost thankful for the XRefs now, because those changes will ripple through the entire project. With one small flaw in my logic, where everybody needs to manually delete remove all substance from the asset manager…

The problem is, it’s difficult to know where the failure occurs. Other than it being a shit plugin.


#5

Could be related to this or might not…
https://www.redshift3d.com/forums/viewthread/25612/

https://www.redshift3d.com/forums/viewthread/19677/

https://www.redshift3d.com/forums/viewthread/17452/


#6

I’ve experienced this issue with Xrefs regardless of render engine. Sometimes the entire xref is duplicated on save/load, which for some assets can absolutely cripple a project. No solutions here I’m afraid, just piping up to say “same here”


#7

Wondering if the Substance C4D preferences option “Create material on Import” being on by default has anything to do with it?


#8

Just throwing this out there- (and may be no help for the substance duplicate issue) -but wondering if using Redshift Proxies rather than C4D xrefs help? Same concept–accessing an object and material from an external source file.