jon3de Posted June 4, 2016 Share Posted June 4, 2016 Hi, playing a little with matts branching example http://www.tokeru.com/cgwiki/index.php?title=HoudiniVex#Solver_and_wrangle_for_branching_structures I have a sphere with a custom attrib int @active = 0. I set one point as active and after that a solver with a wrangle for the grow effect. That works fine. But I want to create a setup where I use another obj to set the first points active instead to create them manually. I did that with attribute transfer. So as the solver only runs on "active" points I created another sphere with active points to transfer the attributes. But then the solver works no longer. Thats a little bit confusing to me because I thought for the solver sop has nothing changed. I attached a file for better understanding. I would be thankful for a hint here. kind regards Jon houdini_grow.hipnc Quote Link to comment Share on other sites More sharing options...
mestela Posted June 4, 2016 Share Posted June 4, 2016 If you look inside the solver sop, the answer is in the layout. You're only reading from 'prev_frame'. This means that it only reads from the 'live' geo on the first frame, every other frame is calculated from the previous frame. Because you're keyframing your active value long after the first frame, the solver never sees it. A quick fix is to connect input1 (ie, the live geo) to the 2nd input of your wrangle, and transfer the active attribute before the rest of the vex code: if (@opinput1_active==1) { @active=1; } Attached an example. houdini_grow_fix.hipnc 1 Quote Link to comment Share on other sites More sharing options...
jon3de Posted June 4, 2016 Author Share Posted June 4, 2016 Thank you very much matt, Now it works as desired...admittedly I didn´t get the problem to 100% This "previous Frame" and the different inputs are somehow confusing to me. I fear I do not understand the work of the solver sop good enough so I will go some steps back and give this a try again after some simpler solver examples Quote Link to comment Share on other sites More sharing options...
mestela Posted June 5, 2016 Share Posted June 5, 2016 I know what you mean, it took me a while to get them, even now I usually have to have a few attempts at a solver sop to make it do what i want. I've been working on a longish tutorial, only half done, the rest is sketched out. I'll be sure to add a section about this sort of effect... http://www.tokeru.com/cgwiki/index.php?title=The_solver_sop 1 Quote Link to comment Share on other sites More sharing options...
jon3de Posted June 6, 2016 Author Share Posted June 6, 2016 On 6/4/2016 at 5:25 PM, mestela said: You're only reading from 'prev_frame'. This means that it only reads from the 'live' geo on the first frame, every other frame is calculated from the previous frame. Because you're keyframing your active value long after the first frame, the solver never sees it. Ahh...after some time I think I got it. So is it right that the solver sop gets the data of attributes etc. on the first frame and then works with a "copy" of that data which will never change only if I explicitly tell it to the solver. I think I was not able to understand this to 100% because I thought "Ok but the previous frame has changed attributes" -- "Yes it has, but not in the data which the solver is using at the moment". And that´s it what you do with : if (@opinput1_active==1) { @active=1; } So basically. "Hey Solver because you cant know that the attributes are changing...look at opinput1 ( the live geo ) and check again for all points if the attribute active is "1" before you run the code. And use that for your copy of data" At the beginning I thought the solver works with kind of a life connection with the data all the time. But i guess that its more so that you pass a copy of you data to the solver ( "into dops" ? ) which is then independent from you live data. At least I hope that this is not complete nonsense Quote Link to comment Share on other sites More sharing options...
mestela Posted June 6, 2016 Share Posted June 6, 2016 Yep, that sounds right. I made a special section in that tutorial about this issue just for you. http://www.tokeru.com/cgwiki/index.php?title=The_solver_sop#Reading_attributes_that_aren.27t_from_first_frame_or_previous_frame 2 Quote Link to comment Share on other sites More sharing options...
jon3de Posted June 6, 2016 Author Share Posted June 6, 2016 ha "Reading attributes that arent´t from first frame or previous frame" ....this is awesome. Thank you!! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.