
Advertisement
LifeIsGood
Member
Content count
34 
Joined

Last visited
Community Reputation
210 NeutralAbout LifeIsGood

Rank
Member
Personal Information

Role
Programmer

Interests
Art
Programming
Social

Github
https://github.com/GoGreenMI
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.

How much longer can Trump/Trumpism last?
LifeIsGood replied to deltaKshatriya's topic in GDNet Lounge
I don't see why you are sorry for this somebody. Your country has modern, legal ways to make somebody who lives in the U.S. an American. This person is part of "the people" just as any other person living there. So, that's Trump to you ? Don't you see that he's cutting relations with whole europe, which has been the biggest partner of the U.S. since WW 2 ? You have ripped that quote out of context. This is not about america being the bad country with this kind of history. This was in reply to Buffo's statement, who claimed that the U.S. was doing great until about WW 1 & is now deteriorating. However, even if it wasn't completly out of context: 2 wrongs don't make a right. "The people" have a responsibility to uphold for the comming generations. It is your responsibility to remain critic about your country's politic, and to acknowledge mistakes that have been made so your country can continue improving. This is the whole idea of democracy. 
The choice you should make is pretty obvious to me: Get out of that team. You are literally just burning your time. Many of those hobby projects will be led by people who want to see their game realized but are not ready to contribute any work. And those projects will fail sooner or later. There are new projects posted by startup teams here everyday. Find one that actually wants to work with you.

