eugh, camerapick is slooooowwww
Blitz3D Forums/Blitz3D Programming/eugh, camerapick is slooooowwww
| ||
| I've just tested my landscape program (using the excellent Fastlib!) and it's getting 1400fps with 2 shadow systems active but not updating each frame (still gets 650fps when constantly updating these 2 systems - I love fastlib!!!). However, performing one CameraPick into the scene drops the framerate from 1400fps to 140fps, so that's 90% lost just to one camerapick... Ho hum - anyone know a fast way to perform the equivalent of the camerapick onto an arbitrary mesh? |
| ||
| You could use raypick, it's one of the functions of a physics engine (i'm sure Naughty will be along soon enough) You can, put a plane and make it pickable, to reduce the length of picks that miss. CameraPick is very slow over large distances, so if you were to scale down the world for a camera pick, it would be faster. |
| ||
| VD Yeah - I ended up using Rubux's PhysX wrapper to avoid Blitz3d's linepick slowness... |
| ||
| I'd rather use a native Blitz way of doing it than have to include a physics library just for that one function. It seems to be related to the number of polys in the target mesh - my landscape mesh has 20000 polys, if I swap to a standard Blitz cube then the camerapick only drops the framerate from 1400 to about 900fps. Still not too good but better than the 90% speed loss. Trouble is I need to accurately pick a point on a hilly landscape mesh and not just on a flat plane... I might try using Blitz's collision system to see if I can get something workable using that. |
| ||
| Can up split up your landscape more? That way the pick would speed up, as the overall size of the individual meshes would be smaller. |
| ||
| Hardly seems worthwhile to split up the mesh - even an 8 poly cube still drops the framerate from 1400 to 900. |
| ||
| You're using a completely unreliable metric to judge your performance. When you have frame rates in the thousands, the time periods are so small that you simply can't rely on the accuracy of the numbers you're getting back to judge performance. Even if you could, it's entirely false logic to say that one camerapick is 90% of your performance. Your performance isn't going to stay at 1400FPS. Almost everything you add at this point is going to appear to take huge chunks out of your framerate, in part because it's so inccurately measured at the moment. Assuming that your target framerate is 60, that pick isn't using up anything like 90% of that, and probably much less when you start getting the framerate down to values where your measurements are reliable. If you obsess over everything that takes a big chunk out of your framerate now, you'll never get the game to point where the framerate matters. Optimize when you know that you have a speed problem, and when you know what it is. |
| ||
| "Optimize when you know that you have a speed problem, and when you know what it is." Trouble is, by the time you have a speed problem that drops you below 60 or 30fps you've got so much stuff going on that trying to pinpoint any bottlenecks becomes much much more difficult. I prefer have it fast to start with which allows me to work upwards, rather than chuck everything in with no thought to the performance hit of each component, then have to cut it all out or spend ages trying to figure out what bit is slow. Fact is, camerapick is slow, apparently very slow. I need to use it in some form, so I want to find a faster way to accomplish the same thing. I had the same problem in SRX - each wheel on the car had a shadow that used a linepick, and at that time I had no idea it was so slow. Once I had the game in a workable state and moved up to 8 cars, 32 linepicks onto a high-poly track brought the thing to its knees, but it took me a long time to pinpoint the linepick as the problem as I suspected it was the physics, and the program was so complex that just removing one aspect had become very tricky. If I'd properly profiled such things as I added them then I would have seen the problem a long time before it impacted on the framerate, saving myself a lot of work. |
| ||
| Your giving yourself little options :o) Eithe use the raypick from the physics lib, which is mighty fast, or use camerapick. I think the only other solution would be firing a small pivot from the cameras position, to the mesh, using a stop collision method and get the co-ords of the collision. But you'd have to have some way of translating the x and y co-ords of the mouse to 3d co-ords to give the pivot a start point. I also agree with Gab here: Going from 1400 fps to 900 fps is nothing. It's probably not even the equivilant of going from 60 fps to 59. 60 fps = a frame every 0.016 seconds 1400 fps = a frame every 0.0007 seconds You lost 1260 frame, to take you to 140 fps 1260 frames at 0.0007 seconds, means your pick took 0.88 seconds. Which isn't much for one pick. I assume it is only one pick per click of the mouse? |
| ||
| VM I sympathise about wanting to stay within Blitz, but I had the same situation when looking at orienting multiple tanks to a landscape mesh. I tried blitz's native linepicks then went to collision pivots - even cut those down to 3 per tank - still ate framerate at an unacceptable rate. Had to go to an external lib in the end. |
| ||
| Is the PhysX wrapper still around? - none of the old thread links or sites seem to work anymore. |
| ||
| Hey Vorderman, here is the PhysX wrapper: http://rubux.net/index.php?option=com_content&view=article&id=47&Itemid=60 |
| ||
| Thanks for the link. £25 just to use a raycasting function is a bit much for me :( |
| ||
| If you obsess over everything that takes a big chunk out of your framerate now, you'll never get the game to point where the framerate matters. That's a very pretty sentence, Gabriel. @Vod: You can always try Abrexxes Engine pack, which comes with a couple of physics engines... http://blitzbasic.com/Community/posts.php?topic=83629 it's the (Engines&Libs) file, in case that's not really obvious. |
   |