FXD adaptive region support

[iloura]

Hi

Fairly new to using stoke so this may be an easy one that I’ve missed: I’m converting OpenVDB files from houdini to FXD files for rendering on FumeFX. The data out of houdini is (in fumefx speak) adaptive in that the grid only contains what it needs to and can travel around the scene, and I’d like to convert these to adaptive fume sims, ie for conversion I’d set up the stoke grid to encompass all the action, and it would only write the sub-region grids for the FXD files correctly with all the space savings one would expect.

I’ve tried converting the entire grid area to fxd using Stoke and then post processing in FumeFX with the minimise grid option on, but this doesnt work as fume isn’t tracking the position of the sub-grid correctly - this is a bug I’ll pass on to sitni satni (it’s not Stokes output as fume does the same thing to it’s own fxd’s), but this workflow is undesireable anyway as it will be considerably slower, with large intermediate files and an extra intermediate step.

Is this possible currently? Something like a minimise grid option…

thanks,
grant

[Bobo]

Hi Grant!

I suspect that you will have to run a Stoke Magma intermediate object just to convert the VDB channels to matching Fume channels for the time being (unless Houdini already saved them as Smoke, Velocity etc.) We hope to add conversion modifiers (e.g. a Stoke Magma Modifier) in the future to allow channel remapping to be done without a Stoke Magma base object.

Regarding the adaptive grid saving, we are using the FumeFX SDK which is quite funky and it is a wonder it actually does anything at all. We don’t believe we would be able to use it in its current form to save an adaptive grid using Fume’s feature. Also, the FumeFX grid does not allow for negative voxel coordinates, so we have to translate our grid into FumeFX space, so if the Stoke grid size was changing in the Min. Z axis, the FumeFX Grid would shift incorrectly.

That being said, the actual FumeFX export is a hybrid MAXScript/C++ implementation, and we could tweak it on either side to possibly get something working.
The MXS side of the exporter code can be found in Stoke_FieldDataExporter.ms. The relevant part looks something like this:

local f = StokeGlobalInterface.CreateMXSField theField StokeGlobalInterface.WriteFXDFile (getFileNamePath theFile + theFileNameFile +(formattedPrint (currentTime.frame as integer) format:"04i")+".fxd" ) theField f.BoundsMin f.BoundsMax f.Spacing f.Clear()

As you can see, we create a MAXScript field out of the actual Stoke object which returns an interface that gives us the Bounds, Spacing, Channels and ways to clear and sample data:

Interface: MXSField Properties: .BoundsMin : point3 by value : Read .BoundsMax : point3 by value : Read .Spacing : float : Read .Channels : string array : Read Methods: <void>Clear() <fpvalue by value>SampleField <string>Channel <point3>Position Actions: OK

I guess we could add an option to StokeGlobalInterface.CreateMXSField() to return a shrunk grid, or expose properties that give us the min. and max. bounds of the actual populated voxels taking all channels into account. You could even run 3 FOR loops in MAXScript and sample the grid with the given bounds and spacing through all channels to find the optimal grid bounds yourself. Then, when calling StokeGlobalInterface.WriteFXDFile(), you just have to provide the smaller bounds and your FumeFX file will be written as you need it. You could ensure that the Min. Z is never changed to keep the base consistent and prevent the Fume grid from shifting vertically due to the positive space limitation I mentioned already.

I tested this by creating a simple default Stoke Magma with a Position -> Magnitude -> Less (30.0) -> Density and saved to disk using

f = StokeGlobalInterface.CreateMXSField $ StokeGlobalInterface.WriteFXDFile ("c:/temp/testbounds.fxd" ) $ f.BoundsMin (f.BoundsMax-[0,0,53]) f.Spacing

When I loaded the resulting FXD file, it contained only the bottom half of the grid. So this proves you could change the grid bounds yourself.
What I have not tested yet is what happens if you vary the bounds over time - our Stoke Field Loader would not mind, but I don’t know whether FumeFX will like that. I hope it would.

Hope this helps!
I will log your request as a Wish, but since we just released Stoke last week and have other projects going on, I cannot give you an ETA when we might be able to address this.

[iloura]

Hi Bobo

Thanks for getting back to me.

We don’t believe we would be able to use it in its current form to save an adaptive grid using Fume’s feature.

I did a little file-hackery test yesterday where I used the magma object with an animated grid - matching the openvdb bounds per frame, read from the bounds of the field loader - writing out to FXD files. Then I wrote a small python script to modify the FXD files to insert both the sub-grid offsets, as well as setting the overall grid to a fixed region encompassing the entire area of interest. (The header information was straightforward to figure out, I have no idea if the format is documented).

This seems to work well and does what is required - the only tricky bit seems to be accurately getting the correct offsets for the subregion (I seem to have some half-grid offsets on some frames), I think I might import the openvdb python api and see if the data is easier to put together that way.

I’ll see if I can insert what is needed into Stoke_FieldDataExporter.ms as a post-export step, thanks for the pointer.

thanks!
grant