What is the light weight alternative to Unity ?
LifeIsGood replied to sprotz's topic in Engines and Middleware
What ? You mean you have run into performance problems because of something like that ? That doesn't sound likely at all. All vector * float really is, is: public static Vector3 operator *(Vector3 lhs, float rhs) { return new Vector3(lhs.x * rhs, lhs.y * rhs, lhs.z * rhs); } Apart from that, that code snippet isn't too bad. If you're working with the separate components instead of directly using the constructor, that's really just style at that point. ("this" is pretty redundant though, yeah.) Btw. That's "Javascript" or rather UnityScript right there. Doesn't have too much in common with Java. 
A novel approach to (nonmanifold) Dual Contouring
LifeIsGood replied to LifeIsGood's topic in Math and Physics
I have adjusted the algorithm a little to address the problem with sharp features like corners. If the vertex has been smoothed out, I'm pretty much just taking the smooth vertex, averaging all the normals together (let's call this new vector A) and interpolating from the smooth vertex position in direction A to find a point lying on that line, where SDF (point) = 0. Also, I had to add a little bias to the new found vertex, but I guess that's just precision problems since I'm using floats right now. The average of the normals is represented by the black lines in the video. https://www.youtube.com/watch?v=C8s3rpk4pZw&feature=youtu.be I'll have to do some more testing to see if this new solution works for the general case. 
Unity dropping Monodevelop a let down for small indie?
LifeIsGood replied to Scouting Ninja's topic in GDNet Lounge
That sounds pretty weird. My guess is, that it's simply not economic to continue the support for monodevelop. 
A novel approach to (nonmanifold) Dual Contouring
LifeIsGood replied to LifeIsGood's topic in Math and Physics
I don't think that's accurate, if you are using a grid with a proper size related to your SDF. If you have a cube the size of 1 single of your grid cells, then it's pretty likely to run into those problems. But it's also really likely to run into different problems such as finding sign changes at all with this kind of size. Generally, your grid should have a lower resolution then your surface, otherwise you are also likely to run into problems with multiple surfaces in one single cell (aka manifold surfaces) I think that's your problem. It's really hard to think about this kind of problem. Once you have a bunch of results & debug information, it's a lot easier to think about it. (That's why I'm showing all this debug information in different colors, like sign changes, normals, surface edges, intersection points, etc.) Absolutely not. I just think you are overthinking your situation. That's what I mean when I say "find a way to fix your problem". Get some results. Once you have those, identify your problems. Then, fix those problems. Edit: Actually, if you let your vertex fall outside of the cell there would be no problem with clearing the adjacent cell. Because if you do, you will have to adjust the SDF of your surface, meaning there will be no more surface in this cell. Edit 2: It might be even better to simply let the vertex fall outside. You would just have to deal with multiple same vertices perhabs. I don't know without testing. 
A novel approach to (nonmanifold) Dual Contouring
LifeIsGood replied to LifeIsGood's topic in Math and Physics
Of course you can, you are using a grid. You will always be bound to it's resolution. As you will always have some sort of aliasing with a pixel display. That's just the way it is. However, reality shows us, that the results are good enough in most use cases. How likely is the case on your first drawing ? If you generate so many small polygons, you'll have to deal with other problems anyways. How likely is this case ? What kind of surface do we have that we could ever experience this kind of problem ? Practice shows us, that none of this is really likely to happen. If it does in your case, find a way to fix your problem! 
A novel approach to (nonmanifold) Dual Contouring
LifeIsGood replied to LifeIsGood's topic in Math and Physics
You don't have to compare the corners, you can compare any values lying on the edge. It's just the most compelling way to choose the corners. However, if that's what you worry about, then you likely are simply using a grid resolution inappropriate for your SDF. See swiftcoder & my posts. If you are not handling this case, well, then you are simply accepting the fact, that the generated mesh is going to be a bit more imprecise. 
A novel approach to (nonmanifold) Dual Contouring
LifeIsGood replied to LifeIsGood's topic in Math and Physics
There are definitely 2 sign changes in the cell above in the sample drawing you habe provided. The only time where that would not be the case, is if the corner would lie directly on the edge of a cell. 
A novel approach to (nonmanifold) Dual Contouring
LifeIsGood replied to LifeIsGood's topic in Math and Physics
Ah, I see what you mean. There's no need to create a vertex here, since there's going to be no intersection inside of this cell (keep in mind that we are working with line segments) the vertex will be generated in the cell above this one. If the corner is outside of the grid's bounds, well, then you simply don't have enough space to generate the whole mesh. I am not too sure how standard DC would handle this, but here's my guess:  You would simply snap the vertex into the cells bounds and you would still get a sharp feature, since we're going to create another vertex in the cell above. 
A novel approach to (nonmanifold) Dual Contouring
LifeIsGood replied to LifeIsGood's topic in Math and Physics
There is indeed a problem with sharp features when averaging the intersection points, as you can see in this video. However, it is not as prevalent as it is with Marching Cubes. Notice the intersection points (in light blue / cyan) and the generated vertex (in dark blue) The averaging smoothes out the corners. I'm currently looking for a better solution then simply averaging the intersection points. Ideally, the generated vertex would lie right above the lower intersection point, creating a normal corner. https://youtu.be/PXKI1PWlmt0 This is a misconception about how the algorithm actually works. 2 or more sign changes per grid cell mean, the function changes here from non solid to solid (or vice versa), so no matter what kind of surface we have in this space, the vertex we're looking for is guaranteed to lie inside this cell. So, when the QEF returns a point outside the cell, it's actually just an "error" of the applied solution. 
A novel approach to (nonmanifold) Dual Contouring
LifeIsGood replied to LifeIsGood's topic in Math and Physics
Pretty much, yeah. Since we're handling the 3D case there's no tangent, but rather a tangent plane. However, we're only interested in one of the 2 vectors (one of those will resample exactly the surface edge we are interested in), that make up the tangent plane. No. The tangent plane can have any orientation, as you can see here: https://www.khanacademy.org/math/multivariablecalculus/applicationsofmultivariablederivatives/tangentplanesandlocallinearization/a/tangentplanes I think it should work. I'll reply back with some results once I've tested that. 
A novel approach to (nonmanifold) Dual Contouring
LifeIsGood replied to LifeIsGood's topic in Math and Physics
Sure. It's a bit messy right now though. Here's my Solve function (I have not included the intersection function etc. since this is just basic geometry): private Vector3 Solve(Vector3[] signChanges, Vector3[] normals) { var intersections = new List<Vector3>(); float avrX = 0, avrY = 0, avrZ = 0; for (int i = 0; i < normals.Length; i++) { var n = normals[i]; Vector3 u, v; GetTangentPlane(n, out u, out v); for (int j = 0; j < normals.Length; j++) { // Do not try to find an intersection point with yourself. if (j == i) continue; var n2 = normals[j]; Vector3 u2, v2; GetTangentPlane(n2, out u2, out v2); // When you calculate the tangent plane, you have effectively 4 directional vectors representing your surface // (u, v & their inverses) // Since we want to "expand" in a specific direction, this method simply figures out which of those 4 vectors to choose. var surfDir1 = GetSurfaceDirection(signChanges[i], signChanges[j], u, v); var surfDir2 = GetSurfaceDirection(signChanges[j], signChanges[i], u2, v2); // Calculate the intersection point of those 2 line segments // (basically the surface edges from the involved sign changed positions) var intersec = GetIntersectionPoint(signChanges[i], surfDir1, signChanges[j], surfDir2); // No intersection. if (float.IsNaN(intersec.x)  intersections.Contains(intersec)) { continue; } intersections.Add(intersec); avrX += intersec.x; avrY += intersec.y; avrZ += intersec.z; } } if (intersections.Count < 1) { // This should not happen, since we already know we have at least 2 sign changes here. // So, if we end up in here, something is wrong... } // Average the position, if there's multiple intersection points. // This point now is the vertex we were looking for. var vertex = new Vector3(avrX / intersections.Count, avrY / intersections.Count, avrZ / intersections.Count); return vertex; } Also, maybe the video I've posted in the comment before helps you to visualize. Edit: Idk why I called it solve.... it doesn't solve an equation like the original implementation. Just sticked with it for some reason 
A novel approach to (nonmanifold) Dual Contouring
LifeIsGood replied to LifeIsGood's topic in Math and Physics
I have fixed a few errors in my implementation. You can see the new results here: 
Hi! First of all, this is still very basic. I just managed to get my first results running, but I figured I would share my thought process & what I have done so far. I'm not that well versed when it comes to Math, so I'm definitely looking forward to hear your guys opinions. This thread is quite long, so feel free to just jump to the heading that interests you. Recently, @Boris The Brave has released a really nice tutorial on Marching Cubes & Dual Contouring. A few years ago, I was already messing around with those algorithms but was lagging the required knowledge about programming back then. When Boris' tutorial came up, it again arouse my interest in this type of field. Also, let me appologize for my poor paint skills in advance Classic Dual Contouring The heart of the dual contouring algorithm is to solve the problem of finding the best fitting vertex for a surface inside of a cell. In the original paper, this problem has been solved with a quite complex solution (at least to us nonmathematicians): Solving & minimizing the Quadratic Error Funtion (QEF) Most projects simply reuse the original paper's implementation to solve the QEF and/or (slightly) adjust it to their needs. Usually, this works perfectly fine & yields pretty good results. However, I was curious if I could find a way to simplify the problem. My approach (2D) Looking at the problem in 2D significantly simplifies the problem, so let's do that first. Here's the information we have: We know the exact position of a sign change on one or more edges. We know the normal of the surface at that exact position So, how do we find the best vertex for that cell ? The normal is obviously orthogonal to our surface, so, what does our surface at that point look like ? Of course, it's simply an edge orthogonal to the normal! That means, there are only 2 possibilities in 2D! (which are essentially kind of the same as they are only the inverse of one another) One of the easiest ways to decide which of those 2 directional vectors we need is to simply move our point a bit in each of the directions. The point that's closer to the next sign change is the direction we are looking for. Now, all we need to do to find the best fitting vertex, is to find the intersection of those 2 directional vectors! (That is, we want to make lines out of those 2 vectors.) Since we know, that we have 2 or more sign changes in this cell, we know that there is either going to be an intersection of those 2 lines inside of the cell, or none at all. And that's it! That's what our actual surface looks like. So, here's all we need to do summarized: For each sign change, calculate the 2 orthogonals to the normal For each other sign change, do the same Look for an intersection between those 2 resulting lines (Essentially, we are looping over all sign changes twice.) In the end, we simply take the median of all found intersection points (required if there are more then just 2 sign changes) My approach (3D) In 3D, there is an infinite amount of orthogonal vectors to our normal, so how do we pick the one representing the edge of our surface ? In 2D, we can represent the course of a surface in a specific point with the tangent line. In 3D, the same principal exists. This time, it is a tangent plane. So, instead of 2 vectors as in 2D (the 2 orthogonal vectors to our normal) we have 4 this time. The vector u & v describing the tangent plane, as well as their inverses. We can apply the same principal as in 2D to find the one vector we are looking for, to represent our surface edge at this point. Now, all we got to do is to again find the intersection of 2 lines (or more specifically, line segments). Results in 2D Circle, from left to right: The complete surface, hermite data (sign changes & normals), resulting vertices (points of intersection) Square, from left to right: The complete surface, hermite data (sign changes & normals), resulting vertices (points of intersection) Results in 3D Left: My approach, right: The result from Boris The Brave's implementation. https://youtu.be/LtZCa359exU

Advertisement