Sorry for the longish thread, the following was from a few weeks ago ::
Hidden content: [ Show ]Post XSI thoughts
A possible 'plus' side of XSI getting purged (slightly offsetting the gigantic 'minus' side overall and to this day),
-- sometimes it almost seems like the least human-friendly DCC's (Maya, Houdini, and Blender)
each made considerable efforts towards making things more digestible in regards to user interaction stuff,
sometimes it feels like XSI was slightly merged into each of them.
____
Houdini had like viewport modeling tools that auto-added nodes without really having to manage them,
among several other user-interaction features... which do improve (it's arguably still low) user-friendlyness.
____
Maya 'humanisation' braught some transform tools
(like match transforms, and a new simplified parenting type),
and early-on, modeling tools like 'nex' (modeling toolkit) tweak tools, or function like middle clicking menus,
a hotkey for hiding, Camera undos ... perhaps materialX might make material editing better (than horrible Hypershade) ,
and there is like a new ICE (sort of).
But some of Maya's implementations have been better than others,
and for me despite something like Bifrost, most of Maya remains sorely non-procedural in a workable way overall.
Otherwise alot of workflows remain atrocious, it can be really buggy (and frustrating),
and it's definitely a pipeline tool (which is good for sizeable pipelines).
Like I don't know what I would even do with Maya if I didn't have access to a renderfarm,
among other things like internally developped tools and such.
____
C4d probably didn't quite need to be 'humanised',
but like many, I find it has traditionally been somewhat overpriced,
unlike Houdini who seems to be more reasonable with their relative pricing.
Otherwise I don't know much about it's pros or possible limitations.
_______________________
Blender
Blender traditionally also had it's own share of issues in regards to usability,
AND it would sort-of start rattling above 60mph, (and it can definitely still do that).
Yet while Blender was the last to introduce the results of these efforts in their 2.8 release,
Blender's own 'humanisation' was around re-doing (starting over) entire chunks of the UI,
while addressing a bunch of performance issues.
( with some things actually getting slower from 2.79, but (alledgedly) for either higher quality or reliability )
-- most of the commands now have excplicit menu entries,
And practically everything they did, seemed (to many users including me) to be in the right direction,
-- the outliner, is no longer mostly like a 'scene outline viewer',
and while the 2.8 outliner which was already good (enough),
the 2.81 introduced good synchronicity with the viewport, while also supporting shift range selections,
and also introduced a variety of transform and pivot tools, ... and now going on 2.82.
-- no more fixed number of unnamed layers, and collections can share elements,
layering system is quite flexible and complete, weather for general scene layering when working,
or when used as 'renderlayers' being one of the 'better' renderlayer implementations I tried,
suppling many (but not all) of the advantages of XSI passes.
-- you can fumble around it, and figure out how things work just by fumbling with it.
(I find that it qualifies as 'intuitive' and workable for everyday use)
...
_______________
Though not as much as XSI, Blender also has bunch of things or aspects that can make your life easier everyday, ...
-- you can duplicate things with relationships like constraints etc..,
and any links to/from things that are included in the things to duplicate, will be remapped to the new duplicates ......,
otherwise the new duplicates will keep links to/from things they were originally linked-to ......
making duplicating all sorts of rigs/setups a breeze ...... (sigh XSI)
-- you can rename things without worrying about breaking links ....(sigh)
-- you can select points edges faces on any object,
and switching to object-mode to do other things,
and back to edit-mode on the same object will keep all it's selected components .... (sigh)
- you can select stuff, and any property page (except Material node parameters)
will allow editing of similar properties in-context for all selected objects (by pressing ALT while editing parameters)
on the 'fly' without going through spreadsheets, or scripting stuff ( also like c4d .. or UnrealEngine )
In regards to proceduralism,
blender (even in pre-2.8 versions), was already quite procedural to begin-with.
-- The armature 'modifier' (the skinning deformer operator),
just like any modifier, you can put stuff before or after it at will...... (sigh XSI)
-- you can tweak either the original geo shape -or topology-,
or add/remove stuff from rigs without redoing weights or anything...... (sigh)
-- It's possible (especially with some addons)
to get quite far with models while staying procedural... or not ......
( no-where near as much as XSI (sigh) but much more than Maya )
Otherwise...
-- you can easily link Parameters,
(like XSI or Maya)
so for example, linking bone rotations to corrective blendshapes to improve skin deformations is easy.
-- weight painting is good
(like XSI, not like Maya)
-- UV editing and UV unwrapping/pelting is good
while there are still complaints with the UV editor,
it's at least good enough to select edges in the viewport
before (reliably) auto-flattening ('unwrapping') it based on the selected edges,
also for dealing with seems, aligning points, or to proportionally tweak UV points,
.. which is good enough for me
(mostly like XSI ... or Maya when it works)
- Managing Multi UV's is workable
-- Playback rate with a bunch of unique moderately dense characters (tried with 16 with 1 Subdiv level )
was just about the same (if not faster) as similarly populated/dense scenes I've playedback or scrubbed through over time...
in either xsi or Maya actually (WITH parallel eval. which is never like in demos in real scenarios)
speedo_multi
-- Node editor (for materials, and other node views ) is quite good, you can group (compound) nodes,
Expanded nodes show editable parameter values,
easing the process with 'birds eye overviewing', or the act of 'birds eye editing' of settings
it can handle pretty big graphs (though not so much with the 2d compositor),
and although some things could be improved, it is quite workable.
( it's also completely open to custom node views,
I've seen a node-based project-scheduling dependency graphs addon using blender nodes)
_______________
Modeling in Blender
Blender modeling was also one of the things that were already quite decent in pre-2.8 versions.
And although many of the common methods still use destructive operations,
different methods can be used to just as simply work fully procedurally ...
and there are addons that can facilitate full procedural modeling.
-- or to more efficiently manage and work with modifierstack modifiers...
Speedflow (commercial plugin)These addons are specifically for procedural modeling , and brings most (or all?) modifiers into a node based interface,
you can also procedurally move / transform subcomponents based on selections or filtered by volumes,
you can also have 'live' (or sort of live) duplicates that retain connections to base meshes
but remain individually editable (like XSI 'Clones') ....
Sorcar
Svershok
................
-- Booleans are very fast AND very reliable in terms of resulting mesh and normals integrity,
and there's a whole bunch of boolean based 'modeling acceleration' addons,
many of which remain fully procedural.
_______________
For the ICE aspect of blender,
already with the AnimationNodes addon can it cover huge chunks of ICE (chunks of ICE lol)
including getting, somehow processing, and setting any parameters..
it can process object transforms or subcomponents ...
It got faster over time using 'Cython' (compiled python) in a bunch of places,
and while it's still not as fast as ICE (or probably bifrost with arnold) with tons of stuff, ...
... 'EverythingNodes' ( the next new (and official) iteration of animation nodes )
will alledgedly be yet much more efficient with multithreading, and wider in it's scope with points (particles),
dynamic simulations, and quite possibly alot of ... well .. everything.
___
Rigging in blender
'armature' rigs are like subsystems or like little scenes in themselves (maybe a bit like XSI 'models') .
You can set inital positioning/proportions of bones with 'metarig' elements,
which then becomes the skeletton once bound to meshes.
Then sub-elements (bones effectors etc..) are in some ways treated like mesh sub-components,
in 'pose mode' for editing / animation.
( I think these sub-elements are lighter-weight than regular empties (nulls) and have specific custom properties )
Sub-elements can still be easily linked to 'external' elements
(for constraints or expressions and stuff)
Otherwise, Blender's default Rigging workflow and capabilities is quite good
with everything pretty straightforward to begin with,
Official Blender rigging tuts are quite good (in the middle of the playlist)
and there are a TON of others from users.and auto-rigging addons only add on top of this already rather complete and straightforward system.
AutoRig pro___
Animating in Blender seems good,
f-curve editor is good, dopesheet is good
(more or less like XSI)
Speedo
variations, with the front center character anim further tweaked.
___
The viewport can be considered like a very (very) high quality viewport.
Even in plain 'shaded' mode, the viewport can look really good,
and they did a decent job in regards to managing view settings/characteristics like 'xray' etc..
____
Evee (Blender's reatime renderer and viewport shader )
for final renderings, especially if using more advanced lighting/shading features,
Evee can be a tradeoff of worryfreeness in regards to artifacts,
in exchange for very high rendering speeds (in seconds per frame).
So it might take more time to setup and/or process things for everything to look final
such as avoiding screenspace artifacts, dealing with reflections flickers,
perhaps using some good old light and AO trickery,
and visually joining-up 'contact shadows' with 'soft shadows' for area lights...
but when you do, it's like your computer became a renderfarm
(Note that this render was processed to address reflection flickers by merging consecutive frames using optical flow)Brigning most (or all if not more?) of the advantages of Unreal or Unity for VFX (except maybe for RTX raytacing),
except within a descent full DCC, and outputs are fully HDR,
(game engines mostly have everything clamped, not just the outputs, but also internally are many values clamped)
Otherwise you can render specific things with Evee
( like for things that are less realtime artifact prone ),
and render the trickyer things, aspects, or utility AOV's with Cycles.
Also, if you set things up for Evee, it will probably look very similar in Cycles
while if lookdeving exclusively in Cycles, you might need to do things for parity with Evee, particularly for GI.
_____________
Cycles on it's own is a quite decent renderer,
and can for instance render fully noiseless and final sunlit interior animation scenes
wthout using AO tricks or fill lights for GI, also with motion blur and/or DOF ( it doesnt care ),
Part of that can be due to the Cycles Denoiser which is also very good and without too much overhead,
and it's one of the few denoisers around which can survive animation,
( if you have enough general samples to begin with )
and denoising happens per-tile which is great for quick lookdeving with low samples.
Getting to similar outputs with CPU renderers... and some GPU ones (without trickery)...
can otherwise easily go in the hours per frame,
for results that are often barely clean enough to be considered final especially across frames.
As a GPU renderer, it's the only one I've found which you can get away with glowy materials as lights,
and (if you want) to not use portal lights whenever inside, without totally killing rendertime.
This is at least in my own limited tests, I have yet to try with tons of instancing and such.
___
XSI Groups and Passes in Blender
The 'ViewLayer/Collection' system is quite flexible and complete,
the only thing I missed relative to XSI, was per 'renderlayer' render settings,
and overrides of specific parameters also per 'renderlayer'
... and pehaps applying properties to groups (... sigh)
TIPS
To get around missing unique render settings for every 'renderlayer' ,
you can create a linked copy of the scene, name it accordingly (like a pass name),
and the linked scene ( in the same .blend file ) will have it's own render settings.
( instancing scenes is instant even for big scenes, also without any size/memory overhead )
So you can easily have a bunch of these 'scene instances'
to render different renderlayers with different rez.. or samples ...
or with different renderers, like perhaps Evee for environments/sets, and Cycles for characters,
... or for full Evee renders while using Cycles for utility AOVs :
such as raytraced AO, normals, ... or motion vectors for proper evee deformation motionblur etc...
Right now, to render multiple scenes in a .blend file in one go
is through the command line (or some renderfarm manager),
and I'm looking into scripting to do that from the interface. (sigh XSI)
Otherwise to get around missing per-renderlayer overrides (other than materials),
perhaps you could unlink specific stuff from linked scenes (?) ,
to perhaps have these specific things as unique duplicates (?) but I didn't try that yet,
or I think the some of the newest 'library overrides' is specifically made for this stuff..
___________________
Compositing
I can recall comments about the FXtree being fine for slapcomps,
but I personally describe the FXTree as more like an integrated (and full 'Shake level') compositor
( once getting around it's quirks with HDR )
In Blender for compositing arbitrary sources,
you might want to create a new dedicated scene in your .blend file
for the comp to have it's own scene output settings.
But for this type of use, or as a full compositor replacement,
unlike the FXTree, Blender's compositor can more accurately be described as 'fine for slapcomps'
relative to basically any dedicated compositor.
Mostly because it will already start choking with more than an unzoomed screenfull of regular nodes or so,
also because of some things not being optimized at-all, including for simple blurs,
and there is a lack of reformatting/transformation options.
( Blender is a 3d app first and foremost after all )
That being said, or despite these limitations, apart that it can fine for basic comps, full color grading/leveling,
or for quickly checking how output layers/AOV's behave with each other,
it can also be quite useful as a host for a variety of elaborate or 'high-level' 2d post-processing nodes
( a few factory ones, or addons, which can be fast on their own )
-- such as for great-looking lens effects
( accurate, reliable with HDR, and non-cheezy )
-- extra denoising perhaps for some AOVs,
-- or for motionblur using Cycles motion-vectors
( especially for reliable motionblurring of Evee outputs )
And other advantages become apparent when needing to (pre-)post-process,
or reorganize outputs of the current 3d scene.
So BEFORE 3d render ouputs are written to disk, |
you can pre-composite/merge, grade, or otherwise process ouputs,
or you can make new elements out of others with the intent of piping them into their own AOV's in the final EXR's,
or just to rename/re-order AOV's,
so it's super easy to specifically tailor the final multilayered outputs written to disk,
allowing to 'prep' outputs before later compositing these layers in a dedicated compositor.
Directly processing 3d outputs at rendertime is really great,
and in that context, you rarely need much more than a few operations anyways (in regards to performance),
and it's something I always wished was possible in XSI.
_________________
Things I miss from XSI
Despite many great new things in Blender, in soo many ways is it still no XSI.
But then again, what is like XSI (?) ,
and that at least for me (as well as for others I'm sure) has been a big point,
alot has been around getting back to square 1 (one) in regards to basic CG authoring,
and I personally consider XSI to remain the pinnacle of (mostly) worry-free
hiend digital-content creation 'app' in existance today.
Like alot of what blender (and maya in differrent ways) has been trying to get to
( including a TON of little things that make your life easier everyday...
... many of which still aren't anywhere else yet ),
except these 'things' in XSI have been there for YEARS
while typically WAY more 'integrated', solid, and/or 'native' to the host app,
when compared to similar implementations in other apps.
XSI is very -procedural (-WHILE- having very little daily complication overhead),
everything you do is a modifier, and you can have things that come out of other things
and you can have alot of dependancies (while not needing many in the first place)
while remaining managable and editable.
___
In XSI, (also relative to Maya on the simplicity side),
you can literally just do stuff, copy whatever you just did from the log to a script,
( as-is, and just like that )
replace the element references with variables,
and easily redo the same thing 1000 times or otherwise on demand on current selection,...
Blender often implies quite a bit of setup of proper context for various commands to work,
and for example, creating new parameters that is saved with the scene is very involving.
Scripting (and working with the simple command log and selections ) in XSI
makes the most technical part of doing CG a breeze
The XSI SDK is itself actually human-readable,
also with all commands and variable names being super explicit, descriptive and long...
You can otherwise design and hook-up all sorts of UI's very easily,
also with UI 'wizards' that can make their 'magic' very simply...
___
'Good old' SubD's in XSI are incredible, superfast and very 'integrated'.
'Polys' in XSI can inherently act as branchable nurbs surfaces ,
they seemlessly work with any renderer,
and are generally like 'bulletproof' when it comes to having anything thrown at them..
They leave little to be desired relative to a variety of Opensubdiv implementations
including in Maya, Blender, and are entirely issue free,
which I think might be why the amount of control points even for cartoony characters,
are typically more than twice as dense as typical base character mesh density in XSI
(for the same output level of detail)
Relative to blender (and Maya when editing), XSI Subd's are also currently MUCH faster,
( otherwise blender sub-d playback can be fine with 1 Subdiv level with deformations in object mode )
________
Everything user interaction in XSI is still one of the most fluid
especially in regards to switching (and smart auto-switching between) 'modes of operation' ,
especially when modeling... (or whatever.... )
and for the universality of hotkeys in whatever mode you are in, or in whatever pane...
___
Undoing (litterally anything) is MUCH faster than blender (mostly instant)
and everywhere much (MUCH!) more reliable than Maya.
( for Blender undos, they are supposedly working on that,
while undoing certain things already got much faster in recent builds,
and until then, you can use the undo history menu to step back a bunch of steps in one shot,
which is exactly as fast(or as slow) as stepping back one single step),
___
how transformations in general work in XSI (...sigh)
(maya 2020 'biggest' new feature 'offsetParentMatrix'
only slightly reproduces how all relative transformations work -natevely- in XSI, )
___
___
ICE is incredible and superfast with always live feedback, it can permeate the entire app in terms of reach
( works with practically everything in XSI, ...everything which generally already works with everthing else ),
___
anyone still doing things in XSI do so because it remains like production heaven in like a million little ways.
(...sigh XSI)
