Procedural Foliage Spawner performance - collisio

I’m also used the base collision that they came with, and I’m only using the HillTree_tall asset for the time being.
how much is a ‘large quantity’ for you? like I said, I have 47’000 trees in an area of 3x4km

is it really the same FPS for you with and without collision? can you confirm that the player character can get its movement blocked by it?

How complex is the collision you are using? I used the kite demo trees with the base collision that they come with (the capsule in the center of the tree) and saw no FPS drop whatsoever when spawning a large quantity of them over a World Composition tiled landscape.

I had ~20k units in the level, I’ll try to up the amount and see if that does anything. My fps was still a consistent 75-78 with expected fluctuations (±5) and the collision seemed to be working as expected. I’m going to test this in just a bit to see if adding even more units will allow me to reproduce this on my end. I’ll let you know once I have more information.

Ok, the test I did was on a 8km x 8km landscape (100 tiles). Spawning in foliage over this entire area dropped my framerate to 18, which is what I would expect in that circumstance as I had no culling or proper LODs set up to prevent a framerate drop. Have you set up occlusion to prevent rendering outside of a specified distance so that you can save on resources? Adjusting this may help with what you are trying to accomplish as well.

well I did set up the culling distance, and the asset comes with proper LODs (4 LODs in total, which includes an imposter version for the lowest quality).

I wouldn’t know how to ‘set up’ occlusion. all I have is a landscape and the trees, and the landscape should do occlusion already shouldn’t it? also wouldn’t occlusion just help with the GPU? but the problem here is the CPU…

and so, if you disable collision you’ll have proper framerate, correct? as I express clearly in the first post, without collision I have really great view distances, and with collision the whole game comes down to a crawl even if the view distances are reduced to an unacceptable minimum.

could you please try to do whatever you’d need on your end, so that we could get the steps needed to have an acceptable performance?

and if nothing more can be done to make it work at the moment, would there be any effort from Epic’s side to improve this bad performance on open world levels with collision?

For some reason answerhub just swallowed my comment… Here goes again, apologies if the other one surfaces.

I managed to package a map that showcases the problem on my end: https://dl.dropboxusercontent.com/u/19527343/FoliageCollisionTest.7z

There are two maps. The startup map “Map1” has really poor physics performance. The second map is called “FirstPersonExampleMap” (can be found under FirstPersonBP/Maps/FirstPersonExampleMap). The maps have about the same amount of instaces, both procedural, but the only difference is that the Spawners and tree meshes are separate for each map. Meshes both have just one collision primitive and the spawners should have roughly the same settings.

I also did some testing what would happen if I replaced the Map1 foliage instances with the one I used in FirstPersonTestMap. Performance issues regarding to physics disappeared. Physx task took 0.8 ms.
After that I switched the instances back to the old proc. inst. spawner. Performance issues came back and fps was in the 10-20 range.
After that I replaced the foliage with the new proc. inst. spawner and no performance issues. After that I set the new proc. inst. spawner to use the same static mesh as I use with the old spawner. No performance issues.

Hi,

I thought worldcomp was created to solve this issue.

So if you split your map 3x5km or whatever size it is into managable tiled sizes then you increase the frame rate. Hide land being loaded/streamed in with fog.

This way you are dramatically reducing the amount of collision on screen at any one time. The more tiled map segments you have the faster you will get it to run. If you run into problems at 47,000 instances (I found 35,000 limit for 70fps) then ensure that over say 9 tiles you don’t exceed that amount. This is because the tile the players on is only one tile and you may also want the tiles round the player also to be visible. And obviously the player needs to see a tile to be able to walk onto the next one and so on and so on.

I used this technique in NO RETURN UDK version 0.135 if you want to test it in action. a 350sq-km map was made using the tiled/worldcomp setup and as you will find all the trees have collision.

I haven’t used worldcomp yet as I too was looking for an easier solution, but it looks like worldcomp is the only one provided in the editor just now. A player location based solution will probably be provided at some point I imagine.

http://www…com/games/no-return/downloads/no-return-v1135

check out this other problem, Why is a regular landscape 2x faster than a tiled landscape? - World Creation - Epic Developer Community Forums - you’ll see that Tiled Landscapes are already severely making my performance worse.

and notice, I still want long view distances. having view distances of 1km when my map could be 10x10km is a pretty horrible limitation if you consider that the cause of it is just badly handled collision.
it’s specially frustrating because you see this nice KiteDemo with super long view distances - it strongly suggests the engine could do it in a real game case, but it really can’t.

and also keep in mind I’m making a multiplayer game. I could only use World Composition if I run a dedicated server. the dedicated server would have always in memory all landscape tiles of all players - all with tree collisions everywhere. that doesn’t sound very promising for performance.

so thanks for your suggestion , but I can only conclude that at the moment there is no working general solution for this. there’s only workarounds that will only fit the needs of certain projects.

No matter what fancy videos come out showing off new game engines, nothing will beat tried and true techniques to get your game simulating a large world.

Firstly, never trust tech demos. The more artsy and cinematic the tech demo, the more your suspicions should be aroused that whatever is being shown would not realistically be in a game, which requires multiple actors, physics, particles, and all types of collision, if you want some action happening. Shadow of the Colossus on the PS2 was allowed to look artsy and cinematic and push the visuals of what’s possible on the PS2 because they designed the gameplay to not require a lot happening at once - just you, your horse, and 1 other colossus. And maybe a lizard or two.

If you want to push a game to the limits of what we’re seeing these days (eg. a giant lush forest) you’re going to have to rely on tried and true techniques - a one-fits-all game engine solution will never solve it for you, since you will have to make decisions on what’s important to your particular game, and cut out the rest, to stay on the cutting edge of what’s possible.

When I see screenshots like this, with some in-engine feature cranked up off to the horizon, I know you’re bound to run into trouble. There is no way for the designer of that feature to know what you need. Are you engaging in hand to hand combat with enemies only a few meters away from you, or is it a siege simulation where you’re lobbing projectiles off into the mountains in the distance? The collision for these situations will have to be handled differently, and trade-offs will have to be made to keep the game running fast.

In your case, you need to come up with your own way to break up the landscape so the game is only thinking about what’s immediately possible to interact with the player at any one time. Can you climb trees in your game? If not, then a simple cylindrical collision for each tree trunk will do. And only for the trees immediately around you. How do you only check the trees around you, and not every tree in the land? This is where you need to put in your effort to make your game run fast. If you are in a small square of terrain and it is the “active” square, then you only have to check the trees within that square. What about when you get to the edge of the square? If there’s a tree in the adjacent square right in front of you, you could chop through it until you cross the border. More importantly, any enemies would be able to walk through the tree. So you’d want an area of 9 squares where you’re in the center square, and each surrounding square is also included in the active set. If you cross out of that square into another, then that one becomes the center square. Then you can have enemies enter the area and move around as long as they’re in the active squares. If they leave the active area, you then have to decide how important it is to your game to keep simulating them. If it is, you will need to code up an alternative, simple simulation that keeps the enemy moving until he catches up to you and re-enters the active area. You could probably forego tree collision in this simplified simulation, and just rely on the heightmap of the landscape. Although if in your game you put up a barrier that should stop the enemy from moving through, this would have to be factored in.

So as you can see, it all depends on what you need to happen in your game, that determines how much work you have to do to keep it running fast and giving the player the sense of being in a larger active world. You can also see that most of your time will be spent on dealing with what happens in these border cases, when ever the active area moves (because the player moved into a new square) or a character enters or leaves the active area.

Every game company that made an open-world game (Elder Scrolls series, GTA series, etc.) has to deal with these issues, and your game is no different.

yeah thanks for all that info that I already knew about, I can come up with ideas for workarounds all day. actually most of what you suggest is either already in place or useless: I already use simple cylinders for collision, I can’t break down the landscape, and the rest of your ideas that rely on ‘stuff around the player’ would not work on a multiplayer game.

