I don't remember how many times I have been explaining people how good is Houdini's procedural approach for rigging.
It's a pity that SESI couldn't put more resources into the characters toolset, I remember explaining some rigs at The Mill some years ago, good times Jordi, to SI TDs and they were really impressed, as many people in our industry though Houdini was only used for particles.
One thing I'm pretty sure, the next release will have serious improvements in the animation/rigging area, and this new wave of users interested about Houdini is going to be great to encourage SESI.

It is great to see all of this interest from SI users into Houdini.
I think there is going to be a great sinergy between these communities.
SI users are going to be surprised about how well Houdini can do in areas where it is less kown like lighting and animation.
In FX it just rocks.
And for the Houdini community and SESI it is going to be great to have the input from users coming from one of the best well designed tool. SI excels Houdini in many concepts specially user-interaction when working from the viewport, this is for me now the weakest area in Houdini.
If something is stopping Houdini to be more accepted in other parts of the pipeline is the viewport interaction.
So well, let's help each other to have a better tool

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.

pberto
So, no “one shader to rule them all”: there is no single BxDF to handle everything. You do need a general purpose + multiple specialized shaders, using different bxdfs, and each of them depends on its own parametrization / UI / UX.
P

Mmm I believe this is the same thing I put in my previous post.
Anyway I don't want to begin a flameware between specialised vs über shaders, this has been discussed many times before.

Well it is mostly a trade off between performance and usability.
Performance has been increased a lot in last years with improvements in shader compilers, so a well designed uber shader performs quite well compared
with a specialed one. Always talking about the usual scenario.
But the difference in usability is huge, lighters only need one
Swiss army shader, don't need to learn something new for every show,
this makes a big difference in artist time which more expensive
than machine time.
You also don't need a big shading department just a few people
manteining the core shaders for the studio.
The pipeline is simpler and tackle buggy shots is much simpler
because you don't have to deal with a collection of shaders.
So basically the total gain in work time is so big that is more
Important than any small under performance done by a more
generic shader.
The only area where you need spesialised shaders is in FX,
to make some lighting trickery or if you are rendering some
particular surfaces like human skin or hair.

MartybNz

lisux
The times for specialized shaders has passed, it is time for powerful uber shaders.

How much quicker is it use these uber shaders?

I have the same convesation with the guys from SESI a couple of weeks ago, I am sure you too jordi, and I think is an area where customers and users needs to ask to Side FX for solutions/improvements.
Thanks to the improvements and maturity of Mantra it is becoming a more accepted solution in many studios, more and more lighters are beggining to use it and this arise the problem of usability and solutions tailored for this part of the production.
Not lighting for FX but for the whole lighting department which is a different thing.
Many improvement are coming in this area with H13 but we got the point where the VEX architecture has it limitations.
VEX is a beatiful solution, one language and context to modify them all.
But well, for look development you need something different.
I love Lightwave approach, the concept of surfaces as uber shaders assigned to your objects, how ramps, textures and procedurals are integreated are great for artist. And the layering of materials similar to photoshop layers is also good.
How something like this could be integrated in Houdini is a different history, but it is definitely something SESI needs to look at, if they want Mantra to be more widely adopted.
The times for specialized shaders has passed, it is time for powerful uber shaders.

jordibares
From the point of view of FX I understand your point, you need the flexibility to bend it backwards.

But the important argument and the reason I am putting a bit of time writing this is because;

I should be able to, I should not be forced to

which is the kind of thing I feel Sidefx are embracing (thanks) and the kind of thing all the new users come to expect and demand.

It is not I want anyone to remove the possibility of getting your hands dirty, is that I really feel I should not battle away little tiny things any simple 3rd rate 3D package does out of the box and Houdini does not.

We have a great tool, great render engine, sub-standard material/shader set, not much to ask I think to improve that by providing, like Arnold, a solid standard shader and utility shader that get us to produce much faster and better, something that I am sure the community will appreciate as suddenly the user base will grow and flourish.

If SideFX does not, a lot of people will take the “foolish” decision that makes economic and practical sense at the expense of everything else and you know what? it won't be the end of the world as for the last 20 years has been constantly proved.

Let's never forget VHS won against BETACAM please

jb

