All our plugins go in project (and end up on perforce) so no worries there, I can remove them, mainly wanted to check there wasn’t some reason. Also would be nice not to have to remove them anytime I grab an update but no big deal.
can this plugin handle grid cells of 4m² each on a 10km² grid - so 2500 cells?
use case: “buildings” in a RTS, so there will only be 0-1 entities in one grid cell at any given time.
also can the grid be “moved” in realtime without significant performance issues?
use case: I want to center a smaller grid (4m² cells on a 1km² grid, so 250 cells) around a moving actor
would the plugin be able to handle both features nicely or would either tank the performance?
So I have found a bug where the fast-path for cell culling may ultimately cull all cells - it’s a combination of floating point error and a dumb mistake on my part. I strongly suspect this was causing the issue Vaei was hinting towards as it results in all cells being skipped for searches in some cases, and is dependant on position of the objects.
I’m going to make a fix ASAP - if you need a workaround in the meantime, move the plugin to the project directory and set USE_FAST_BOUNDS_SEARCH_REJECTION to 0 in ST_SparseGrid.cpp
EDIT: I****ssue found and fixed - update will be submitted ASAP. (I will also update the 4.18 and 4.19 versions to remove the monolithic headers as well, as the 4.20 version has.)
That’s not the kind of thing it’s designed for I’m afraid. It’s a broadphase sorting/searching system.
Version 1.2 has been submitted, this fixes a couple of issues:
- Object Bounds not being updated correctly (resulted in many valid queries being rejected with a small number of objects in the grid)
- Pre-placed objects being registered even if the grid component is not active.
I’m working on a revamped version of the plug-in that supports multiple grids at the same time, so object types can be separated etc. This will be more of an update for C++ users than BP users.
V1.2 is live!
Version 2.0 is coming soon, which supports multi-layer grids for C++ users. Lot’s of extra power and potential!
Do you have any tutorials? Would be very helpful to a noob like me 
I’ll probably do some when Version 2.0 drops, I’ve basically reworked the underlying system to be much more flexible for C++ users without compromising the existing functionality of Blueprint - so I’ll get on that ASAP.
Just testing version 2.0 in my own projects to make sure it’s stable etc.
What new features are going to be in 2.0?
The main feature is the ability to have more than one grid. The grid data is now a template which makes it more flexible for C++ users. I’m using it to store different objects types in different grids.
BP functionality is still the same, but given this is a performance/utility-oriented plugin I’m okay with that.
Is there any eta for the 4.21 version yet?
I’ll see if I can get it out today. Sorry, been preoccupied!
Version 2.0 is ready for approval, but unfortunately the Epic side of things is throwing a hissy fit everytime I try to submit the update. Waiting to hear back from technical support.
Version 2.0 is now live for Engine Version 4.21!
The API has been dramatically improved. Grids are now template types, and the system supports multiple grids per world. You can create and update these however you choose. In this internal project below, I have separate grids for ‘Game Objects’ ‘Radar Scanners’ and Radar Jammers’. Each can be queried separately and are able to query each other.
This allows you to expose custom queries for your project that prevent the need to do any filtering, offering a speed boost and reduced virtual function calls.
This version is suitable for all platforms!
Excellent, thanks for the all updates.
I was running the beta launcher. The update was not showing up. On a whim, I opted out of the beta launcher and it shows up.
Very interesting, a optimized spatial partition design pattern can be very useful in RTSs. Can be used for selection group units, minimap implementation, fog of war, can replace perception in AI implementation to detect possible targets.
Could this component hide inactive units in pooling? Have you ever done performance testing with a large number of moving actors (over a thousand, for example)?
I really got interested, I’ll wait for the tutorial to better understand the possibilities of the system.
That’s pretty much exactly what it was developed for - my own game has RTS roots and it was essential to implement some kind of broad phase partioning. Spatial queries make up a huge chunk of time in RTS like games.
I haven’t done any discrete performance testing - my only result was that it was considerably faster and more convenient than using physics or actor/object iterators to find objects I need to query often.
Hi,
I am having an odd issue. With a box trace, it seems I can’t get the grid to detect objects close to the origin of the box. With the sphere trace it works fine With the box, I need to back far away from the object before it is detected.
Any thoughts on diagnosing this? I can upload a video if it helps.
Interesting… I’ve not seen that issue before. By all means send a video over to support[at]stormtide.co.uk and I’ll get back to you on it ASAP.