|
Hi Andy,
Thanks for the feedback!
- Can handle lots of objects or
elements and a few things became very much faster in recent
versions (multi-threaded or openCL)
(SI is still is king for sheer high-poly-count on fewer
objects, which includes *tons* of island transforms)
Have a look at packed primitives. You can chunk your geometry into
sections and get excellent performance there along with deferred
rendering.
For island management, then there are workflows that use the
"name" string primitive attribute to differentiate between pieces.
Some SOPs support this (see clustering and fracturing for
example).
Indeed I'm aware of packed prims, and I already agreed with you
there (was in the "Good!" section :P )
Elements seem to be either
inside OR outside, or object level elements (where regular
parenting happens) are almost like separate scenes
Not sure I completely understand your point. I've not had an issue
with referencing data or geometry. You can use the Object Merge
SOP to pull geometry from anywhere though, and you can use
expressions and VEX to pull info from other objects too (although
I'd generally recommend object merging them for clarity). The
convention (as you've probably seen) is to use a Null SOP called
something like "OUT_Geometry" for example, or to use an Output
node, and then reference those from another object. That has the
advantage of being able to insert more nodes before the referenced
node, so you don't have to update all your references.
I know about merge sop, but is it possible to refer to outputs or
elements located in other object level networks?
(or having object level items used as inputs for multiple other
object level networks?)
- ICE equivalence
(personally my biggest gripe)
Wished for one thing, that Vop nets allowed for subnetworks
with custom port names,
This is possible, but you need to create a digital asset to do it.
Kinda painful as a workflow, but it is there.
If that's at-all realistic, as it
would probably involve very systemic changes, like how/when
compilation happens (?)
(to allow time dependancy inside vops, but I don't know)
You can have time dependancy inside VOPs, you just need to use the
Time input from global variables, rather than use $FF inside
expressions.
Thanks, also I think promoting parameters
allows for time dependency?
But I was referring to time dependency as what could prevent
entire processes to be self contained inside a single VOP net.
(or one of the things)
everything (such as different
settings or where to adjust different things) is all over the
place
Yes, it can be, which is why it's crucial to try to be as
organised as possible and work in a consistent way. If there's an
occasion you can't be consistent, then put down a post-it note in
your network to document it for when you or someone else comes
back to the scene.
--- expressions ::
even if often very simple, driving values with more
elaborate procedures,
requires equally more elaborate expressions with
often somewhat cryptic and sensitive syntax
with single or two letter functions that can be easy
to remember for the more common ones like 'F' or 'P',
but otherwise involves having the doc open at all
times.
You get used to it quickly, but you'll probably find you move more
towards Vex, which will make most expressions redundant.
Perhaps I could get used to it, like I could
also get use to C++, but the point was that it's not what I would
want to deal with under tight deadlines (or where I would like to
spend most of my time)
I've done my fair share of scripting, even some quite elaborate
ones, but always commenting the heck out everything and having
extra descriptive variable names to not have to decipher myself
even the next day, but I couldn't say I could decipher half the
scripts I come across, and such things remain quite difficult for
me (as for many artists).
To simply -- say
randomizing something with range that changes in time, is
comparatively quite something,
involving creating attributes (set or bind data) and
float parameters,
then processing these references in _expression_
strings, spread over a couple of nodes...
Yep, completely pain in the ass. Unless you do it in Vex Wrangles,
where it's super simple and fast (highly recommend learning the
basics).
Thanks, I guess simple and fast can be very
relative.
---- and in general,
string references to elements, attributes, or to things
defined in one of the 10 other Xops (all over),
*** following dataflow, (or getting an impression of what
is happenning) can be very -convoluted-.
often requiring great scrutiny or finding
sources of references to discover what different nodes
actually do.
Agreed. There's a definite need for programming-like strategies to
cope, e.g.: Compartmentalise where possible into small blocks of
nodes that do one simple task is a very similar argument to
programmers not writing long functions.
- lots of Cryptic or
non-self-explanatory nomenclature.
Yes, there's a definite learning curve here. Probably not going to
change now as it's so embedded in the software and documenation.
You brought up quite a few other points, but thought I'd just
address those for now as I don't have much time. Feel free to ask
back questions though if you need clarification.
Cheers,
Andy
Again thanks for the pointers Andy!
-J
|
