It looks like you're new here. If you want to get involved, click one of these buttons!
I am currently working on a Rts game and I want to draw at least a few hundred figures on the screen. Trees terrain and units. For the moment I am using "for" loops, but when I draw hundred trees the frame rate slows down to 30fps. I just want to know if someone knows a better way to draw a bunch of meshes at once?
Comments
Keep the number of meshes down to a minimum by using a sprite sheet approach. Here's a demo which draws 2000 objects as a single mesh. Each object is one of four possible images (the four corners of the Codea icon)
Don't know what the FPS is but I believe there is a bug in the current release of codea which may slow things down
Sprite sheets (upto 2048 pixels square) are definitely the way to go - texture changes are about the slowest thing you can do in OpenGL
@West I added frame rate code to your code and on my iPad Air, 2,000 meshes ran at 28. I upped it to 5,000 and that ran at 11. I upped it again to 10,000 and it ran at 5. Curious to see how it runs when we get the next version that fixes the speed drop.
@dave1707 - that speed is linear, it says Codea can draw (this sprite) on your iPad, about 55,000 times a second.
On my iPad3, I get an FPS of 17 for 2000 meshes (NB I am using a beta with the intended speed fix, which may give me an advantage).
@dave1707, @Ignatz thanks for the info. You both talk about 2000 meshes - I thought it was 2000 objects/Rects (4000 triangles) in a single mesh but maybe my terminology is off.
@West - no, you're right, it's 2000 objects
Thank you everybody. This will help my game along quite a bit.
>-
@West Is it possible to move a single figur using the translate function, without moving all of them?
The easiest way to do it with the above code would be something like:
which would move the 17th object to the right.
Do this outside the loop and you'll probably want to remove the other movement by deleting the following lines
Not got my IPad at the moment so can't check
@West - sorry to come late to the party... but... looking at your demo above, I think it would be a lot faster if you create the mesh once in the setup function instead of recreating it every frame and then storing the id returned from mesh:addRect in a table so that you can update the individual rectangles each frame instead (in fact you probably don't even need to do that if all your doing is adding rectangles - just use the required index in the mesh:setRect() call
Also replace the
with
As you'll have the overhead of 2000 function calls as lua calls the pairs iterator which is also quite slow.
If you're worried about adding and deleting objects on the fly during your game, just add enough rects to the mesh at the start for your worst case scenario and then use the rects as a pool and just set unused ones to 1x1 pixels and move them off screen.
That way your frame rate should be consistent regardless of how many objects you have moving around.
Hi @TechDojo - thanks for the pointers - will try it later. The example was butchered from a previous test of sprites vs meshes I had kicking about
@TechDojo Could you please post your code, where you can specify what models are moving?
@Holger_gott - I'll see if I can dig some out later but in the mean time, I'll make the changes to @West's above although I'm not able to test it...
Here goes...
This is the basic idea. Be interesting to see what kind of speed difference this makes especially as the number of objects ramps up. @dave1707 any chance of you putting your FPS code in this and posting some stats?
@TechDojo Your version needs some work to get it to run.
Here's a working version
I added my frame rate code and got the same values. 2,000 was 28, 5,000 was 11, 10,000 was 5. I tried 55,000 as @Ignatz suggested above and the frame rate was 1.
@dave1707, @West - thanks for fixing the code, I wasn't near my iPad so I was coding blond. Although personally I'd still move the 'local s' outside of the for loop.
To be honest, im surprised at the speed timings I'm assuming you're using the new fixed beta. So recreating a mesh every frame takes the same time as updating each text?? When I get five minutes I'm going to try and create a kind of profiling framework so we can time these functions to get a better understanding of what's happening.
Hi @TechDojo,
We wrote a profiler for Codea, I cant get on to GitHub at the moment to create a gist, so code included below...
It works on an 'object' level, e.g. a table that contains functions, or a class instance...
Basically it swaps out every function it finds into a wrapper that does timing and counts of calls and calculates averages etc. It's a little clunky as it allows a maximum of 10 parameters per function, could probably do some cleverer arg unpacking...
Usage is as follows, when game is running (from the console), or in code if you like:
If you add a delay time in seconds then profiling will automatically stop and halt the game and report to the console...
Here are the helper functions, class definition is below:
Class definition:
@brooksie and this is why I love this forum! Thanks
I got the same averages as @dave1707 on my iPad 4 using the latest beta.
However, I decided to look a little closer at the numbers being produced and discovered that the variance in the framerate is quite large. The framerate ranges from about half the average to about twice. This results in extremely choppy animation.
If your mesh rectangles are following a deterministic path (as they are in @West's code), it is far, far more efficient to use a shader to update their trajectory. Then you need to pass in a load of initial data but at each draw cycle you only pass in the elapsed time. The shader then computes the updated position. Moreover, as this is happening on the GPU, it can be done in parallel rather than in a single thread on the CPU. Not only is this far, far faster it also results in much smoother animation.
For example, using my explosion shader (which does the same: moves and rotates rectangles), I get a framerate of 30 with 27,000 rectangles. At 55,000 rectangles, my framerate is 20. At 110,000 the framerate is 11. As with the code here, once it starts going down then it is inversely proportional to the number of rectangles but the number of rectangles needed before it starts going down is far higher.
(Incidentally, @Ignatz's terminology is incorrect. A linear relationship is described by an equation of the form
y = m x + c
and this is not. Rather, it is inversely proportional in that the number of rectangles times the framerate is roughly constant. You could say that the relationship between the number of rectangles and the time taken for each frame to render is linear but "time taken" is the reciprocal of the framerate which was the quantity being discussed.)So if you can, shift the mesh's movement into a shader. An explanation of my explosion shader can be found at http://loopspace.mathforge.org/HowDidIDoThat/Codea/Shaders/.
Hi @LoopSpace,
Regarding:
...it is far, far more efficient to use a shader to update their trajectory. Then you need to pass in a load of initial data but at each draw cycle you only pass in the elapsed time. The shader then computes the updated position.
How do you pass arbitrary data in? Is it just a set of numeric variables, or do you 'spoof' up a texture and read results out of eg rgba values?
Just curious...or does the shader now support table/array data?
@Brookesi
@Brookesi Take a look at the link I posted. That contains the details of how to pass this information through.
@TechDojo @LoopSpace I'm still running the slow version of Codea. I expect the fixed version will result in a speed increase of about 3 times. I tried doing a more instant timing and found that the time varied a lot from frame to frame. That's why I used an average time over the whole run, it's easier to get a fixed value. I use the total number of draw cycles divided by the total of DeltaTime.
Hmm - as a lot of those triangles would be passing over each other as they move I wonder if the GPU is doing some clever stuff ignoring overdrawn pixels and therefore the actual drawtime could fluctuate, or alternatively it might be down to the rotation (matrix calc) taking effect, it might be interesting to stop the rotation and just use a fixed angle to see if that makes a difference.
@dave1707 - I actually really noticed the slowdown for the first time yesterday, I was playing with an old fractal landscape demo, where most of the code is done in setup to actually generate the mesh and then each frame it simply repositions the camera. What I noticed is that the initial startup time took a lot longer (so much I'd initially thought the demo had crashed on the new build) but when actually running the difference was minimal (if anything). So I guess any timings on processor intensive operations should be ignored until the new version is released.
@LoopSpace - thanks for sharing the shader code, I'm still trying to get my head around your perspective correct shader
@dave1707 I ran West's code on my iPad and got the same figures as you did. So the speed-up from passing to shaders is entirely down to passing to shaders and not to being on different betas. Also, while average fps gives a reasonable overview, looking at variation can be important too. I looked at the time taken per frame and saw that it jumped a lot, so looked at the minimum and maximum time over the last ten frames as well. That's where I saw that it varies from half to double the average.
@TechDojo Which is the "perspective correct shader" you're talking about?
@TechDojo - In my 3D work I've noticed (the obvious) that the more pixels need colouring, the slower it is, so I wondered if that had an effect here because the screen is so crowded.
I tried simply restricting the images to 1/4 of the screen, so 3/4 was blank, and it had no effect on speed whatsoever, which surprised me, because another thing I learned from 3D is that OpenGL is extremely efficient at culling unseen vertices, and when you restrict screen space, that should mean fewer visible vertices.
@LoopSpace - it was this one http://loopspace.mathforge.org/HowDidIDoThat/Codea/Gradient/
@Ignatz - From my readings of OpenGL I think it can detect (possibly through the use of a z buffer) if the pixels have already been drawn and then not draw them again - I remember something about rendering semi-transparent triangles and making sure that they are drawn in the correct Z order. This would obviously be beneficial if the triangles were pre-sorted in Z.
I worked for a company many years ago that created an arcade board that was very good at rasterising spans of pixels for objects across each scanline ensuring that there was no overdraw. It was very fast and particularly good at scaling sprites (ala Afterburner and Outrun) but semi-transparency then was a real issue (I don't think it was supported - but then it was 1993
).