While I am working on a houdini project which has 2.4MB size file. After I put a couple of “Primitive” node in a node tree, it makes Houdini slow, which means that it slows the navigation (zoom in/out) in the viewer window and the node window. it could be a real pain if I didn't realize the problem.

“Primitive” node


Is there any other heavy nodes which I have to avoid? Because I use a normal computer with Nvidia Quadro FX1500, it affects my processing time significantly. I still use Houdini Master 8.2.13.

I hope it help someone who use a normal computer, and please advise if you know any other heavy nodes.

Tojam

What parameters did you set in the Primitive SOP? It only adds attributes or changes attributes on the geometry. I wouldn't expect it to slow things done. Could you post your .hip file? Compress it with .zip or .gz first.

I've noticed that on my configuration (Vista 64, 7950, 4GB, 9.1.105) adding a prim Cd attribute slows the 3d viewport down to a crawl on any goemetry heavier then 5K polys.

I can't recall when exactly, but I've had this pop up on early builds of 9.0, it went away for a while, and now it's back.

G

keyframe, please send in an example .bgeo to support, citing the problem so that we can try to reproduce. My fear is that is that it might be video driver related.

I add the Primitive node to color objects for separating it from other objects while modeling, but it makes slow the navigation of the viewport.

Window XP sp2 in a dell computer
Nvidia Quadro FX1500


Thank you,

Tojam

edward
keyframe, please send in an example .bgeo to support, citing the problem so that we can try to reproduce. My fear is that is that it might be video driver related.

This is a very common issue - sometimes its primitive colors which are dreadfully slow, sometimes point colors. I'm sure it is ultimately driver/card related. Running Houdini is like walking a tightrope sometimes.

This is a very common issue - sometimes its primitive colors which are dreadfully slow, sometimes point colors. I'm sure it is ultimately driver/card related. Running Houdini is like walking a tightrope sometimes.

Agreed. Tightrope or not though, it's a little frustrating going back to an older version and discovering that the issue is non existent with the same drivers.

At the end of the day, the net result is reduced interactivity - which is bad any which way you slice it.

I'll package up some sample bgeos an submit to suppose as soon as this coffee does it's thing.

Cheers,

Gene

keyframe
Agreed. Tightrope or not though, it's a little frustrating going back to an older version and discovering that the issue is non existent with the same drivers.

Rest assured that it's not only frustrating for users. I've looked into this problem before, and it doesn't look like we're doing anything particularly silly. Using random vertex colours so that the vertices of a given polygon each have the same colour was roughly 100x faster than using the same random primitive colours, despite both approaches issuing the same number of GL calls. The only difference is in the order those calls are issued, and this difference is so minor that it's difficult to view this as anything other than a driver optimization flaw.

Heya Ondrej,

Thanks for the feedback.

At the risk of being ignorant, is it worth entertaining the idea that “even though a solution is technically correct, it may not be feasible in a production environment?”. In production we are asked to make these kinds of compromises every day.

In other words, if issuing one set of instructions is known to be slower, why not issue a different set of instruction (which are known to run faster, despite them being ‘incorrect’)?

As you know, the use of prim Cd throughout Houdini has been steadily increasing over the years. Particle fluids, SDF visualization, etc. These are all areas that I avoid like the plague at present, because I can't do something as basic as tumble my viewport.

G

If it were as simple as flipping two lines of code, I would have done it already. Unfortunately, implementing such a fix is a bit more involved, given the way our code is structured, and something i absolutely want to avoid as anything less than a last resort.