How to limit a numeric value by the number of points in the geometry?

[magneto]

I have a Python SOP with some parameters where the artist can specify how many points to deform, but that number should not exceed the number of points in the input geometry.

How can I make it so it can't go past that?

Can I type an expression into the Range field in the parameters tab of the operator type properties dialog?

Or is there a command like evalParm to set a value inside the code so I will have to set it myself if it's over a certain number?

Otherwise internally I cap the value, but the UI still shows the entered value which is not what I want.

Thanks

[hopbin9]

You can't be sure that the number of points on one frame will be the same the next. The param might be valid one frame and invalid the next.

None of the particle POP nodes that worked on point count restrict the value limit. So I think Houdini users understand how your SOP will work.

[magneto]

Thanks hopbin, I didn't know that.

But what happens if you type in values that are way over the limit?

Say your SOP creates a curve using a subset of points in your point cloud, and you only have 10k points and you type 11k, etc.

If I don't limit the UI values then I should limit the value internally otherwise I will run into out of range exceptions. But this should be fine per frame as I assume Houdini will reevaluate the SOP per frame.

[rdg]

But what happens if you type in values that are way over the limit?

It's generally considered a good habit to validate user inputs in your code.

http://www.sidefx.com/docs/houdini11.0/hom/pythonsop

raise hou.NodeError("Invalid parameter settings")

Houdini's help is pretty extensive and worth reading.

Edited January 1, 2012 by rdg

[magneto]

Thanks that makes sense. I glanced through that page before, but not sure if I should flag error state for invalid value ranges.

The SOP I am writing, it will be common to use the value ladder to see the curve being drawn, but if you go over the limit, I want the tool to "cap" the value.

I feel this is in the same spirit of limiting the values using the operator type properties dialog, say for negative values, instead of raising an error flag for the user.

[rdg]

If it's an error, flag it.

If it's no error, don't.

I don't like it if over-engineered SOPs try to be smarter than the user.

[hopbin9]

Parameter ranges should be fixed. It's often more of a pain to handle dynamic ranges and adds little value to the user experience.

Sure, setting a parameter value to 11k might have undesired results, but the same is true if you set the birth rate to something wrong in a particle system.

@rdg raises a good point. Throwing an exception is a good approach, but you have to decide what the correct behavior is. Should the asset produce a null output upon an invalid parameter, or should it produce something close to the desired result?

If you throw an exception, then it's possible that you'll catch the problem during rendering of a sequence and fix it. If you don't throw an exception, you might not know there was a problem until an entire sequence is finished. Another argument is, you have to restart the sequence if there was an error. So there are two sides to the coin.

Finally, look at the time consumed by such a simple thing. Why is it these things always take up so much brain power?

[hopbin9]

Why not just ask for the percentage rather then a fixed point count? Would that be easier?

[magneto]

Well I am asking how to do it, not why, as I know this is not an exceptional case. In general I only throw an exception when the world I model through code is not what I assumed it to be.

POP approach seems to be in line with how I handle this, as hopbin pointed out, so I will handle it on the code side only.

[graham]

My suggestion would be to handle it like the Switch operators: clamp the value internally and raise a hou.NodeWarning at the end of the code stating the value is out of range.

[magneto]

Thanks Graham, Switch SOP behaves just like my SOP. If the value is greater than the number of connections, it uses the last input. The negative values are also prevented via a hard limit on the minimum value.

I will just add a warning, and it will be good.