Cool, thank you! For this case in particular, it is when you select forest items and copy/paste them instead of placing them with the paint tool. This bit is more for my own curiosity than anything.
So only on placement with brush you have collision detection for forest items, on shift clone or copy paste no.
Thank you! I know that was a simple question. I just wanted to be sure it would not detect forest items with exactly matching transforms and delete them.
Found these forest item shelves while scavenging for map assets. There are about twenty of them stacked inside each other. Are these sucking computing power for all of them or do they count as just one item?
I know this thread is old, but I have just developed a conversion tool for static assets from the scene tree to forest items. You can find it here: https://www.beamng.com/threads/beamng-tool-for-map-creators-updated-2023-10-07.89058/ t works quite well. But the big question is why you should convert your static assets from the scene tree to forest items nowadays. I just examined Johnson Valley. It has around 16.000 assets in the scenetree and only "real" forestitems like trees and bushes. It still has a good performance even in the editor. See this discussion: https://www.beamng.com/threads/converting-placed-meshes-to-forest-items.86837 Maybe I coded it for the trash... I just converted Johnson Valley with my tool and perhaps I do a performance comparison on it.
That tool is a great idea. I will have to try it out when I get back into map-making. I was just going off of really really old information at that point. I read somewhere in passing that forest items were less performance-intensive, so I wanted to make sure I used what was best. It turns out that they are exactly the same, but it's easier to place a bunch at a time in random configurations and random sizes with the forest tool. My issue with performance in the editor was due to drawing ray-traced bounding boxes over so many items. If I deselected them, the framerate would recover. I think a good tool for performance in maps could be something that checks if copies of static meshes or forest items are in the same location or very near to it. So something that would extract the location data of forest items and highlight ones that meet the closeness criteria so you can use this info to find them or just erase the excess meshes. I think this could help with forest tools in particular, because there is no indication as to how many meshes you have selected, so you would have to move them one at a time manually to identify any duplicates.
I can now at least safely confirm that forest items have no performance advantages. I have converted all 12957 static assets of Johnson Valley to forest items and there is not the slightest improvement in FPS.
Well... That's good to know at least... a shame, as I was hoping to gain some FPS on some of my maps!
I would not get distracted by the framerate performance while in the world editor. There is more demand when in that mode than when simply playing. Hit your ~ key in the world editor and make sure you don't have some infinite error looping. Just because game is running does not mean you did not create errors. They hide and hinder performance.
I agree that it is absolutely important to double-check for errors and check framerate outside of the editor when optimizing a map. I just wanted to add clarification as to why I saw the dips in performance that I did while in the editor with so few meshes loaded.
I only thought forest items use was for ease of placement (though I still prefer to hand plant things) And forest items can use vertex painted meshes for wind interactions. Performance I would think would be the same, if the mesh was static mesh, or the same static mesh but painted with the terrain painter. Each can have LODS, and be nulled or BB'ed at a distance. Not sure if the game gives some performance discount if more things are categorized as forest meshes rather than track objects but I can see how from just looking at my scene tree how its easy to have a mess of static meshes in 100s of different groups. I have not really done much in the way of optimizations for scene tree related. Curious myself on this.
I think years ago in older versions only the forest items had instancing. But these times are over, luckily