the fact of the matter is that I’m not really looking at a techdemo. I’m using an engine with their advertised “Open World Tools” and “Foliage Tools” and yet I can’t use them together without tricks and gimmicks.

every game company that made an open-world game designed and built their engine to deal with these issues, and I’m using an engine that supposedly offers this. yet it doesn’t.


, so what is it that keeps getting accepted as the answer?

Don’t dismiss what I’m saying out of hand, I do make games for a living :slight_smile: I worked 4 years at Halfbrick Studios, also some time at Krome working on the Dragon where we had to deal with what you’re dealing with now, and I now teach game development at Evocca College for 2 years now, making my own game in my own spare time, which incidentally, is an open world game achieving just the sorts of things you’re trying to do - except using Unity (which makes no difference, since the principals are the same).

I understand you’re pretty frustrated, but I’m only trying to pass on my knowledge, so there’s no need for the agressive tone. I also appreciate you’ve so far been dealing with a UE4 staff member that doesn’t seem to have a whole lot of game dev experience, and I can see how this is also frustrating. Just don’t take it out on me! I also notice he marked his own answer as accepted when you were clearly still having trouble, which I found strange.

Ok since there is a comment limit, I’m going to have to break up my reply.

These are not work arounds, this is actually how it’s done. Firstly, you absolutely MUST break up how much the computer is dealing with at any one time, you will not be able to avoid this, multiplayer or single player.

If you have a fixed playable area (i.e. not open world) you may not have to break up the landscape itself if the target system is able to render the entire terrain at once. If not, you will have to break that up too, and load the new chunks in as you walk forward and remove the old chunks behind you. The view distance of how many chunks / how big your chunks are, is up to you, and how much the target system can handle.

Either way, you absolutely must break up how many trees you’re asking the computer to check for collision with the player at any one time. You have a fucktonne of trees (technical term) and there’s absolutely no reason to be checking collision against all of them unless you’re simulating some kind of planetary scale lawn mower :smiley: And yes, this will work on multiplayer - how else do you think multiplayer games actually work? This is what they do - each client handles things in its immediate area and reports back to the server. Depending on what kind of gameplay this is, the server will be programmed to make certain decisions on what happened first, and let the clients handle the rest, to keep network traffic down. Eg. in an FPS it’s really important to have the server play “umpire” on who shot who first, especially when each client is experiencing different amounts of lag. However, when one of them blows up the car and the fragments bounce around and then disappear shortly after, there’s no need to be sending all that info to the server when it’s purely aesthetic. (continued next comment)

Collision between static geometry that never changes, is also pointless for the server to be dealing with, since the client computers can handle that themselves, and this is the situation you currently have. Unless of course, players can randomly chop down trees during gameplay, then you will have a much more elaborate situation on your hands, and I sure hope it’s a lumber jack simulator, because tree chopping had better be an essential part of the game that you just can’t do without, to justify how much work you will need to do to allow this functionality and still have the game run fast for all clients.

Glad to help you further, but I’ve pretty much told you all I can based on what I know about what you’re doing so far. Feel free to ask questions or provide me with more info.

sorry about the agressive tone. I also make games for a living and your post sounded a little like you’d be explaining things to a kid - but you wouldn’t know. so sorry again and thanks for the extra info.

as for the multiplayer part, unreal works with a server-client model and for the movement of Pawns the server always syncs it (client moves locally and asks the server if it’s ok, server corrects any wrong movement), so the server would need to check the collision of every player against foliage at all times or I would need to modify this behavior and make speedhacks super easy.

however im convinced if they give out these tools in the engine then it should work out of the box with the rest of the expected features (in this case, something as basic as collision). because anyone that would try to use the open world tools would need collision as well - expecting everyone to implement their own collision solution seems a bad thing since they offering and advertising the feature in the first place.

and yes it’s frustrating to deal with the way answerhub works and Epic’s policy about it (marking everything as answered because of tracking purposes without caring if it’s answered) or just the little help they provide - the icing on the cake being a crash I reported on April 2014 which is still unresolved. I want to use this engine but I am not able to do it

