hi, I am trying to create attribute(sFrame) that should save creation frame ($F) of each primitive. so, I am checking if attribute "sFrame" exists or not, and if it does not exist than I am creating it and saving frame number in it. but somehow it gets updated every frame and its value is always current frame and is not locked to initial value.
You need a solver to do that kind of feedback. What you have checks the input for the existence of the attribute, not the previous frame. There is no previous frame. All frames exist independently of each other without a solver to store the previous time step.
jsmack You need a solver to do that kind of feedback. What you have checks the input for the existence of the attribute, not the previous frame. There is no previous frame. All frames exist independently of each other without a solver to store the previous time step.
Thank you for guidance, yes solver did the trick, but still bit confused as why one method works and other don't, if all frames exist independently than nothing should work without solver as nothing should be able to access anything reliably. Sorry i am new to Houdini and it all is bit unintuitive for me right now. Thanks again for help.
tamte Solver (or equivalent) is required only when you want to feed back resulting geometry or data from previous time step
Most sop setups don't require that, meaning that geometry of each time step is independent from any other
But in your case you want to remember the information from previous time steps so solver is one of the ways
Thank you for response , am still learning and i think it all will start making sense once i have more understanding of the software, i have previous knowledge of scripting in 3ds max and c# in unity. so maybe i do have some hardwired concepts about programming, guess i need to approach Houdini with clean slate, and should not go at it with regular programming concepts. still i guess some thing like "memory node" could have helped to store and access data(just a suggestion). but nonetheless you guys are awesome and very helpful for a newbie like me. Thanks again for your time and effort to make me understand the concept.
anujraghav so maybe i do have some hardwired concepts about programming, guess i need to approach Houdini with clean slate, and should not go at it with regular programming concepts.
Thinking about houdini from a programming perspective is one of the best ways to think about Houdini. Although each frame could be considered a separate execution of the 'program' defined by the nodes. In something like Unity, the program is running as a feedback loop by default, where operations change what's in memory after each time step. This behavior can be simulated, (ha!), with a solver sop, and is the basis of all simulations in Houdini.
Thanks, Maybe when i have enough practice with Houdini, I will start getting hold of it. (...It already has) thanks for going out of the way to make things clear. this has helped me a lot.
