What's Geometry setup shown in the Performance Monitor?

[magneto]

Hi,

When I am doing certain operations (create a grid, transform it), there seem to be a huge discrepancy between how long it takes to cook a node vs the time for Houdini to become responsive again. So when I checked the performance monitor, it shows that the "Geometry setup" is taking 5-10 times the actual cooking of the node.

Is this normal? Is there a way to minimize this?

Although when I checked 12.5 to see if it does the same, I noticed it also had it but instead called "geo-setup", which was even slower, about 4 times slower than Houdini 13's "Geometry setup" time.

So is this actually the time it takes for Houdini to transfer the results to the GFX card for the resulting geometry to be shown in the viewport?

Thanks

[Jason]

I think this be related to many things that get done for the viewport, including the convexing of geometry. You could test this by turning off Convexing in the Display Options and see if it changes.

[magneto]

Thanks, when I turn it off, it's 1.7 times faster than when it was on. I didn't see that option before.

[malexander]

Geometry Setup was renamed from geo-setup for H13, to be a little less techy. It's the process of taking the GU_Detail from the SOP (or DOP/POP/etc) and converting for display in OpenGL. This can mean convexing (as Jason mentioned), point normal generation (if the model lacks normals), polygon collection, generation of all the vertex arrays and at least the processing of the commands to upload them to the GPU (not necessarily including the transfer itself). A fair amount of that process is threaded, but issuing of the GL commands are pretty much single-threaded given the constraints of the API.

If you do turn off Polygon Convexing, note that concave polygons will look wrong. The default geo, ground plane object and most geometry generated by the font SOP will show rendering artifacts. That's why it's on by default; at least if the user turns it off themselves they're less likely to think it's a bug It is helpful for cases where you know the geometry is well behaved, such as if you're lighting or animating pre-modelled geometry. Also, if the geometry is composed of triangles, it won't convex regardless of the setting.

[magneto]

Thanks Mark, that's fair enough. I didn't expect it to be a simple operation Out of curiosity how would you know if the model is made up of triangles though? Do you have a check that goes through all polygons or do you rely on the internal geometry type. For example if it's TriStrip type, etc. I believe Convert SOP has those special types.

Also would the display mode of the viewport have any affect on this geo-setup time? I assume Hidden Lines would take less time than Smooth Wire Shaded?

[malexander]

The benefit of a simpler draw mode really depends on the primitive type you're viewing. For example, polysurfaces don't need to compute N if it's missing for wireframe modes and flat modes, and some attributes can be ignored (like uv). Volumes can avoid the light-baking and volume slicing in wireframe. Others, like curves and primitive spheres, circles and tubes, don't see much benefit at all.

The point range of polygons is determined during the partitioning pass of the detail's primitives. For tristrips and fans it's implicit, though soups, meshes and individual polygons are very easy to query.

[magneto]

Thanks Mark, the viewport is definitely very high-tech