Jump to content
  • Advertisement

JoeJ

Member
  • Content Count

    1629
  • Joined

  • Last visited

  • Days Won

    10

Everything posted by JoeJ

  1. JoeJ

    Fractals in games

    Reminds me about kkrieger - all procedural, entire game in 96 kb:
  2. JoeJ

    Github and Viruses

    Yeah, people mostly avoid uploading executables or dlls. So no virueses, but a lot of fun to build all those dependencies yourself.
  3. This. Still no feedback - ist your jump working now or not? And... well, you have a hard time learning programming, but you don't give up. Because you really want to create the game of your dreams. Fine. And now you ask others what to add to this game?
  4. Here is Prototypes solution (page 2): Here is mine (page 3 - not using GLUT but easy for you to do so): Both should work, but it was you who gave no feedback on this. Did you try? Did it work? (I had to zoom out a lot to see the jump working - you may need to tweak velocity and gravity until it behaves like you want.)
  5. Ther is some option in Visual Studio, and enabling it lists how inclusion dependencies are resolved, so while compiling it prints all header files in order, and from that you can see unnecessary cycles or something. Helps to fix it. I think it's this option: A helpful work around is to make certain files compile faster by using debug build, even if release build is selected. snippet from @Hodgman #if defined _MSC_VER #define MAKE_DEBUGGABLE __pragma(optimize("", off)) #elif defined __clang__ #define MAKE_DEBUGGABLE _Pragma ("clang optimize off") #else #define MAKE_DEBUGGABLE #endif With this included, just add MAKE_DEBUGGABLE on top of your slowly compiling files (before or after the includes matters ofc.) Very helpful also in case debug builds run too slow to be useful.
  6. ---- Proposal: Please do Pong or Pacman first. Here physics are very simple, and it sould be much easier to figure out what problems are caused by logic / math bugs on your side, or unecpected timing issues coming from GLUT. It seems actually there is too much uncertainty to progress and learn. With Pong working, you can come back to the jump'n'run game and continue.
  7. ... yeah Phil, although two people posted two working solutions you would only need to copy (IIRC Prototype and me), you 'fall back' to using an anlytical closed form approach to calculate jump trajectory. As said earlier, such approach will fail if other objects collide with the player while jumping for example, because the closed form math has no konwledge of the changes caused by such unexpected events. Believe me, closed form is a dead end here. Closed form analytics are good to do things like predicting where the jumping player will land most likely, or to calculate launch angle for a catapult to hit a target. Any kind of control problems. But not here. For game physics simulation you want to use integration as you did before already. It deals with collisions, moving platforms, unecpected events etc. in a simple, doable way. (The reason your character jumps only once seems you do not set time to zero when starting the next jump. The closed form formula assumes zero as the starting time of the jump.)
  8. JoeJ

    3D smooth voxel terrain LOD on GPU

    Yeah thanks, this is what i have expected (also with edges as shown in the paper). Notice Half-Edge will not work easily for this, because usually a vertex points only to a single polygon.
  9. JoeJ

    3D smooth voxel terrain LOD on GPU

    Do you guys know any resources on how such non-manifold cases look like, or how they can be fixed? I have just tried it (https://github.com/mikolalysenko/mikolalysenko.github.com/blob/master/Isosurface/js/surfacenets.js), and i like the resulting quads will cause less sharp angled triangles than marching cubes. I need this so solvers behave well. But manifold is more important, although things like self intersections would be ok.
  10. JoeJ

    3D smooth voxel terrain LOD on GPU

    Yes, but depends on what physics you need. If it's just enemies / vehicles but no box stacks, LOD could work. Also you could replace physics simulation with procedural animation at the distance.
  11. Haha, yeah... maybe i should try this - never did Sounds your game is top down / 2D. I remember nice tutorials about visibility by clipping, for both AI but also to cast shadows. So maybe shadows could be a useful search term as well.
  12. JoeJ

    3D smooth voxel terrain LOD on GPU

    Probably a missunderstanding on my side - because you metioned LOD i assumed you want more details near the player and less at the distance. So if the player would move around, the terrain would change and a resting stack of boxes could fall over for example. I did not mean the transition issues like gaps and discontinuities that often arise in LOD terrain approaches. A compromise might be to only detect contacts on GPU and send them to PhysX used by Unity, but that's still difficult and likely messes with contact caching the engine uses internally. So i would stick at your idea to download geometry. (Be sure to observe performance cost of submitting new gemetry to physics - usually this involves building an acceleration structure if it's not just a height map, so another reason to use low poly meshes.) I rough idea of mine - not sure if this ever has been used for games. I talked about it recently in a PM, copy paste: So the idea is, if you have a maze, put water to the target until it flows out at the source, and then just follow the path where height of water increases the most.
  13. Yes, but do not confuse colors and normals. The color gradient is a result of interpolated normals and using them for shading to get the color. (So dpending on shading, there may be other unknown factors that affect colors and how smooth they change over the surface) Finally it's also worth to know that even if normals form a nice gradient over a single triangle, the gradient (or slope, or derivative) itself is not continuous accross edges. Se even with interpolation and per pixel shading the tessellation can become visible unfortunately (would be too expensive to fix).
  14. Most triangle meshes are a discrete approximation of a continuous, curved surface, so interpolated normals are just a visual trick to make them appear smooth and curvy again.
  15. JoeJ

    3D smooth voxel terrain LOD on GPU

    While reading this, i noticed it's a similar approach to the method from @spacerat from my first post. Which made me aware of this: IIRC, Spacerat used indexed meshes, and eventually this also leads to a simpler edge collapse function. (You should look up his code to compare) The thing is, researchers working on geometry processing will just use Half-Edge for everything because it can do everything and they have thier frameworks. (I think Leif Kobbelt also worked on https://www.openmesh.org/ which is a Half-Edge library) I don't think Half-Edge is necessarily the best chioce for simplification in a game. (Although physics engines use it too for collision detection... really not sure)
  16. JoeJ

    3D smooth voxel terrain LOD on GPU

    You may be the first who does this on GPU - would be worth a blog post then... The main problem will be the complexity of the edge collapse operation. Here my code for that so you can imagine: bool HEMesh_Modeling::IsCollapseableEdge (const int edge, int *data) { assert (edge!=-1); int loop[2]; int prev[2]; int next[2]; loop[0] = edge; loop[1] = GetEdgePair(edge); int vI0 = GetEdgeVertex(loop[0]); int vI1 = GetEdgeVertex(loop[1]); // do not collapse edge if isolating a vertex int edgeCount0 = GetVertexEdgeCount(vI0); int edgeCount1 = GetVertexEdgeCount(vI1); if (edgeCount0 <= 1) return false; if (edgeCount1 <= 1) return false; // do not collapse noncontradictable loop for (int s=0; s<2; s++) { int eI = loop[s]; do { eI = GetEdgePair(eI); if (eI!=loop[0] && eI!=loop[1]) { int v0 = GetEdgeVertex(eI); int v1 = GetEdgeVertex(GetEdgePair(eI)); if (v0==vI0 && v1==vI1) return false; if (v1==vI0 && v0==vI1) return false; } eI = GetEdgeNext(eI); if (eI!=loop[0] && eI!=loop[1]) { int v0 = GetEdgeVertex(eI); int v1 = GetEdgeVertex(GetEdgePair(eI)); if (v0==vI0 && v1==vI1) return false; if (v1==vI0 && v0==vI1) return false; } } while (eI != loop[s]); } prev[0] = FindEdgePrev(loop[0]); prev[1] = FindEdgePrev(loop[1]); next[0] = GetEdgeNext(loop[0]); next[1] = GetEdgeNext(loop[1]); // do not collapse edge on isolated remaining triangle if (edgeCount0==2 && edgeCount1==2) { if (GetEdgeVertex(prev[0]) == GetEdgeVertex(prev[1])) return false; } if (data) { data[0] = loop[0]; data[1] = loop[1]; data[2] = prev[0]; data[3] = prev[1]; data[4] = next[0]; data[5] = next[1]; data[6] = vI0; data[7] = vI1; } return true; } int HEMesh_Modeling::CollapseEdge (const int edge) { assert (edge!=-1); int data[8]; if (!IsCollapseableEdge (edge, data)) return -1; int loop[2]; int prev[2]; int next[2]; int vI0, vI1; loop[0] = data[0]; loop[1] = data[1]; prev[0] = data[2]; prev[1] = data[3]; next[0] = data[4]; next[1] = data[5]; vI0 = data[6]; vI1 = data[7]; bool collapse[2] = { prev[0] == GetEdgeNext(next[0]), prev[1] == GetEdgeNext(next[1])}; // move edges from v1 to v0 int vEI = GetVertexEdge(vI1); do { SetEdgeVertex(vEI, vI0); //ImGui::Text(" Set edge %i to vertex %i", vEI, vI0); vEI = GetEdgeNext(GetEdgePair(vEI)); } while (vEI != GetVertexEdge(vI1)); SetVertexEdge(vI1, -1); // update remaining vertex if (GetVertexEdge(vI0) == loop[0]) SetVertexEdge(vI0, GetEdgePair(prev[0])); // update edges for (int s=0; s<2; s++) { if (collapse[s]) { int vIp = GetEdgeVertex(prev[s]); if (GetVertexEdge(vIp)==prev[s]) SetVertexEdge(vIp, GetEdgePair(next[s])); int vIn = GetEdgeVertex(next[s]); if (GetVertexEdge(vIn)==next[s]) SetVertexEdge(vIn, GetEdgePair(prev[s])); int pair0 = GetEdgePair(prev[s]); int pair1 = GetEdgePair(next[s]); SetEdgePair(pair0, pair1); SetEdgePair(pair1, pair0); DisconnectEdge(prev[s]); DisconnectEdge(next[s]); } else SetEdgeNext(prev[s], next[s]); } // update polys for (int s=0; s<2; s++) { int pI = GetEdgePoly(loop[s]); if (pI==-1) continue; if (collapse[s]) SetPolyEdge(pI,-1); else if (GetPolyEdge(pI) == loop[s]) SetPolyEdge(pI, prev[s]); } DisconnectEdge(loop[0]); DisconnectEdge(loop[1]); //SetVertexPos(vI0, pos); return vI0; } (I had to split it into two functions for some reason, and i use the term 'Edge' everywhere, should have used 'Half' instead) It's full of branches, indirection, random memory access - not the ideal case for a compute shader. Either this (+ geomoprhing for continuous LOD if needed), or recording the changes happening from edge collpases. But because you support runtime changes of the terrain you can't do that, i guess. Yeah, that's what i would do. It's easy and suits GPU implementation well (and i'm really the last who would say GPUs can do only simple brute force stuff.) Do you already have some physics? Here a LOD approach might not work because abrupt changes on the mesh cause collision issues, and continuous changes would still add energy to the physics system. Having chunks of constant detail and downloading those nearby dynamic objects sounds more robust and practical. (I never heared about LOD for physics, although it would be an interesting topic.) If so, all you would need the whole scene for would be path finding. And this alone would not justify the efford we discuss here IMO. Pathfinding on GPU could be an option too. (Diffusion approach could work better here than the usual graph algorithms, depending on what you need.)
  17. Even with those obvious optimizations the problem still requires either poly clipping for an accurate soultion (e.g. the beam tree - one of Cramacks failures), or a discrete sampling approach like rasterizing or raytracing a frame buffer representing the frustum (a narrower frustum is still a frustum). Any of this is challenging even for a single viewport, but much too slow for the line of sight tests needed for many players / bots. AFAIK, all 3D games use raytracing for this purpose, with a single ray (EDIT: or a few of them, maybe for each larger bone of the skelton?), but i remember 2D games that had accurate clipping solutions. Explains why the bad guys in games often fail to see me
  18. Sure, could be solved by jittereing the ray and using a temporal filter like visibility = visibility * 0.95 + newVisibilty * 0.05 (the lag from this would even make ai behaviour more natural) To jitter the ray use a random position on a bounding capsule around palyers for example, but will require to trace two rays then instead just one. When using simplified geometry for the purpose (maybe already there for physics / occlusion culling), or having simple geometry like Quake, the minimalistic approach should be good enough, and tiny / dynamic objects like flies could be ignored. Which usual occlusion culling algorithm would you propose, to handle this at reasonable performance?
  19. Build a line between the two players. If the line is outside both frustums, they can't see each other. Otherwise trace a ray through the level to see if the ray hits any obstacles in between so view is blocked. If not, any player who has the ray in frustum sees the other player.
  20. JoeJ

    3D smooth voxel terrain LOD on GPU

    I did it for loading indexed meshes to get started. For this reason i made the simple solution using std::map. I use the mesh editing because i work on quadrangulation, and i made edit operations like create polys, edge collapse, edge rotation etc. Likely the same stuff you would need for dynamic LOD. While working on this i realized the map is not necessary. Maybe yes - makes sense, but not sure. Converting indexed mesh to half-edge could be just as good. (The example below is more the kind of half edge mesh from indexed) I do not target realtime, but here an example (of how slow it is ): So that's a tessellated bunny model, with editing ops used for tessellation. Input mesh (solid random color) has 2500 vertices, and the tessellation (blue wire) has 15500. Takes about 7 seconds on single core. (looks like delauney, but i use a trick to align hex grids to triangles so i do not need expensive delauney triangulation algorithm. It's just connecting grid points to triangles, followed by edge flips and smoothing to improve the result - very most of those 7 seconds are used for mesh creation and editing.) I have no idea how fast such things can be for realtime use. I do only care about time complexity and try to reserve memory whenever possible. Multithreading, cache efficiency, avoiding dynamic allocation... that's definitively a lot of work to make such stuff fast. ( @Gnollrunner should be able to give a much better answer) Anyways, i would still think about alternatives first. For example, if you have a volume, would it work to downscale the volume, make surface net on GPU and transfer this back to CPU? Mesh simplification (which i assume you want to do on CPU from high res surface net) sounds like you could loose a lot from the advantage to generate your stuff on GPU so far. I have a mesh simplification stage as well in my project, which uses edge collapses and a priority queue - pretty standart, and not so suited for realtime. Here some work of a guy who tired to avoid the need for a queue, but not aiming realtime either: http://voxels.blogspot.com/2014/05/quadric-mesh-simplification-with-source.html For realtime usually people try to precalculate the simplification process, like progressive meshes do. To me it seems much less work to downscale the volume and then use some isosurface extraction.
  21. JoeJ

    3D smooth voxel terrain LOD on GPU

    That's quite involved. Personally i came up with two options: A simpler one, i could post the code (just let me know), but it requires a map to track incomplete half edges. So probably bad for realtime. Later i had to add full mesh editing functionality. And now i use just that instead the above. Here there is no need for a map, instead the incomplete mesh is traversed to make sure half edges find their proper pair. I'm not sure if that's faster but guess so. (But too much code to post. Also my entire work aims preprocessing not realtime.) Actaully i do not remember about details. Personally i like half-edge because it is easier to get things done than with alternatives i had used before. But it is almost impossible to write code that is intuitive or easy to follow, and comments do not help much to imagine what goes on geometrically. Because of this it is hard to learn from code of others, reinventing the wheel might be faster and better here. However, this guys blog was helpful for me: http://kaba.hilvi.org/homepage/blog/halfedge/halfedge.htm
  22. JoeJ

    Fractals in games

    The game POLLEN used fractals for it's ending sequence. Felt like 2001 - Space Odyssey, very cool.
  23. Usually, just sum up all samples and take the average.
  24. I assume the very most programmers learned programming very quickly. Maybe a matter of weeks / months but not years. Programming itself is not hard for us. Solving problems, learning required math, keeping large codebases maintable... that's hard, never the programming itself. But many people just have not the ability to learn the very basics, like others who never can learn a musical instrument. They might learn to play a song given notation and long time practice, but they can not learn improvisation or composition. After all those years it certainly seems what you do is similar to this music example, and it might be just a waste of time to continue. So why do you pursue, why not GameMaker for example?
  • 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!