-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question #2
Comments
Hi! First of all, I don't think the old plugin has much to offer, this one is an improvement in every way. What you're trying to do would be quite simple with our plugin, as long as your data is one-dimensional (1 value per voxel). If it isn't, you'd have to make several changes to the light calculation and the raymarching material itself. To break down - to see how we import the data into the volume texture, see the LoadRawIntoNewVolumeTextureAsset() function. In the end, you'll need an array of floats packed in the usual order (first X elements is the first row in Y, first X*Y elements is the first slice in Z). Then the other steps depend on how much synchronization your calculations need. Presumably you'd make one calculating compute shader with an InputVolumeTexture and OutputVolumeTexture and do your calculations and write to the output. Then probably a second compute shader could write the results back to the original texture, so you have the result data back in-place ( I haven't experimented with swapping the low-level RHI resources to VolumeTextures, maybe that would be a way to avoid this copy, but also, just a copy in CS is pretty cheap). A lot of our shaders are a bit overcomplicated, as the light propagation has to be synchronized on each slice, for a simple example, you can see ClearVolumeTexture_RenderThread (which sets all voxels to a single value, unsurprisingly) and ClearTextureShader.usf. Add a second volume texture to that, do your calculations and write to output. Or if your calculations can be done in-place, just overwrite the value right away (but I don't think that's your case, as for each voxel, other voxels will depend on the value of this voxel). Afterwards, set the RequestedRecompute flag on the raymarching volume, so that the light gets recalculated too. I'm thinking that for your application, you could probably simplify the raymarching and light computation to not use a transfer function, instead directly setting opacity based on the value you have in your voxel, which would get you rid of a lot of texture reads. But for starters, for a cloud, you can just make a color curve going from full transparent white to full opaque white and use that as your TF. Cheers, Tommy. |
Say, I have a scientific weather simulator that takes in a 3D grid of data, does calculations, and then spits out a 3D grid of data that contains all kinds of information (3d representation of weather data such as clouds)
I'm thinking of a combination of
https://github.com/tommybazar/UE4GlobalShaderRaymarcher
and this to achieve this.
Would you have a generalization of the connecting processes to make this happen?
Steps:
Imports initial weather state from CPU to GPU
Run ComputeShaderCalculations on GPU using initial weather state
Render calculations to Volumetric Texture
How do I organize the input data, is its sequential slices, or does it actually have to be blocks stacked vertically/horizontally? (So it will be compatible with volumetric textures)
Do you have a discord channel you use often?
The text was updated successfully, but these errors were encountered: