Hey there guys… wanting to gauge interest on a mini project that i was doing.
Mainly i’m creating an ocean project but for personal reasons… and one of the things i was asked to, was to implement the typical GPGPU acceleration.
Using Content Driven Multipass i managed to create a pretty modular system mainly for image manipulation.
Here’s a little snippet of the results being applied to a Water Shader… all this can be extended to do other things like convolutions with kernels, filter images, etc…
It’s not A LOOOOT, but i would like to know if people would be interested on this project, or extend it in a way that people would want to use/buy it…
The basis for this solution was mainly the GPGPU Paper and Tessendorf’s Paper on Water simulation.
Now… my main goal was to create an ocean shader… but there are already other projects like this, and i don’t want to reinvent the wheel…
So i’m here gauging interest:
Would you support yet another ocean plugin (would have to differentiate it somehow, maybe make a low poly / stylized version)
Would you use the Solver Kernel for image manipulation?
It seams nice, but even if I purchase it to use in a product, I would need a license to use it in a commercial purpose with intention of reselling it. Example: if I create a plugin for Unreal using your solution and if I think I could sell it later on the Marketplace, its license must allow me on doing so, because plugins in the Marketplace are sold with source-code, including from third-party libraries/work.
A license granting this can be made with a signed document via DocuSign mobile application in this case, which is the same method used by Epic to allow access to console dev kits. Let me know what you think about it.
Sounds feasible enough… i would have to think about that though, mainly because selling to another plugin developer would most likely have other implications… but i don’t think there would be any issues regarding that
They should really look at allowing dependencies on third party marketplace plugins.
Regarding the plugin itself, i’d definitely buy it but it absolutely needs a CPU implementation that we can use for height reads. So long as it implements this i’m happy. I’m pretty sure 512 on the GPU and 64 on the CPU is sufficient:
If you mean to create a Solver using a CPU implementation, then that’s easy to do… but is slower (hence the limit on the CPU).
For heightfields, even if we use the GPU implementation we can get away with doing QUEUEs to the render thread… but to do them right would need a little experimenting. In tat regard a CPU implementation of the FFT would be faster to read, because the data would be on Buffers on memory.
Will check it out… i do have an implementation for QUEUEing the Render Targets, but i’m not at all happy with the resulting speed
It is just a matter to read the buffers ensuring the data is read before the update of its contents (locking might not be a good idea, would be better a secondary buffer updated with less frequency) and doing it in a frequency lower than the rendering actually. For buoyancy purposes I think is enough between 100 and 200ms each read… 200ms might not be a good value for small objects since they might look a bit popping, unless you learp the transition from one place to another when moving the obj’s coords. Large objects will be unnoticiable even 300ms.
What I was doing is creating a ReadOnly buffer for the Main Thread, and a Write Buffer for the render Thread… after the RenderThread completes the Write, i would have to copy the data to the ReadOnly Buffer… so it acts like a proxy.
The trick there is to avoid possible race conditions, and as i understand, that’s a solid enough way of doing that… separating the objects into Render thread only objects and MainThread objects…
