Ah, I see, understood! :)
On 22/03/2017 09:03, Jonathan Moore wrote:
Andy, I meant nothing more than that last Cheat Sheet was published
back in 2011. I’m sure a bunch of folk would be interested to see what
your 2017 Cheat Sheet looks like. 😊
*From:*[email protected]
[mailto:[email protected]] *On Behalf Of *Andy
Nicholas
*Sent:* 21 March 2017 23:09
*To:* Official Softimage Users Mailing List.
https://groups.google.com/forum/#!forum/xsi_list
<[email protected]>
*Subject:* Re: Random Thoughts about H.
Yep! Still reading :) Here’s the link to the cheat sheet as it didn’t
come through in your email: http://www.andynicholas.com/?p=1344
I think it would be brilliant if he updated his Cheat Sheet for
these post HScript days.
They're expressions, not HScript, or am I misunderstanding what you’re
getting at?
Anyway, if you have suggestions about what you’d find useful from an
updated cheat sheet, then by all means let me know.
I did start looking at making an update, and made a couple of mind
maps breaking down the most popular SOPs and expressions into
categories. I'll can post that when I next get a chance.
A
On 21 Mar 2017, at 19:07, Jonathan Moore
<[email protected] <mailto:[email protected]>> wrote:
I think Andy covered off most stuff. The only thing I can
reiterate is the importance of VEX. I shared a link the other day
to the VEX masterclass with Jeff Wagner and had positive feedback
from other XSI alumni on this list. If you haven’t watched it yet,
you should. It makes sense of many of SideFX’s design decisions.
Ultimately Houdini is an operating system for 3d and becoming
comfortable with VEX and Python within Houdini are mandatory
things. SideFX might like to market Core as a replacement for XSI
but VEX in particular and Python (if you want create portable
assets) are essential ingredients in getting the most out of Houdini.
I came to Houdini with a hackers knowledge of Python scripting and
competent Processing (which I suppose is Java) skills. Never
learnt C++ and I certainly wouldn’t classify myself as a
programmer; and I find I’m comfortable with VEX. Sure I have the
help browser opened permanently on my second browser the check my
function arguments, but I muddle along without pain most of the time.
If Andy’s still reading, I think it would be brilliant if he
updated his Cheat Sheet for these post HScript days. When I was
first learning Houdini it was a huge help. And funnily enough even
though HScript has mostly been discarded, the list of ‘essential’
SOP operators Andy listed back in 2011 are just as relevant in
2017. 😉
*From:*[email protected]
<mailto:[email protected]>[mailto:[email protected]]*On
Behalf Of*Jason S
*Sent:*21 March 2017 18:36
*To:*Official Softimage Users Mailing
List.https://groups.google.com/forum/#!forum/xsi_list
<https://groups.google.com/forum/#%21forum/xsi_list><[email protected]
<mailto:[email protected]>>
*Subject:*Re: Random Thoughts about H.
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
------
Softimage Mailing List.
To unsubscribe, send a mail
[email protected]
<mailto:[email protected]>with "unsubscribe"
in the subject, and reply to confirm.
------
Softimage Mailing List.
To unsubscribe, send a mail to [email protected] with
"unsubscribe" in the subject, and reply to confirm.
------
Softimage Mailing List.
To unsubscribe, send a mail to [email protected] with
"unsubscribe" in the subject, and reply to confirm.
