Jump to content
  • Advertisement
CelticSir

I don't understand how people apply LOD to an FFT

Recommended Posts

2 minutes ago, JoeJ said:

What i mean is to distrubute that change gradually, so it would not matter visually.

What does that even mean ? Distribute what exactly?

Share this post


Link to post
Share on other sites
Advertisement

image.png.dfe55945bcb1bd7eab4863c8ef9e27b8.png

Example: The FFT has only 2 terms, and when reducing the LOD, term1 should become constant so you can remove it from the simulation at lower detail.

To do so, gradually drive it to zero from left (high detail) to right (LOD transition in the middle).

The simulation code would need to handle halfing / doubling the phase shift with neighbours at transitions. If done right, the change of LOD should be hidden well enough.

Share this post


Link to post
Share on other sites
2 hours ago, JoeJ said:

image.png.dfe55945bcb1bd7eab4863c8ef9e27b8.png

Example: The FFT has only 2 terms, and when reducing the LOD, term1 should become constant so you can remove it from the simulation at lower detail.

To do so, gradually drive it to zero from left (high detail) to right (LOD transition in the middle).

The simulation code would need to handle halfing / doubling the phase shift with neighbours at transitions. If done right, the change of LOD should be hidden well enough.

I guess my understanding of the algorithm is missing something because that doesn't seem to be possible. The paper suggests that vertex count must equal NxN which is the 2^n value and since its the sum of all vertices, if you space them out you have less vertices than you have N which won't match the output ?

Share this post


Link to post
Share on other sites
16 minutes ago, CelticSir said:

which is the 2^n value and since its the sum of all vertices

I don't know the paper and can't make any sense from this statement, you'd need to explain things a bit.

but...

17 minutes ago, CelticSir said:

if you space them out you have less vertices than you have N which won't match the output ?

... i assume the paper is about fluid simulation on a regular grid. This means the distance between the vertices is constant which simplifies the math you now need to understand in detail to support variable resolution. Likely you have certain properties at each vertex, like velocity / pressure, etc, and those properties are represented by waves. And likely the simulation works by integrating those properties using the contribution of the neighbour vertices. For this you usually have to weight the neighbours, which now becomes more difficult because it's no longer a simple regular grid. Number of neighbours is no longer the same everywhere, distances vary, etc. When working on a irregular triangle mesh, this is done using cotan weights (see here: http://rodolphe-vaillant.fr/?e=91). You could precumpute those weights for the various edge and corner cases. (However, triangle mesh != quads of a regular grid, so this won't be trivial)

Additionally, because you use waves not just scalars, likely you need to transform those waves from the neighbour vertex to how they would look like on the current vertex. In my case that's converting distance to angle and rotating the complex number representing the wave by that.

But all this is based on my assumptions. I hope somebody with knowledge about the methods from the paper can help better.

Share this post


Link to post
Share on other sites
1 minute ago, JoeJ said:

I don't know the paper and can't make any sense from this statement, you'd need to explain things a bit.

but...

... i assume the paper is about fluid simulation on a regular grid. This means the distance between the vertices is constant which simplifies the math you now need to understand in detail to support variable resolution. Likely you have certain properties at each vertex, like velocity / pressure, etc, and those properties are represented by waves. And likely the simulation works by integrating those properties using the contribution of the neighbour vertices. For this you usually have to weight the neighbours, which now becomes more difficult because it's no longer a simple regular grid. Number of neighbours is no longer the same everywhere, distances vary, etc. When working on a irregular triangle mesh, this is done using cotan weights (see here: http://rodolphe-vaillant.fr/?e=91). You could precumpute those weights for the various edge and corner cases. (However, triangle mesh != quads of a regular grid, so this won't be trivial)

Additionally, because you use waves not just scalars, likely you need to transform those waves from the neighbour vertex to how they would look like on the current vertex. In my case that's converting distance to angle and rotating the complex number representing the wave by that.

But all this is based on my assumptions. I hope somebody with knowledge about the methods from the paper can help better.

I have the paper here - see attachment.  Page in question is 3-6 top of left column.

Perhaps you can understand it a bit better. From my interpretation of it, the summation is based on total vertices defined as N by M since it converts a vertex X to a vector K based on L (size of the mesh) and N (resolution of mesh). Which means if i have a mesh with less vertices (small N) then i calculate different spectrum same if i change L ?

This is how i interpreted the vertex to k vector in code form:

// Where N is resolution for both .x and .z dimensions. And L is the size of the mesh for both .x and .z axis.
Vector2(Mathf.PI * (2 * vertex.x - N) / L, Mathf.PI * (2 * vertex.y - N) / L);


 

tessendorf.pdf

Share this post


Link to post
Share on other sites

Oh, i think what i got wrong is this: In the paper they generate periodic (so repetive) patches. So my proposal would break this. Also i intended to have one unique FFT per vertex, while they seem to spread them out over the whole patch? I assume the paper is orders of magnitude faster than what i had in mind, but it is no true simulation that could handle interaction with something like a boat or coast.

Not really sure about anything, i'm no expert here, but if you aim for peridic patches, i do not see a need for LOD in the simulation at all? It's just necessary for the rendering?

Anyways - seems i was totally offtopic, yes :$

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!