March 9, 2019 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >
March 9, 2019 [00:09:12] *** LunarJetman <LunarJetman!LunarJetma@5ec16e1a.skybroadband.com> has quit IRC (Ping timeout: 245 seconds)[00:19:59] *** freefork_afk is now known as freestyledork[00:28:39] *** LunarJetman <LunarJetman!LunarJetma@5ec16e1a.skybroadband.com> has joined #gamedev[00:38:39] *** adamsky <adamsky!~quassel@178235186241.unknown.vectranet.pl> has quit IRC (Remote host closed the connection)[00:42:51] *** diwr <diwr!~bruno@unaffiliated/diwr> has joined #gamedev[01:00:49] *** joshbright <joshbright!~joshbrigh@rrcs-24-123-119-190.central.biz.rr.com> has quit IRC (Ping timeout: 246 seconds)[01:01:48] *** knops <knops!~yannick@ip-62-143-84-11.hsi01.unitymediagroup.de> has quit IRC (Remote host closed the connection)[01:10:19] *** ZeroSystem <ZeroSystem!45f81b6b@gateway/web/freenode/ip.69.248.27.107> has joined #gamedev[01:12:50] *** diwr <diwr!~bruno@unaffiliated/diwr> has quit IRC (Quit: Konversation terminated!)[01:20:23] *** refs <refs!~refs@dslb-188-103-172-230.188.103.pools.vodafone-ip.de> has joined #gamedev[01:24:51] *** mandeep <mandeep!~mandeep@unaffiliated/mandeepb> has joined #gamedev[01:47:02] *** Beliar <Beliar!~Beliar@2a02:8108:9640:6c42:bdf3:eae4:e3f8:e2cd> has quit IRC (Read error: Connection reset by peer)[01:55:27] *** LunarJetman <LunarJetman!LunarJetma@5ec16e1a.skybroadband.com> has quit IRC (Ping timeout: 252 seconds)[02:10:18] *** xen74 <xen74!~xen74@2001:44b8:2e3:9b00:716b:85b3:5a2c:a36e> has joined #gamedev[02:25:39] *** mandeep <mandeep!~mandeep@unaffiliated/mandeepb> has quit IRC (Quit: Leaving)[02:27:24] *** togo <togo!~togo@2a01:5c0:e08b:76e1:45:c1e6:1bae:629f> has quit IRC (Quit: Leaving)[02:27:31] *** freestyledork is now known as freefork_afk[02:49:32] *** R2robot <R2robot!~R2robot@unaffiliated/r2ro> has quit IRC (Ping timeout: 272 seconds)[03:25:41] *** blackpawn <blackpawn!blackpawn@gateway/vpn/privateinternetaccess/blackpawn> has quit IRC (Remote host closed the connection)[03:35:06] *** RoadKillGrill <RoadKillGrill!~RoadKillG@cpe-75-187-140-196.neo.res.rr.com> has joined #gamedev[03:56:27] *** R2robot <R2robot!~R2robot@unaffiliated/r2ro> has joined #gamedev[03:57:48] *** refs <refs!~refs@dslb-188-103-172-230.188.103.pools.vodafone-ip.de> has quit IRC (Quit: refs)[04:01:31] *** freefork_afk is now known as freestyledork[04:01:46] *** [Relic] <[Relic]!~Relic]@2602:306:33a3:6d30:4d6b:bb12:60d0:5f70> has joined #gamedev[04:06:55] *** pavonia <pavonia!~user@unaffiliated/siracusa> has joined #gamedev[04:46:34] *** [Relic] <[Relic]!~Relic]@2602:306:33a3:6d30:4d6b:bb12:60d0:5f70> has quit IRC (Quit: Leaving)[04:50:09] *** pulse <pulse!~pulse@unaffiliated/pulse> has quit IRC (Quit: the cheetahmen ran off... and now ... the cheetahmen)[05:02:24] *** mandeep <mandeep!~mandeep@unaffiliated/mandeepb> has joined #gamedev[05:02:27] *** qrestlove <qrestlove!~qrestlove@2601:446:c201:f560:2115:d724:c123:1a9> has quit IRC (Ping timeout: 252 seconds)[05:08:21] *** freestyledork is now known as freefork_afk[05:19:12] *** Twipply <Twipply!~Twipply@unaffiliated/twipply> has quit IRC (Quit: Leaving)[05:30:26] *** _DB <_DB!6ccefbd9@gateway/web/cgi-irc/kiwiirc.com/ip.108.206.251.217> has quit IRC (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)[05:51:19] *** mandeep <mandeep!~mandeep@unaffiliated/mandeepb> has quit IRC (Quit: Leaving)[05:52:48] *** Tylak <Tylak!~Tylak@074-135-002-092.res.spectrum.com> has quit IRC (Quit: Nettalk6 - www.ntalk.de)[06:05:38] *** moongazer <moongazer!~moongazer@unaffiliated/moongazer> has joined #gamedev[06:09:37] *** RoadKillGrill <RoadKillGrill!~RoadKillG@cpe-75-187-140-196.neo.res.rr.com> has quit IRC (Read error: Connection reset by peer)[07:14:42] *** diwr <diwr!~bruno@unaffiliated/diwr> has joined #gamedev[07:28:50] *** terminx <terminx!~terminx@173-16-252-156.client.mchsi.com> has quit IRC (Ping timeout: 255 seconds)[07:29:30] *** moongazer <moongazer!~moongazer@unaffiliated/moongazer> has quit IRC (Read error: Connection reset by peer)[07:31:45] *** terminx <terminx!~terminx@173-16-252-156.client.mchsi.com> has joined #gamedev[07:33:00] *** moongazer <moongazer!~moongazer@unaffiliated/moongazer> has joined #gamedev[07:47:34] *** brainzap <brainzap!~brainzap@217.22.129.78> has joined #gamedev[08:14:38] *** Kelzorz <Kelzorz!~Kelzorz@162.104.220.155> has quit IRC (Quit: 0x80)[08:16:11] *** Serpent7776 <Serpent7776!~Serpent77@90-156-31-193.internetia.net.pl> has joined #gamedev[08:46:51] *** moongazer <moongazer!~moongazer@unaffiliated/moongazer> has quit IRC (Ping timeout: 252 seconds)[08:46:57] *** universecoder <universecoder!~moongazer@unaffiliated/moongazer> has joined #gamedev[08:56:44] *** zalt_ <zalt_!~lambda443@unaffiliated/lambda443> has joined #gamedev[08:59:47] *** zalt <zalt!~lambda443@unaffiliated/lambda443> has quit IRC (Ping timeout: 240 seconds)[09:17:37] *** brainzap <brainzap!~brainzap@217.22.129.78> has quit IRC (Quit: My tummy says it's time to sleep Mr. Bubbles.)[09:19:38] *** brainzap <brainzap!~brainzap@217.22.129.78> has joined #gamedev[09:20:57] *** Beliar <Beliar!~Beliar@2a02:8108:9640:6c42:3cc6:3051:e9c1:54c2> has joined #gamedev[09:24:19] *** brainzap <brainzap!~brainzap@217.22.129.78> has quit IRC (Ping timeout: 268 seconds)[09:26:40] *** ShadowIce <ShadowIce!~pyoro@unaffiliated/shadowice-x841044> has joined #gamedev[10:12:04] *** brainzap <brainzap!~brainzap@178.197.235.13> has joined #gamedev[10:34:45] *** brainzap <brainzap!~brainzap@178.197.235.13> has quit IRC (Quit: My tummy says it's time to sleep Mr. Bubbles.)[10:35:37] *** ShadowIce <ShadowIce!~pyoro@unaffiliated/shadowice-x841044> has quit IRC (Quit: Leaving)[11:21:48] *** gogoprog <gogoprog!~gogoprog@2a02:a03f:4466:7600:3ab1:d4d4:9081:13c3> has joined #gamedev[11:24:39] *** togo <togo!~togo@2a01:5c0:e08b:76e1:45:c1e6:1bae:629f> has joined #gamedev[12:05:27] *** immibis <immibis!~immibis@125-238-72-168-fibre.sparkbb.co.nz> has quit IRC (Ping timeout: 240 seconds)[12:12:15] *** brainzap <brainzap!~brainzap@178.197.235.13> has joined #gamedev[12:19:40] <Donitzo> wow, so I am jumping between AABB Tree and Spatial indexing back and forth[12:19:47] <Donitzo> like I'm at 50 50[12:19:55] <Donitzo> damnit[12:20:14] <Donitzo> it is clear to me that an AABB Tree won't scale well for GIGANTIC WORLDS[12:20:32] <Donitzo> but it's also clear that spatial indexing doesn't do well with objects of wildly different sizes[12:21:03] <Donitzo> Sweep and prune is out of the question for massive worlds[12:21:26] <Donitzo> quadtrees suffer from the same issues as AABB trees[12:22:31] <Donitzo> correction: massive worlds in more than one axis[12:23:59] <Donitzo> by spatial indexing I mean a spatial grid[12:24:16] <Donitzo> a sparse spatial grid[12:24:46] <Donitzo> </ramble>[12:26:09] <Donitzo> (trees won't scale well for large worlds because each time you doublt the number of entities you add an additioanl collision check for everything)[12:26:15] <Donitzo> double*[12:27:13] <Donitzo> or in the case of quadtrees I guess... each time you quadruple the number of entities[12:27:21] <Donitzo> at best...[12:29:55] <NiniGeo2> Hmmmm, it sounds to me like you may be doing an inverse-quadtree if you have to change your quadtree when the number of entities grows larger :o[12:30:34] <Donitzo> I haven't mentioned that detail yet, I just meant the actual collision checks[12:30:35] <NiniGeo2> Typically a quadtree is more like a quad-bucket-tree, where you have a fixed number of buckets and entities can be placed into the buckets. Therefore, your tree doesn't have to grow if the number of entities in one bucket grows too large.[12:30:37] <Donitzo> as the trees grow higher[12:30:58] *** xen74 <xen74!~xen74@2001:44b8:2e3:9b00:716b:85b3:5a2c:a36e> has quit IRC (Read error: Connection reset by peer)[12:31:16] <Donitzo> let's for the sake of simplicity assume the entire world is static for now[12:31:44] <Donitzo> and we're just trying to check what all collides[12:32:48] <Donitzo> can you do reverse collision checks using either AABB or quad trees?[12:33:00] <Donitzo> start from the leaves and only travel as high as reqired[12:33:11] <Donitzo> required*[12:33:41] <NiniGeo2> Typically with quadtrees they're set up in such a way that you only need to check for collisions with things in your immediate bucket (or depending on how you store your entries, with your bucket and its sibling-buckets).[12:34:29] <Donitzo> what about objects that overlap nodes[12:34:37] <Donitzo> like let's say, an object at the very center of world[12:34:46] <Donitzo> it'd have to be checked with 4 global branches[12:36:35] *** brainzap <brainzap!~brainzap@178.197.235.13> has quit IRC (Quit: My tummy says it's time to sleep Mr. Bubbles.)[12:41:53] <Donitzo> one solution is to store objects in the biggest node able to accomodate it, and check collisions from the leaf nodes and up[12:42:36] <Donitzo> *smallest node able to accomodate it*[12:43:05] <Donitzo> another solution is to store multiple references of the same object in the tree[12:43:21] <Donitzo> at the leaves[12:43:30] <Donitzo> that can't possibly be efficient[12:44:22] <Donitzo> and as you said, you could also check collisions with sibling nodes, but I have no idea how that works[12:44:31] <Donitzo> seems a bit odd[12:45:14] <Donitzo> also that method forces you to define some kind of... minimum object size[12:45:15] <Donitzo> bleh[12:45:16] *** diwr <diwr!~bruno@unaffiliated/diwr> has quit IRC (Quit: Konversation terminated!)[12:48:44] <Donitzo> maximum*[12:52:00] <NiniGeo2> I wrote a fairly efficient octree spatial partitioner for a former project I did, it worked pretty well. We used it for hierarchical frustum culling, nearby light gathering, object picking (eventually replaced with Bullet's raycast function), and some other stuff.[12:53:22] *** Groogy <Groogy!~Groogy@90-227-38-205-no61.tbcn.telia.com> has joined #gamedev[12:53:53] <Donitzo> Oh I agree that they are efficient[12:54:13] <Donitzo> but I suspect that the efficiency will diminish once you go beyond like, millions of objects[12:54:18] <Donitzo> I'm not sure[12:54:46] <Donitzo> at least there are some issues with dealing with things like overlap mentioned above[12:55:16] <Donitzo> again, assuming a static world[12:57:07] <NiniGeo2> See: https://sourceforge.net/p/aedra/code/HEAD/tree/Project%20Aedra/Project%20Aedra/Renderer.cpp#l2122 for the renderer use, and https://sourceforge.net/p/aedra/code/HEAD/tree/Project%20Aedra/Project%20Aedra/ObjectsIntersectingBox.h#l8 for some of the physics uses.[12:57:21] <NiniGeo2> Here's how the octree gets split (the most complicated part of building the whole tree system): https://sourceforge.net/p/aedra/code/HEAD/tree/Project%20Aedra/Project%20Aedra/StreamLoader.cpp#l66[12:58:33] <NiniGeo2> Yeah it did turn out to be pretty efficient for a pretty large number of moving objects. I guess the general insertion algorithm into this octree was to take an object's AABB and "push it down" as far as it will "fit" in the octree. I'm sure that a quadtree implementation would work similarly.[12:59:16] <Donitzo> yeah, I guess that was one of the methods I described[12:59:34] <Donitzo> <Donitzo> one solution is to store objects in the *smallest node able to accomodate it*, and check collisions from the leaf nodes and u[12:59:39] <Donitzo> hmm[12:59:45] *** brainzap <brainzap!~brainzap@217.22.129.78> has joined #gamedev[13:00:03] <NiniGeo2> Then at runtime if you want to say find the nearest objects within X distance, you quickly build an AABB of side length 2X centered at your test point, and then push that AABB as far down in the tree as it'll go, running AABB-vs-AABB tests along the way for any encountered objects on your trip down the tree to find ones that are close to you.[13:00:04] <Donitzo> but that method will suffer when you have things at the borders between nodes[13:00:39] <Donitzo> imagine for example you have a world with 1.000.000.000 objects, and thousands of those are in between the root node branches[13:00:49] <Donitzo> which will now have to be checked every for every collision[13:00:56] <NiniGeo2> Ah so I actually had a switch for that, since in different cases you might want to do different things. I have the concept of a "graphics octree" and a "physics octree", and for one the rule is that only leaf nodes can store objects, and in the other it's allowed to store objects on branch nodes.[13:01:49] <NiniGeo2> I just called it "graphics" and "physics" octree because I figured that the big distinction was between the use cases. It sounds like what you want is a "physics octree".[13:02:02] <Donitzo> in my case they're both[13:02:25] <Donitzo> with an AABB quadtree you can just as easily render or collide[13:02:49] <Donitzo> hell, you could just make the camera its own object[13:02:52] <Donitzo> and just render its collisions[13:02:57] <Donitzo> really quite simple[13:03:05] <NiniGeo2> Mmhmm[13:06:47] <Donitzo> nope, the only reasonble alternative for huge worlds is to store things at the leaf level always[13:07:01] <Donitzo> it's not an option to store things at the higher levels[13:07:10] <Donitzo> the performance would take a dump[13:07:34] <NiniGeo2> Well I mean how many objects are we talking about?[13:07:52] <Donitzo> let's for the sake of arguments say... 1.000.000.000[13:07:55] <Donitzo> if they can fit in memory[13:08:00] *** knops <knops!~yannick@ip-62-143-84-11.hsi01.unitymediagroup.de> has joined #gamedev[13:08:08] <NiniGeo2> Would these be really simple objects, or complex ones?[13:08:19] <Donitzo> static AABBs for now[13:09:14] <Donitzo> and I want to do one complete check between collisions for all of them[13:09:30] <Donitzo> that's a good test case[13:09:58] <NiniGeo2> Hmmm, for a million objects checking every frame might get rough...[13:10:20] <NiniGeo2> Of course you'd need some sort of spatial partitioning to do this, 'cuz 1 million squared checks is never gonna work.[13:10:20] <brainzap> profile before you talk[13:10:24] <Donitzo> naw, just assume that we need a single check now[13:10:43] <Donitzo> I don't need to profile to see the obviously issues in the quadtree approach[13:10:53] <Donitzo> which can be solved[13:10:58] <Donitzo> obvious*[13:11:44] <Donitzo> 999.999.999.000 entities checking collisions with 1.000 entities overlapping the root branches would tank anything[13:11:57] <Donitzo> did I add 999 too much there[13:12:04] <Donitzo> 999.999.000 *[13:12:47] <NiniGeo2> 1 billion objects? :o[13:13:04] <Donitzo> swedish or english billion?[13:13:21] <NiniGeo2> I wasn't aware there was a difference :o[13:13:24] *** adamsky <adamsky!~quassel@178235186241.unknown.vectranet.pl> has joined #gamedev[13:13:43] <Donitzo> "In British English, a billion used to be equivalent to a million million (i.e. 1,000,000,000,000), while in American English it has always equated to a thousand million"[13:14:05] <Donitzo> Sweden used... I don't even remember anymore[13:14:07] <NiniGeo2> Oh, I mean the metric kind. 1 gigaobjects.[13:16:44] <NiniGeo2> Anyhow, I don't think that you could do 10^9 of any real kind of work per frame. Even if you had a 100-core, 10GHz processor, you'd only have 1000 cycles to do your whole thing, even if you maxed out the entire CPU, and even then you'd clock in at a whopping 1.0 FPS without doing any kind of rendering or audio or networking or input or other game update stuff.[13:17:01] <Donitzo> let's assume its a one-off thing[13:17:09] <Donitzo> like, when the world is initialized[13:17:26] <NiniGeo2> Oh then as long as it doesn't noticeably impact load times, then it can take as long as you want it to take.[13:18:12] <Donitzo> It's just an example scenario to illustrate an issue with using a quadtree for a huge number of entities[13:18:46] <Donitzo> as opposed to for example a spatial grid[13:19:56] <NiniGeo2> So you would store the grid locations that each object's AABB overlaps?[13:20:22] *** knops <knops!~yannick@ip-62-143-84-11.hsi01.unitymediagroup.de> has quit IRC (Ping timeout: 250 seconds)[13:20:25] *** MrSponck <MrSponck!~yannick@ip-62-143-84-11.hsi01.unitymediagroup.de> has joined #gamedev[13:21:12] <Donitzo> the spatial grid approach would use a hash table with keys like cell_x + cell_y / cell_count_x and value an array of entities within that cell[13:21:20] <Donitzo> when a cell becomes empty it is erased from the hash table[13:21:45] <Donitzo> when a cell becomes occupied the key is added together with an array from an object pool[13:21:51] <Donitzo> quite simple, straightforward[13:21:53] <Donitzo> efficient[13:22:08] <Donitzo> but doesn't work well when there are objects much larger or smaller than the cell size[13:22:50] <Donitzo> cell_y * cell_count_x[13:22:52] <Donitzo> *[13:23:42] <Donitzo> using this approach entities would only need to check collisions with other entities within the same cell[13:24:22] *** MrSponck is now known as knops[13:24:25] <Donitzo> and larger entities would need to add itself to more than one cell again[13:24:43] <Donitzo> thats the issue[13:25:12] <Donitzo> something like a planet overlapping 100000 cells would take a huge time to update when moving[13:26:26] <NiniGeo2> Right. Quadtrees solve that move problem by reinserting at a higher level in the tree. But I guess you're saying that quadtrees have the problem where you have to check each branch in the tree above from an object's leaf if you want to find collisions with that object?[13:27:26] <Donitzo> yes[13:27:44] <Donitzo> well, the problem is when you have a lot of smaller objects closer to the root of the tree due to them overlapping nodes[13:27:57] <Donitzo> having a few large objects closer to the root isn't a big concern[13:28:07] <Donitzo> but having tons of small objects overlap the root branches would be[13:29:02] <Donitzo> I assume now that when you try to find the smallest node able to hold an object, that also means that an object will be kept inside a branch in which it overlaps two leaves[13:29:18] <Donitzo> or two sub-branches*[13:29:39] <NiniGeo2> Yes, that was my solution with the octree that I linked earlier. It tries to find the smallest node that will fit an object's AABB, and it "pushes down" the AABB from the root through the tree until it either reaches a leaf node, or it can't fit into any smaller nodes.[13:30:44] <NiniGeo2> Then when you want to test for collisions, you take your test-AABB and push it down the tree as far as it will go, testing with objects along the way until your test finishes or you can't go any further.[13:30:53] <Donitzo> but this should be solveable by cutting up the large objects and pushing it down the tree[13:31:10] <Donitzo> BUT, then you're right back to the same issue as with the spatial grid[13:31:18] <Donitzo> large object updates taking a long time[13:32:04] <Donitzo> small objects would need to cut between branches, large objects not[13:32:27] <NiniGeo2> Hmmm, wouldn't small objects still need to be cut if they straddle between branches?[13:32:57] <Donitzo> yes, like a small object in the center of the world would need to be treated as 4 objects each in a quadrant of the world[13:33:12] <Donitzo> but, a HUGE object in the center of world would still need to be kept inside the root node[13:33:57] <Donitzo> how would you even determine whether or not to split an object like that[13:34:28] <Donitzo> I speak methaphorically split[13:34:39] <Donitzo> you don't actually need to split the object, just treat it as 4 objects in the tree[13:34:59] <NiniGeo2> I'm not sure if it's a good idea to split-or-not-split depending on the object size, because that makes testing complicated. If I'm testing for a collision, now I need to both test locally for small objects *and* test globally for large objects. It might be the worst of both worlds D:[13:35:53] <Donitzo> mmm maybe[13:36:05] <Donitzo> you would have to check from the leaves and up[13:36:25] <Donitzo> start from a leaf, check all collisions inside the leaf, check collisions between objects in the leaf and the leaf's parent[13:36:26] <Donitzo> and so on[13:36:30] <NiniGeo2> Yes. That is functionally the same as checking from the root down to the specific leaf where your object resides. You traverse the same nodes, just in reverse order.[13:36:36] <Donitzo> you never check in the reverse order[13:37:02] <NiniGeo2> For collision detection, does it matter which order you check in? Won't you stop after you find any collision?[13:37:13] <Donitzo> hmmm[13:37:40] <Donitzo> I guess not[13:37:46] <Donitzo> made sense at the time[13:38:00] <Donitzo> as long as its consistent[13:38:18] <Donitzo> so if you start from the root node, and the root node contains entity "planet"[13:38:23] <NiniGeo2> Yeah I think that so long as it's consistent it should be fine.[13:38:23] <Donitzo> planet will be checked with everything[13:38:36] <Donitzo> Oh yeah, but it would be really inefficient wouldn't it though[13:38:55] <Donitzo> now you check collisions between planet and every node in the entire tree[13:39:12] <Donitzo> so you iterate every node in the tree once for just that one entity[13:39:23] <Donitzo> instead of just traversing the reverse way from the leaf upward[13:39:35] <Donitzo> which would check only the HEIGHT of the tree for every collision check[13:41:54] <Donitzo> idunno, makes sense in my head but maybe I'm not thinking hard enough[13:43:25] <NiniGeo2> You should try it out :)[13:43:27] *** aly777 <aly777!~kes777@50-242-177-217-static.hfc.comcastbusiness.net> has joined #gamedev[13:46:00] <Donitzo> height of tree=3, root has planet, leaves have 2 objects each, node travelsals from root order=4*4, collision checks from root order=2*4*4+1*4*4, node travelsals from leaf order=4*4*2*2[13:46:11] <Donitzo> ok I guess from root is better[13:47:11] <NiniGeo2> I would recommend testing this out with some sample game data. The reason being that you're gonna do some fine-tuning (with respect to the node sizes and maximum tree depth and whatnot) that's going to affect the outcome significantly.[13:47:43] <Donitzo> I would but I do need to solve the conceptual problem of small objects overlapping nodes first[13:47:55] <Donitzo> because that will become an issue with enough objects[13:48:06] <Donitzo> "enough" objects[13:50:10] <NiniGeo2> Is this game going to actually have objects of such massively varying sizes?[13:50:52] <Donitzo> would be nice of the possibility was there to have massive seamless worlds[13:51:07] <Donitzo> if the*[13:52:40] <NiniGeo2> So I had a massive seamless world, broken up into cells, and then just had one octree per world cell. This led to the sort of situation of having a 2-level tree, where each cell had an octree, but the "top level" of world cells was just a flat grid.[13:54:06] <Donitzo> ah grid[13:54:11] <Donitzo> a mixture of spatial grid and octree[13:54:18] <Donitzo> What the hell brain[13:54:23] <Donitzo> ah yes*[13:54:43] <NiniGeo2> Yeah there's nothing preventing you from mixing and matching either. You could have an octree with grids at each leaf, or you could do what I did and have a grid with octrees in each grid cell.[13:54:55] <Donitzo> it does add a fair amount of complexity though[13:55:11] *** Twipply <Twipply!~Twipply@unaffiliated/twipply> has joined #gamedev[13:55:14] <NiniGeo2> Yeah it really does![13:55:29] <NiniGeo2> I don't think that there's any "right" or "wrong" answers here, you should do what works best for your specific game.[13:57:34] <Donitzo> well, an quadtree could work really well as discussed before if for example you added a constant value like "minAreaOverlap" to it, which would determine how much of a node an entity overlapping borders has to at least occupy to NOT be split and pushed further down[13:58:09] <Donitzo> minAreaOverlap=0.2 means that the overlapping object has to occupy at least 20% of the cell to not be split[13:58:19] <Donitzo> its one magic numbers, but it should be enough[13:58:23] <Donitzo> number*[13:59:07] * NiniGeo2 yawnz[13:59:13] <NiniGeo2> I'm gonna head to bed now, it was nice chattin' though :3[13:59:20] <Donitzo> yeah, thank you for the chat[13:59:27] <NiniGeo2> Good luck with your implementation![13:59:32] <Donitzo> danke[14:02:50] <Donitzo> and while I'm at it, I'm going to make the quadtree grow infinitely in reverse[14:02:56] <Donitzo> because I'm too lazy to figure out the correct size[14:25:11] *** LunarJetman <LunarJetman!LunarJetma@5ec16e1a.skybroadband.com> has joined #gamedev[14:27:07] *** zalt_ <zalt_!~lambda443@unaffiliated/lambda443> has quit IRC (Ping timeout: 240 seconds)[14:29:00] *** zalt <zalt!~lambda443@unaffiliated/lambda443> has joined #gamedev[14:52:39] *** diwr <diwr!~bruno@unaffiliated/diwr> has joined #gamedev[14:55:44] *** brainzap <brainzap!~brainzap@217.22.129.78> has quit IRC (Quit: My tummy says it's time to sleep Mr. Bubbles.)[15:22:07] *** jokoon <jokoon!~jokoon@2a01:e35:2e08:9f10:7dcc:b3af:1a09:5714> has joined #gamedev[15:30:32] *** gogoprog <gogoprog!~gogoprog@2a02:a03f:4466:7600:3ab1:d4d4:9081:13c3> has quit IRC (Read error: Connection reset by peer)[15:43:07] *** ShadowIce <ShadowIce!~pyoro@unaffiliated/shadowice-x841044> has joined #gamedev[15:43:32] *** jokoon9000 <jokoon9000!~jokoon@2a01:e35:2e08:9f10:b928:cfc8:2ff:7362> has joined #gamedev[15:43:37] *** jokoon9000 <jokoon9000!~jokoon@2a01:e35:2e08:9f10:b928:cfc8:2ff:7362> has quit IRC (Read error: Connection reset by peer)[15:46:27] *** jokoon <jokoon!~jokoon@2a01:e35:2e08:9f10:7dcc:b3af:1a09:5714> has quit IRC (Ping timeout: 258 seconds)[15:57:05] *** brainzap <brainzap!~brainzap@217.22.129.78> has joined #gamedev[16:05:00] *** zalt <zalt!~lambda443@unaffiliated/lambda443> has quit IRC (Remote host closed the connection)[16:08:04] *** adamsky <adamsky!~quassel@178235186241.unknown.vectranet.pl> has quit IRC (Ping timeout: 250 seconds)[16:20:45] *** RoadKillGrill <RoadKillGrill!~RoadKillG@cpe-75-187-140-196.neo.res.rr.com> has joined #gamedev[16:21:25] *** zalt <zalt!~lambda443@unaffiliated/lambda443> has joined #gamedev[16:25:11] *** pulse <pulse!~pulse@unaffiliated/pulse> has joined #gamedev[16:28:24] *** adamsky <adamsky!~quassel@178235186241.unknown.vectranet.pl> has joined #gamedev[16:33:20] *** Tylak <Tylak!~Tylak@074-135-002-092.res.spectrum.com> has joined #gamedev[16:35:43] <brainzap> pulse, Mr Kawaski expect you to deliver the game on monday[16:37:27] *** adamsky <adamsky!~quassel@178235186241.unknown.vectranet.pl> has quit IRC (Ping timeout: 240 seconds)[16:41:54] <pulse> oh[16:58:00] *** RoadKillGrill <RoadKillGrill!~RoadKillG@cpe-75-187-140-196.neo.res.rr.com> has quit IRC (Ping timeout: 252 seconds)[16:58:09] *** jokoon <jokoon!~jokoon@2a01:e35:2e08:9f10:b928:cfc8:2ff:7362> has joined #gamedev[17:01:14] <brainzap> if you can not deliver we will change your salary from 0, to -200$[17:12:47] *** RoadKillGrill <RoadKillGrill!~RoadKillG@cpe-75-187-140-196.neo.res.rr.com> has joined #gamedev[17:29:31] *** _DB <_DB!6ccefbd9@gateway/web/cgi-irc/kiwiirc.com/ip.108.206.251.217> has joined #gamedev[17:46:24] *** aly777 <aly777!~kes777@50-242-177-217-static.hfc.comcastbusiness.net> has quit IRC (Ping timeout: 252 seconds)[17:54:05] *** Kelzorz <Kelzorz!~Kelzorz@162.104.220.155> has joined #gamedev[17:54:15] *** CustersRevenge <CustersRevenge!~cppcon@187.39.238.73> has joined #gamedev[18:05:40] *** ShadowIce <ShadowIce!~pyoro@unaffiliated/shadowice-x841044> has quit IRC (Quit: Leaving)[18:10:36] *** zalt <zalt!~lambda443@unaffiliated/lambda443> has quit IRC (Ping timeout: 252 seconds)[18:12:41] *** solidfox <solidfox!~solidfox@unaffiliated/snake/x-2550465> has joined #gamedev[18:17:55] *** gareppa <gareppa!~gareppa@unaffiliated/gareppa> has joined #gamedev[18:24:17] *** pavonia <pavonia!~user@unaffiliated/siracusa> has quit IRC (Quit: Bye!)[18:26:47] *** gareppa <gareppa!~gareppa@unaffiliated/gareppa> has quit IRC (Quit: Leaving)[18:33:35] *** knops <knops!~yannick@ip-62-143-84-11.hsi01.unitymediagroup.de> has quit IRC (Remote host closed the connection)[18:44:24] *** [Relic] <[Relic]!~Relic]@2602:306:33a3:6d30:8d50:89d1:79eb:88a> has joined #gamedev[18:51:10] *** RandomCouch <RandomCouch!~RandomSof@207.219.200.115> has quit IRC (Quit: Leaving)[18:52:20] *** refs <refs!~refs@dslb-178-005-228-022.178.005.pools.vodafone-ip.de> has joined #gamedev[18:52:33] *** RandomCouch <RandomCouch!~RandomTab@modemcable249.134-83-70.mc.videotron.ca> has joined #gamedev[18:56:01] *** jokoon <jokoon!~jokoon@2a01:e35:2e08:9f10:b928:cfc8:2ff:7362> has quit IRC (Quit: Leaving)[19:13:59] <Spec-Chum> https://link.springer.com/book/10.1007/978-1-4842-4427-2[20:18:31] *** CustersRevenge <CustersRevenge!~cppcon@187.39.238.73> has quit IRC (Quit: This computer has gone to sleep)[20:20:27] <brainzap> uuf that blue dot on github gets my blood high everytime it is there[20:20:59] *** RoadKillGrill <RoadKillGrill!~RoadKillG@cpe-75-187-140-196.neo.res.rr.com> has quit IRC (Read error: Connection reset by peer)[20:23:25] *** Prestige <Prestige!~Prestige@pool-71-121-203-35.bltmmd.fios.verizon.net> has quit IRC (Quit: Prestige)[20:28:06] *** Prestige <Prestige!~Prestige@pool-71-121-203-35.bltmmd.fios.verizon.net> has joined #gamedev[20:30:37] *** RoadKillGrill <RoadKillGrill!~RoadKillG@cpe-75-187-139-141.neo.res.rr.com> has joined #gamedev[20:40:12] *** diwr <diwr!~bruno@unaffiliated/diwr> has quit IRC (Ping timeout: 252 seconds)[20:54:56] *** solidfox <solidfox!~solidfox@unaffiliated/snake/x-2550465> has quit IRC (Quit: WeeChat 2.4)[20:58:18] *** brainzap <brainzap!~brainzap@217.22.129.78> has quit IRC (Quit: My tummy says it's time to sleep Mr. Bubbles.)[21:13:33] *** code_zombie <code_zombie!~code_zomb@2605:a601:aa1:da00:7dbc:8e63:f3ea:5976> has joined #gamedev[21:19:03] *** RoadKillGrill <RoadKillGrill!~RoadKillG@cpe-75-187-139-141.neo.res.rr.com> has quit IRC (Read error: Connection reset by peer)[21:20:11] *** brainzap <brainzap!~brainzap@217.22.129.78> has joined #gamedev[21:24:10] *** brainzap <brainzap!~brainzap@217.22.129.78> has quit IRC (Client Quit)[21:46:53] *** mijowh <mijowh!~mike@24.102.203.175.res-cmts.t132.ptd.net> has quit IRC (Read error: Connection reset by peer)[21:48:58] *** mijowh <mijowh!~mike@24.102.203.175.res-cmts.t132.ptd.net> has joined #gamedev[21:54:39] *** brainzap <brainzap!~brainzap@217.22.129.78> has joined #gamedev[21:59:12] *** brainzap <brainzap!~brainzap@217.22.129.78> has quit IRC (Ping timeout: 245 seconds)[22:07:58] *** universecoder <universecoder!~moongazer@unaffiliated/moongazer> has quit IRC (Ping timeout: 245 seconds)[22:08:56] *** Tylak <Tylak!~Tylak@074-135-002-092.res.spectrum.com> has quit IRC (Quit: Nettalk6 - www.ntalk.de)[22:17:46] *** Tylak <Tylak!~Tylak@074-135-002-092.res.spectrum.com> has joined #gamedev[22:34:17] *** zalt <zalt!~lambda443@unaffiliated/lambda443> has joined #gamedev[22:52:04] *** adamsky <adamsky!~quassel@178235186241.unknown.vectranet.pl> has joined #gamedev[22:59:20] *** adamsky <adamsky!~quassel@178235186241.unknown.vectranet.pl> has quit IRC (Remote host closed the connection)[23:26:06] *** zalt <zalt!~lambda443@unaffiliated/lambda443> has quit IRC (Ping timeout: 246 seconds)[23:40:25] *** Serpent7776 <Serpent7776!~Serpent77@90-156-31-193.internetia.net.pl> has quit IRC (Quit: leaving)[23:40:27] *** LunarJetman <LunarJetman!LunarJetma@5ec16e1a.skybroadband.com> has quit IRC (Ping timeout: 245 seconds)[23:48:29] *** pavonia <pavonia!~user@unaffiliated/siracusa> has joined #gamedev[23:51:38] *** LunarJetman <LunarJetman!LunarJetma@5ec16e1a.skybroadband.com> has joined #gamedev[23:58:48] *** togo <togo!~togo@2a01:5c0:e08b:76e1:45:c1e6:1bae:629f> has quit IRC (Quit: Leaving)