I'm developing an iOS game targeting iPad 3/4 that features a high resolution map display. I am using Ogre 3D as a graphical foundation. I have 100 1024x1024 textures stored as .png files which take up 58 MB of hard disk space total. I would like to display anything from 2 to 40 of these textures at once depending on zoom level. I would also like to keep RAM usage below 500 MB if possible.
I have set up some code to load all of these textures as a unique material, each assigned to a Rectangle2D. I then attached 16 of these textures to a scene node to make them visible. This resulted in around 400 MB of memory usage at varying zooms. Attaching all of the textures to that node resulted in a crash due to lack of ram even if 96 of them were off screen and culled.
I am generating 5 mipmaps by default. Assuming these were in .png format it would only roughly double the 58 MB. Obviously there is some decompression going on here. (If the generated mipmaps were completely decompressed, this would account for the memory usage). I can lower the resolution by a factor of 2 and make this work easily enough, but I'm trying to avoid having to do that.
What tools and strategies are available to conserve RAM in this case?
Thanks for any help!
 Home
 » Viewing Profile: Topics: daedalic
daedalic
Member Since 28 Nov 2010Offline Last Active Aug 25 2012 04:38 PM
Community Stats
 Group Members
 Active Posts 31
 Profile Views 1,778
 Submitted Links 0
 Member Title Member
 Age Age Unknown
 Birthday Birthday Unknown

Gender
Not Telling
Topics I've Started
Memory conservation for tiled textures using Ogre 3D
14 August 2012  11:03 AM
Best data structure for storing pointers with indexing by 3D points
29 March 2012  05:56 PM
This data structure will have frequent insertions and lookups. In addition, it needs to be able to return a null pointer if it is indexed by a 3D point that has not had an insertion associated with it. Up to millions of pointers will be inserted into this structure.
At first glance some form of associative array seems appropriate, but the 3D component complicates things. So I'm not sure if i need to use spatial partitioning with this or not.
If its any help, the ranges for the x and y components are integers from 1 to 100,000+. For the z component it will range from 1 to 1,000+. The points that index this structure will be near each other. A distance of more than 1000 between any points used here is unlikely.
Memory usage and speed are both important in this case.
If there isn't a clear winner for a data structure to use, feel free to name several candidates.
Thanks for any help!
At first glance some form of associative array seems appropriate, but the 3D component complicates things. So I'm not sure if i need to use spatial partitioning with this or not.
If its any help, the ranges for the x and y components are integers from 1 to 100,000+. For the z component it will range from 1 to 1,000+. The points that index this structure will be near each other. A distance of more than 1000 between any points used here is unlikely.
Memory usage and speed are both important in this case.
If there isn't a clear winner for a data structure to use, feel free to name several candidates.
Thanks for any help!
Best Data Structure for Traversed Nodes for A* on a 3D Grid?
02 February 2012  07:36 PM
This particular A* implementation I am starting on will be operating on a 3D grid of a large size, where every node represents a cube in that 3D grid. What is the best data structure for storing refrences to the nodes that have already been traversed in this case? This data structure would ideally be able to work well for both very small and very large search spaces.
The idea I came up with would be a dynamically growing octree, that would begin with just the one start node and would grow over time and add additional layers of parent nodes as the search space increases. Performance is critical, so I need to know if there's a better way to do this.
Thanks for any help!
The idea I came up with would be a dynamically growing octree, that would begin with just the one start node and would grow over time and add additional layers of parent nodes as the search space increases. Performance is critical, so I need to know if there's a better way to do this.
Thanks for any help!
How do I get elements in a variadic templated tuple
21 November 2011  01:12 AM
I am making a tuple class using variadic templates and am stumped on how to correctly implement a get element function.
I've tried a few approaches, only to have them fail miserably for various reasons.
Here is my code for the tuple:
I am not interested in using the stl tuple, I am just interested in learning how to use variadic templates.
Thanks for any help!
I've tried a few approaches, only to have them fail miserably for various reasons.
Here is my code for the tuple:
// undefined tuple template<typename... T> class tuple; // empty tuple template< > class tuple< > { }; template<typename U, typename... T> class tuple<U, T...> { public: tuple () {}; tuple (U& f, T&... r); U first_; tuple<T...> rest_; }; template<typename U, typename... T> tuple<U, T...>::tuple (U& f, T&... r) { first_ = f; rest_ = tuple<T...> (r...); }
I am not interested in using the stl tuple, I am just interested in learning how to use variadic templates.
Thanks for any help!
Potential Problems with Perspective and LookAt Matrix
02 September 2011  01:29 AM
I am designing matrix functions for a right handed coordinate system where x is right, y is forward, and z is up.
Currently, I am using matrix code taken from a right handed system where x is right, y is up, and z is backward. I have not modified this code except for yaw pitch and roll which seems to be working fine via a 90 degree clockwise x axis rotation applied to it. Although the game terrain appears to look normal, the camera starts facing down instead of forward and movement of the camera position is very odd.
I am thinking that some modifications to the perspective and lookat matrices are needed. I have tried a few modifications such as the same 90 degree rotation given to yaw pitch and roll, but none of these modifications have helped much and they usually make things worse.
Here are the functions for perspective and lookat matrices that I am currently using:
Does anyone have any ideas on how these functions can be corrected?
For starters it seems that height might be better off in a z position instead of a y position in perspective, and that given the different direction of up, z and y could be swapped in some way in lookat. However simple swaps don't seem to help much, so I must be missing something.
Thanks for any help!
Currently, I am using matrix code taken from a right handed system where x is right, y is up, and z is backward. I have not modified this code except for yaw pitch and roll which seems to be working fine via a 90 degree clockwise x axis rotation applied to it. Although the game terrain appears to look normal, the camera starts facing down instead of forward and movement of the camera position is very odd.
I am thinking that some modifications to the perspective and lookat matrices are needed. I have tried a few modifications such as the same 90 degree rotation given to yaw pitch and roll, but none of these modifications have helped much and they usually make things worse.
Here are the functions for perspective and lookat matrices that I am currently using:
void MatrixPerspectiveFov (Matrix& dest, float32 fov, float32 aspect, float32 nearClip, float32 farClip) { float32 height = Cot (fov / 2.0f); dest.Init (height / aspect, 0.0f, 0.0f, 0.0f, 0.0f, height, 0.0f, 0.0f, 0.0f, 0.0f, farClip / (nearClip  farClip), 1.0f, 0.0f, 0.0f, nearClip * farClip / (nearClip  farClip), 0.0f); } void MatrixLookAt (Matrix& dest, Vector3D& eye, Vector3D& at, Vector3D& up) { Vector3D xAxis; Vector3D yAxis; Vector3D zAxis; Vector3DSubtract (eye, at, zAxis); zAxis.Normalize (); Vector3DCross (zAxis, up, xAxis); xAxis.Normalize (); Vector3DCross (zAxis, xAxis, yAxis); dest.Init (xAxis.x, yAxis.x, zAxis.x, 0.0f, xAxis.y, yAxis.y, zAxis.y, 0.0f, xAxis.z, yAxis.z, zAxis.z, 0.0f, xAxis.Dot (eye), yAxis.Dot (eye), zAxis.Dot (eye), 1.0f); }
Does anyone have any ideas on how these functions can be corrected?
For starters it seems that height might be better off in a z position instead of a y position in perspective, and that given the different direction of up, z and y could be swapped in some way in lookat. However simple swaps don't seem to help much, so I must be missing something.
Thanks for any help!