January 18, 2017 at 13:04 #17748
– Large Procedural World
– Composed of 9 Terrain tiles (1000 x 1000) that are moved on run-time to simulate an “infinite” world
– The player is spawned on one of the terrains, as he navigates towards any of the others that terrain gets procedural generated, old terrain is disabled (flattened) and moved. think of it as an infinite tiled terrain.
– Covering Such a large world on run-time without movable grids.
– Multi-Grid solution and dynamically disabling/enabling grids (this would be what we need help with
but if we do cross grid navigation, which is needed u have to initialize all the girds that use the path)
– Efficient/Fastest Possible grid initialization (A* Pathfinder project currently wins at this)
– Free Mobility for agents across this gigantic world.
– Grids need to be initialized on run-time, i attempted to play around with the grid field option but i don’t know if tons of small grids with 4-6 of them needing to be initialized at the same time is a cheaper option than a move-able grid around the player using A*.
Looking forward to your responsesJanuary 18, 2017 at 13:53 #17752
Thanks for your post (however, did you really need the bump after 2 minutes though?).
Your image link is not working for me.
I’m not sure exactly what you are asking about, since there are no actual questions in your post.
In regards to a large procedural world, it is something that Apex Path is very good at. Take a look at this video.
Apex Path grids cannot be moved at runtime. So you should look into enabling/disabling grids instead.
Cross-grid pathfinding is not a problem, as long as you are only using Apex Path and not Apex Steer, which has limited support for cross-grid movement (groups do not move well across grids in all cases).
Apex Path ships with A* and Jump-Point Search, which is faster in some cases in regards to pathfinding. You can optimize grid initialization if you disable height map generation and instead use live raycasting.
The grid field utility provided is for edit-time creation of grids. For runtime you need to write your own solution, although you can use the grid field utility as inspiration for it.January 18, 2017 at 14:27 #17754
I tried posting the link again, hope it works this time. Apologies for not being clear enough in my previous post. so let me explain exactly what i was referring to.
My question is: What’s the most optimized and fastest approach for initializing grids across such a large world and how would you approach dividing it up? (6×6 (80×80) grids?) in the following context:
– terrains are not marked as static and are moved during run-time.
– grids have to be initialized and generated on run-time
– each of the smaller grids will be initialized based on player proximity.
– cross grid navigation for groups (apex steer was in our consideration for steering).
Lastly, include any optimization tips or things to enable/disable to get the fastest possible grid generation / initializationJanuary 18, 2017 at 14:56 #17756
Hey again Mohamed,
As I mentioned in my previous post, Apex Path grids cannot be moved at runtime. So you will have to look into enabling/disabling and possibly disposing of grids instead.
In regards to how to divide it up, this depends entirely on your game and your needed use-case. If you need lightning fast grid initialization you should go for smaller individual grids, which will require more enabling/disabling as the player moves around. Larger grids will take more time to initialize, but require fewer initializations/disabling. You should experiment a bit to find the right setup for your game.
As mentioned previously, if you disable height map generation and you can do without clearance, you will get faster grid initializations than otherwise.
Apex Steer groups do not fully support cross grid movement. There are certain cases where they will fail, especially if movement commands are given to the group while the group is moving from one grid to another. You could potentially fix this yourself (since you get full source code), but it is by no means an easy or trivial task.January 18, 2017 at 15:22 #17758
I’ve mentioned the use case twice now. 9 terrain tiles 1000 x 1000. so please provide feedback on how to approach dividing this up.
as for apex groups, my use case is if there is a group chasing the player and he crossed a grid. what then?January 18, 2017 at 15:24 #17760
Lastly, the apex steer group issue is critical as i will be dividing the world into smaller grids. so mobility would be a great issue.January 18, 2017 at 15:27 #17762
I cannot say exactly how you should divide up your world into smaller grids, you will have to experiment to find a setup that suits you exactly. A general guideline is to probably not go below 50×50 cell grids, and not surpass 200×200. That is just a rough guideline, not a rule. You need to discover which settings fit your exact use case the best.
In general, we say that Apex Steer groups do not support cross grid movement, because there are many corner cases which are not covered or solved adequately. The main issue that I can remember off the top of my head is that while a group transitions from one grid to another, the group will split and movement fail if they are given a new movement destination while crossing grids. There are probably also other issues that I am not remembering currently.
Thus, if you need this feature, you can either attempt to implement your own solution with the provided source code (not easy), figure out whether the provided functionality is something you can work around, or not use Apex Steer for your groups.January 24, 2017 at 13:27 #17862
So i had a question about the cross grid navigation issue u mentioned for groups. did u mean by that the Steer For Vector Field component?
So what i thought was to represent a “group” of entities as just individuals with each having a path of their own. does this still mean the cross grid navigation issue will still exist?
MohamedJanuary 24, 2017 at 14:46 #17866
Steer for Vector Field does not fully support cross grid-navigation in groups, yes. It works fine for individuals in all cases, and it works for groups as long as they do not cross any grids.
You could use SteerForPath (check out OnePathForAll group) with individual paths, although the performance of this will leave something to be desired, and there is no option for formations and other nice group-based behaviours (e.g. separation). However, they should be able to cross grids.January 24, 2017 at 14:51 #17869
For our current game we have no need for formations or any group related behaviors except them being a group conceptually. ideally one path for all the group would be great thou.
So if i use steer for path & unit avoidance on each member of this “group” that i create, will they be able to cross grids and get a single path request for all the group?
MohamedJanuary 24, 2017 at 16:37 #17883
Yes, I believe so.
You may want to look at one of the examples provided with Apex Path, which has a class called something like “OnePathForAll” as far as I recall. This is an example of a group where all units have individual paths, while still being conceptually in a group.January 29, 2017 at 12:41 #17974
Hello it’s me again. so i did some progress on grid initialization but i am facing a set of optimization problems. i took a look at load balancers but i don’t know they can be used in my current use case. so i’ll explain the context of the issue and what it is then it would be great to get some help on this.
The terrain is divided in to 7×7 grids generated on run-time. i copied the grid field code and tailored it for efficient run-time use via using grid prefabs that initialize on run-time. below is an image of the grid field, my grid prefab & my navigation settings (Load balance, Settings)
A single 70 x 70 grid is eating a lot of performance. i don’t know why. below is a screen shot of the FPS consumed by initializing 1 grid. the grid is calling the Initialize function that is supposed to smooth things out over multiple frames. i drop from 389 FPS to 66 to initialize 1 grid. so perhaps it’s a problem with how i am configuring things.
Looking forward for the solution
You must be logged in to reply to this topic.