Ah, I see. Might be worth submitting a bug to see what they say?
On 30 March 2017 at 18:47, Andy Nicholas <a...@andynicholas.com> 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 <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. > > > ------ > 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.