ndickson
Oh man, I long for the day that someone figures out how to fix Cookie, but this one's just sad, because operating on polygon lines should be the second-simplest case, after operating on disconnected points, which also don't seem to be supported. Unlike with closed polygons, there'd be no complicated reconnection needed after, or handling of holes, etc. Someday…

+1
The Cookie SOP really need some love.

MartybNz
Interesting; sounds like a pipeline built ‘top-down’, the render considered first and plugging components into it. I wonder how ‘bottom-up’ pipelines look different, where they consider the inputs to be most important.

Which how a pipeline should be designed.
The render engine is the only tool in your chain that needs
to process all the data to deliver the final image to comp.
So yes, better take a decision about the tender engine before
consider any other stage of the pipe later.
And returning to this thread topic.
I don't believe Mantra Surface is so far from Vray or Arnold
“Out of the box shaders”, at least is not the impression
I have after talking with our lighters.
I am not saying it needs to improve, but for me the real problem
Is how you fill the gap between TDs and lighters.
And this basically means that forcing lighters to go into
VOPs to make simple things like adding a new texture map to the material
Is not good. You need an easy way to add simple modifiers to
materials, and leave VOPs only for the hard stuff.
Said that, honestly, I haven't seen mantra shading a major hurdle
in production.

IPython in Houdini would be great, it is such an useful tool
Something like iHython…

Only problem with this workflow, and correct me if I'm wrong,
is that DOPs internally is still using regular volumes to
represent fields or grids.
So it is quite efficient to create the SDF using VDBs but
when they are added to the collision grid they are converted
to regular volumes, loosing most of the benefit of the VEBs.
Which will be great is to have the option to create VDBs
grids in DOPs.
Thanks for the examples.
Cheers

mattebb
Hi, I'm working with carsten.

In the end, it looks like it was just the sheer number of nodes - nothing was ever getting cooked. We need to instantiate hundreds (or perhaps thousands) of HDAs which themselves contain a few other nodes. It turns out though that one of those internal nodes was a moderately complicated VOPSOP, containing ~75 VOP nodes. It seems like these internal VOP nodes also contribute to the total node memory usage budget, so that in the end we were having hundreds of thousands of nodes in total, including all sub children.

To reduce the total number of nodes, we compiled this VOPSOP to a VEX Sop, which reduced our time spent creating, and memory usage, to a third of what it was originally.

Mmmm the buggy Vop Sop again.
I have recently had a vey weird issue with some HDAs that
took a long time to load and after sending it to support seems that
the problem was related to a bug in the Vop Sop operator.
This was in 12.0 and 12.1, seems that 12.5 has improve the situation
but I haven't tried yet.

edward
I think your analogy here is stretching it a bit thin. When SESI started supporting Linux, the overwhelming majority of paying customers were on IRIX. I would argue that the business case of a “free” vs paid UNIX is a lot more compelling than the one of FreeBSD vs Linux here.

Definitely Edward, it is much more easy to convince companies to move away from IRIX to Linux than to Linux to FreeBSD.
But when the first Linux version of houdini come out some years ago other software companies were just waiting to see how the markets move, Houdini was one of the first, this is the reason because I put this analogy.
But I also think your understand my points about the problems caused by some decissions that has been done in the Linux ecosystem:
- The way Linux kernel is developed, breaking the ABI and forcing people to recompile the kernel for a lot of very common operations is absurd. This cause a lot of hassel with Nvidia drivers and keep away a lot of companies of doing proper support for their hardware. appart from the GPL problem of course.
- How everything is descentralized. The competition between distros just cause more confussion than good for Linux in my opinion.
- The lack of a back compatibility philosophy across many important areas of the system.

And many others.
don't take me wrong, I love Linux in some ways, I have been using it for the last 12 years I think.
But for me is clear that all of these points cause that Linux has reach it limit in expansion, in cant go any wider than it actual market.(I am not taking about embeded or mobile systems)
It is good for a niche of the server market, and a very specialized sector like our indistry. But even in our industry I have heard a lot of times developers blaming Linux because all of these.
It is so easy to develope in more stable, consistent environments like windows or macos.
But anyway these area just my thoughts I am sure other people can have good points to refute them.

Alanw
http://bernard.toneplus.com/search/?q=gentoo [bernard.toneplus.com]