I’m just trying to make a game here, I don’t want to have to fix the engine first so it allows me to make a game.

Practically speaking, there’s zero reason why the server would have to check every player against every static object in the entire level, it’s no different than a single player game. You still have objects that can be considered as being inside one “chunk” of the landscape which means there’s no need to check it against anything else outside of that chunk.

However, your problem is you’re relying on existing UE4 functionality to do the networking, which means, like a lot of other aspects of UE4, you’re committed to doing it the way it’s set up to do unless you have an option to get in and modify it yourself.

I’ve been reading all your posts that you linked too, and I find your questions very legitimate, well researched, and you try everything everyone suggests. You deserve a response from a person who knows how to do what you’re trying to do, with UE4. But this response has not come.

You probably won’t like the sound of this, but you’re probably using the wrong engine for what you’re trying to do. Which contradicts what they’re trying to sell you with the Kite tech demo, but as you’ve seen, it’s just a tech demo, and like pretty much every tech demo, it’s set up to look nice, and not to demonstrate what kinds of games this engine can let you make easily. Eventually you’ll learn to be jaded at tech demos. That’s a very pretty landscape the boy is chasing his kite through, but please - throw in 20 orcs all trying to pathfind their way to the barbarian player, have some combat, that crashes the orcs into shattering barrels with their pieces physically interacting with the surroundings, etc. etc. you know, stuff that actually happens in a game!! All the kite tech demo shows us is that you can make a whimsical game about a boy who chases his kite but suffers from a severe case of dendrophobia and will never touch any trees.

(character limit reached, new post)

But often, you have no choice but to get to this point to realise that this is the wrong tool for the job. You just have to get in there and get involved and see what it’s like. Well now you know.

Case in point - in an open world game, you should be allowed to divide up the landscape to compartmentalise what the computer has to process at any one time. That’s a pretty normal thing to do. However, if you use UE4’s lovely terrain system, each landscape comes with a cool feature that tessellates the geometry depending on your distance. This is very cool - for one landscape. When you have multiple of these, you have the computer doing a whole lot of work that you don’t need to do!

This is one of many reasons why, depending on what game you want to make, you may have to fight the way UE4 is designed and would be better off using Unity. Why is that? Well UE4 is very very good at the high level. Choose one of the templates, and you can be up and running making a game FAR quicker than Unity. And don’t get me wrong - you can make plenty of wild and wacky games in UE4, their system is not limiting.

(limit again, new post)

But it’s when you get to making something that’s very technically different - eg. procedurally generating meshes, multithreading, making your own level chunking / streaming, or networking, you need to work at a lower level of functionality. In UE4, you will be fighting the way its set up and have a hard time, because the polish is at the high level. However, Unity’s polish is at the lower level - it’s not fast to make a game like UE4 can, but it’s much faster and easier to do things when you need something much more customised. Want to draw onto a texture in real time using code? No problem; go new Texture2D, and use SetPixel(x,y, colour), or even SetPixels(colour array), where you give it a 1 dimensional color byte array that it will blit to the texture surface SUPER fast, allowing you, for example in my game, generate textures for my landscape chunks so you can see a sort of Google maps effect for the distant terrain based on what landscape items were procedurally generated for those chunks, instead of actually creating all the meshes for those objects when they won’t be needed at such a long distance away.

This has been a pretty long post but I figure it’s a hard pill to swallow after so much of your work has gone into using UE4 so far, you’ve been trying to get answers for a while, and I wanted to make sure I gave you a response that you’d benefit from. But your time spent in UE4 is not time wasted - you learnt a lot about the system. The bottom line is, UE4 and Unity are both extremely good and fill in different niches for indie game developers.

I know this is an old thread but it still lacks a solution. The suggestion doesn’t work in a real-world scenario because of things like projectiles and so forth that will pass through trees/foliage etc.

Can you find a viable solution to this problem?