Thanks everyone, the plug-in is finally available 
Iām gonna make some changes to the initial post and use this thread as a support thread now! Enjoy!
Looking forward to some videos as I have a complex searching ai in a large open world. Could multiple ai access the same heat map and could all ai update the heat map as its searched? I presume the heat map colour represents 0 to 1?
Forgive me if this is a stupid question, as it certainly seems like youāve focused on performance, butā¦
Is this not very similar to what PhysX ultimately does behind the scenes for overlap queries? The collision objects are stored in various acceleration structures to make it fast to do spatial queries, so Iām curious as to any specific numbers you have regarding the performance improvement of using your plugin to do a common sphere overlap test rather than just using the existing PhysX API.
Iām quite interested in using this plugin if it does prove to be significantly faster than a sphere overlap, so please donāt take this as an attack. Iād simply like to see more detailed profiling numbers before making a purchase.
All objects query the same grid, and all objects that have the grid component are sorted into that grid. You can think of the Grid Component as being similar to an Actor, in that you will need to filter and/or cast objects yourself once youāve found them. In a couple of cases, Iāve internally used the Grid Component as a basis for a more generic āGame Object Componentā which shares common functionality for that game (e.g, team number, health etc.)
The Heatmap is not populated by searching, but is a visualization of cell density. Itās an editor-only system mostly there for debuggingās sake (i.e, a huge world where you might not know if you need to change the density of cells etc).
Youāre pretty much on the ball, the acceleration structure in this case is a coarse grid, (which in my use-cases proved faster and simpler to manage than a Quadtree/Octree or similar). I should certainly provide some performance metrics as soon as I can, but itās worth nothing that this system is meant to be used in tandem with PhysX rather than replace it.
You would typically use this more for game-specific searches. The idea is that you apply the grid component to common gameplay objects (e.g, vehicles, powerups, pawns etc.) - and then use the grid to find those objects rather than relying on collision sweeps etc.
One advantage is that youāre only ever querying and filtering relevant objects rather than every object that belongs to a given collision channel (or channels) - but it also means that you donāt have to manage a project with ever-more-complex collision settings that can easily introduce bugs and so on (e.g, somebody modifies the collision setting of a vehicle, but now certain types of projectiles canāt find it etc.)
Itās not so much that the plug-in is magnitudes faster than a sphere overlap. If anything in some cases PhysX may well be faster (though often thatās not the case), but itās just a ānicerā way to sort and search for things at the gameplay level, in this guys opinion at least! Itās also kind of the result of some personal gripes I have with people attaching enormous collision shapes to projectiles and AI entities, then wondering why their physics scene stats are through the roof 
Hey, this looks super interesting, but I have to admit that I donāt really understand how this is used, or useful.
Letās say I am building a colony-management / rts game, with AI ācitizensā going around collecting resources, building stuff, etc. - and enemy AI, which is more or less walking around on a very big map (so open-world in the sense of outside, but not an endless map).
I build the map by procedually spawning āmap-tilesā (which are static meshes) with foliage and enemy AI and other stuff on top, at runtime.
Now, if I add this plugin to my project, in which way exactly can it benefit me?
Thank you for enlightening me (:
Thanks for the detailed response! The plugin as a way of reducing the absurdness of managing collision channels (if you try to use them for generalized spatial queries) in Unreal makes a lot of sense, and is another reason why I was interested in your plugin in the first place. I look forward to seeing some profiling numbers just for due diligenceās sake but your answer gives me confidence that you know what youāre doing.
Hey! Did you see my post just above yours?
(NB: I also replied to the comment on the store page)
Sure thing - Iāll put together some test cases when I get the chance so people can see how it performs in different situations!
FYI
I copied your plugin into the source and it compiled fine. However got the following warning. I just purchased it minutes ago.
2>Module.ST_SparseGridEditor.gen.cpp
2>Module.ST_SparseGridEditor.cpp
2>Module.ST_SparseGrid.gen.cpp
2>Module.ST_SparseGrid.cpp
2>[5/8] Link UE4Editor-ST_SparseGridEditor.lib
2> Creating library E:\UnrealEngineSource\Engine\Plugins\ST_SparseGrid\Intermediate\Build\Win64\UE4Editor\Development\UE4Editor-ST_SparseGridEditor.lib and object E:\UnrealEngineSource\Engine\Plugins\ST_SparseGrid\Intermediate\Build\Win64\UE4Editor\Development\UE4Editor-ST_SparseGridEditor.exp
2>E:\UnrealEngineSource\Engine\Source\Runtime\Engine\Public\Engine.h(10): warning : Monolithic headers should not be used by this module. Please change it to explicitly include the headers it needs.
2>[6/8] Link UE4Editor-ST_SparseGrid.lib
2>[7/8] Link UE4Editor-ST_SparseGrid.dll
2> Creating library E:\UnrealEngineSource\Engine\Plugins\ST_SparseGrid\Intermediate\Build\Win64\UE4Editor\Development\UE4Editor-ST_SparseGrid.lib and object E:\UnrealEngineSource\Engine\Plugins\ST_SparseGrid\Intermediate\Build\Win64\UE4Editor\Development\UE4Editor-ST_SparseGrid.exp
2>[8/8] Link UE4Editor-ST_SparseGridEditor.dll
2> Creating library E:\UnrealEngineSource\Engine\Plugins\ST_SparseGrid\Intermediate\Build\Win64\UE4Editor\Development\UE4Editor-ST_SparseGridEditor.suppressed.lib and object E:\UnrealEngineSource\Engine\Plugins\ST_SparseGrid\Intermediate\Build\Win64\UE4Editor\Development\UE4Editor-ST_SparseGridEditor.suppressed.exp
2> Creating library E:\UnrealEngineSource\Engine\Plugins\ST_SparseGrid\Intermediate\Build\Win64\UE4Editor\Development\UE4Editor-ST_SparseGrid.suppressed.lib and object E:\UnrealEngineSource\Engine\Plugins\ST_SparseGrid\Intermediate\Build\Win64\UE4Editor\Development\UE4Editor-ST_SparseGrid.suppressed.exp
2>Deploying UE4Editor Win64 Developmentā¦
Huhā¦ thatās interesting. Might be a new thing coming in 4.20.
Iām fairly sure I needed to get to GEngine which is (currently at least) declared in engine.h. Maybe itās been moved for 4.20, Iāll have to look at that when 4.20 comes out Iām sure.
I donāt know if youāre still having this issue, but to fix it, you can change the include to āEngine/Engine.hā
Iāve just learned this one recently - there are two Engine.h headers as it turns out, one is the huge monolithic one and the other is one used by the IWYU system. When I update the plugin for 4.20, Iāll backwards-fix that issue as well.
So how do you actually use it? The documentation is a good step but it still needs a āhow to setup/useā section.
I made a grid, I put the component on an object, I made it query with a sphere when you press a key, however the object itās querying is always returned even when it shouldnāt be and thereās no information on why it would do that.
The sphere has a radius of 100, and Iām very far from the object, Iām debugging the sphere andā¦ very far from the object. Why is it being returned?
Oh my badā¦ Iām not sure how I managed to skip that part of the docs. Iāll update the docs today and add some more information.
The setup should be simple, add a grid to the world in the Grid Editor mode, then set the properties so that the cells cover the entire playable area of the world. Then add the Grid Component to an actor and you should be good to go. The Grid Component uses the actors Root Component to find itās location.
Can you post a screenshot of the world itself, and the test scenario? Query Grid [Sphere] should function in a similar fashion to a Sphere Overlap test.
Tried to recreate the issue in another project since this ones under NDA and it would show too much but it worked in my other project. Iāll have a play and get back to you if Iām really stuck.
Edit: Just me being an idiot, the item equipped to the character was registering - didnāt even realize it was still there.
Now thereās another issue. I have items (the base class has the component) Iām standing right on top of, and they donāt register. Then I walk to another side of the item and they register. Iām doing a sphere query based on GetActorLocation of the player character. The green debug sphere is completely overlapping them and not registering them based on where Iām standing for some strange reason (perhaps something to do with whether the trace location is within the cell or not). Is this system really inaccurate compared to a sweep?
Something certainly sounds off there, but without being able to look at the setup itās hard to diagnose the issue. I assume that the items themselves are actors which have the Grid Component right?
One thing to bear in mind is that the queries are location-based, not collision-based. Unless the world-space location of the object is inside the query sphere, it wonāt be counted. Iām going to update the documentation with some images to explain this a little more clearly. (Working on some better docs as we speak)
āI assume that the items themselves are actors which have the Grid Component right?ā - Absolutely
Soā¦ itās really odd. I was moving some stuff around in the level, and it was working properly. Moved it around again and it wasnāt. Tried it with a regular actor BP (with component added) and worked fine again, then found it was also working fine for items andā¦ well, Iām just a bit confused. It seems that at times it can misread a location, is it possible that some sort of cache isnāt updating?
There are times I can be standing right next to an item when it feels like not working properly, and the query wont get it. Currently itās working properly, figure Iāll just proceed with integration and find the issue if it arises.
It shouldnāt be, the grid is updated every frame and uses the current Unreal World Position (needed to be as plug-and-play as possible).
If you manage to find a repeating issue though do get back to me. Iāve been using it in my own projects for quite some time without issue (though I did beef up the functionality for the marketplace version, so perhaps something got missed). Iāll be opening up a Discord group soon to get a bit more realtime feedback.
The 4.20 version has finally been submitted, so we should be up-to-date soon. Iāll be making some bigger changes in future versions to make the grid a little more flexible, and open up room for different grid types.
The āNumber of Cellsā is capped at 192 and cell size at 16,000. Canāt even begin to encompass our world with the grid. Think you can remove the clamps? Or is there a reason theyāre there? The auto fit can exceed them but if I try and adjust it just gets clamped again.
Also think you could add this C++ function? I noticed the doc C++ is marked TODO so you might already be planning to
template<class T>
FORCEINLINE static TArray<T*> GetOwners(const TArray<UST_SGComponent*>& GridComponents)
{
TArray<T*> Actors;
Actors.Reset(GridComponents.Num());
for (const UST_SGComponent* ComponentItr : GridComponents)
{
if (T* CastActor = Cast<T>(ComponentItr->GetOwner()))
{
Actors.Add(CastActor);
}
}
return Actors;
}
Going to pick this up Wednesday.
Initially those clamps were added to retain sensible sizes, but since the Kite Demo can get up to 100km in each direction (and grid supports up to 30km at the moment) I will probably remove those. There are no ill-effects to removing the clamps for gameplay, but as the grid size gets larger the engine will start to tank when drawing debug information (and the heatmap will be slower to update as well). I may have to add some manual culling so that it can still be easily debugged!
Interesting that the auto-fit extends thatā¦ I do mention in the docs that the plugin is designed to be customized, so moving it into your project directory instead of engine directory might be preferable (Marketplace doesnāt allow that unfortunately :(). Glad someone is using this now, all the features I initially didnāt need can be added in haha