As the title says, I’m wondering about this. I admittedly have no idea at the complexities of implementing this, but I think it could be very useful. I’m running into situations where I think this could be useful. It wouldn’t have to be exclusive to Stoke, but I posted here because that’s where the current export lies.
I know that technically it might be redundant because you could always render as voxels. But, I’m finding that just a straightforward export to be loaded into fume is what is needed. For example, a particle stream for let’s say missile/meteor trails.
Again, this might be redundant or not possible but I thought I’d note it anyways.
FumeFX FXD files can only contain voxel information (and have some other limitations we are aware of, like no negative voxel addresses, minimum voxel count per axis limits etc.
You can already convert Meshes, Particles and various Voxel formats (FumeFX, F3D, VDB) to Stoke Fields using the Stoke Field Magma object, and export any Stoke Fields to FXD, F3D or VDB using the Stoke Field Data Exporter. There is no way to generalize this further because most of the data in Max makes no sense as a field unless you define how to process it, what the fields should be called, how they should be samples, scaled etc.
So you can already do pretty much anything that could be done, but it requires some Magma setup before it goes out. Adding a plugin to the File>Export of Max would not solve any problems, just introduce new ones IMHO.
Can you explain where the current solution fails and your suggestion would improve things?
Thanks for the reply, Bobo. I think I’m just confused a bit when it comes to extent to the fields export. I think what might be confusing me is this:
In the simplest example I can think of, let’s say I have a plane and I do a vanilla PRT SURFACE that creates 10,000 particles. I want to export those particles to .fxd. To do this, with no manipulation and just an export, should I just set up a Stoke Field Magma with velocity > velocity and density > density, then hit sim?
This is mainly where I keep getting confused. For instance, I have a setup of ocean waves I made using Genome. I mapped the velocity to a color blend on the mesh. The higher velocity is white, the lower is black. Now, I used a PRT Surface on this mesh and culled the particles that are in the black areas. So I’m left with particles on the wave crest. Now, using Stoke and a wind I’m having those particles emit what would be “mist.” I want to export these as .fxd so I can render in fume.
This is pretty much where my confusion lies. How to take existing data and pump it through fields with and without manipulation.
First of all, PRT Surface does not produce any Velocity (only PRT Volume does).
But if you emit Stoke particles driven by something from the PRT Surface particles, the Stoke particles will have a Velocity.
Now you can create a Stoke Field Magma around them, use an InputParticles -> PVelocitySplat to get the Velocity and output to Velocity output. You must take the Magnitude or the X component of the Density though since the Density output of PVelocitySplat is a Vector with separate Density values in X,Y and Z. You can output the resulting Float as Density to be exported as Smoke. Then open the Field Data Exporter and write to FXD. You might have to tweak the Density value going out as Smoke if it does not look right when rendering…
In general, particles can be converted to a Field by using PVelocitySplat, ParticleSplat, or the old ParticleSumRadius operators. The former two use a Grid to do the conversion (similar to how Stoke uses particles to make fields internally), the latter searches for particles in a spherical volume and is not as precise. PVelocitySplat has an option to produce fluid motion (remove divergence), ParticleSplat is a more general purpose operator that can splat any available channels. This is just for particles to fields conversion.
But Field Magma can turn Meshes into fields too - either by using the LevelSet operator, or by using NearestPoint or IntersectRay.
You can also convert splines to fields by first sampling them to particles.
So my point was that while you can do all these things, the exact details of the conversion are up to you, and creating a simplified exporter that takes all these possibilities and exposes them in a clean UI while producing something that is actually usable would be quite tricky.
Awesome, you answered my questions. That’s what was holding me up. Besides, even if I still want something that doesn’t move, I can just load in the single frame after the fact. Ah, this is such a relief, thanks!
That’s what was holding me up. Besides, even if I still want something that doesn’t move, I can just load in the single frame after the fact. Ah, this is such a relief, thanks!