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