[WS2122] Homework 3 Discussion

[changkun]

This thread is open for the discussion of homework 3.

[nico778]

When I'm selecting mean curvature, it does not seem to work, is this problem relevant for this homework?

[changkun]

Hmm. That's a good point. I think you are right. Maybe we have to change the vector implementation back to how it suppose to be.

[nico778]

Okay, I'm going to use the old way for now, and adapt if I'm running into issues.

[JohannesMerkt]

So im I supposed to change the this.vertsOrig to this.vert? And I guess I have to update the buildMesh function to set vertsOrig, but why is it an array though?

[JohannesMerkt]

Or is the vertsOrig refering to all vertices so i have to pass the entire vert array there?

[JohannesMerkt]

Ok, so this is what I found for anyone with the same issues:

1. You will need to update your build Mesh function so that it fills in the vertsOrig array. Be careful when doing so, you want to make sure that verts and vertsOrig do not reference the same object and that a vert and a vertOriginal do not reference the same position vector object. This will cause issues later on when manipulating the verts
2. In the buildmesh function you will also need to assign the vertOrig field with the vertOrig array for halfedges

[JohannesMerkt]

When calculating the laplaceWeightMatrix and the mass matrix should it be based on the original verts or the verts that could be already modified?

[changkun]

That's a very good question. If you read the original paper, it may say based on the original vertices.
However, if you do more research, you will find that people also proposes to use modified vertices. The performance of the two shows quite different results. Hence I suggest you could try both if time permits.

[MarlQ]

I'm getting a h.face is undefined error when choosing Angle Weighted as the normal method.
Inside the code in primitive.ts it loops over all halfedges and assumes they have a face, which is not the case for boundary edges and which is why it crashes... ?

[MarlQ]

But how would I do that logically? Halfedges on the boundary are not supposed to have faces, are they?

[JohannesMerkt]

Oh sorry i overread that. Guess I made a mistake in my implementation. It works for me but i think its due to assigning faces to boundary halfedges by accident. Will check it tomorrow

[changkun]

I don't remember if we discussed the boundary virtual faces or not. But I think it is quite intuitive that for boundaries, using a virtual face will make the traversal of boundary edges a lot more easier.

[JohannesMerkt]

@changkun so if I want to use virtual faces do I create a face for each boundary loop but dont save it in the faces array and only in the boundary halfedges?

[changkun]

Yes, I think that's the meaning of "virtual faces" as they are not really real faces.

[alvaxgln]

Hey,
i'm currently working on Homework 3, and while the Uniform Laplacian is looking ok, the cotan seems to move a lot faster than in the reference pictures. (It disappears after a very small time step)

Also the time step slider only works forward.
This is probably because my construction of the Laplace matricies relies on the Halfedges, which dont work with the vertsOrig array, so they are always built from the current position of the vertices.
I think i'd have to build the complete Halfedge Connectivity twice, so that the functions which depend on Halfedges work with the vertices in the vertsOrig array, or redefine all the functions to work with the Halfedge.vertsOrig attribute.

That seems pretty complicated, so if it's possible it would be nice to extend the deadline to end of monday again, so we can maybe discuss that after the lecture?

[MarlQ]

The deadline says '29.11.2021 23:59:59' which is the end of Monday, no?
Also, I don't think the Halfedge connectivity has to be built twice, after all it's just the position of the vertices that changes.

[changkun]

Yes, cotan is expected to move fast. I suspect you might suffering some numerical issue. We could rescale the values if make sense. Furthermore, the deadline ends on Monday

[MarlQ]

"Ends on Monday" has ambiguous meaning... do we have until end of monday or not?

[changkun]

Hey. Can we please stop talking about the deadline? Is the number not clear enough?

[alvaxgln]

The deadline says '29.11.2021 23:59:59' which is the end of Monday, no?

Oh, yes that's my bad, sorry ^^

[MarlQ]

OK, I'm a bit at a loss. The implementation I have looks correct when inspecting the matrices, but the graphical result looks horrifically spiky instead of smooth. I added the 1e-8, but that made no difference.

I'm not entirely sure if I understood the various parameters correctly.
What exactly is the smoothStep? Is that just h * lambda?
Why is the timeStep a float value? In all examples I can find, the time is just the number of iterations as an integer...

It's hard to figure out right now what I'm doing wrong...

[changkun]

The parameter timeStep is equivalent to the h in Slides page 38. It represents how much diff that we introduce in the time dimension.

The parameter smoothStep is equivalent to the lambda in the Slides page 38. It represents how much diffusion we need in the 2nd order derivative. See page 12 for its physical intuition.

The linear system hint that given in the code template:

    (M - tλW)f' = Mf 

is equivalent to the following formula:

[alvaxgln]

OK, I'm a bit at a loss. The implementation I have looks correct when inspecting the matrices, but the graphical result looks horrifically spiky instead of smooth. I added the 1e-8, but that made no difference.

Maybe the sum in the Weigth Matrix is wrong, i had it at positive values, instead of negative ones, and the result was this:

[MarlQ]

Ok, thanks. With the timeStep used like this, my uniform solution now looks similar, though not quite as extreme as the reference. Cotan is still totally broken, but maybe I haven't used the cotangens or the vertex area correctly...

Is (I - lambda * h * L) numerically unstable somehow? Because when I use it, the whole mesh breaks again...

[MarlQ]

OK, I'm a bit at a loss. The implementation I have looks correct when inspecting the matrices, but the graphical result looks horrifically spiky instead of smooth. I added the 1e-8, but that made no difference.

Maybe the sum in the Weigth Matrix is wrong, i had it at positive values, instead of negative ones, and the result was this:

No, it's nothing like that. As I said, I looked at all the matrices, and they looked correctly. So the mistake must be more complicated.

[changkun]

Yeah, the above screenshots look exactly like the matrices are incorrect.

[changkun]

I just pushed the reference solution for homework 3. Thanks a lot for the great discussion regarding this project as we discovered several interesting things:

1. Can avoid using a full copy of vertsOrig from @JohannesMerkt
2. Numerical issue discussions with @MarlQ
3. Mass matrix discussions together with @alvaxgln @MarlQ @JohannesMerkt
4. A potential new algorithm ;) with @alvaxgln @MarlQ @JohannesMerkt
5. (perhaps lost from memory...)

In the reference solution there are some highlights that are good for you (in case you haven't thought about it):

1. We previously reset the indices at the end of the halfedge construction. It is essentially necessary and consumes a lot more time in the build phase. Instead, we could simply assign indices on the fly incrementally.
2. Before updating vertex positions, we need to validate if the solved solution is a true solution for the linear equation. This means we need a further verification on the equation that our solved solution f_ subjects to (M - tλW)f_ = Mf. It can be easily done by moving elements around to a single matrix: S = (M - tλW)f_ - Mf. If f_ is a solution of the previous equation, matrix S should have all elements being zero. To balance verification time, we could simply sum all elements and check if it is zero or not. (Note that this is only necessary but not sufficient condition)
3. The reference solution also fixes an issue regarding curvature mode. When rendering mesh curvatures, after a smooth step, the curvature color was reset in the template, but now we can smoothly see how the curvature changes while smoothing a mesh. (Though the fix is just a workaround)
4. A execution time measurement is added to the smooth callee, which you could observe its performance when you open the console and conduct at least one smooth step.