voted ;-) On Thu, Mar 30, 2017 at 2:08 PM, Christopher Crouzet < [email protected]> wrote:
> Ah, I see. Might be worth submitting a bug to see what they say? > > > > On 30 March 2017 at 18:47, Andy Nicholas <[email protected]> wrote: > >> Hi Chris, >> You get an error saying "Input data type does not match output for input >> 'input1'." I agree with you that it should work. If you look at passing in >> a non-array value, the VEX code looks like it would be perfectly happy >> receiving an array as it just calls "min(parm)". >> >> I figure it must be some sort of validation that's happening at a higher >> level in the Network Editor that's forbidding the array to be hooked up to >> it. >> >> >> >> On 30/03/2017 10:42, Christopher Crouzet wrote: >> >> 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 <[email protected]> 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 < >>> [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]> >>> 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]] *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 < >>>> [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]> 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]> >>>> wrote: >>>> >>>> The EOL_lib >>>> >>>> or >>>> >>>> The KnightsOfNi_lib >>>> >>>> >>>> >>>> 2017-03-29 20:05 GMT+02:00 Fabricio Chamon <[email protected]>: >>>> >>>> softLib looks good! >>>> >>>> >>>> >>>> Em qua, 29 de mar de 2017 às 18:51, Andy Nicholas < >>>> [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]> >>>> >>>> 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]> >>>> >>>> wrote: >>>> >>>> In >>>> >>>> honor of inspiration how about? >>>> >>>> >>>> >>>> >>>> >>>> • softLib >>>> >>>> >>>> • siLib >>>> >>>> >>>> • ICELib >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> > On Mar 29, 2017, at 6:08 PM, Andy Nicholas >>>> >>>> <[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] >>>> odesk.com >>>> >>>> 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. >>>> >>>> >>>> >>>> ------ >>>> >>>> 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. >>>> >>>> ------ 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. >>>> >>>> ------ 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. >>> >>> -- >>> 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. >> >> -- >> 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. >> > > > > -- > 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.
