Yes, yes I do. So Iāve been thinking about how to implement the foam for quite a while. Iāve been specifically setting my eyes on 2 methods:
The more performant one, but less accurate method: basing it off of height - The way NVIDIA went in GPU Gems 2
The less performant one, but more accurate: using a Jacobian determinate
Eventually thought I decided to go with the way that NVIDIA went, basing it off of height. I mainly chose this since if you look at a Jacobian graph (image below) it closely resembles the height, and if we just use the height, something we already have available without extra calculations, then weāll be able to implement it with minimal performance loss.
(Tessendorf 2001)
And hereās the finished product: (I forgot to invert the values )
Iāve come back to this project, ā¦for like the third time. A few changes were made and more may come. Most of the work is going to be on optimizing some of the math and caustics, as you can see Iāve actually already done something with the caustics. Iāve made them blend into the texture of the seabed (Texture size is still limited to the Mesh resolution).
Although this is not done without issues, if you look closely some of the rocks donāt tend to behave how they should be. This is because theyāre in a different UV position on the texture. The way to fix this would be to get the UV of that specific vertex and change the texture there. Which isnāt currently possible, as the only transformation between UV and World space is by getting the UV space of a Vertex. But since each vertex is not a single pixel on the texture, that wonāt work. Meaning, that this is best used on a UV map that is a top down view of the mesh.
For the near future, Iām planning to make the caustics take in account shadows. Letās also not forget that weāve still got an entire underwater to make, this is only the start. In the upcoming days and weeks Iāll mostly be focusing on the underwater parts of this, so detecting if youāre underwater, caustics accounting for shadows, and an underwater effect. Hopefully by the next post I make all or at least some of these things will have been already finished.
So, it seems that a recent major update to both the Editable Mesh and Image has broken everything, not surprised since it was (and still is) a beta feature.
Iām going to be gradually fixing it, hopefully youāll also see improvements in performance, or at least Iām hoping so. Looking at the new API, it seems that itās a lot more verbose. Iāve already got the movement and color of the vertices back in a working state and Iāll be gradually fixing the other features.
This whole new API change felt really rushed and unstable, the previous version was much more reliable and better to work with. Iāve had to hard code certain things such as the image resolution, because theyāve decided to remove the Resize() function and not create an alternative (yet). Iāve also decided to hard code stuff like the VertexID, NormalID and ColorID, so that may break in the future, so Iāve already prepared a non hard coded version. Honestly I slightly hope that thereās a new API update, not because Iām some sort of masochist who wants to rewrite it again, but because this new API is utterly garbage. Itās unnecessarily complex and verbose, while missing past features and being more unstable than before. While containing even more bugs than the past version, obscure bugs such as the mesh not rendering if all the vertices are on the same Y level, texture content not changing if you use CreateEditableImageAsync instead of CreateEditableImage, color values went from 0-1 to 0-255 for some reason.
Iām unsure of the performance improvements, mainly because Iām using a VM, but from the performance Iāve seen it seems to be better than before.
I just tried it and it seems to be working fine for me. Although, I did also fix an issue with WaitForChild returning an infinite yield, so if that was the issue itās fixed now.
If this didnāt fix it then could you copy the errors from your output and any steps to reproduce it?
Thank you, been wanting to test it out. I was talking to DevVexus about it and if we do a bunch of optimization(Lerping, etc) methods we could get it at a stable rate mabye even for a game.
Iām not aware of any ways to give you permission to use the image, no clear way to do it through the development items menu at least. Best I can do is give yāall the image and then have you import it yourself and modify the floor texture variable.
PS: image is 96x96, because Roblox cannot implement a full API update and didnāt include a lot of features for EditableImages, including the resize function
The caustics themselves sadly donāt adapt to other parts, they only work on the floor texture. Iāve thought of adding that in, and maybe even casting shadows but the performance costs would just be through the roof.
If youāre curious on how I change the texture then I just simply cache the texture buffer and write the RGBA depending on the dot product of the normal and sun. (with an offset)
For some reason each of the IDs (Vertex, Triangle, Normals) have different starting positions, I got this number just by subtracting that offset. Thereās also a version without the hard coded values which has to index a table each time it wants to get the relevant ID. This was primarily a slight performance decision, itās a lot better to just add N rather than indexing a table with N.
Potentially? Iām unsure of the cause of the issue you have but the UV coordinate of the vertices might be the issues. I donāt actually use UV coordinates here, since the color is based on the vertex.
Iām talking about the ID, which is an integer, you can just do this by keeping count of the number of UV IDs and then subtract the ID that returns from :SetFaceUVs with that number, giving you a constant number.
The problem youāre facing is probably because of an incorrect vertex ID. You can compare it with my implementation if the values arenāt the same:
for X = 1, FOURIER_SIZE-2 do
for Y = 1, FOURIER_SIZE-2 do
local Vertex1 = X * FOURIER_SIZE + Y
local Vertex2 = Vertex1 + 1
local Vertex3 = (X + 1) * FOURIER_SIZE + Y
local Vertex4 = Vertex3 + 1
local Face = OCEAN_MESH:AddTriangle(4294967296+Vertex1, 4294967296+Vertex2, 4294967296+Vertex3)
OCEAN_MESH:SetFaceColors(Face, {12884901888+Vertex1, 12884901888+Vertex2, 12884901888+Vertex3})
OCEAN_MESH:SetFaceNormals(Face, {8589934592+Vertex1, 8589934592+Vertex2, 8589934592+Vertex3})
local Face = OCEAN_MESH:AddTriangle(4294967296+Vertex2, 4294967296+Vertex4, 4294967296+Vertex3)
OCEAN_MESH:SetFaceColors(Face, {12884901888+Vertex2, 12884901888+Vertex4, 12884901888+Vertex3})
OCEAN_MESH:SetFaceNormals(Face, {8589934592+Vertex2, 8589934592+Vertex4, 8589934592+Vertex3})
end
end
)
