new dops and pyrofx in production ??

[Nibbler]

i'm just curious if ANYONE use pyroFx and new dop's stuff in production? don't wanna sound rude but this technology is rather slow, even in low quality, I wanted to test it and have so many project ideas but this speed blocks me;

second, is there ANYONE(exept those who invented it) who really knows what's goin on under the hood in dops and pyroFx, IMO it's SO COMPLICATED

[pclaes]

From March onwards there are a couple of blockbusters coming out that are using some smoke stuff. Some completely custom developed in dops.

It's really not that bad once you get into it, just keep at it and spend some time with it.

[Nibbler]

thanks for info Peter, it's cool what you say about this, but custom stuff sounds like something made stricly for their needs, something like scripting in maya's mel, for individual user i think it's better to stay with particles and render using metaballs + isooffset + volumes + one of the new pyro shaders but new shader could be connected directly with fluids fields like heat or fuel so that part could't be reproduced in pops, right?

also shots for production with fluids should be calculated with big resolutions, i think it's out of reach from this perspective, do you know what's the different in speed is, comparing 32bit linux to 64bit doin'g fluids?

edit

must to mention rigid bodies and cloth are really quite fast and see here many possibilites

Edited January 18, 2010 by Nibbler

[sam.h]

I used the old and the new in production and using upres is sooo much faster. The only bad thing now is that the rendering is much slower with the huge resolutions on the fluids.

[pclaes]

thanks for info Peter, it's cool what you say about this, but custom stuff sounds like something made stricly for their needs, something like scripting in maya's mel, for individual user i think it's better to stay with particles and render using metaballs + isooffset + volumes + one of the new pyro shaders but new shader could be connected directly with fluids fields like heat or fuel so that part could't be reproduced in pops, right?

also shots for production with fluids should be calculated with big resolutions, i think it's out of reach from this perspective, do you know what's the different in speed is, comparing 32bit linux to 64bit doin'g fluids?

Initially tools start out for a specific show, but then they are modified for more general purposes. Staying with particles is still an option in certain scenarios eg. rockettrails -> very long fluid boxes, but by only using particles it is hard to get that swirly rolling motion. On top of that the orientation (and rest position for noise) of your metaballs can often be a problem too. It is often quite hard to get wispy smoke, there are techniques that will allow you to use millions of particles with delayed load, but at that point you are dealing with a lot of data and you are trying to create a volume with particles. ... you might just consider using a volume in the first place.

Also there are other advantages of being in the dops context rather than sops... collisions between particles and objects, potential modification with sopsolver. Adding custom fields to control your fluids. Fluids behave very much like nodes in a compositing software, but then in 3d.

64 bit allows you to use a lot more ram, which is required when uprezzing. Generally a low res does not require more resolution than 100. Speed wise you can partition your fluids over several machines if you have enough batch licenses. This is a bit of a hidden cost, considering each batch license is around $2500 I think.

Rendering does take time, but there are settings that can speed it up. Also the pyroshader can be quite slow, it offers a lot of control, but that comes at a price.

[chumbuk]

second, is there ANYONE(exept those who invented it) who really knows what's goin on under the hood in dops and pyroFx, IMO it's SO COMPLICATED

If you about Pyro asset... The Pyro solver it is modified version of a smoke solver, advanced smoke solver. There are many components inside it, but a main algoritm rather simple. It is compute velocity vector field from temperature and other field, and advect from it. If you have the intrest, I may share a some thinkings and examples, whose explain a logic it's construction.The advantage of such knowledge in comparison with using as example "FumeFX" and "Afterburn" in max, etc., It is а crazy deep customization and design arbitary "look" for your project and the dreams. Microsolvers it's a relatively new staff in houdini, and it is a little slow, but I'm sure it is not for long.

[lisux]

I lioke the flexibility of DOPs, but for fluids and cloth is still really slow, even with custom setups.

Most of the time fluid sims rigs are more or less simple, is not like particle systems, most of the stuff is automatically sone by the solver, just some settings, some objects for sollisions and most of your needs are accomplished. So a faster solver will make the difference. fumeFX can do the 90% of the production work much faster.

It is a pity but is truth.

However I think RBD in DOPs works really well, slower than other (videogames) systems but the sim quality and the collisions are really good.

And the volumetric render, well is not so bad, i think is ok and more flexible than any other solution, but again should be faster to make Houdini more valuable than other solutions.

[bunker]

Pyro fx is not that slow when you have a couple of computers around.

You can easily prototype in low-res and render with a low volume sample setting.

Since Pyro fx is node based and some of the nodes are digital assets, you can dive inside and

have a look at the way it's built and modify it to make it more efficient ( or build your own solver )

It's not that complicated but there is a serious lack of help/tutorials on Dops in general.

Edited November 9, 2010 by bunker

[lisux]

Pyro fx is not that slow when you have a couple of computers around (or a renderfarm since you ask about production)

You can easily prototype in low-res and render with a low volume sample setting.

Since Pyro fx is node based and some of the nodes are digital assets, you can dive inside and

have a look at the way it's built and modify it to make it more efficient ( or build your own solver )

It's not that complicated but there is a serious lack of help/tutorials on Dops in general.

The main point is that you can integrate Dops with everything else in Houdini and you get

a lot more control that "black box solutions" like Maya Fluids or Fume FX.

But feel free to use Fumefx if you want something easier and faster

Man I know all of these, I have been using Houdini for years, and I use it in my day by day job, I can also use a very big renderfarm. And yes I am doing production also, amazing!

Don't try to convice me about the goods of Houdini, is almost the only package I use.

But the thing about speed is a real issue that SESI needs to solve sooner or later.

[junaid]

Lisux I agree with you, but one thinhg I belive in CG is that, the more control you have on certain things the less faster it will be to output the results at first place, because Houdini Dops are node based and give you liberty for creating microsolvers and feeding diffrent type of data and also let you interact diffrent types of simulation with in one network itself, that's why things tends to go slower, its one of those things, renderers like vray tend to attract many people because it gives you beautiful result with in some button clicks and its fair for some studio to use vray beacuse they can't afford to put time and money to run renderman in there pipeline and they also don't need that advance features, I feel its entirely upto what kind of production one invloves in, but yeah I also feel that SESI needs to put some more documentation and some more smarter solution in houdini dops, since they have user base from lower/mid-level to larg-level studios.

Cheers,

Junaid

[Nibbler]

just a quick note from me, discussion is great but i think it's a way how you look at it, so detail_view is the most important thing in dops IMO, one can't change the values in detil_view tree - there are nodes for this job and it's all about data, correct? objects are also type of data, yeah i think for some like me it's sometimes hard to change the way of thinking and that's what make it complicated, it doesn't work like sop editor, data is collected from tree view then send to engine right?

[Fomal]

just a quick note from me, discussion is great but i think it's a way how you look at it, so detail_view is the most important thing in dops IMO, one can't change the values in detil_view tree - there are nodes for this job and it's all about data, correct? objects are also type of data, yeah i think for some like me it's sometimes hard to change the way of thinking and that's what make it complicated, it doesn't work like sop editor, data is collected from tree view then send to engine right?

The details view is very important, since it tracks and displays information about all of your objects. Interaction, position, vel, fields, simulated geometry) It's good to consider your dop environment as one big engine. Objects have data attached to them that get's used by solvers. Most solvers are closed, handling specific data attached to objects. (rbd solver for rbd objects (which are open and easy to modify once you understand the elements involved.), Others open (fluid solvers for example) Different objects can work together once you set up the relationships, and solvers need to handle the interactions between them. For example: a collision relationship between an rbd object and fluid creates a volume representation of the rbd by using a specific field specified in the fluid object, this field is used by the fluid solver to update the velocity field (namely by using the gas build collision mask and gas enforce boundaries microsolvers). The other way around is possible as well, where the pressure field of a fluid can influence the behaviour of an rbd. As a user you simply specify what objects should talk to each other, when and in what fasion. And in that way it is totally different from sops.

Áll objects start out as an empty object and only what data you attach to that object will make it suitable for a certain type of simulation. By giving the user access to such low level information in node form you initially think it's slower to solver, but it also creates the opportunity to speed up your simulations tremendously. By only activating certain objects (or forces per object) when necessary or eliminating all data that does not get used.

This especially applies to fluids since the solver is completely open. But for manipulating the actual process it's good to have a decent understanding of dop data flow and basic physics. There is a lot of information about the way houdini handles it's simulation data in the help. Even the general solvers come with pretty extensive documentation. Let alone the objects or parts that make up an object. The Pyro solver and object are packed with features. By using the right options and understanding the solver you can get decent results and good initial vel fields for further simulation or post processing. I created most examples on a single computer, within a day. As with everything in Houdini it's a matter of coming up with a suitable process. Using sops, dops, pops (or sops and pops within dops ) together. Whatever works.

But above all it triggers people to dive in and investigate. Just the fact that you can use the same data, updated, during a simulation in progress (at whatever interval or time) and modify it for the next timestep is a huge advantage. For only that reason I will never ever use anything else . No matter what time it takes (and yes I do use a farm, so should you. If not, it's houdini, be somewhat clever)

[lisux]

But above all it triggers people to dive in and investigate. Just the fact that you can use the same data, updated, during a simulation in progress (at whatever interval or time) and modify it for the next timestep is a huge advantage. For only that reason I will never ever use anything else . No matter what time it takes (and yes I do use a farm, so should you. If not, it's houdini, be somewhat clever)

Absolutely agree, this is extremely useful

[mightcouldb1]

Well said