I started working on this custom curve/polyline tool a few weeks ago. I made similar things before for specific generators, namely a cave and a racetrack generator. This time I wanted to create it as a general standalone tool with lots of QoL features that will be used as an input to generator HDAs and would work well with Session Sync in Houdini Engine for a gamedev context. Examples where this could be used would be plants or trees, road networks, house layouts etc. Most of the work is related to the Python Viewer State.
Because it would be hard to explain all the little features and the UI with pictures and text, I decided to make this WIP thread with videos.
If you have any ideas for cool features or feedback in general it would be appreciated. I want to make this tool as universal as possible.
Some awesome features there, Peter - it's looking really promising. Are you planning on adding support for subdivision of those curves? If so, would the end points stick to the initial placement?
I have a similar multi-curve tool on my end that's been incredibly helpful in production. It focuses less on the branching approach that you've taken and more on how to make the curve creation and modification as straight-forward as possible. I was actually thinking of updating the viewer state of mine from H17.5 to make use of all the improvements that have happened since then and submit the result here as well.
As for subdivision support, that is in my backlog of things to add. It doesn't seem overly complex to have some conversion of input position to final position, I could just put a resample node in the network, set it to subdivision and maximum segments to 1 and I'll keep the UUID while getting the new position which I could then read in the viewer state. I see a few big problems though:
If the point is displayed on the subdivided position, the user also expects to place and move points that way. Which also would be really cool but difficult to implement with subdivision.
The difference between a resample with subdivision compared to interpolate is very minimal if it is assumed that the input points should be displayed and interacted with on the output curve. So perhaps, I should just allow interpolation instead of subdivision.
I want to add generic parameter -> attribute support not just for points but also for connections/edges. Meaning each edge will need to be its own primitive. I could of course make it work with interpolating first, then cut it into the right primitives and then assign/transfer the attributes. But it would be weird UI wise to have a smooth curve that consists of multiple primitive chunks.
But I'm prioritizing the generic attribute support and some other features for now. If I have time during the challenge, I'll add it but if not, it'll happen afterwards.
I'll post another update video tomorrow, hopefully with the generic attributes working :S
Ahoy, sorry for not actually posting an update last weekend, I ran into a huge wall trying to get the custom parms to work. Basically I tried by having a multiparm on each point, containing the custom parm values. All the multiparms completely tanked UI and viewport performance and basically made it unusable. But now with a different approach it is working, so here's the update video:
Again, if you have any suggestions or feedback, please tell me!
Thanks Ziboo! I'm using the multiparm to store the input from the user, a python node in the subnet then creates the attributes from that data. So I'm not sure I understand the question correctly but in the output of the node, the parm values will be on the points as attributes.
Peter_Prickarz Thanks Ziboo! I'm using the multiparm to store the input from the user, a python node in the subnet then creates the attributes from that data. So I'm not sure I understand the question correctly but in the output of the node, the parm values will be on the points as attributes.
Instead of reading from the multiparm and create the geometry based on that, you can store everything on the geo, and then have the UI read from the geo
What I mean is that you could: - create the geometry (points and prims) - Stash the geo - When user change a value, you change it on the points too and update the stash - You can then read the value from the geometry
Like that you don't have to store any values on the multiparm.
Ah, now I understand, thanks! I have never considered that option because I always assumed it wouldn't work with HE but I never actually tried, so maybe it does with a Data parm?! I'll deffo look into it at some point.
