[SOLVED] Better handling of 3d

[SOLVED] Just finished coding a 2d side scroller just for fun, so I thought that I would try something more challenging. Getting 3D graphics was a little hard, but that’s what I expected. The problem comes when I started to actually build the level. After adding about 40 cubes and a player made up of 5 cubes, the fps dropped dramatically. I’m not sure if this is because the app is using CPU only without the gpu, or if it just isn’t optimized for what I want. For now, I can add it where side of blocks you don’t see won’t draw, but this is only delaying the inevitable when I want to actually start designing levels. 45 blocks should be easy to handle, but the game becomes almost unplayable (lower than 10fps). Some sort of constant to show the fps would also be nice. Despite this, the app is still a great purchase! Keep up the great work, TwoLivesLeft!

Generally, the speed seems to drop roughly in proportion to the number of triangles and meshes, although I’m surprised it’s so slow for 40 cubes.

You could maybe use some 2D trickery. For example, if you’re making a straight wall with a texture from an image, you would normally have to make triangles for each repetition of that image. But if you use a simple shader, you can draw a wall - or a very large floor - with just two triangles, because the shader repeats the image pattern for you.

I also use 2D photos for things like trees, because if you keep them rotated to face the viewer, they look pretty realistic. As a result, I can create a complex 3D scene, with some buildings, 100 trees and a large expanse of hilly terrain, with FPS about 25-30.

So do you really need all those 3D blocks?

Right now the game is super simple. Just a player and blocks (stored in a table for easy level editing). I like the idea, but in my case, it doesn’t help… Just finishing up the code so if a block is out of the view or too far away from the character, it won’t draw, and this seams to help. It could be because I’m using an iPad 2nd gen, so I’ll have to test it on a newer model.

A good tip for 3D is if any of your meshes have transparent pixels, sort them (every time you draw) in order from furthest to nearest, so the furthest gets drawn first. Otherwise you get weird effects, because OpenGL won’t draw anything behind a transparent pixel once it has been drawn (ie it thinks it is opaque, so no need to draw behind it).

An alternative is to “discard” transparent pixels using a shader, so they don’t get in the way. I have code for this.

Your problem may be that you have 12 triangles per block. If you never see the bottom of a block, just leave those triangles out altogether.

The problem is that there is not back or front because the camera rotates around the player. You can sometimes see the bottom of blocks, but I just made it so that if the player is above a certain point, the bottom won’t draw. I also added the same for the top. As for the sides, I’m working on it checking if any other blocks are next to it to see if it can just skip drawing some sides. I’m still working on the math to check the camera angle to discard the sides facing away. All this along with a fog effect should help! Thanks for all the help!

What kind of game are you making, if I could ask?

Are you creating your mesh in setup or draw? It will be slow in draw.

Not sure if this helps or not, but the way some 3d games handels it is by creating “fog” around you and only the blocks in the fog are rendered, thus not having to much pressure on the Ipad.

Just as a side note: I’ve never used 3d before on codea, but Ignatz has. So he can probably help you a bit more then me

Edit: I just realized that’s what your trying to do, oops :frowning:

You should be able to draw 40 blocks, maybe if you share some of your code, we can give you more suggestions…

There shouldn’t be a frame rate drop with so small a number of blocks. The roller coaster example can cope with the order of 70,000 vertices with no appreciable frame rate drop.

Right now I’m using draw (mainly translate, rotate, and rect) and I could see how this would affect the fps… I have now added fog and some code that makes sides of blocks not render if they are facing away from the camera, and this helped a lot! I would like to try the mesh approach and see if I can save myself some headaches.

This is some of the code that I use for it. It’s incomplete right now

ox, oy, and oz are offsets
px, pz, and py refere to the player position
This is written as a function so I can use it in other places as well (the game is block based)

If anyone can give me an example of a mesh that does the same thing would be great!

(sorry about the indents. The “if CamAngle” stuff was tacked on after I finished the code. And it’s a pic because the forum screwed up the returns when I posted)


This is the code that I use for the fog

if math.abs(self.posx - px)<fog and math.abs(self.posz - pz)<fog then



Here is a pic of the game in case you wanted to see it


Oh, I see. You’re using rect. That’ll kill framerate. Definitly use a mesh instead.

The only problem is that I have no idea how to do a mesh…
If anyone wants to help, that would be great!

The character looks really cool, is that textures or all code?

Here is a good mesh tutorial: http://twolivesleft.com/Codea/Talk/discussion/1244/mesh-tutorial/p1

Ignatz also has some I think on his blog coolcodea

His face is just a sprite. Thanks for the link! Once I get the mesh thing figured out, I’ll start posting update videos, so stay tuned if you are interested!

Looking over the mesh, I think I’m going to change all of the static terrain to mesh, but keep the player as is. Again, thanks for all the help, everyone!! This is my first interaction with the community. Glad to see that it is strong and kickin’!!!

No wonder your FPS was slow, if you were drawing 3D with sprites!

I have some posts, look for the 3D section


I have more on meshes here in a Codea ebook, in one of the latest chapters