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 <[email protected]> > 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 <[email protected] > <mailto:[email protected]>> 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: [email protected] > <mailto:[email protected]> > [mailto:[email protected] > <mailto:[email protected]>] 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/#!forum/xsi_list> > <[email protected] <mailto:[email protected]>> > 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> wrote: > > The EOL_lib > > or > > The KnightsOfNi_lib > > > > 2017-03-29 20:05 GMT+02:00 Fabricio Chamon <[email protected] > <mailto:[email protected]>>: > > softLib looks good! > > > > Em qua, 29 de mar de 2017 às 18:51, Andy Nicholas <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> > > 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 <[email protected] <mailto:[email protected]>> > > wrote: > > > In > > honor of inspiration how about? > > > > > > • softLib > > > • siLib > > > • ICELib > > > > > > > > > > > > On Mar 29, 2017, at 6:08 PM, Andy Nicholas > > <[email protected] <mailto:[email protected]>> > > 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 [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] > <mailto:[email protected]> > > with "unsubscribe" in the subject, and reply to > > confirm. > > > > > > > > > > > > > > > > > > > > > > > ------ > > Softimage Mailing List. > > To unsubscribe, send a mail to [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] > <mailto:[email protected]> with "unsubscribe" in the > subject, and reply to confirm. > > > > > > > ------ > > Softimage Mailing List. > > To unsubscribe, send a mail to [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] > <mailto:[email protected]> with "unsubscribe" in the > subject, and reply to confirm. > > > > ------ > Softimage Mailing List. > To unsubscribe, send a mail to [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] > <mailto:[email protected]> with "unsubscribe" in the > subject, and reply to confirm. > > > > > ------ > Softimage Mailing List. > To unsubscribe, send a mail to [email protected] > <mailto:[email protected]> 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 [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.
