Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

215 Neutral

About LifeIsGood

  • Rank

Personal Information

  • Role
  • Interests


  • Github

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. LifeIsGood

    A Novel Approach To (Non-Manifold) Dual Contouring

    I want to deform meshs in realtime, so while a precomputation of a general mesh is fine, it should be the same possible in realtime. But yeah, not really working on this algorithm anymore, anyways.
  2. After my first (semi-failed) algorithm, I started to think about a new approach. The idea was to utilize simple mechanics such as Ray Marching to extract a polygon mesh from a signed distance function (SDF). So, this is what I came up with: The algorithm is divided into 2 separate steps. Ray Marching (or what I call in this case "Ray Sampling") and Mesh Construction from said samples. Ray Marching. Ray march the "scene" (i.e. the SDF), most likely from the player's perspective, on a low resolution. I used 192x108 mostly in my tests. Current GPUs have no problem whatsoever to do this in realtime. Instead of saving the color at the "hit point", as usual when ray marching, I'm saving the point itself in a buffer. Accompanied by the normal of the SDF at that exact point. What we end up with after the first step, is a collection of 3D points that resembles the SDF ("samples") & the normals at those positions. Mesh Construction. Construct a polygon mesh from those samples by simply connecting neighbouring pixels with each other. Lastly, scale up the mesh to account for the low resolution that we have used when ray marching. (I haven't done this yet in the images/videos you can see at the bottom) I think the results look quite good. There's problems that I'm still trying to solve of course, such as this weird aliasing (yes, I do know what the root of that problem is) It currently runs at about 40-70 fps, or takes somewhere between 10 - 25 ms per mesh. (Only the 1st step is parallelized & I haven't done much to optimize the algorithm) The Pro's No complex, underlying data structure such as a voxel grid Can run in realtime with no problems, especially if optimized No Level-Of-Detail required, which is one of the most painful things when writing a voxel engine. The mesh is as detailed as the image constructed by the Ray Marcher. (Which is pretty good, it's just small! Scaling up a complete mesh works way better than scaling up an image ) Enables sharp features, caves etc. (because, duh, it's ray marching.) Completly relys on SDFs (2D - "heightmap" or even higher dimensional SDFs) Meaning, we could deform the mesh in realtime by applying simple CG operations to the SDF. Infinite terrain for free! (We're only rendering what the player can see, if the SDF is "endless" so is our terrain) The Con's Right now, there's no precomputation. I'm thinking about the possibility of precomputing a mesh by taking "snapshots" from different perspectives. However, at the moment, it's all realtime. Only creating a mesh for what we see also means that AI etc. that is not close to the player has no mesh information to rely on. I don't know yet. Will update more con's when I find 'em. Maybe you have some ideas ? Results! All results have been generated using a simple SDF consisting of 2 sinus curves. A huge terrain constructed by taking "snap shots" from above. The same mesh in wireframe. Wireframe close up.
  3. For the sake of "completness", my first entry is about the very first algorithm I came up when I was thinking about new solutions to procedural meshing / extracting a polygon mesh from implicit geometry (e.g. from a signed distance function, SDF) You can find out more about it in this thread right here. At first, I liked the idea. However, the more I worked on the algorithm, the more I found characteristics that I dislike about this approach. You can read about the pro's in the thread linked above, so here is the stuff that I dislike now: The algorithm is a typical "voxel" algorithm. It relies on a 3D grid. It may suffer from floating-point imprecision It lost it's simpleness. The idea behind the algorithm was to find a simple alternative to DC. This is still very true for the 2D version of the algorithm, but for the 3D version, not so much... I had to account for more & more "special cases" during the development of the algorithm, resulting in an algorithm that wasn't simple enough anymore for my taste.
  4. LifeIsGood

    Looking for C# programmer, Unity

    Hey, I think it would be pretty cool to see some of the stuff you've done / worked on
  5. I agree. Politics is simply a topic that emerges wherever people come together. I don't see the solution in banning it from the forums. However, what I will say is, that it has been way too present at the main page. I do disagree with taking it entirely from the main page as it is content that belongs to these forums as any other. What I wish, is that political topics are a bit more limited on the front page though. Those threads tend to get more frequent answers than most other threads (especially when it gets a little heated) If there's 10 answers to that thread, it shouldn't pop up 10 times a day on the front page. Some sort of display restriction would probably prevent the main page from being spammed with those replies.
  6. LifeIsGood

    Old School VS Ray Tracing accelerated by GPU

    Sorry, but that article is pretty senseless. First of all, ray tracing is considered a general term for algorithms based on, well, tracing rays. "Normal" ray tracing, which only handles direct light certainly falls into the category. So does Path Tracing, which adds an approximation for indirect lighting. So does Ray Marching, which also considers non-solid matter. It is a fix. Not to make an awesome game out of a shit game, but for exactly the features that he named. Reflections, refractions, hard shadows. All in realtime. That's the reason why we will see hybrid renderers for the next couple of years or decades, not pure ray tracers. That being said, it's a first step towards more sophisticated algorithms such as path tracing, which relys on the same principles. Sending out huge amounts of rays. Running a lot of intersection routines. Hardware needs to be adjusted for that, which is starting to happen now. That's just a stupid point. Of course we won't simulate photons. It's nothing but a waste of resources. That's also not true. GI in games is often based on some form of path tracing. For example, Unity uses path tracing for their light mapper. That's why we have seen all those new denoising algorithms coming up the last couple of years, to make some form of path tracing feasible. Now, of course we're cheating, and more or less of the quality of a path traced image is lost through denoising. But it's still already some form of it.
  7. This topic reminds me of the principles (or whatever you want to call it) of Facepunch studios (https://wwww.facepunch.com/about/) One of them being I haven't worked there. So, I don't have personal experience and I don't know if this would also work for bigger teams, but they seem to do fine.
  8. LifeIsGood

    How much longer can Trump/Trumpism last?

    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.
  9. LifeIsGood

    Should I depart from my game project group?

    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.
  10. 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.
  11. LifeIsGood

    A novel approach to (non-manifold) Dual Contouring

    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.
  12. LifeIsGood

    Unity dropping Monodevelop a let down for small indie?

    That sounds pretty weird. My guess is, that it's simply not economic to continue the support for monodevelop.
  13. LifeIsGood

    A novel approach to (non-manifold) Dual Contouring

    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.
  14. LifeIsGood

    A novel approach to (non-manifold) Dual Contouring

    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!
  15. LifeIsGood

    A novel approach to (non-manifold) Dual Contouring

    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.
  • Advertisement

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!