Hey Andy,
Seems reasonable?
I am not arguing against the creation of a GetArrayMinimum node, I was
just being curious to understand what I was missing (the min() VEX
function always seemed to work for me), so thanks for taking the time
to explain!
In fact I'm now curious to know why the MinVOP wouldn't work on arrays
but unfortunately I don't have access to any of the *Array*VOP nodes
in Houdini 13 so I cannot try it on my end. Does the node errors out
when you connect a single array into the first input? If not, maybe
you can check "View VEX Code" to see what's happening there? Since VOP
compiles directly to VEX, I wouldn't have expected that it'd work in
one case but not the other.
On 30 March 2017 at 15:58, Andy Nicholas <a...@andynicholas.com
<mailto:a...@andynicholas.com>> wrote:
Hi Chris,
Yes, the min() VEX function does indeed work on arrays, but the
Min VOP unfortunately doesn’t.
It works as a good example though. I don’t want to confuse things,
but if we assume for a moment that the Min VOP did actually work
on arrays, I think it wouldn’t be unreasonable to find a way to
expose the functionality better to an artist, as it’s fairly
unusual to have a function that finds the minimum of several
inputs, as well as coping with feeding an array in. Creating a
node called "Get Array Min” that wraps the “Min” VOP, would make
things clearer at a small expense of duplication. Also, if someone
hits Tab and types “Array”, then they get to see all the nodes
that work on arrays include the new “Get Array Min” node. Without
it, they wouldn’t ever see the Min VOP and would risk overlooking
that functionality.
This way of thinking is similar to what SideFX have been doing
with the wrangle SOPs. (For those who don’t know, the Attribute
Wrangle,Vertex Wrangle, Point Wrangle, and Primitive Wrangle are
all exactly the same nodes, just with different presets applied.)
I think this added verbosity of “macro” nodes is okay in
situations where it provides clarity and requires the user to
remember less. Just as long as you don’t end up with a library of
nodes that does nothing but translate the linguistic differences
between Softimage and Houdini, as that wouldn’t really help anyone
in the long run.
But since the Min VOP doesn’t work, I imagine we would just wrap a
VEX snippet calling the min() function and make sure it looks as
similar as possible to the other VOPs. Seems reasonable?
I rarely feel the need for storing arrays in attributes
Yep, arrays aren’t needed that often in attributes, but they’re
essential for some types of operations, e.g. edge relaxing, where
you need to store rest edge lengths. I would imagine that most
people who have used a lot of ICE find it quite comfortable to use
arrays (e.g strands) and are an essential part of their toolkit,
so it makes sense to streamline Houdini's workflow to support it.
Maybe the first thing to do before porting a node/workflow from
Softimage would be to figure out how to do it best in Houdini, as
a way to get more familiar with Houdini's philosophy, and then
balance the pros/cons of each approach.
Exactly. See what I wrote in the first paragraph in my reply to
Jordi yesterday at 20:08 and I think you’ll see we’re thinking on
the same lines. Whatever gets made must feel like a natural
extension of Houdini and be highly compatible with the standard
way of working in Houdini, rather than working against it.
I think there’ll be a lot of back and forth about how nodes are
authored and what expectations we need to have of them, so do get
involved when it moves across to the Google group.
A
On 30 Mar 2017, at 02:09, Christopher Crouzet
<christopher.crou...@gmail.com
<mailto:christopher.crou...@gmail.com>> wrote:
Regarding GetArrayMinimum: there is a min()
<http://www.sidefx.com/docs/houdini/vex/functions/min> function
in VEX, or were you referring to something else?
Note that I'm still using Houdini 13 where support for arrays is
not as extended as in later versions, but I rarely feel the need
for storing arrays in attributes, or even using arrays at all in
my code. An example of exception would be to store the list of
neighbouring indices for the downstream nodes to use, but then
it's likely that putting all the logic in a single monolithic VEX
instead wouldn't be such a bad approach.
Maybe the first thing to do before porting a node/workflow from
Softimage would be to figure out how to do it best in Houdini, as
a way to get more familiar with Houdini's philosophy, and then
balance the pros/cons of each approach.
PS: I personally find it cool to see the list revived with
Houdini discussions!
On 30 March 2017 at 02:10, Jonathan Moore
<jonathan.moo...@gmail.com <mailto:jonathan.moo...@gmail.com>> wrote:
/| BTW, I suspect that many on this list might prefer we move
the discussion elsewhere to stop the off-topic noise. I was
thinking of Google groups being a good option./
//
Sounds like a good idea.
*From:*softimage-boun...@listproc.autodesk.com
<mailto:softimage-boun...@listproc.autodesk.com>
[mailto:softimage-boun...@listproc.autodesk.com
<mailto:softimage-boun...@listproc.autodesk.com>] *On Behalf
Of *Andy Nicholas
*Sent:* 29 March 2017 20:08
*To:* Official Softimage Users Mailing List.
https://groups.google.com/forum/#!forum/xsi_list
<https://groups.google.com/forum/#%21forum/xsi_list>
<softimage@listproc.autodesk.com
<mailto:softimage@listproc.autodesk.com>>
*Subject:* Re: Houdini Digital Assets for Softies
Yep, agreed. I think we can be more ambitious. Rather than
just cloning old workflows, we should use them as inspiration
to improve on. There’s no point precisely duplicating
something if that ends up causing long time Houdini users
confusion because it doesn’t work the way they expect, or if
it adds too much performance overhead just to make it “nice”
from a Softimage point of view. I think it should be about
making Houdini faster, simpler, and easier to use to create
and rapidly prototype effects. That was what we liked so much
about Softimage and ICE after all.
Houdini tends to have big nodes with lots of functionality. I
think we should think about having smaller nodes, with more
singular functionality that is extremely clear. That way, you
don’t have to read the manual each time you put one down.
They should all be VEX expression-able too. I suspect some
sort of convention about how nodes are made will be necessary
in order to provide simplicity through consistency.
How easy all this will be in practice, I don’t know. I
suspect the most important thing to decide on first is what
the problem actually is, before we figure out ways to solve
it. Three key areas for me are:
* Obvious missing VOP functionality (e.g. like the example
that came up earlier: GetArrayMinimum, etc.)
* Extend the POP functionality. I find the current one quite
clunky and hard to do things quickly like manipulating
particle orientation. Ever tried making a particle spin
around it’s local velocity as it travels? It's not quick to
do at all.
* Decide on some typical and frequently used DOP use cases
and figure out ways to set them up simply. E.g. Emit RBD From
Particles.
That’s just off the top of my head, but I’m sure others have
their own ideas and priorities which I’d love to hear. Do
pipe up as well if there’s something you’re keen to help with
or have a strong opinion on. I’m not doing it all myself! ;)
BTW, I suspect that many on this list might prefer we move
the discussion elsewhere to stop the off-topic noise. I was
thinking of Google groups being a good option.
A
On 29 Mar 2017, at 19:30, Jordi Bares
<jordiba...@gmail.com <mailto:jordiba...@gmail.com>> wrote:
Don't you think although the inspiration may be to clone
useful components and tools found in Softimage there is
potentially a much bigger scope?
Not only that, traditional Houdini artists may find these
tools useful too?
I guess what I am trying to say is, Softimage is dead,
let's move on to an even better place rather than hang
around in old memories.
My 2 cents
Jb
Sent from my iPhone
On 29 Mar 2017, at 19:23, Olivier Jeannel
<facialdel...@gmail.com <mailto:facialdel...@gmail.com>>
wrote:
The EOL_lib
or
The KnightsOfNi_lib
2017-03-29 20:05 GMT+02:00 Fabricio Chamon
<xsiml...@gmail.com <mailto:xsiml...@gmail.com>>:
softLib looks good!
Em qua, 29 de mar de 2017 às 18:51, Andy Nicholas
<a...@andynicholas.com
<mailto:a...@andynicholas.com>> escreveu:
haha! :)
Will leave this question hanging tonight in
case anyone else wants
to chime in. Final decision can happen tomorrow.
On 29/03/2017 17:38, Olivier Jeannel
wrote:
Autodesk lib ?
Naaaa too rancorous...
On Wednesday, March 29, 2017, Andy
Nicholas <a...@andynicholas.com
<mailto:a...@andynicholas.com>>
wrote:
I'd probably go with
something like Andy's siLib or
softLib - it's a bit more
obvious what it is. Probably the
latter if it was up to me.
What do you guys think? Any other
suggestions?
On 29/03/2017 17:14, Jonathan Moore
wrote:
I was thinking H20...
On 29 March 2017 at 17:12, Andy
Goehler
<lists.andy.goeh...@gmail.com
<mailto:lists.andy.goeh...@gmail.com>>
wrote:
In
honor of inspiration how about?
• softLib
• siLib
• ICELib
> On Mar 29, 2017, at 6:08
PM, Andy Nicholas
<a...@andynicholas.com
<mailto:a...@andynicholas.com>>
wrote:
>
> Continuing the thread here:
>
> Any suggestions for a name?
> A
>
> On 29/03/2017 17:00, Andy
Nicholas wrote:
>> I'm more than happy to
help. I'm just
unsure how much time I'll be
>> able to devote to this as
I'm pretty
busy with some personal work at
>> the moment.
>>
>> How about I set up
something similar to
Nick's on Github and we go
>> from there?
>>
>> We need a name for it.
Let's start a
new thread on the list and move
>> discussions over to that.
Is that okay?
>>
>> A
>
> ------
> Softimage Mailing List.
> To unsubscribe, send a mail
to
softimage-requ...@listproc.autodesk.com
<mailto:softimage-requ...@listproc.autodesk.com>
with "unsubscribe" in the
subject, and reply to
confirm.
------
Softimage Mailing List.
To unsubscribe, send a mail
to
softimage-requ...@listproc.autodesk.com
<mailto:softimage-requ...@listproc.autodesk.com>
with "unsubscribe" in the
subject, and reply to
confirm.
------
Softimage Mailing List.
To unsubscribe, send a mail
tosoftimage-requ...@listproc.autodesk.com
<mailto:softimage-requ...@listproc.autodesk.com>
with "unsubscribe" in the subject, and reply to confirm.
------
Softimage Mailing List.
To unsubscribe, send a mail
tosoftimage-requ...@listproc.autodesk.com
<mailto:softimage-requ...@listproc.autodesk.com> with
"unsubscribe" in the subject, and reply to confirm.
------ Softimage Mailing List. To
unsubscribe, send a mail to
softimage-requ...@listproc.autodesk.com
<mailto:softimage-requ...@listproc.autodesk.com>
with "unsubscribe" in the subject, and reply
to confirm.
------ Softimage Mailing List. To unsubscribe,
send a mail to
softimage-requ...@listproc.autodesk.com
<mailto:softimage-requ...@listproc.autodesk.com>
with "unsubscribe" in the subject, and reply to
confirm.
------ Softimage Mailing List. To unsubscribe, send a
mail to softimage-requ...@listproc.autodesk.com
<mailto:softimage-requ...@listproc.autodesk.com> with
"unsubscribe" in the subject, and reply to confirm.
------ Softimage Mailing List. To unsubscribe, send a
mail to softimage-requ...@listproc.autodesk.com
<mailto:softimage-requ...@listproc.autodesk.com> with
"unsubscribe" in the subject, and reply to confirm.
------ Softimage Mailing List. To unsubscribe, send a mail to
softimage-requ...@listproc.autodesk.com
<mailto:softimage-requ...@listproc.autodesk.com> with
"unsubscribe" in the subject, and reply to confirm.
--
Christopher Crouzet /https://christophercrouzet.com/
<https://christophercrouzet.com/>
------ Softimage Mailing List. To unsubscribe, send a mail to
softimage-requ...@listproc.autodesk.com
<mailto:softimage-requ...@listproc.autodesk.com> with
"unsubscribe" in the subject, and reply to confirm.
------ Softimage Mailing List. To unsubscribe, send a mail to
softimage-requ...@listproc.autodesk.com
<mailto:softimage-requ...@listproc.autodesk.com> with
"unsubscribe" in the subject, and reply to confirm.
--
Christopher Crouzet /https://christophercrouzet.com/
------
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with
"unsubscribe" in the subject, and reply to confirm.