Nice link, I have put a comment in Bernard's blog telling that
histories like this one just demonstrates why we shouldn't be
using Linux.
Again is not a long term solution.
I built Debian systems running several apps in a chroot environment.
And yes I made them working but then I found problems with X
system, later with the window manager, a long list of small
but annoying issues.
At the bottom it is always the same, every single district uses
different versions.
Look at the versions numbers of libc and linstdc in Beenard's epic
history.
It is not only that redhat picks up a version of libc different than
Debian for instances. They also applies their own selection. Of
patches onto it.
Too much for me .

Alanw
If you end up using Linux, I'd recommend Gentoo, Funtoo, or even Sabayon. All of them can use, or do use portage, which is very similar to the BSD style ports system for package management. Gentoo is also a very hands-on distro that you can customize until your hearts content. (including the use of clang to build a majority of the system if you want)

And then sooner or later you will have issues with the libc version not talking about the infamous libstdc in Linux …
At the end you will end up using RedHat (Fedora, CentOS).
Is the only way to ensure you use the correct libraries versions.
And because Linux distros and linux kernel developers enjoys so much to break the ABI and done keep backward compatibility it is really hard in the long term to use a different distro.
I love how Linux distros makes users lives so easy
If we would only have a standar ….

Delight0092
Are you listening SESI!

Well I don't think this is the best way to talk to somebody.
SESI is not blind but they can't go against the whole industry.
At some point Linux beat FreeBSD and won the popularity battle.
It is a pity because all of us suffer the lack of a centralized and coordinated development in the Linux world.
It is a real problem for any industry to depend on a system ecosystem like the linux one.
Well more or less all studios adopted RedHat as the facto standard.
I still think FreeBSD is much better crafted system then Fedora or CentOS, which what studios really use.
What I am saying is that in the same way SESI make a remarkable movement soem years ago supproting Linux as a growing platform, nowdays I think the professional UNIX should FreeBSD rather than Linux.
By professional I just mean used for production work.
Would be great if SESI make this step and try to convince other palyers in this industry to make the move.
The other UNIX used in our industry is MacOS, and definitely FreeBSD is closer to Darwin than to GNU/Linux, so I think it is much better for all software developers to mainly work for BSD platforms.

Well, this is interesting, I was thinking exactly the same thing
the other day.
How good would be to have BSD the standard unix for our
industry rather than Linux.
Pretty much all the points where Linux is weak, and the reason
because it would never be a system for the masses, are
the points that BSD has solved.
Still being open it lacks fromf ragmentation, the development
cycle is much more predictable, always trying to keep
back compatibility.
Well the reasons because Linux is more or less a
nightmare to mantein and develop for, specially for proprietary
software companies like SESI.
So yes please make the move with an unofficial build to BSD
somebody needs to start to show the path away from Linux
to a better open platform like FreeBSD.

Congrats!
Another well deserved award.
Keep the good job.

This is looking really promising.
Looking for new videos.
How the solver scales, I mean with much more particles?
Great stuff!

twod
Apple is choosing the “all or nothing” approach, it seems.

As usual Apple making life easier for OpenGL developers.
Well, for me is much more important that Houdini runs smoothly, without refreshing problems, with popup menues that draw correctly, etc … rather than getting all the bells and whistles of opengl high quality lighting.
Are they updating drivers for both nvidia and amd/ati cards?
Will the nvidia series 8000 cards affected by this update (I think this will be too much for Apple)
And finally any performance test compared with previous drivers version?
Thanks twod, these info is really appreciated.

twod

Talking about this, it is supposed Lion will support opengl 3.2, if this is truth then most of houdini opengl capabilities should work in Lion.

From what I've seen, the last remaining issue with Nvidia hardware & OSX has been cleared up on Lion, which was the sole remaining OpenGL difference between OSX and an up-to-date Linux or Windows platform. This will allow High Quality lighting to work in all its glory, which was previously disabled on OSX and Nvidia.

High Quality Lighting has always been working on AMD cards on OSX, however.

This are excellent news twod.
I understand new drivers in Lion enable the needed features to get high quality lighting?
I am wondering if they resolved all the refreshing problems with nvidia cards as well.
I cant believe they are jumping to 3.2 …
Probably one just one day. Mac will have docents drivers.