Pandora What Are The 3D Limitations Of The Pandora?

[Barnaby]

Hello everyone, I'm a bit of a noob so I'm sorry if I'm not very clear.

A friend of mine was planning to learn PyGame to code for the Pandora, and when I found out that PyGame can support 3D graphics I was interested in tagging up with him to make a game. I'm a 3D modeller without much experience, and I think making models for a game would drastically improve the quality of my models, as well as give me a goal to aim for. However, I have no idea what limitations the Pandora has. For example, how many tri's could I use per character? How compressed would textures need to be? Is this reliant on just the Pandora's raw power, or is it also down to how well my friend codes an efficient 3D engine?

Supposedly the Pandora has a better graphics chip than a PSP, correct? Would something like this run well on a Pandora then:

http://athey.deviantart.com/gallery/#/dwhl4j

I didn't make this, but it's made for the PSP and has a tutorial for it I was planning to follow. Any tips related to getting 3D graphics running on the Pandora would be greatly appreciated.

Oh, by the way, I use 3DS Max to model, so if anyone know the relevant file type I need to export, that would be handy. I assume it would be something like .obj or .ase? I really have no idea, but these two formats seem to be fairly common (I know the Unreal Engine III uses .ase, as I'm currently making a level in it for my final college project).

 

[JayFoxRox]

A model like this should work, however, the limiting factors are:

- Draw calls (batch stuff and use ibos, vbos, degenerated triangle strips etc.)
- Textures (don't use more than a handful of textures and atlas as much as possible)
- *-Switches (different shaders, renderstates, shaders, ..)
- Rendering to texture (don't expect to use realtime reflections)
- No volume textures (at least it's not supported by the drivers I tried)

The polycount is not much of a problem I think. However, your friend probably has to learn a lot before writing the engine.

For the model format obj sounds fine to me because it's easy to import and it supports most features which are necessary for realtime rendering + you can easily extend it.

 

[Barnaby]

Cheers for the speedy reply! I don't know what all of that means, so looks like I've got some learning to do myself. Could you give me a quick explanation as to what draw calls, volume textures, and switches are? If not I'll google it tomorrow, it's getting late now.

Any game we end up making will probably look fairly simple, so it won't be too high on textures and I doubt there will be many models on screen at once. I didn't expected there to be any realtime reflections, as far as I know that technology only came into use with the Xbox 360 and the PS3, correct? (not so sure about the Wii)

This may never see fruition, but we were just throwing some ideas around and figured it would be a good project for us to do together - he's currently studying music in University, so he'd have to learn the engine in his free time, while I'm studing Games design in college and moving onto the same course in University later this year, so I may be able to do it as a project or something.

 

[Tempel]

Pygame can do 3D? That's news to me, and I've been using it for a while. I know that some 3D engines can render to Pygame surfaces, but then you're just using a 3D engine and Pygame hardly matters. There are 3D engines that will work with Python on the Pandora, but it won't be easy; Eniko is the first to dare, but she'll actually be using Cython, a superset of Python. She also seems to know what she's doing, so I won't dare follow until it becomes simple enough for me.

But if your friend is just learning to program games, I would definitely not recommend starting with something in 3D; that extra dimension makes everything difficult. Your friend should take a shot at making a 2D game first. Fortunately for you, a 3D modeller is still useful for a 2D game. If you make and animate 3D models, they can be rendered to spritesheets and used as 2D sprites in-game. Monk has been doing this for PanJoust, with excellent results.

 

[JayFoxRox]

We have vertex and pixel shaders - basicly we can do A LOT of things, however the problem is that they won't be in realtime anymore. But from the graphics quality, you can expect a lot more than from the PSP.
Basicly if you do graphics programming you have the models vertex data and the information how the vertices are connected (indices).
You upload these to the graphics hardware using vertex and index buffer objects (vbo/ibo).
Then you upload a texture, set up renderstates (stuff like ZBuffer, Texture filters, ..), set a shader (which you also have to upload before) and do a draw call in which you specify which ibo / vbo to use.
The draw call will then tell the graphics hardware to execute the shaders.
First it executes a vertex shader which can move vertices around in realtime without modifying the mesh in RAM (this is used for animations for example). When the vertex shader is done, the polygons are rasterized, for any pixel (/fragment) the fragment shader will be executed which calculates a color for the given pixel (By looking up textures for example).

The actual rasterization should be fast, however, changing the shader (or using shaders which do lots of complex tasks), texture, renderstate, .. is a costly process and should therefore be avoided.

For example, if a texture is already loaded on the graphics hardware you should continue to use that. So even if you only use 64x64 textures it might be clever to upload a 128x128 texture with 4 textures on it to avoid a texture-switch between draw calls. Additionally you can batch draw calls by merging the mesh data into one huge vbo / ibo.
Obviously this does not work for draw-calls which require different renderstates, shaders, texture wrapping, ... - The developer has to take care of this (unless it's already done by your graphics API (Irrlicht for example)).

All of the above assumes he is going to use OpenGL ES 2.0. OpenGL ES 1.1 is closer to the desktop OpenGL, but you won't have features like shaders - hence it might not be the best option if you go for impressive graphics (In the end it could look far worse than something simple in 2D - 3D is harder to do for the developer normally).

//Edit: Tempel: You can wrap almost anything to python. And I'm sure GLES will be wrapped in no time if it isn't already. This is already the reason why I assumed that he is going to use it. It's the fastest option we have as you are working closer to the hardware, compared to other APIs or engines AND it should be available in python unlike most other solutions. (And I wouldn't want to wrap a 100+ function library myself as beginner, but hope someone else does it. In the end it's probably easier to go the GLES route )

 

[warmi]

Assuming no fancy shaders (and a reasonable backend implementation , meaning decent batch counts etc ), you could count on being able to display around 50-60K polys at around 30 fps - of course that's a very rough estimate ... there are many other things in play.

PS.

With a very basic shader I was able to display 9 Counter Strike Source (HalfLife 2 quality) characters running at around 40 fps on the iPhone 3gs ( which has a bit faster GPU but overall is quite similar to Pandora)

 

[darkblu]

Assuming no fancy shaders (and a reasonable backend implementation , meaning decent batch counts etc ), you could count on being able to display around 50-60K polys at around 30 fps - of course that's a very rough estimate ... there are many other things in play.

PS.

With a very basic shader I was able to display 9 Counter Strike Source (HalfLife 2 quality) characters running at around 40 fps on the iPhone 3gs ( which has a bit faster GPU but overall is quite similar to Pandora)

apropos, are the vert/tri stats on those shots correct? if so, you have some spectacularly bad meshes in that test - no vertex sharing whatsoever (#tri == #vert / 3). that's not good for vertex caches.

 

[Exophase]

With a very basic shader I was able to display 9 Counter Strike Source (HalfLife 2 quality) characters running at around 40 fps on the iPhone 3gs ( which has a bit faster GPU but overall is quite similar to Pandora)

Resolution is way different though, unless we're not talking about 800x480 on the Pandora.

 

[warmi]

Assuming no fancy shaders (and a reasonable backend implementation , meaning decent batch counts etc ), you could count on being able to display around 50-60K polys at around 30 fps - of course that's a very rough estimate ... there are many other things in play.

PS.

With a very basic shader I was able to display 9 Counter Strike Source (HalfLife 2 quality) characters running at around 40 fps on the iPhone 3gs ( which has a bit faster GPU but overall is quite similar to Pandora)

apropos, are the vert/tri stats on those shots correct? if so, you have some spectacularly bad meshes in that test - no vertex sharing whatsoever (#tri == #vert / 3). that's not good for vertex caches.

Nah, these wer just fake numbers ... essentially vertex counts calculated out of triangle counts ( admittedly useless data and I got rid of that since then)

 

[Eniko]

Pygame can do 3D? That's news to me, and I've been using it for a while. I know that some 3D engines can render to Pygame surfaces, but then you're just using a 3D engine and Pygame hardly matters.

Correct. Pygame can basically set up a rendering context for 3D work and handle window creation for you, and that's it. The rest is all manual OpenGL work, and will require a different library.

There are 3D engines that will work with Python on the Pandora, but it won't be easy; Eniko is the first to dare, but she'll actually be using Cython, a superset of Python. She also seems to know what she's doing, so I won't dare follow until it becomes simple enough for me.

Looks can be deceiving. Anyway, I can't find any information about PyOgre's bindings being ported to ARM architecture, and I know Irrlicht has Python bindings, but again no idea if those would be usable either. This is despite the fact that Irrlicht and Ogre3D are being ported to the Pandora. Just because a library is ported doesn't mean it's Python bindings will. There's also the chance that PyOpenGL will be workable with OpenGL ES, and in my Googlings I have found a tiny measure of evidence for this.

The problem with just using basic OpenGL is that - last I checked - it doesn't really have any features for model animation. You'd have to write that stuff yourself and that's just a ginormous pain, so the best you can expect from that is rendering your animated models to a sprite sheet and then rendering those as billboards into a 3D scene. Unless your friend is some 3D guru and I'm missing something here.

But if your friend is just learning to program games, I would definitely not recommend starting with something in 3D; that extra dimension makes everything difficult. Your friend should take a shot at making a 2D game first. Fortunately for you, a 3D modeller is still useful for a 2D game. If you make and animate 3D models, they can be rendered to spritesheets and used as 2D sprites in-game. Monk has been doing this for PanJoust, with excellent results.

Good advice if Tempel's assumption is true.

//Edit: Tempel: You can wrap almost anything to python. And I'm sure GLES will be wrapped in no time if it isn't already. This is already the reason why I assumed that he is going to use it. It's the fastest option we have as you are working closer to the hardware, compared to other APIs or engines AND it should be available in python unlike most other solutions. (And I wouldn't want to wrap a 100+ function library myself as beginner, but hope someone else does it. In the end it's probably easier to go the GLES route )

Like I wrote above, unless I missed a memo just having access to OpenGL ES doesn't animate your models for you, so they'd probably still want an actual library which is probably even harder to get to work than wrapping OpenGL ES or converting PyOpenGL so it works on ARM/with ES.

I'm not some guru though so some/all of what I wrote may be just flat out wrong.

 

[Barnaby]

Looks like we've bitten off a bit more than we can chew, but we're still gonna give something a go at least. Rendering 3D models onto a Spritesheet is a great idea, so we're gonna forget about a 3D game for now and focus on 2D for now. My friend's learning the coding side of things, so that might take a while... I'll use the time to improve on my 3D Art and once we have an idea of what we're going to do, make some models for it. He should really join in this discussion... I know he's been watching the topic. Thanks for all the replies, and cheers Tempel for the good suggestion .

 

[1magus]

Can the PSP do shaders? Because I have seen some cool effects on the PSP like glow around weapons and lighting from spells and other things in game, or would these be particles? Also I have seen some real time reflection in Valhalla Knights.

 

[darkblu]

Can the PSP do shaders? Because I have seen some cool effects on the PSP like glow around weapons and lighting from spells and other things in game, or would these be particles? Also I have seen some real time reflection in Valhalla Knights.

none of those things necesitates shaders. apropos, shaders allow for more sane/optimal usage of the GPU hw, but they don't change the fundamental GPU model. some time ago there was an academic HLSL (high-level shading language) that was implemented entirely on top of fixed-pipeline openGL, but I can't be bothered to check the name of that project now.

 

[JayFoxRox]

Can the PSP do shaders? Because I have seen some cool effects on the PSP like glow around weapons and lighting from spells and other things in game, or would these be particles? Also I have seen some real time reflection in Valhalla Knights.

Probably screen space effects by rendering the whole framebuffer a bit larger over the existing one with transparency.
In Suicide Barbie the "bloom" was done by creating it with the CPU in a post-processing step, because the graphics hardware was busy with the scenes and the implementation to ineffective.

The PSP has support for envmapping too which is used in some games for reflections. Wether you update the envmap is a different story - but if you want to, you can ofcourse do that.

Things which we can't do on the PSP but on Pandora would include per-pixel lighting (including normalmapping for example), math and particle physics on the graphics hardware (this would be ineffective on the SGX though - but possible ), proper gaussian blur, unlimited number of lights (as long performance allows you to, PSP had 4 lights max.), raytracing on graphics hardware, .. just to name a few of it

 

[nexferret]

Look up glBlendFunc. You can do all kinds of funky (badum tish) things with it, such as inverting the colours of whatever sits behind, adding to the colours (making a bright light) or blending between the two (good for smoke) and glEnable( GL_ALPHA_TEST ) is good for cutouts such as leaves and wire mesh fences. There is a problem with glBlendFunc, though, in that it can be problematic unless you render transparent things last.