Why is this code so slow
Blitz3D Forums/Blitz3D Programming/Why is this code so slow
| ||
| The following code is some ive been playing with to wiggle some verticies up n down. Even with just one quad 32x32 'water' type it slows down real bad. Anyone know why? or is it because the vertexcoords command is slow? For wa.water=Each water wa\phase=wa\phase+wa\speed mesh=wa\h la=0 n_surf = CountSurfaces(mesh) For s = 1 To n_surf surf = GetSurface(mesh,s) n_vert = CountVertices(surf)-1 For v = 0 To n_vert la=la+wa\speed VertexCoords surf,v,VertexX(surf,v),(Sin(wa\phase+la)*wa\amplitude),VertexZ(surf,v) Next Next UpdateNormals mesh Next |
| ||
| Try to only 'wiggle' one vertex per frame. Andy |
| ||
| wont that be too slow? ive stored the vcount in the water type to eliminate the uneccacery code: Function UpdateWater() For wa.water=Each water wa\phase=wa\phase+wa\speed la=wa\phase wa\v=wa\v+1: For v = 1 To wa\vcount la=la+wa\speed VertexCoords wa\surf,v,VertexX(wa\surf,v),(Sin(la)*wa\amplitude),VertexZ(wa\surf,v) Next UpdateNormals wa\h Next End Function Would it be faster with an animated mesh? |
| ||
| How many verts are there? How fast is it without the UpdateNormals() function? |
| ||
| prety much the same without update. its a quad 32x32 single sided |
| ||
| moving one vert up to a point, is as slow as moving 100. Because it uploads the entire mesh to the card each frame. Thats 1024 verts you're moving each frame. See if it's any quicker without 1024 sin calls by using a lookup table. And debug mode off? |
| ||
| ok, back 2 the drawing board. Ill try the lookup table but ultimately i think ill use animated meshes |
| ||
| tanks for the help everyone |
| ||
| As willy said, adjusting a mesh on the fly can be slow, and moving one vertex forces the entire mesh to be reuploaded to the card. I don't know how Blitz's bone system works, but it seems likely to me that most characters will have more than 1024 vertcies in them. That being the case, and it being the case that thouands of Blitz users have not cried out in pain at bone animated meshes being too slow to do anyhting with, it may be that animating vertcies with bones is faster than animating them manually. This could be because the 3D card controls the vertex movement in the case of a bone. Or it could be that Blitz optimizes the mesh uploading for bones. But it's an avenue to explore at least. If you produce a mesh in your 3d program and attach bones to it and load it as a B3D file you might be able to animate water then by moving the bones instead of the vertcies and gain some speed. Maybe. |
| ||
| I have alot of animated meshes in my engine. Instead of having a large mesh though I use one 4*4 quad mesh and then copyentity that mesh to where it is needed. Adjusting the original mesh using VertexCoords means the copies animate too. If you get the sine/cos frequency set right they will seamlessly tile next to each other and look like one larger mesh. This does not help obviously if your mesh isn't repetetive in shape. |
| ||
| I really like that idea. |
| ||
| updatenormals() is sloooow... |
| ||
| Shambler: That's a clever idea. But Blitz runs slowly with too many entities, even when they are copies. So you would want to find the right balance between the number of vertices you're animating, and the number of entity copies you make. It seems to me that unless your ocean waves are very low polygon, or wave very little that a 4x4 grid might not be the best mesh size to work with. |
| ||
| D-Grafix-- To approach this from a completely different angle, it appears to me that you are only modifying the y axis. Why not just use a terrain? It's much, much faster (not to mention better detailed). |
| ||
| "hang on lads ive got an idea" :) what about if i do all the mesh alterations into an animated mesh and animate it? Or move the mesh sideways until the sine peaks match. Is it possible to create an animated mesh within blitz |
| ||
| I don't know how Blitz's bone system works, but it seems likely to me that most characters will have more than 1024 vertcies in them. That being the case, and it being the case that thouands of Blitz users have not cried out in pain at bone animated meshes being too slow to do anyhting with, it may be that animating vertcies with bones is faster than animating them manually. This could be because the 3D card controls the vertex movement in the case of a bone. Or it could be that Blitz optimizes the mesh uploading for bones. Perhaps there aren't enough Blitz users with bone animated models out there. Blitz does handle them very slowly. They're not done in hardware ( the only way is shaders AFAIK ) but you're right that there must be *some* optmization going on internally, because although it's horribly slow, it's not as horrendously slow as VertexCoords would be. |
| ||
| Yes you can with SetAnimKey()...not sure if it takes into account vertex positions and I've not got Blitz near me to try it out but it sounds like it should work. |
| ||
| setanimkey is for entity position/rotation/scale only. Use lookup tables as someone suggested, and if the deformation isn't extreme, calling it less frequently. |
| ||
| Thanks everyone, i need a pretty dense mesh because i want to simulate tiny ripples on the water that effect a cubemap ive decided to use a movement method with fall-in fall-out zones as an animated mesh. |
   |