Is it better to use the Duplicate SOP if you don't need stamping?

[magneto]

Is it micro managing to use the Duplicate SOP if you only want a number of copies based on incremental transformation?

Or does Duplicate SOP exist purely based on historical reasons i.e. before the Copy SOP?

I see a lot of people using the Copy SOP even for the above case, and I feel like the Copy SOP must have more overhead than the Duplicate SOP, purely based on gut feeling

Thanks

[Stalkerx777]

Can't you make some performance test? Why does this bother you so much? .Difference in those SOPs didn't make your sim/render look nicer Use both...

Edited April 22, 2012 by Stalkerx777

[hopbin9]

I think the Duplicate SOP is faster then the Copy SOP because they operate differently. The Duplicate cooks it's input only once and then replicates the data, where as the Copy SOP cooks it's inputs multiple times.

While the two may have the same performance if the Copy SOP has stamping disabled.

[anim]

I wouldn't be so concerned about it

but just be careful that they work a little differently

number of copies in Duplicate SOP means number of new copies/elements, so it results with original + number of copies which is number of copies +1

whereas in Copy SOP, number of copies is total number of resulting elements

performacewise they should be very similar if used within the limits of Duplicate SOP

[Netvudu]

well, if you are going to nitpick so much, "Duplicate" is quite longer in name than "Copy", so you are indeed wasting some of your keyboard life time typing about it

Edited April 22, 2012 by Netvudu

[magneto]

Thanks guys.

I was also thinking the same that maybe without stamping Copy SOP might be similar.

@anim, good insight on the difference between the 2. Another thing that can help is, using Duplicate can make your intentions more clear that you simply wanted to duplicate geometry.

@Netvudu: I only type 2 letters for either of them

[hopbin9]

I think you guys are being a little unfair in regards to the seriousness of the question, as I've worked on a few projects where cooking time at the SOP level greatly impacted the rendering times. Often in those cases, it was knowing that little things in Houdini can make big differences in performance. Had I known that in the first place, would have saved me a lot of time in reverse engineering many SOP networks to figure out where the bottle necks were.

For example, the "Remove NANs" in the Clean SOP is extremely heavy and can slow down a SOP cook time greatly. That option is ON by default, and the manual doesn't warn you that it's heavy. Now that I know this, I always turn it off, as I seem to never need it.

Knowing the difference between Duplicate and Copy might not seem like it matters, but it's not something I want to discover later on in a project as the reason everything is cooking so slowly.

Edited April 22, 2012 by hopbin9

[zarti]

taking this topic and hopbin 's story as good examples , i think SESI did a very good thing on implementing Performance Monitor .

i havent used intensively H12 lately , but during the first days i did , keeping an eye on it was very interestng .. so to speak .

i could see where and how much Hou was working even in miliseconds . thats definitively a great debuging Tool !

--

@hopbin : good to about 'NANs' !

maybe we should build a Usual Suspects list gradually over time in this forum .. with the help of PerfMon .

.. just an idea .

[lukeiamyourfather]

If it bothers you that much use the performance monitor to get some real world numbers. That's probably my favorite features of Houdini 12. Unless the network heavily leverages the Copy or Duplicate SOP nodes I'd expect the differences to be measurable but indiscernable.

Edited April 23, 2012 by lukeiamyourfather