Hi SESI Tech team,

Greetings
In todays VFX pipeline - Time pressure and “too” much of client's expectation for peanut money has become the norm which makes us- the artists as starving artists and tired. But we don't give up, and we want to be THE BEST and to be on the cutting edge & to impress clients we are forced to look around for “faster design iteration”. BTW I quit Maya because I got tired of starting all over every time when the client asks for changes. Therefore we know Houdini's procedural paradigm is God sent to ease our pain. I remember the interview by our Founder KimDavidson above were the reason they wrote Prism>Houdini.

To me Houdini 15 is amazing (from release 10 onwards speedup & funda change in POPS & DOPs - I salute you guys) sort of complete in terms of Bells and whistles EXCEPT easing our pain in above Scenario.

Its really kind of depressing when some one like Fabric engine or this guy who boasts he is doing - 100x faster than houdini's solver.

https://vimeo.com/146191683 [vimeo.com]
& the first comment & reply
————
Strob 1 week ago
Amazing list of features. Can't wait to try it. I finally just bought Houdini (indie version for only 199$) and still learning it but now I have even more to learn! First I want to try your grain solver in max! And see what bullet can do. So basically you're saying that you grain solver is faster than houdini's one?

Alpha VFX PLUS 1 week ago
Hehe faster doesn't even describe the speed difference our solver is about 100x faster than houdini's solver.
——————–

The saying goes in today's CG tools business is -
'If it is not real then its not real“.

If you ask me this is what we need for Houdini 16 - ”Zero New Features"
BUT all the development resources channelized to make every node on Steroids with GPU Flag - where we could interact, sculpt, sim and render Billions of data - REAL/Close-to-REAL TIME then Houdini would be complete. Am I spoiled and expecting too much like my clients :-( :-)+)

YOU GUYS CAN DO IT :-)

Cheers

100x faster (maybe) but cant handle things like dynamic topology collisions?? … (in the comments)
Things like that is what drove me away from Max and into Houdini.
FumeFX was super fast back in the day, before H11, but it was one part of a giant broken ecosystem. Plugins didnt talk to each other properly and workflows that you wanted to implement were simply impossible.
Houdini gives you a homogeneous ecosystem to build your workflow in. It might be a bit slower than a few plugins here and there but I would take that 1000x over having to go back to 3dsmax to do any FX work.
I would say even with a faster solver like that, a complex shot will get done in Houdini quicker than in Max (plus the 20 plugins you need to get anything done).

The sand,and water sim looks like a bunch of tiny balls jumping around i dont like it

Its just the old bullet solver,try using packed primitives or bulletsop

And people dont use Houdini beacuse speed,you enter in Houdini and you know you will end you work there,no need to jump between programs/plugins

I dont even mention the new distributed thing on Houdini.

Jorge Ivanovich
The sand,and water sim looks like a bunch of tiny balls jumping around with no constraint,imho looks like shit..

Yeah, I thought that when I saw it a week ago too!! If they do some examples like SESI have with their sand and snow looking awesome then I would pay attention.

I remember people ridiculing Maya nCloth and its closed nature, but you cannot fault how fast it evaluates.

Likewise im sure there will be better example of their grains/water sims over time.

To me there is always a trade off between customization, familiarity, accessibility and speed.

With each iteration Houdini gets faster yet maintaining the core principles of open ended features and a very consistent workflow throughout the entire package.

But optimization is something that time and time again people want and you cannot say SESI do not listen. Be it giving users a multi-threaded environment with almost complied level speed in the form of VEX/VOP, handling geoemtry better in the viewport, or take for example the new Precompiled HDA.

These aren't primitive solutions like welding boosters on the side of a rocket just to make it go faster. We all know Houdini is more of a space station with interchangeable multiple modules.


No one should be loyal to a tool, use what is best for the job or what you have access to etc… but be smart, there is nothing wrong in always using something that is reliable/solid while still being a familiar workflow.

Does sims do not come even close to look realistic. Yeah, they collide together, influence each other etc. But it doesn't behave realistic. Might be that by tuning the settings you can achieve realistic simulations - but why wouldn't a company show that instead to make the objects jump all over the place?

http://forums.cgsociety.org/showthread.php?f=59&t=1323651 [forums.cgsociety.org]

Personally I'm not impressed by stability of presented simulations.

McDonalds also serves food 100x quicker than a Michelin 3-star restaurant.

TL;DR: Benchmarks can be handy. Take every one with a grain of salt and insight, regardless of what it says. Let's keep improving Houdini.

It is the (largely unavoidable) nature of any benchmarks that they are generally skewed toward whatever the primary focus of the testing is, regardless of who's doing the benchmarks or what the focus is. It takes a huge, often not worth-while, amount of work to try to make any benchmark “fair”, or even just to determine what it means to be “fair” in a given context.

