Hi Jason,
That's a good list. My thoughts and suggestions on your issues below:
**- 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).
*Passes*
- there's probably 3 or more ways to set-up 'passes', and all of them
are comparatively excruciating.
Yep. That's a fair comment. Most people have their own preferred method.
It's generally recommend staying away from Takes as a technique to
create passes though, apart from when absolutely necessary.
*- Help!*
- Can be Really bad for browsing reference sections
- Alphabetically sorted flat list of all nodes, all
expression functions or all Vex functions ...
For example :: the 'Inflate', 'Instance', 'IsoOffset'
nodes, all concern very different things.
Yes, the docs really need a lot of work still IMHO and have done for a
while. The documentation for DOPs in particular frequently make me want
to scream at the lack of clarity to what they do and how they're
supposed to be used. It is majorly lacking in context and clear examples.
- Perhaps there is something up with my setup, but help views
seemed very buggy
and (sometimes not always) very slow especially when always
having it open.
Yes, definitely slow. Would highly recommend opening it in an external
browser, and making a bookmark for the local documentation. You'll need
to launch Houdini's help first before the external browser so that it
starts the http service. The port number will vary for each Houdini
version, but the local URL will be something like
http://127.0.0.1:48626/_index
The help does crash regularly (SideFX know about this, and are working
on a fix), so worth bookmarking the online documentation too.
http://www.sidefx.com/docs/houdini/
- *Scene item Tree list *(outliner/Explorer) seems somewhat basic,
Network view is great, but tree lists can be much more optimal for
overviewing hierarchies
and unless I missed a preference(?) H tree view is a flat list of
all object level items without parenting hierarchy representation.
There are various tree views that can appear for selecting objects, etc.
but the main tree view shows all the hierarchy of operators at every
level. It doesn't show object parenting hierarchies (unless you nest
them in subnet works that is). There's no view to show object
hierarchies (unless I've missed something).
*- Inconsistent highlighting and/or viewport element display*
Yep, it can get quite confusing, and I think Houdini gets quite confused
too about the UI state sometimes. Couple of things to remember: 1) if in
doubt hit Escape a few times to get back to a known state. 2) Pressing
and holding space will get you into Viewport mode (a bit like holding S
down in Softimage). So, for example: pressing and holding Space then
pressing "5" will always move you to UV view, regardless of what active
tool you have. Same goes for pressing Space + "f", "g", or "h".
*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.
*Performance*
Yep, cloth is frustratingly slow compared to Syflex, I'm no expert, but
I'd say that it's more flexible in terms of what you can do with it in
Houdini.
*- 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.
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.
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).
---- 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
------
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with
"unsubscribe" in the subject, and reply to confirm.
