Hey Matt, Spent the afternoon digging a bit. It's really nicely explained in the HDK with examples.
I would start here as SOPs are the beginnings of all things Houdini. http://www.sidefx.com/docs/hdk13.0/_h_d_k__op_basics__sop.html Followed by Houdini Geometry to show the data structure. http://www.sidefx.com/docs/hdk13.0/_h_d_k__geometry__intro.html And Houdini File System for read/write: http://www.sidefx.com/docs/hdk13.0/_h_d_k__f_s.html Look at writing ROPs too as it will let you do sequences of things. Both could work. The way Houdini's geometry work is indeed procedural. By default, the result of the node tree is held in memory. However, every node in SOPs has a lock flag that essentially bakes the result of the nodes into the file. Once a node is locked, everything upstream doesn't matter and it's essentially frozen. This can make for big .hip files so the workflow is to usually write out the data and read it back in as to not evaluate every time. When we write out a .geo or .bgeo file, we're essentially stripping the history away. You can make your node reference Houdini's node path to choose from which point you want to write out. OR, you can connect the node at any part of the tree and just rely on the input to get your data in GU_Details. Doesn't look so scary now that I'm looking at it. Famous last words... :P -Lu On Thu, May 22, 2014 at 4:32 PM, Matt Lind <[email protected]> wrote: > Have you or anybody else tried to write importers/exporters for Houdini? > > We would need to write an importer to migrate Softimage data, and an > exporter to dump data to our game engine. In softimage, evaluating a mesh > is mostly taken care of by the SDK as it evaluates the construction history > and hands you the final result depending where in the stack you ask it to > evaluate. Since Houdini is procedural and doesn't have a concept of a > 'frozen' mesh, how do they handle this? > > > Matt > > > > > > > -----Original Message----- > From: Andy Nicholas [mailto:[email protected]] > Sent: Thursday, May 22, 2014 4:07 PM > To: Matt Lind; [email protected] > Subject: RE: Houdini Weaknesses > > Yep. Just check out Houdini's digital assets (also known as OTL's). > They'll do much of what you need and more. You can hide and lock stuff up > to your heart's content if you need to be protective about functionality or > content. It'll never be fool proof, but you can at least make it hard to > break. > > > > > > On 22 May 2014 at 23:45 Matt Lind <[email protected]> wrote: > > > I think Softimage is OK on that front. Good in some areas, lacking in > others. > > Almost anything we've had to do Softimage got us 80% of the way there > > fairly quickly, but the problem has always been getting that last 20% > > which is often the most critical part. I've probably spent more time > > than I've cared for to work around the lacking points or limitations. > > The lack of open file format and ability to deal with nested models > reliably has been a hindrance. > > Softimage relies too much on top-down cascading propagation and needs > > more support for lateral relationships such as groups and sets to > > establish dependencies. > > > > Basically I've had to come up with a logical design for a pipeline > > that can accommodate the file structures/dependencies of both > > Softimage and our game assets and it hasn't always been easy. Having > > a new environment with different rules would put a fresh spin on the > problem. > > > > > > Matt > > > > > > > > -----Original Message----- > > From: Andy Nicholas [mailto:[email protected]] > > Sent: Thursday, May 22, 2014 2:36 PM > > To: Matt Lind; [email protected] > > Subject: RE: Houdini Weaknesses > > > > God yes. With bells on. > > > > If you think that Softimage is good on that front, you'll fall > > hopelessly in love with Houdini. > > > > A > > > > > > > > > >
