I was recently dealing with some mocap animation data, and noticed that the interactivity and playback were super slow. I thought it was just lots of data, but the exact same data in maya plays back ~15 times faster.

What gives?
I cannot accept that houdini's graphics is 15 times slower than maya's. That would be an epic fail and embarrassing beyond belief.

Can you upload the file please - it's much harder to diagnose without raw data. Thanks!

Houdini has never been good at dealing with playback of thousands of discrete objects (bones, in this case), though it has improved slightly in the last few years. We do have plans to address this in a future release.

MartybNz
Can you upload the file please - it's much harder to diagnose without raw data. Thanks!

the houdini file is too large for the forum ( much bigger than 5Mb ) and would not compress below the limit, or I would have.

twod
Houdini has never been good at dealing with playback of thousands of discrete objects (bones, in this case), though it has improved slightly in the last few years. We do have plans to address this in a future release.

there are 880 objects in the scene: 248 bones and 632 nulls
less than 1 thousand, not “thousands”

according to the performance monitor, ~64% of the time used is for the viewport, ~26% is unaccounted, and ~9% to cook the nodes

I was already aware that houdini was slower, but 15x slower is pretty extreme.
Which future release is this planned for? and how much of this gap do you think will be closed at that time?

As new Houdini user and a XSI veteran i have some observations about viewport performance on deformed polygonal objects.

1. a simple deformer applied to poly objects is slower on Houdini than XSI (ICE and NON-ICE). (appearly the deformer internally is faster in Houdini, but when need show the result to viewport the slowdown occur) (my theory is about normals update on OpenGL on Houdini is pretty slow).

2. When importing animated bgeo of deformed polygonal objects is much slower than than same using ALEMBIC animated geometry. (except Alembic in Houdini primitives modes)

3. Even when using CACHE node on Houdini to force all deformation reside on RAM, the viewport for poly animated objs is slow than Alembic node.

it´s very weird, because Cache and Bgeo are native code of Houdini.

the similar slowdown behavior in XSI occur when animated poly obj have Polygon Discontinuity set to 0 degree or Non-Automatic. changing this speedup viewport on deformed geo dramatically.


I´m planning some test scenes with identical deformers/geometries to better compare, and will put in a video.

Anyway, Houdini is fantastic, and very flexible…(light years from any other) but with some optimizations on normals/polys/viewport will be even more fantastic.

UPDATE:

after some test, my theory about normals slowdown maybe wrong, because even showing objects in wireframe the framerate not change… maybe bottleneck is in put all this in OpenGL…

Malcolm Zaloon
Anyway, Houdini is fantastic, and very flexible…(light years from any other) but with some optimizations on normals/polys/viewport will be even more fantastic.

I agree completely.


Issues like the ridiculous speed difference are among the reasons I hear cited most frequently when explaining a preference for a dominant competitor over houdini. I would love to see houdini become the go-to 3D app for everything, not just simulations.

These are great tests. As always if you can post simplified .hip files and those videos, issues can usually be quickly identified and resolved. Thanks again.

Edit: For larger files can you link to a dropbox or something?

nobodyinparticular
I was already aware that houdini was slower, but 15x slower is pretty extreme.
Which future release is this planned for? and how much of this gap do you think will be closed at that time?

This does happen to be a particularly bad case for Houdini at the moment. I would imagine that the viewport sorting all all bones and control rig pieces into a single render object would fairly dramatically improve performance, as it's the per-object overhead that's taking all the time. Removing that overhead would probably put the viewport draw on par with the cook time.

Bones also draw as regular polygon meshes, so there fairly significant improvements that can be made by specializing the GL drawing of bones.

Bones also have the x-ray flag on by default, and as you can see that takes some time to draw as well.

This is planned for the release after 13.0, whatever that may be called. I don't have a timeline on that but given that H13 just released, it's not just around the corner.

Malcolm Zaloon
after some test, my theory about normals slowdown maybe wrong, because even showing objects in wireframe the framerate not change… maybe bottleneck is in put all this in OpenGL…

It's not the OpenGL side of things, as much as it is SOPs. Currently they don't provide any information as to what has changed in the geometry, merely that the geometry has changed. The viewport has no choice but to redo everything - connectivity, attribute uploads, partitioning, point normal computation, etc. We are looking into making SOPs more viewport-friendly for the next release.

Alembic primitives do provide this information, and you can see the difference this makes. Alembic optimization is still ongoing though, so expect to see better performance in the future (but again, not 13.0).

nobodyinparticular

MartybNz
Can you upload the file please - it's much harder to diagnose without raw data. Thanks!

