How to manage BIG scene on Mobile?

[qidaozhilong2]

How to manage the extremely BIG scene using Irrlicht,especially on Android?

I have succeeded to use .obj model as a scene on my game of android phone.
But i found its not a good choice as mobile RAM is so small and no Octo tree, LOD and others advanced skills to raise performance.

Hava any better choice?
And i use 3DMax to make the .obj models and it's useful.

[hendu]

Split it to chunks and load as needed.

[qidaozhilong2]

Split it to chunks and load as needed.

That's a good idea. Maybe i should forget LOD, oct Tree skills.
And still use .obj scene

[Virion]

Check out Occlusion Culling technique. reuse any 3D models as you can. and use texture formats that can be read by hardware directly (such as PVR or KTX), don't use PNG or JPG as it can use up a lot of memory after decompression. you will also need a compressed 3D model format. check out openctm http://openctm.sourceforge.net/

[fmx]

OpenCTM gets small files because of LZMA compression, the data would still need to be decompressed and stored fully inside RAM.
the only thing it will help with is to reduce loading times...

like hendu said, biggest gain on mobile platform will come by splitting the scene into smaller models and only loading what is necessary.
octrees, lod, occlusion culling, and compressed textures wouldnt hurt, use them too

[hendu]

Actually, LZMA decompression is very slow compared to the usual deflate, this difference is much greater on limited platforms such as mobile.

[REDDemon]

the only way to compress models is by reducing number of poligons. Other tecniques will consume the same memory amount with additional overhead for decoding (LZMA, zip, normals discretization). I think that android packages files are alredy compressed (not sure eh ^^) but compressed images may be needed even if the package is already zipped, you will never achieve the same size of a JPG with a zipped BMP. ETC compression helps to solve those problems, is not as HD saving as JPG, but is RAM saving wich is great, and have no decoding overhead.

[Klunk]

usual techniques for art side memory overhead reduction would be....

reduce texture sizes
indexing textures to 8 & 4 bit. (not sure but i don't think it's supported in irrlicht)
shared monochrome textures (can be as low as 4 bit, but as above) , and then varying by colourizing with vertex colours.
polygon reduction.
baked vertex lighting. reduces memory by removing the need for normals at the cost of losing "realtime" lighting. (not really supported in irrlicht)
moving ambient lightmaps from textures to verts.
getting rid of LODS altogether (if memory has priority over framerate)
simplify collision meshes -> reduce polys or reduce to primitive descriptions.

[Virion]

never use jpg. although it has small size but the memory consumption is high.

see this chart:
http://www.learn-cocos2d.com/wordpress/ ... .23.10.png

[hendu]

Now that I'm not buying. One pixel takes the exact same amount of ram uncompressed no matter where it comes from, be it png or jpeg.

edit: Haha, the chart is about loading times on an iPhone, not about VRAM use. Certainly much better.