Blender’s modeling toolkit is really solid honestly. The only thing I can think of right now is the ability to apply modifiers to specific faces/verts of a mesh (without having to create vertex groups all the time)
Also the state of the deformation modifiers is still really weak. Even such a simple fix as adding a “direction axis” to the relevant modifiers would do a lot to improve the usability of them. Not having to either rotate the mesh in edit mode or add a null object just to fix the rotation would be wonderful, I’ve wanted that for years.
Such a request can’t be fulfilled because of the GPL.
In the same way, you can just forget about ever working with the Houdini Engine and the Fabric Engine (at least in a manner that is fast, intuitive, feels well integrated, and doesn’t require a custom build). The only way to have things that are similar would be to find a dev. who can develop a custom solution just for Blender (as the alternative method of liberating the Blender code from its license is just about impossible).
As for what is missing from my perspective, most of what I want to see in Blender is either in the planning stages or is being worked on (though it would be good to find someone who can actually make particle and modifier nodes a reality).
Only if you try to implement sbar file support within blender; a “converter tool” which has MIT license can be used to process a *.sbar or *.sbs library which converts the data to a node group cycles can use (maybe using python script to generate it).
The algorithms which create the textures are closed source. The same is true for the file formats. From a practical point of view, the suggested “convert tool” doesn’t seem to be a realistic goal.
animation layers… would be very useful!
maya has built in fk ik switching since 2016… not essential as you can work around with dingo legs style setups but very nice to have by default!
constraints are often a pain and using offfset mode has hoops to jump through…
otherwise blender is already pretty damn good with unreal!
For sure there are lots of things that are clunkier than they need to be in a gamespipeline but most things are possible!
What I suggested doesn’t have to do anything with the substance designer nodes or sbar file structure. Allegorithmic can build the converter tool as closed source by themselves or with collaboration with the Blender developers. The converter would be a kind of “sbar reader” which outputs baked textures (for tiled textures and generators) and material nodes for cycles as python script or similar. The license of the “converter tool” doesn’t have to be MIT; all that is needed is an exclusive agreement with Allegorithmic and a blender developer with commit rights.
This same method is used in the game engines where substance is supported; where the engine reads sbar file output and creates shaders and assigns corresponding textures.
sbs files are source files which require processing, for example from substance designer. Sbar files are archive files which are probably coverted to binary which require only reading.
Sorry because I’m new to some things in Blender, I though Blender has animation layers, so you can make an animation and correct poses using layers over that animation, that is not possible?
Dont want to turn this into a substance-blender solution thread… but what you wrote applies if you implement the sbar file reading through an interface with or without external libraries. What I was suggesting was using an middleware program which has compatible license for both proprietary and FOSS programs.
Libraries and interface would be used on the middleware tool > “Sbar Reader / Converter”
Then the middle ware would either use a connector python plugin for blender to send/update the info to blender/cycles or alternatively another system like OSL to generate the data in blender/cycles.
Edit: From what info I could gather the issue is more about practicality and preference. Nobody wants to build and manage a 3rd party tool just to support blender. Allegorithmic doesn’t care because you can still bake the materials and use the textures directly in cycles and Blender doesn’t care because substance tools are all proprietary software which is not their responsibility…
I can understand that the developers are not lining up for this task. Even if there would be a lot of technical challenges in such an integration, the main ones would clearly be to sort out and manage the legal side of it. The decisions could not be made on a technical level, but would need to be approved by a lawyer. That sounds like a dream come true for developers!
Well according to the developer the only legal way would be to write a python plugin that calls some kind of command line interface (or other ways of non-linked inter process communication) and it would be to slow. Such a plugin wouldn’t be worth the effort, if it doesn’t hit some kind of realtime requirements. The non realtime way of just baking to the textures in Substance Designer (or Substance Player) works with Blender, too. Someone could write a plugin for auto texture-reloading and you have a kind of bridge, too.
Indeed the alegorithmic thread post basically says “nope python is too high level language to pull that off realtime”. So if python is not fast enough for real time a third party program written in a low level language like c or c++ would be both fast enough to run in realtime and will be beneficial in long term since the core implementation would only need to be updated every time substance makes a huge change in sbar file. The connector plugin would then be handling less info; generation of the material structure (node generation) or updating the node tree (which is just updating references). On top of that because Blender has more frequent updates than substance you would mostly only updating the python plugin.
To directly answer question of OP @(for UE modeling)- Blender has everything and more, it’s one of the most efficient modeling apps.
To go along with discussion, when people are talking about APEX or Substance, it does highlight one major limitation - no simple way to use commercial plugins with Blender nor stack features of specialized builds. A basic plugin API could be welcome addition.
Well, I don’t think that a automatic copy of the node tree will ever happen, even without the legal issues. What could happen without the legal issues is some kind of substance node that ouptuts that acts like a texture node or even like a shader. This node would probably expose the parameters of a substance and would bake to a texture everytime something changes. You would probably implement this by giving blender a pointer to the texture, so that it is really fast. But with the legal issues (and a python plugin in general) passing a pointer isn’t possibly. You would end with something like this: The user changes a parameter, a Substance command line interface is called. Substance calculates the image and prints it in the terminal or writes it into a temporary file. The python plugin would read it in and sets the data. I don’t know the internals but probably the data gets copied to get it from python to c. This should be legally possible, but would need some file/output parsing and unneeded copying of the data and would be quite slow.
Exactly what I was trying to say… it may be slow or passable, its hard to know because you might not need to rebuild the tree each time, keeping a list for changed data would speed things up… also it might be directly effected by node pixel size and output size; a material with 256x256 px texture nodes with multiple 2048 x 2048 px output might be faster than 512 x 512 px nodes and 1024 x 1024 px outputs… writing and reading color data from pixels shouldn’t take that long - unless they are compressed. From what I tested in Unity complex substances do take some time to evaluate when you make changes, but it is workable in their version.
Anyway we may never know until some one who is capable and has the time tries it out.
Blender is seriously lacking in the VFX department.
Physics, destruction(fracturing), massive amounts of polygons, volumes, particles, simulation of fluids, smoke, fire, crowds with ragdolls etc…
Basic functionality is there, but none of the systems is stable enough to scale it up into epic proportions. Neither do these systems communicate/interact with each other.
I know that this is expensive and seriously hardcore stuff, but it is what i am mostly interested in.
And this has mostly nothing to do with creating stuff for UE4, so if you want to do that you can ignore my rant completely.
Luca Rood (cloth guy) has hinted he´d like to work full time on physics in Blender. Here´s hoping - that kid is a phenomenon Him and Lukas on physics even? If Lukas hasn´t quit completely, that is…
Mantaflow looks also promising and that fracture build has nice functionality.
But i am currently falling deeply in love with Houdini and if i could transform all of Houdini’s power into Blender i would be a happy man.
So, i would be totally satisfied with a 100% working OpenVDB and Alembic I/O for now.
Him and Lukas on physics even? If Lukas hasn´t quit completely, that is…