Is it common practice to extend the built-in operators?

[magneto]

For instance a standard operator that does 90% of what you want, but lacks the 10% additional control you need, and it's generic enough that it's reasonable to have this functionality by default.

But instead of writing the same thing from scratch, is it an accepted practice to extend this operator?

Does it make a difference depending on the type of the operator? For instance the Mountain SOP which is written in VEX, vs the Color SOP which is a subnet of other operators, vs some other operator that's written in Python, vs a C++ one?

Also I am not thinking of modifying the actual operator but duplicating it and extending it where Houdini will load the latest version of this operator with the same name, which will be coming from your library. Houdini allows this AFAIK.

Anyone does stuff like this? Or is performance a consideration? I imagine a C++ operator that's extended using some other operators and collapsing them into a subnet to create a new digital asset might slow it down if the added functionality always runs (affects the result).

But I don't see why a VEX operator with your code would be a bottleneck, provided you know what you are doing. For instance adding a new noise type to the Mountain SOP that you implemented in C++, etc.

Thanks

[symek]

I don't see any problem here, except of perhaps pure C++ nodes, which as I suspect will be added in order of its presence in path, not version control/timestamp etc like HDAs (I haven't checked this though), so you'll have inconstant pipeline. HDAs are easy to extent, and yes, you can overwrite built-in by creating new one with the same name, Vex based operators are perhaps the easiest example of that.

The question is what for? This is more a pipeline question, than performance. What will happen if your scene won't find custom otls? Does it safely roll back to standards, or blow up in artist face? Wouldn't it be less confusing for an artists, if studio's tools have all prefixed convention of names? Wouldn't it be easier to maintain these tool sets?

On the other hand I usually replace lights and cameras with extended versions, because it plays nicer with Houdini's shelf tools and such, but I'm pretty sure scenes open fine without them.

[rdg]

But instead of writing the same thing from scratch, is it an accepted practice to extend this operator?

Recycle or die.

<edit>

Sorry I meant to say:

What differentiates Houdini from the rest *is* the option to just extend anything without rebuilding it from scratch.

If you have the resources to rebuild operators to add an additional 10% ...

What ever works for you.

</edit>

Edited January 31, 2012 by rdg

[magneto]

Thanks guys, good replies.

@Symek: That's good question. By having prefixed conventions, do you mean creating new operators with different names?

If the extended operators can't be found, then I suspect a number of things would happen. For instance if you are using some new option in the Mountain SOP, the result would be different. I imagine very rarely it would error out (for operators that do not change topology, etc), unless they reference these in some other place.

Like you said the pipeline is a consideration, although for most of my questions, I am only interested in my own personal setup where I have tons of extra functionality. Kinda like how some people (like me) who customize their apps to a far greater degree.

Btw you said you replace lights and cameras, can you please tell me what you change? I am not sure what you mean by "it plays nicer with the shelf tools". I am probably missing something

Also didn't Peter Quint (I believe) recreate most of the POPs as SOPs? I remember reading something like that here, but not exactly 100%, but thought it was awesome if some people make their own version of the standard operators that are superior.

Edited January 31, 2012 by magneto

[symek]

Thanks guys, good replies.

@Symek: That's good question. By having prefixed conventions, do you mean creating new operators with different names?

I meant, that every tool in, say, Digital Domain is probably named like dd_mountain (saved in dd_mountain_v01.otl)

If the extended operators can't be found, then I suspect a number of things would happen. For instance if you are using some new option in the Mountain SOP, the result would be different. I imagine very rarely it would error out (for operators that do not change topology, etc), unless they reference these in some other place.

Exactly. Something like a modifying attributes may play ok, but the more you add to the tool, the more likely it will break a scene, once roll back to sesi version of it. That's why it needs consideration.

Like you said the pipeline is a consideration, although for most of my questions, I am only interested in my own personal setup where I have tons of extra functionality. Kinda like how some people (like me) who customize their apps to a far greater degree.

Do I need MountianSOP instead of MagnetoMountianSOP

Btw you said you replace lights and cameras, can you please tell me what you change?

colored shadows, cubic shadow maps, light lenses, standard projectors, ies profiles, camera import from custom format and database, OGL HUD display. Things like that.

I am not sure what you mean by "it plays nicer with the shelf tools". I am probably missing something

I meant shelf tools allowing to place light/camera via viewport. Also, scenes created outside studio, when opened here, can access our lights/cameras this way.

Also didn't Peter Quint (I believe) recreate most of the POPs as SOPs?

VopPOPs more likely.

[magneto]

Thanks Symek, I understand what you mean. But wouldn't the same thing have to be considering when creating/using brand new operators? That will also probably blow up when people opening your scene don't have them.

I feel this is similar to how over time you have your additional library/framework where you have a lot of complex stuff very easily, say in some other 3d apps, sdk, and later when you have to code some new plug-ins, it's so much faster for you, than someone else since you have these additional and/or higher level functionality.

That's why at the time, you spend that much time initially at the time, where it pays off in the future several times over, so much that if you take them out, even you ask yourself how you solved a particular thing in your library implementation, since you always took it for granted. After all it's your implementation

Sorry you are right, it must be something like VOP POP's. Recreating all POPs as VOP POPs, right? Anyone else did something like this? I bet you have some uber SymekOperatorLibrary with never-seen-before stuff

[symek]

But wouldn't the same thing have to be considering when creating/using brand new operators? That will also probably blow up when people opening your scene don't have them.

Strictly speaking not. In case of missing node, you exactly know what will happen. Error, and a node returns empty cook. Perhaps I'm overreacting because I had this situation once, when I couldn't even open any scene in a shot after our otl magically disappeared from a path. Annoying. Scenes were crashing on a farm, with no specific message, because the node was there, just in a wrong cut.

[kgoossens]

Something that is also often overlooked is that you can greatly extend the possibilities of the existing node by saving expressions on the nodes as presets. It can save you needing to create digital assets.

[magneto]

That's a great trick kgoossens, thanks. I use expressions all the time too. I was mainly talking about stuff like additional noise algorithms in Mountain SOP, or an alternative coloring in the Color SOP, but yeah with expressions, 99% of the cases are already covered.

@Symek, that's a scary experience. I see what you mean now. In that case though Houdini doesn't really distinguish between operators that are used in the scene with other mechanisms other than names, right?

So if you use your Color SOP in a scene and I open it, Houdini will just looks if there is a Color SOP in my session? I thought there could be other lookups, maybe like versioning, etc.