As long as the proprietary code can be linked to Cycles I don’t see why they couldn’t just open-source the UI part, I am pretty sure the patented secret sauce is in the rendering side of substance? Texture previews go trough Cycles so UI would just be values to pass or am I wrong here? Maybe the OP should point out to Allegorithmic that Cycles is not GPL, I wouldn’t assume that to be commong knowledge.
The question is why would you actually want Substances in Blender? Substances are useful for big levels/scenes where you can introduce variety to instanced objects(floors walls etc) by playing with exposed knobs. It’s absolutely redundant for everyday artist.
Since we are talking about substances, we can implicitly assume artist is interested in Substance Designer output(not painter that is per asset). Designer has handy option to auto export upon any changes to graph. You can reload it with a moment in Blender. If you need variety, you can create few instances of that substance in designer and output each. It really takes a moment.
In other words, there is no practical need for substance reading in Blender, export textures that are fully compatible with everything (viewports, cycles, any render engine). No overhead, no speed penalty, no problems.
Question here.
If anything linked has to be GPL compatible, and Apache is more permissive, can it be possible that the Blender part is Apache licensed, and the Apache licensed part be linked with the proprietary part?
(something similar to linking anything to Cycles instead of Blender)
Cheers!
Was proposed to make a API licensed in Apache to be used by companies without limitations. But few Devs wants to work on it.
Substances are just complex procedural graphs. Ask yourself why you would need complex procedural textures as opposed to bitmaps and you’ve got your answer. I don’t know if you’re aware of this (honestly, not being smug) but they are not converted to bitmaps before rendering, they stay procedural. Which, come to think of it, makes me pretty sure they wouldn’t work with GPU rendering anyway.
Exactly. Blender already has a better (in my view) Painting workflow. You really do NOT need those extra redundant brushes and stuff.
Basically, if you are a talented artists, you only need the ESSENTIALS. And Blender got you covered.
Sorry but if you believe Substance is just about PBR texture painting you are only looking at the tip of the iceberg.
With some testing, we came up with a methodology of batch baking substances per UV tile (UDIMs). Using parametric substances we could design a surfacing pipeline which could create a new set of textures far quicker than hand painting. We could re-run these Substances each time there was a modeling update.
All the textures for the Animus were procedural; no bitmap textures were used. It was surprising how quickly I could match onset references using a combination of shipped Substance Designer nodes and custom ones I made.
I’m currently developing a new suite of tools which will form the framework for far more complex Substances. An example of one of the tools is a dripping rust Substance which will always flow over the model due to gravity regardless of UV orientation or scale.
Sure enough, they were also baking to bitmpaps before rendering. Still the procedural workflow had a lot to offer.
It would be great if one day, in this forum, the work and workflow of other users would be respected. And don’t let anyone say that if you don’t work in the same way as him then you’re not a talented artist. Like that’s a valid argument.
It would be nice if people would try to understand that there’s a world of 7 billion people out there.
1 Like
Unreal and Unity already make usage of those files while they still are procedural and you can decide within the engine(s) to switch the calculations of Substances to the GPU engine.
Its strange to me why a lot of smart people here which are otherwise adamant for the cause of streamlining and connecting Blender into professional pipelines are trying to shying away others when it comes to Substance Designer?
To make it more understandable you can output a file from Substance Designer which is like a Cycles Material where you have build everything procedurally and you have the ability to change that Material within other programs of your pipeline.
There is a need for a streamlined workflow where you have procedural dynamic textures available throughout the whole pipeline
and Blender is even with its Nodes in Eevee and Cycles an island solution, you can´t simply use your still intact procedural cycles/Eevee materials inside Unity/Unreal or other engines.
The problem with asset specific Substance workflow is that it dictates need for baked maps which in turn require LP/HP mesh with LP having nonoverlapping UVs or any other problems. There is always countless baking issues in particular in Designer (< worse than SP). Consider that the formats exported to SP/SD also have a fraction of information you can have in main 3D app.
Blender would benefit far more from having a few additional procedural nodes introduces to Cycles that are pivotal in SP/SD workflow. We recently got amazing Bevel shader thanks to Brech that is also usable for Curvature. What is missing is Ambient Occlusion that can be used as a MASK. These are really the pivotal maps in SD/SP workflow (normals, curvature, position, ao). If we have these covered then very complex shading networks can be done right here in blender. Paint wear - no problem (Curvature + AO). Dirty and dust in cavities - AO. Dust on surface - Geometry normal Z(up) etc
Posted this video already a couple of times, but you can see how it’s done in Vray:
TL;DR: Having Cycles AO node would allow very powerful procedural texturing in Blender without need for pre-baking, lp+hp overhead. What SD does is simply complimentary.
I totally agree with you!
But I would like a better curvature node because the one we have is really limited.
Then you’d only integrate Substance into a standalone Cycles, but not into Blender.
Is this really so hard to understand? Blender is GPL licensed. Anything that goes into Blender, via direct build or add-on, must be compatible with the GPL.
I think there would be a lot of benefit in having Substance Designer like nodes system in Blender. Cycles is real time; memory and GPU constrained. You can’t always fit the entire scene into a memory, have too much data and make everything really slow. Which is why you need baking. Many procedural texturing workflows can be very CPU intensive, and can’t be done inside Cycles.
Of course, if it was easy to just bake parts of the Cycles node system and insert it back as textures (as in point to a node and click one button), that would help a lot.
Also my pet peeve of Blender having texturing nodes duplicated functionality in compositor and materials. I’d much prefer a united textures workflow that was easily extendable. You could have all: compositor, materials and textures use same texture nodes. Maybe there’s a programming gotcha there that I’m not aware of, might be. Considering the DRY principle, this just irks me.
From an indie gamedev point of view both Cycles and the compositor are mostly useless, and the texturing workflow is really lacking. There are many powerful texturing functionalities but they are either locked behind the compositor or Cycles.
It’s not really something that’s an issue for me at the moment (at all), as I just import the models to Substance Painter. It used to be, when I was just using Blender.
My 2c FWIW.
P.S. I like GPL
Are you sure about that? My understanding is the graph IS rasterized during render startup, since the Substance engine isn’t fast enough to be run on every shader call.
That’s the way it works in all game engines. I would be surprised if it was different for the non-realtime renderers.
Now that I think about it, it has to work that way. The Substance plugins are for 3D apps (ex, Substance for Maya) rather than for renderers (ex, Substance for Arnold)
I have to agree with DrVertice here, while the essentials (theoretically) allow you do anything if you’re good at crafting things by hand. The utility of tools and features that allow you to add many times the detail and complexity with only a small fraction of the work cannot be understated or dismissed.
Also to note, there are things that even an experienced artist can find difficult to do. Texturing software also allows you to create tons of little details using algorithms (details that might be missed if you did everything by hand).
Comments like this do disservice to Blender as a whole.
1 Like
Also you can already convert substances to PBR(and others) images via Substance Player. It’s free and supports up to 4096 resolution, you just need a substance to use with it. You can tweak and adjust all of the procedural knobs and levers with it to your liking too.
Yes, I can admit if I made an error. I did come across as too quickly dismissing Substance Painter’s methodology. It was not my intention to force any particular method of texturing — I was merely pointing out that their dependency on layered procedural texturing is over-complicating texturing. It can slows down rendering.
3D is a very complex field, with many research areas. Why complicate things further?!
My intention is simply to employ the simpler approach — of course, apologies for my overly direct statements. Everyone has their own take to texturing. I like to keep it fast & simple because I want to use it for Games, which require efficiency. I realize not everyone aims towards Gaming, where slower render times in Animation is acceptable.