JoeJ

Members
  • Content count

    565
  • Joined

  • Last visited

Community Reputation

2528 Excellent

About JoeJ

  • Rank
    Advanced Member
  1. Recast works by voxelization and then producing some low poly navmesh? Do you think this might work for low poly occluders as well? That's what i'm looking for: A single double sided polygon for each wall
  2. You can use a BSP to seperate solid from empty space if the leafs of the tree contain convex polyhedra, which are either all solid or all empty. IIRC Quake used empty leafs, so if you are in a cube like room it's likely all wall that you see are the surface of a single leaf node (though there may be some splits dividing the room into two or more volumes). If there is a door to another room, the empty volume inside the door is another leaf, and the other rooms walls form another leaf as well. There are some chapters about BSP in Quake / Doom here: http://www.jagregory.com/abrash-black-book/ The faces of the door volume are invisible but still there. They connect one empty space to another - those faces ar often referred as portals and have been used to precompute a PVS to get a list of potential visible leafs from the camara leaf. See for the nightmare of implementation - you should njot need this, but just to give you a hint on complexity: http://www.cs.utah.edu/~jsnider/SeniorProj/BSP/default.htm So for you it might be better to store solid instead empy leafs. The algorithm would help to find a single fused mesh from multiple models that build up your world, and from that you could use a polygon reduction algorithm to get a low poly version. Or you can reduce the BSP itself (e.g. remove the few small leafs that from a football in a stadium). Also low poly BSPs are very good to ray trace (should be much faster than voxels), if you want it to trace sound rays around in real time. BSPs are often used for boolean CSG mesh opartions (union, subtract, intersection), maybe a good search term as well. But it's really the last option - it will drive you crazy to do this robustly for the detailed stuff we use in actual games. I guess you have to invest so much time, building low poly meshes by artists might be cheaper So if voxels do it, why is performance an issue? Do you want to do this in real time? Generating BSP in real time is no option. BSP can handle details at any scale and are exact, but that's the only advantage over easy voxels and this should not be necessary for sound. Edit: Did you try Simplygon? I did not find the occlusion mesh generation in the tool, also i did not find the SDK after installation, but this stuff should be there.
  3. Yeah, me too. But i'm not sure if it's my age or the current state of games. I've had a similar time 7-8 years back, then i've discovered the game Penumbra (predecessor of Amnesia), and this game was so awesome i really gained a lot of motivation again. At the moment there are quite a few games around that i think are very good, but nothing stands out. It has always been like this - mostly. The best times are when there is a leap in technology that pushes new ideas / genres, but what could come up next? VR alone seems not quite enough. But younger people seem to be still excited about games. They dress like Overwatch characters, football players do a Switch pose after a goal... Seems there is more interest than ever, although we've had games that were so much better in the old days than actual ones, right? However, if i play games they constantly appear too big and too complex for no reason. Boring huge open worlds, pages of UI to level up your character, dozens of things you need to know. This is true not for all but often for very popular and sucessfull titles. I totally do not understand how people enjoy this and have enough time - this is where i really feel old
  4. This one may be quite important. The typical game of someones dreams would be either much too expensive to do, or technically (yet) impossible. Some obvious things: Characters can't think, talk or walk - they can only act based on very poor artificial intelligence, play animation and recorded speech. Worlds can't be infinitely large and detailed. Etc. So if your ideas contain stuff never seen before, you should clarify if this stuff is technically possible at first.
  5. That's a typical idea for someone being new to this. I'll point some things out... If your user uses only e.g. the top left corner of the intire space, you can traverse the quadtree once until you find the top most non empty node node. You can use this node as the root for all your collision or culling queries. This saves you from treversing some top levels of the tree each time for nothing and gives the performance improvement you expect from your idea. Notice that using a single tree you already have multiple trees (each node represents a subtree), so there is rarely a need to use multiple trees with an additional mechanism to handle this. So, no, use just one quadtree and no hash table at all. There is something you miss: The scene is dynamic, things will move around. The hash table approach causes dynamic memory managenment during runtime because the usage of lists (and maps), but you don't know how large they need to be. Lets see what happens under the hood (i'll use the term 'grid' instead of spatial hasing, it's the same thing) Each grid cell needs a resizable vector to store pointers to all objects. The system allocates some memory for the list, but if it becomes too large it needs to allocate a larger chunk of memory and copy the list to the new place. This may happen severall dozens, hundrets or tousand times per frame and can become a bottleneck. So using the grid we have this: gridCell->list[obj0, obj1, obj2, ...] Also, you need to store the objects in multiple cells, and to avoid duplicates, the suggested usage of a map needs to look up the current map each time a new item is to be added. To speed this search up, the system may implement a binary tree or something, resulting in building a tree for each query. (Compare this with the quadtree approach: It uses only one tree and it's already there) So this is terribly slow, but how can we do better? Using a multiresolution grid can fix this: Imagine our finest grid level 0 has 8*8 cells, each 1*1 in size, level 1 has 4*4 cells, each 2*2 level 2 has 2*2 cells, each 4*4 level 3 has 1 cell 8*8, the whole scene Then we have a circle object with a diameter of 1.9 and we put this in a cell of level 1, because we can be sure this and the neighbouring cells will cover the intire object. To find collisions we need to look at the neighbouring cells but also at the correspondending cells an their neighbours at levels 2 & 3 to detect collisions with larger objects. We do not need to go down and check cells from level 0, because collisions with smaller objects will be found from those smaller objects. You can optimize to check only 3 neighbours instead of all 8. So this works, and because each object needs only one cell we don't need a vector of pointers per cell, all we need is: mrGridCell->obj0->obj1->obj2 No dynamic allocation or duplicates problem here. A loose quadtree is just an extension of this idea, you may start with a multiresolution grid and if this works go to quadtree.
  6. You could look at the success story of Superhot: They had a great idea of gameplay mechanic, made a free webgame everyone tried out, then it became a full game. Notice that nobody stole their idea. They used Unity engine which people say is beginner friendly. I would not rush to talk too much to strangers by Email - they have more experience so it's a lot easier for them to turn it to money on their own. Forums like this can help to solve specific problems without the need to expose your idea. You need to strip down your vision to the bare minimum (which may be still a year or more of work to get something going).