Houdini, as with just about every other piece of software/hardware, is frequently compared using benchmarks that are skewed against it, not through any nefarious intent, but often because people who are very familiar with some tool will know how to optimize for it and may not know how to optimize as thoroughly for Houdini. The reverse is probably also true in many cases. I'm pretty sure I've seen at least one performance test unfairly skewed heavily in *favour* of Houdini, too, due to mismatched assumptions. I've also seen comparisons that outlined completely legitimate concerns in Houdini. Sometimes, users will report suspiciously slow performance and it will turn out to be due to an easy-to-fix bug or even confusing documentation.

In any case, it's always good to keep improving Houdini's performance, so that there can be an adequate response when these sorts of things come up. Some times, people want fast, approximate results? Great! They should be able to have that. Some times, people want more accurate results? They should be able to have that too. Some improvements require moving mountains or building new ones, so not everything happens overnight, but it's good to keep our feet to the fire, to make sure that the pressure stays pushing forward.

Houdini, as with just about every other piece of software/hardware, is frequently compared using benchmarks that are skewed against it, not through any nefarious intent, but often because people who are very familiar with some tool will know how to optimize for it and may not know how to optimize as thoroughly for Houdini.

I think most remember that one fabric video showing an asset from orbolt, a fence tool then the same in fabric engine. It was pretty unfair comparison and they realized their error and removed it. But the excitement of running faster than houdini is what blinded them i imagine.

Especially for an platform like Houdini where people want to software to improve, education should also be a focused area of improvement. There are many ways to skin a cat but some way are going to be more efficient than others. The more vops, vex wrangle education the better, be it math based or just from a logic standpoint.

And sometimes there are just certain features than run faster or are recommended because of their internal efficiency and only a handful know about it. I'm always told to use bindVOPs instead of parameters but im still not clear on what i should use.

btw in wrting this i found it no excuse to still no know, but thanks to a little searching found the answer

http://forums.odforce.net/topic/17701-is-bind-export-vop-faster-to-use-than-add-attrib-vop/#entry107311 [forums.odforce.net]

This should be in the help because it is very helpful

(although one thing im not sure on, bind vop's are meant to be used in place of parameters especially in use of cached vex code in HDA's but in H15 this doesnt seem to be the case anymore?)

ndickson
Some times, people want fast, approximate results? Great!

Yep! for example Octane Render is not Mantra but it is killer for iterative design with nice AO and shadows, this allows one to pitch and design efficiently. In fact the documentary Meru that I contributed to was just shortlisted for an Oscar and scanline rendering was perfect, no raytracing needed.

As always, perfect is the enemy of good; true artists make use of all tools regardless of what the peanut gallery opines

Well don't be too much excited or depressed when a new plugin like this pretend to do things faster. We'll compare them when they have the same feature set and stability. Right now BulletFX seems quite beta. There's not even a way to continue a sim after stopping it. i did a few FEM test and with other geo than a cube it was exploding and crashing all the time. Now I have some time for learning and testing softwares, but I got Houdini, Houdini engine for max, phoenixFD, max creation graph, lucid physic so a lot to try and when one soft is just crashing all the time I have have to go to the next or I'm loosing my time.

I am now jumping back to Houdini and I noticed that it's very powerful and a well implemented ecosystem but some simple things a re a bit slow. Like I'm playing with procedural noise map and was surprise we can't even see them easily in the viewport and changing parameter in the noise cause quite slow refresh of the render view, while in max most of the time you can see the noise updating in realtime in the viewport and the material preview.

Anyway owning and knowing both apps is the best!

Thanks to every one for sharing your views.
I am seeing all your views after a week because my city was flooded in the recent rain and we were out of power, mobile & network communication. By God's grace we are up now
Well. There is no app out there which can save us like Houdini in terms of versatility to what we can create. Hats off to SESI. Period.
The reason I posted this is I want our Houdini to get better in terms of speed and no one from the battlefield can deny this. I want our developers to know whats going around them or What is coming. There is ALWAYS room for improvement. I would like them to take a look at BulletFX 3.0 and if there is anything that they can take and incorporate in to Houdini then we are all winners.

Thanks again to every one

I think that it's just a matter of time and we will see improved speed in simulations. From my point of view having faster fluids first will be the best option.

MartybNz
McDonalds also serves food 100x quicker than a Michelin 3-star restaurant.

Here is me(hsolomon) back who started this thread 2 years back and I happen to see my own thread accidentally while browsing. Its sometimes amazing/fun/sad how the time/history is progressing.
FabricEngine is closed(My heart goes out for those wonderful guys for the hard work they put especially the key demo guy who created the demos by burning his mid night oil). Good luck guys. I strongly recommend the FabricEngine team to join SideFx and be a part of creating the most advanced CG Tool man kind has ever created.

Houdini 16.5 preview - another tip of iceberg I see.
https://vimeo.com/239828144 [vimeo.com]

SESI, To whom I can compare you to now !!!!!!……..

Goodtimes SESI: