OK. I give up. I've been looking around for the last 2-3 hours to see if I could find a way to attach a vector attribute (rest position) to my volume-based smoke, and have failed miserably… after combing through the docs as well…

If someone could describe the general process of attaching arbitrary attributes (I will need more than rest pos eventually) to the “initial conditions” of a volume, I'd be very grateful. I just need these attributes to advect along with the density, that's all.

TIA.

Making a little headway here…. I think.

It would seem that the only way to do this is to create three separate volumes (VolumeMix), each with $TX, $TY, and $TZ respectively, then merge them and pass the result to a SOPVectorField DOP, which then collapses the three volumes into a single vector field, then ensure that the new field is advected inside the SmokeSolver HDA… and I haven't yet tested to see if this will even make it all the way down to my shader… whew… could we make this a little harder please?

Am I on the right track here? Or am I just missing the magic shelf button that does it all for me?

Hi Mario,

I haven't done this for a while, but yes, 3 volumes are what you need as I recall…

Cheers,

Peter B

Here's a simplified version of a method that JeffL showed me.

Yes. It seems to be working now. Thanks for the confirmation guys.
@PeterR: yes, that's exactly what I ended up doing: 3 volumes imported (and collapsed) via a SOPVectorField DOP.

But I gotta say… this whole process seems unnecessarily painful right now. Now that I understand it better, I'll be able to do it quicker, yes, but “quicker” in this case is still “painfully slow” compared to stomping down an AttributeCreate SOP (or a RestPosition SOP in this particular case).



Adding passive initial state attributes to a volume right now is equivalent to having to define an object's surface attributes as multiple copies of the same object with a single Alpha attribute each, then opening up the IFD and manually collapsing all the copies to a single instance, then renaming and reassembling all the Alpha's to the proper target attributes.

I blame the volume primitive. It just seems too light-weight right now: it's just a scalar field (which I interpret as “a single field object which can only contain a single scalar value per constituent voxel”).
It would be much better, I think, if it could hold any number of attributes (actual Attribute's that can be accessed by the other attribute-related SOPs) per voxel, because then:

1. In SOPs, while preparing the initial state, you'd be able to follow your IsoOffset with any of the existing set of attribute-related SOPs to define all the things you'll need down the line: for the sim, for shading, whatever.

2. In Dops, at the “SmokeConfigure” stage, you'd point an imaginary “SOPAttributeFiled DOP” (instead of the current SOPField DOP pair) to the single SOP from step #1, and enter an attribute mask (instead of the single type-specific “Data Name”) for all the attributes you want accessible to your sim – the system would deduce each attribute's type from its own definition.

The associated visualization streams could also be similarly unified: instead of a separate visualization setting per data, you'd have a single set of visualization parameters for multiple data. On the user side this would mean that, instead of having umpteen “Guide” tabs with about 23 parms each (99% of which are identical from one tab to the other, and each having to be meticulously bubbled up to the top of the HDA), one 23-parm set per data, you'd have a single visualization set of parameters for a single user-defined data name to apply it to (much like the PaintSOP, for example).

By the time we hit the solving stage, things should be able to stay as they are, because all the attribute-to-field mappings would have already occurred during the config stage.

3. At the back end (post simulation), we would have a *single* DOPImport SOP, instead of one per attribute that we wish to import. It would just come back with all the attributes we sent it with originally (and only those in the mask of step #2 possibly modified), and we'd just merrily go ahead and use all the attribute tools at our disposal to further modify the outcome if needed (instead of being stuck with only the VolumeMix SOP).

Life would be sooooo much easier this way…

Right now, every additional attribute we may need has to be managed separately (together with its own visualization) all the way down the DOP line – breaking all the top-level “let's make DOPs user-friendly” HDA's, since they can't accommodate (or ever *hope* to accommodate) anything beyond the strict set of attributes they've been designed with, making them very brittle. I mean, who the heck renders smoke/clouds *without* some shader-based noise (and therefore rest positions)??!!!?? – meaning that the SmokeObject and SmokeSolver HDA's break down the moment you actually want to use them. Suddenly you went from using DOPs in blissful ignorance, to “you must know absolutely *everything* there is to know about the Gas-related DOPs *right now* if you want to add your silly rest position”.

Sorry, but it's Friday, and it's late.

Thank you Mario!

I mean, who the heck renders smoke/clouds *without* some shader-based noise (and therefore rest positions)??!!!??

Rest positions should be rigid but in the case of rest volumes they aren't ops:

hoknamahn
Rest positions should be rigid but in the case of rest volumes they aren't ops:

Sorry Hok, I'm not sure I follow. What do you mean by “rest volumes aren't rigid”?

I'm in agreement here, Mario. This is something that should be easy and more logical to set up; and if there was a better backbone architecture to make it so (all of which I agree with too, btw), all the better.

In either case it would be great to be able to initialize texture coordinates at the touch of a button - and/or with a toggle on the Fluid Object DOP, rather than forcing the user to cobble together their own system for this basic need.

Some of my initial advice on fluid simulations to SESI was also to allow each of the fields to be able to be easily configured at different resolutions; so, for example, a low-rez velocity field advecting a high-resolution density field along with a low-rez texture/rest field. I'd still like this as it might help solve some the issues with attempting to get high resolution smoke without paying the dear price of running all the velocity field calcs at high resolution.

Practically speaking, the biggest driving force for needing texture/rest fields to be propagated is really due to the fact that fluid sims are so damn slow at any reasonable resolution. This is mostly symptomatic relief we're going for. This is not going to change soon, I think.

I have some additional suggestions for SESI regarding vorticles and such - which can be related to this… coming soon in another post.

Mario Marengo

hoknamahn
Rest positions should be rigid but in the case of rest volumes they aren't ops:

Sorry Hok, I'm not sure I follow. What do you mean by “rest volumes aren't rigid”?

I mean if you try to advect a rest field by any other field and then use it as a source of coordinates for noise you will get a stretched noise. Is there any voodoo magic allows to avoid this? Advected points could give a very good result but rest volumes is really important question.

hoknamahn
I mean if you try to advect a rest field by any other field and then use it as a source of coordinates for noise you will get a stretched noise. Is there any voodoo magic allows to avoid this?

A typical remedy for this is blend together two fields which are initialized x frames apart from each other. It's not a great solution but lets you get away with some things especially if the blend itself isn't just a straight cross-fade but blends across in a spatially varying manner.

It's really just mashing together a hack on a hack for just long enough to make it work ok for the shot. Our biggest tool is that many shots are only 30-50 frames in length and you can sometimes get away with no extra work.

Jason Iversen
Some of my initial advice on fluid simulations to SESI was also to allow each of the fields to be able to be easily configured at different resolutions; so, for example, a low-rez velocity field advecting a high-resolution density field along with a low-rez texture/rest field.

That would be very helpful indeed. I'm coming up against the same problem: desity field needs mucho resolution, but I could get away with 1/8 that res for the velocity/temperature fields. Multiresolutions would be very nice.

Jason Iversen
Practically speaking, the biggest driving force for needing texture/rest fields to be propagated is really due to the fact that fluid sims are so damn slow at any reasonable resolution. This is mostly symptomatic relief we're going for. This is not going to change soon, I think.

Yup. Sim-solving speeds at division levels that would give me crisp clouds would be simply prohibitive. It's just too slow to be practical. So without shader help, it would be simply useless (at least for what I'm trying to use it now: highly detailed, crisp clouds, not some amorphous smoke).

hoknamahn
I mean if you try to advect a rest field by any other field and then use it as a source of coordinates for noise you will get a stretched noise.

Right, I see what you mean. I haven't tried Jason's method yet, but I think the problem is that you're only defining the rest position for the region where there is non-zero density. Rest position needs to be well defined everywhere in space, much like velocity. So what I ended up doing (which seems to work fine, though I don't know if it's the “best” way to do it), was to make the rest position volumes from a box the same size and location of the sim volume extents (i.e: occupying the same chunk of space, or larger, as the sim volume). Then the rest position is well defined everywhere (not just in the region of the initial smoke).

Otherwise, if you just use an IsoOffset of your “density” object to represent the rest positions, your smoke will be embedded in a field of zero-valued rest positions and as it diffuses it will look like it's stretching (well, it is: stretching to the rest position {0,0,0}).

Here are some results. I hope the attached animated gifs work – they seem to in my browser, but you never know…

jason_iversen

hoknamahn
I mean if you try to advect a rest field by any other field and then use it as a source of coordinates for noise you will get a stretched noise. Is there any voodoo magic allows to avoid this?

A typical remedy for this is blend together two fields which are initialized x frames apart from each other. It's not a great solution but lets you get away with some things especially if the blend itself isn't just a straight cross-fade but blends across in a spatially varying manner.

It's really just mashing together a hack on a hack for just long enough to make it work ok for the shot. Our biggest tool is that many shots are only 30-50 frames in length and you can sometimes get away with no extra work.

Did you mean a blending between two rest position fields? Say rest in frame one with the same rest field in frame… 10?

Mario Marengo
I haven't tried Jason's method yet, but I think the problem is that you're only defining the rest position for the region where there is non-zero density.

Nope. It's well defined in the whole bounding volume. Yes this works for such simple cases like on those gifs but doesn't work for cases when you want to get a “good” distribution of frequencies. Noise tends to stretch in one direction and pull together in other. And there is a big question how to get rotations. Probably better to explain this problem on pictures. Unfortunately I don't have them now. I've tried several approaches. One of them was advecting the points and bake them into i3d texture. The goal was to get a good CS and at the same moment make this stuff faster. But this approach has other limitations. Some time ago (before last Siggraph) I saw a video with demonstration of realtime GPU based volumetric rendering. Guys have used for this stuff a low res volume plus some magic hash for refinements. I don't know what that hash means but that demo was impressive. Probably someone here remember it or even know more about that technique.

hoknamahn
Nope. It's well defined in the whole bounding volume. Yes this works for such simple cases like on those gifs but doesn't work for cases when you want to get a “good” distribution of frequencies. Noise tends to stretch in one direction and pull together in other.

I see. Well, I can't say I've come across that particular problem yet. Have you or Jason been able to determine the exact cause of it (so I can try to steer away from it)? Could it maybe have been a bug in H9 which got fixed in H9.1? Would it be possible to recreate it in a simplified setup that you can post?

Thanks for the heads up Hok. I'll continue to run tests (I can't avoid it since I need to use this stuff for a job) and I'll be on the lookout for stretched/deformed rest noise, but if anyone at SESI already knows about this, please speak up as I wouldn't want to walk into a trap at the eleventh hour.

Thanks.

Mario Marengo

hoknamahn
Nope. It's well defined in the whole bounding volume. Yes this works for such simple cases like on those gifs but doesn't work for cases when you want to get a “good” distribution of frequencies. Noise tends to stretch in one direction and pull together in other.

I see. Well, I can't say I've come across that particular problem yet. Have you or Jason been able to determine the exact cause of it (so I can try to steer away from it)? Could it maybe have been a bug in H9 which got fixed in H9.1? Would it be possible to recreate it in a simplified setup that you can post?

This is rather feature than bug - stretching highly depends on fluid motion because of mixing of different parameters (P, frq, amp and others) inside voxels.

hoknamahn
This is rather feature than bug - stretching highly depends on fluid motion because of mixing of different parameters (P, frq, amp and others) inside voxels.

Hmmm. I personally *want* my smoke to advect and diffuse according to the dynamics of the fluid (stretching, coalescing, dissipating, etc.)… just as long as it's my initial shader-based density distribution that's doing it. That kind of fluid-induced stretching I have no problem with. In fact, I fully desire and expect it – it's kind'a the whole point of the thing.
But if you're also driving fields for the other noise parameters like freq, amp, lac, etc. (especially frequency!), then yeah, I can see how things could get a little… delicate.

Anyhoo. I haven't seen anything objectionable yet at my end so I'm crossing fingers. Still if you have time to post a couple of images or something to show the problem you mention, then I can probably start panicking again

In my experience, the stretching and compression of the texture coordinates become objectionable only after a certain amount of swirling of the smoke. In fact, with smoke it's a lot more forgiving than with liquids. With large scale liquids you use the texture coordinates to add capillary waves (the little wind-generated ones) and if the coordinates stretch even by a factor of 2:1, this looks bad.

So the technique to blend between two leap-frogging texture fields which reset periodically can help. Oh, and I'm not talking about blending the two texture fields to make a third texture field upon which to look up your noise or whatever, it's performing a lookup on *each* texture field and blending the result.

jason_iversen
So the technique to blend between two leap-frogging texture fields which reset periodically can help. Oh, and I'm not talking about blending the two texture fields to make a third texture field upon which to look up your noise or whatever, it's performing a lookup on *each* texture field and blending the result.

Ah, OK. Thankfully I won't need to have my fluid push around recognizable texture features (or rather, nothing that needs to stay recognizable for any significant period of time), so I think I'll be alright on that front. Point taken though, and I'll definitely keep your suggestion in mind if/when I ever need to do so.

Thanks for the explanation! (I finally “get it”… sheesh! )

Mario Marengo
Thanks for the explanation! (I finally “get it”… sheesh! )

Dude, knowing what I know about you, the blame lies entirely on my poor explanation.

Anyone know how to add rest position to a simple IsoOffset volume *without* going through DOPs?
Is it possible?