So yes, I still have the problem. Like others, it seems to work regardless. Changing BaseVolume.cs line 756 where the texture is created from TextureFormat.RGBAHalf to TextureFormat.RGBAFloat removes the error but, I'd assume, means twice the data is being shunted about so is half as efficient, right? Anything from Unity on this yet? Moving on... I now have a few questions related to my integration attempt. Short versions: How to tell Fluidity to emit at certain locations within its simulation volume? How best to allow fire simulation anywhere the camera goes? As background, in my local arena brawler (kind'a), I aim to make parts of the scene flammable (and later give my characters optional flamethrowers (like the Angry Bots demo)). I've created my own code for fires spreading and registering where a fire is emitting (since I need that for non-Fluidity version for pre-DX11 mode). What I haven't worked out is the best way to get Fluidity to consider other areas as emission sources within the volume. For (Question 1) I suspect I have 4 options: Use temporary emitters at all fire locations and scale them (something similar to what I'm already doing for non-Fluidity (particle systems)) -- best option I suspect? Use texture emission which I update -- limited to fires on a plane Use volume emission (where I update the Texture3D with my fires -- suspect the most efficient approach?) custom code / customize code ... perhaps something extra in Simulation.Inject()? For (Question 2) the only approaches appear to be: a single static fluid volume that covers the whole level accompanied by a simulation that uses a crazily large grid resolution. I already mostly hung Unity with 512^3! a simulation that moves with the camera (similar to Angry Bots integration demo). other? Given these, I guess (2) is the only viable one. The tricky part being that both my camera and multiple players move. I do already calculate the camera's desired bounding volume so I guess I could center the simulation there. I'm not sure what can be done about the breadth of view changing? (i.e. as the players move apart, the camera sees more.) Ideally, I'd like the volume and simulation to be as optimal as possible. Any thoughts? (I'm guessing one cannot change the Grid Resolution during simulation?) EDIT: Just tried doing it in GUI while running in the Ruins demo -- it switches to only updating the overlap between the numbers. Maybe different if volume also changed but unlikely, I'd assume. Any and all recommendations, etc on either question (or other issues you might think I'll encounter) will be greatly appreciated! Thanks in advance! Rupert.