Memory usage of int float string textures meshes ?
Blitz3D Forums/Blitz3D Beginners Area/Memory usage of int float string textures meshes ?
| ||
| Hi :) I have searched the forum to understand how many bytes/octets a variable or a texture or a mesh or an animation can take in memory. I want to know this by curiosity, and also to see how detailed a mesh can be before taking as much memory as a texture. What i have read so far : 1 integer = 4 bytes For example : 1000 integers = 4*1000 = 4000 bytes which is approximately 4 ko ? 1 float = 4 bytes For example : 1000 floats = 4*1000 = 4000 bytes which is approximately 4 ko ? 1 string = 4 bytes + length of string For example : 1000 strings of 20 characters = (4+20)*1000 = 24000 bytes which is approximately 24 ko ? 1 texture or 1 image = PWidth%*PHeight%*3 bytes (R%,G%,B%) For example : 1 texture or 1 image of 1024*1024 -> 1024*1024*3 = 3145728 bytes which is approximately 3.1 mo ? 1 mesh = number of surfaces + number of vertices per surface*12 (X#,Y#,Z#,NX#,NY#,NZ#,U#,V#,R%,G%,B%,A#) + number of triangles per surface*3 (V0%,V1%,V2%) For example: 1 mesh of 2000 tris with one surface, assuming each triangle has its own vertices = 1 + 2000*3*12 + 2000*3 = 78001 bytes which is approximately 78 ko ? 1 animation 3d (with each vertex influenced by only one joint, no weights) = numbers of frames*number of joints*9 (X#,Y#,Z#,Pitch#,Yaw#,Roll#,ScaleX#,ScaleY#,ScaleZ#) For example : 1 animation of 100 frames with 17 joints = 100*17*9 = 15300 bytes which is approximately 15ko ? These previous examples are not accurate, they are a guess, please correct what you think is false or missing. From the results above, it shows that a mesh is really "light" compared to a texture ! But i guess this does not mean that the performance will be better with a highly detailed mesh rather than with a texture ? Thanks, edit : removed some errors, added some details |
| ||
| Yeah, you've only really considered the core data here and not the packaging objects that "wrap" this data to make it usable (e.g. consider where EntityX and so on are held - not in the vertex array!). e.g. A string is actually has a 24-byte header, which is copied for every reference to the string (but on the other hand, allocated from a free list so technically the space used doesn't change often... yeah), and the character data may take up more space than the length of the string too, as it is rounded up to the nearest convenient size for fast allocation. Images and textures pixel data is held within a DirectX buffer, which in turn is held within a Blitz Image or Texture object. These objects hold data like the X and Y size of the image, the refcount of the texture, the blending modes in use, and various other magic used for speeding things up much of which isn't available to the end user. Probably come to <256 bytes if I recall correctly? Meshes are entities, and thus have a vast amount of metadata beyond just the vertices and triangles (position, rotation, scale, parents, names, transformation in "high-speed" internal matrix format, more alpha blending and so on). All together comes to around 1KB. For animations... bone weights are stored in the mesh/surface data, and have nothing technically to do with animation (the visible effect on the mesh is part of the rendering step, not the animation step). More importantly, there is no guarantee that an animation will have a keyframe for every joint every frame, so no there is no easy way to guess the size of an animation by its length or skeleton size: any given frame could be a keyframe for an object, or it could not. Most animations won't be anywhere near as large as that estimate. So.... the answer is that while inaccurate, your guesses are useful because they do account for the bulk of the data and the rest is tiny by comparison. It's actually more useful to think in terms of orders-of-magnitude, or size multipliers, than it is to bother to remember the individual bytes of tiny structures that don't get multiplied up. But i guess this does not mean that the perfomance will be better with a highly detailed mesh rather than with a texture ? The way things are handled in hardware these days with dedicated circuits for applying a texture to a mesh means that texturing is essentially a free operation, performance-wise. Important limits to consider are: - B3D meshes have a detail limit of 65535 vertices - you can add surfaces to get more detail - surfaces are the blocks in which data is sent to the graphics card: one complex surface will load quickly, ten simple surfaces will load slowly - textures stay on the graphics card unless being edited ...while it is possible to come up with interesting new ways of rendering things, textures are very, very fast these days. CPU-edited meshes on the other hand are not, as that's kinda the opposite of where shader technology has evolved. |
| ||
| Interesting infos, thanks :) I have forgotten to count the material used by each surface in a mesh. CPU-edited meshes on the other hand are not, as that's kinda the opposite of where shader technology has evolved. I don't know if you meant "in real time" or not but if a mesh of, for example, an armor part, is created only when the player opens a furniture or when he equips it inside the inventory, i don't think this will cause any slow down. What i am trying to do is to create a game with only meshes colored with vertex colors and to use vertex lighting on subdivided meshes so that the render looks nice. I will use a few textures for some effects and the particles but that's all. A render like this but with more detailed crates and furnitures :  I also use the DevilShadowSystem, and i really like it :) |
   |