Linepick and slowdown
Blitz3D Forums/Blitz3D Programming/Linepick and slowdown
| ||
| I am trying to even the performance of my level out. I don`t know the exact FPS, but what I do know is that at times the performance slows down for several seconds then speeds up again. Since I have added some more linepicks to determine whether the enemies can see the player it has got even worse. I know my machine is up to it so it must me my shoddy programming or something. I have messed around with entityinview and entityvisible but the enemies still seem to be able to see through walls (yes the obscurer is set for the level). So linepick works technically but is really slow. I use 3 linepicks at varying lengths to determine different actions. I have 10 enemies all cycling through their AI with linepicks for 3 of the 7 possible actions. I have read several posts in the forums. Any suggestions ? |
| ||
| Maybe do an entitydistance() first -- if they're too far away then you don't need to check if they can see the player. If you're not already, do one enemy per frame rather than all enemies each frame where it won't break the integrity of the AI. |
| ||
| stupid question but how would I code one enemy per frame. The AI is quite simple but at the moment I have no FPS limiting at all. The AI is called in a function and the main loop does the updateworld, renderworld etc. |
| ||
| stupid question but how would I code one enemy per frame. Rather than doing a For...Each...Next loop every frame you keep a reference to the currently active AI, deal with that one alone and, once you're done, notch it along to the next one with After (and if the instance after is null you loop back to the First). Just be careful not to let the reference go null should the currently active AI happen to expire (because even though you're doing one AI per frame, you're still doing the collision logic/animation etc for every enemy). |
| ||
| Yeah, whats probably killing you is the number of linepicks per frame. I believe linepick works quickier if you have less polygons in your mesh. So splitting up the level may help. Aside from that, you really shouldn't update every enemy AI each frame. Asking for trouble really :o) And also, only render a screen frame when you actually need to. If your screen takes 5 ms to render and your only doing 60 fps, that only adds up to 300 ms. You have another 700 ms per frame to process things. Additionally, a render occurs once every 16 ms, so you have 9 ms to process your AI and such. Mind updateworld takes time to perform. |
| ||
| Linepick can especially be speed up by not doing it over hundreds of units. Its true power is short range picking for example to implement moving platforms, check bullet -> target collision (where you only need to pick from the current position to the future one with the bullet radius) It thought is very bad if you intend to use it for long range "sensors" on an AI and the like ... |
| ||
| why not use some physics lib and use RayPick (im doing that with Physx wrapper)..its way way faster and I didnt notice any slowdown at all..just select objects you want to detect as a obscurers and simply check which one is picked..its damn fast.. |
| ||
| Make sure you are picking box/spheres and not geometry, as this will be much slower. You can also check the viewangle/distance before picking. Have you seen this code?: http://blitzmax.com/codearcs/codearcs.php?code=532 |
| ||
| Cash Yeah - linepicks - very useful for AI, but can slow things down hugely. As mentioned above, only do when absolutely necessary - it's unlikely, for example, that you'll need to linepick for every entity, every frame. If you can, try to stagger/spread your checks for all your entities so that they don't all linepick on the same frame. For example, entity 1 checks on frame 0 and then again on frame 30 (assuming 30fps). Entity 2 checks on frame 1 and then again on frame 31, etc... Another tip is to split your level geometry into separate meshes which are/aren't pickable. Typically I'll split a level into terrain, walls and scenery. The terrain and walls meshes will be pickable/collidable. The scenery mesh contains non-pickable/non-collidable extra detail. Sometimes I'll include invisible polys in the wall mesh to make it appear elements in the scenery mesh are collidable, but with a low polycount. |
| ||
| thats something you alway should do. keep "collision - pick" meshes as alpha 0 objects to which the real object is attached only used for collision. (this way round that automatic collision handling stops the real object as well) qhull is actually a quite usefull userlib to create convex hulls which are quite low poly compared to most freeform meshes you have. very usefull if you need simple collision on fairly complex objects |
| ||
| Staggering AI updates over multiple frames is one of those really useful things that I keep forgetting about. |
| ||
| "Staggering AI updates over multiple frames " okay but how would you code that ? The enemy AI function is one long select, case so how would you stagger it over frames. Sorry if i sound stupid but its not something I am familiar with. I guess I will need a complete rewrite .. |
| ||
| Well, i'd imagine the largest amount of time is consumed with pathfind, so save the state and pathfinding grid (if your using that kind of system). Then upon the resuming of the AI, you simply choosing the last entity pathfind/AI updating, restore the pathfinding table/grid and states and resume. It probably will require some recoding i think. |
| ||
| Other people are suggesting using After to keep incrementing, but I would suggest adding a field to keep track of things (I'm assuming you're using types for your enemies.) So like in the type definition add a field called "updated" and store Millisecs() in there whenever a character updates. Then code the AI to only update if the last update was like half a second ago or something. Now you just have to make sure to stagger their initial state in order to stagger the updates. ADDITION: oh wait from sledge's post I get what you are asking. Yeah I'm describing a different approach to the same thing he is getting at; the AI calculations for a single character still happens in a single frame, but you aren't updating all of the characters every frame. |
| ||
| Other people are suggesting using After to keep incrementing, but I would suggest adding a field to keep track of things Then you're back to trawling through every instance just to see whose turn to think it is, when you could just as easily already know. |
| ||
| "Staggering AI updates over multiple frames " okay but how would you code that ? The enemy AI function is one long select, case so how would you stagger it over frames. I wouldn't try to stagger the thought process over several frames, just the instance that gets to think it: That's the basis of it. |
| ||
| He was originally trying to use EntityVisible. He simply moved to LinePick because he didn't succeed with EntityVisible. This avenue clearly has yet to be explored fully. |
| ||
| Then you're back to trawling through every instance just to see whose turn to think it is, when you could just as easily already know. True, but the actual loop through every character isn't the problem. As long as you aren't calculating the time-consuming AI every frame (the LinePicks in particular) then that's what's important. Besides, with my approach you get a lot more flexibility. For example, it's trivial to adjust their reaction time; just adjust how long between updates. |
| ||
| Besides, with my approach you get a lot more flexibility. For example, it's trivial to adjust their reaction time; just adjust how long between updates. There's still no reason to store the delay multiple times as a field in each instance, unless you're describing a system in which each instance's delay can be unique, in which case that's totally different to what we're discussing (because unique delay periods may well sync over a certain period of time and we're specifically trying to avoid that). On the surface it looks like a straightforward mark of progress to go from updating every enemy every frame... to one enemy every frame... to one enemy every x number of frames. But if updating a single enemy is so time-consuming that you're thinking about not even doing one every frame then I'd stop to think how your game is going to look: Jerky, with one frame in however many taking longer to resolve than the rest. In that situation I would bite the bullet, drop the frame-rate of the game down in line with the speed of updating one ai and go back to doing one per frame. There are advantages to keeping the load even, I think. |
| ||
| EDIT: whatever, this is a silly argument, both approaches work fine |
| ||
| He was originally trying to use EntityVisible. He simply moved to LinePick because he didn't succeed with EntityVisible. This avenue clearly has yet to be explored fully. I tried to use EntityVisible to auto-init some path nodes once but the results were very erratic. Cash packaging up a small level with some test code that exhibits the problem, and posting it up in Bug Reports (or here) is probably the way to go with that. |
| ||
| I have notice a thing with line pick. the first line pick always takes several second fro me. about 10 seconds. i am having a mesh of 3.500.000 polys. adther that first pick line pick works fast again :D Are you having problem with the first line pick or is the game slow all time ? |
| ||
| The terrain and walls meshes will be pickable/collidable. The scenery mesh contains non-pickable/non-collidable extra detail. i find funny to read old posts which existed before i started to use Blitz3d with the exact same way to describe things ("pickables", "collidables") than i do now :D |
| ||
| so you necroed a post from 9 years ago, you are in my record book |
| ||
| i have seen it done for a 11years old post, so i am still a noob in this field... ;) |
   |