the houdini file is too large for the forum ( much bigger than 5Mb ) and would not compress below the limit, or I would have.

It would be helpful to send these files into support for benchmarking internally regardless.

Thanks!

twod

nobodyinparticular
Alembic primitives do provide this information, and you can see the difference this makes. Alembic optimization is still ongoing though, so expect to see better performance in the future (but again, not 13.0).

Oh, this really make sense! Thanks for explanation.

But is it possible add some sort of node at end of network to enforce this information (the no change things) to be passed to openGL?

some special node to force this…? or is it possible to build one using VopSop? (workarounds at this time)

Malcolm Zaloon
Oh, this really make sense! Thanks for explanation.

But is it possible add some sort of node at end of network to enforce this information (the no change things) to be passed to openGL?

some special node to force this…? or is it possible to build one using VopSop? (workarounds at this time)

I am not Mark, but I don't think you can do that. It's much lower-level than that.

Yes, unfortunately as pusat mentions it is a fairly low-level change. Were it that easy it would have been done by now

However once this is complete, it should benefit not only the viewport, but cooking as well. SOPs will be able to tell which parts of their inputs have changed, which could enable faster cooking codepaths automatically in some cases. Some of the infrastructure is already there, as I was hoping to have this for H13, but the short dev cycle of H12.5-H13 bumped this to post-H13 work.

twod
Some of the infrastructure is already there, as I was hoping to have this for H13, but the short dev cycle of H12.5-H13 bumped this to post-H13 work.

Well known that the viewport issues are high in the priority of things for the ned release is a relief, because I think it is probably one of the big problems, pretty much of the architecture in Houdini has been changed internally except the viewport and this cause a bottleneck for artist.
SOP cooking has been improved dramatically in the last 2 years, whereas viewport is still behind competition.

i agree.. the viewport almost made me quit houdini and switch to other software at certain parts.

also some of the issues can be very frustrating to new users and make them quit fast.

Doudini
i agree.. the viewport almost made me quit houdini and switch to other software at certain parts.

also some of the issues can be very frustrating to new users and make them quit fast.

Can you expand on this. Which features make ‘them quit fast’ and which viewport areas made you almost quit?

hi marty,
its hard to explain since most of these i got arround now and i'm happy with houdini. I think the most frustrating part was that a lot of times in H12 the selection of points, faces etc. didnt work good. snaping also glitched out sometimes and i usually had to restart houdini until i figured out making a new scene view solves it too. I also must mention that i use a Wacom Tablet and it makes selecting things even harder at some points. I think the wacom support could be better since i dont have problems in other applications.

Here a few other things which still annoy me sometimes today:
-randomly disappearing geometry. (happens more often in H13 to me now)
-Cant select points/faces when zoomed very close. (not sure if fixed) my workaround nowday is to build stuff bigger.
-selection tools behaves differnt on H11 and the opengl view modes. (???)
- if there is a lot of geometry in the scene and i press the right mouse button sometimes it hangs for like 30seconds. (still happening, made me avoid right mouse button)
-H11 viewport is working faster on geforce470 in displaying geometry but has trouble switching views and browsing networks?
-brush selection seams slow with lots of polygons.. (which made me almost never use this its sad since i love this mode of selection in cinema4d and modo. also there is no pressure control for thickness with wacom tablet. )
-in general selection of edges, points etc seems to be buggy sometime.
-sometimes when i have points selected and i template something to snap to points the snap doesnt work on the selected point or templated geometry. (If i make a new scene view it works again)
-sometimes “area select visible geometry only” doesnt work. (again if i make a new scene view in the tabs it works.)
-Also better Wacom Support would be cool. dual display setup doesnt work with 1 tablet.
-Toggle snapping with shift key when using translation/rotation/scale handle in the viewport would be cool.
-3d grid snapping would be awesome too.


sorry for my english!

whoa - that's opposite of my experience on OsX! Everything you write works here that is supported in Gl2 viewport.

Which graphic card, driver and version of Houdini are you using? Thanks!

newest geforce driver. i have a 470. i will soon upgrade to a 700er series with 4gb so i hope that will improve the performance.

when i fire up a new houdini session all the stuff works great.
the right mouse button for example starts to behave weird when i have lots of geometry in the scene. like maybe 50 with each of maybe around 100k polygons. Also the snapping starts to get very slow.

i am using H13 current stable build.

I did some testing with 5mil polygons and also get the slow right mouse button on AMD 7950/OsX It might be worth logging these as bugs in the Support menu at the top of this page.

When do you get disappearing geo?

Thanks!