Hello, I’m making a forest scene with lots of foliage. I’m using speedtree to make all of my trees, and it’s hard to make my trees look good and keep the poly count relatively low. I’ve heard lots of things about where the poly count should be with trees. I’ve heard some people say it should be around 3,000, I’ve heard some people say it doesn’t matter, I’ve heard some people say that it shouldn’t be higher than 1,000. I was wondering if there are any definitive answers on what I should keep my trees at. Any and all input is greatly appreciated 
It totally depends on the target machines graphics card
What about consoles then?
So again… it all depends.
Which console? PS4, Xbox 360, Switch… all have different gpu.
The other issue is where do you want to spend the polygon budget in your game?
For example, one Big Tree in a limited courtyard scene could easily have 60k verts if targeting PS4.
But a whole forest, seen flying from above is vastly different story. Even 1K verts is too much withou using some kind of LOD and probably quad billboarding.
A forest seen from the ground , with lots of occlusion culling terrain and rocks could support much higher count trees.
Your best approach is to start with a decent tree. Design a “blockout” prototype scene. Profile on the target hardware.
You could use Hierarchical Instanced Static Meshes (default in foliage tool) and have nice trees closer to the player and lower poly trees far away.
Basically Verts cost very little. Shaders cost more. But having a ton of small verts results in the pixel (fragment?) shader doing a lot more work than it has to to figure out what to draw to the screen.
3am so hope this isn’t awful advice but basically:
Verts cost less than masked or translucent materials.
Small polygons, especially long skinny Tris are bad for performance
Other than that you have to test on target hardware. Sorry 
but Laptops are way different from phones, Consoles or desktops. Same goes for each of those compared to one another or even low/mid/high specs of each other. Not to mention RAM/CPU/GPU configs can be wildly different. So. Test + Profile. It’s unfortunate, I know. But that’s seriously how it goes.
For instance, Laptops typically don’t have VRAM AND have limited RAM but have low res screens. They have limited and varied keyboard configurations, may be running on battery (low performance mode), wireless, and even outside in the sun on a table 4 feet from the user and at a low angle (awful view). Maybe even muted audio.
Sorry. Digression. Anyway, in that case less pixels to draw is good but no vram = slower draw speeds, low RAM (and no vram) means textures must be kept small, ect.
Epic. Please. Mobile post editing.
Anyway. Hate losing my posts due to the back button or a call or something so posted.
A lot of things can cause a frame to take more than 16 milliseconds to draw. Your task is to identify the specific cause and solve it.
If my computer can’t do 80 Ai because my CPU is weak and I’m your min spec you’ve gotta either increase minspec, free up my cpu somehow, or reduce Ai costs. Because that’s gameplay.
If your minspec laptop can’t handle 4k textures don’t not make them. Just let the Laptop user scale them down in the settings. Not gameplay.
For polycount (lod bias means you can reduce stuff like polycount sooner) and textures alike the point is the same. Use what you need and pay attention to efficiency - diminishing returns specifically. If a polygon isn’t helping edge flow, sillhouette, depth, vertex colors deformation, ect. Enough to warrant its existence then don’t use it. Normal maps are fantastic. Once you get the hang of them it becomes very clear when too much detail is being added (it encroaches on the Normal Map’s territory). If you can look at the mesh from every reasonable in-game angle and not see (within reason) the polygon(s) protruding outside the mesh (think your nose sticking out when you look left as a yes and your nose sticking out but you’re only ever seen front on as a no… except noses are probably too big of a displacement for this example) you should just use a normal map. Fake the lighting.
Those are my current thoughts. It’s possible that you may not make use of a particular normal map enough to warrant its memory footprint (so add more detail, remove it, or create a “no normal map” alternative material for low memory hardware) but I think I made everything clear enough.
Edit: Found “full site” aka request desktop version. Awful on mobile but didn’t want a triple post. Anyway. Note that there’s a visualizer in editor (overdraw?) That’ll tell you based on pixel size (ie camera distance and viewport resolution) whether the pixel took too long to calculate. More or less you’ll see that the further you get from a mesh the more “Too many verts!” You get. The goal is to make that warning not appear until a decent distance away and then use LODs to make it go away each time it starts getting bad.
The many thing with triangles is keeping the Quad overdraw/Quad Complexity view blue. Tiny quads that are smaller than the 2x2 pixels GPUs draw are a lot more expensive. Long thin tris are also more expensive.