Anim8or Community
General Category => Ongoing Anim8or Development => Topic started by: slex on March 10, 2016, 03:53:27 pm
-
unfortunately, I had few crashes in scene editor when there are many steps with loaded object consisted of a mix of subdivision+mesh+textures and it's figure and sequence with multiple instances included in a scene, my laptop has 4gigs of ram so I guess it isn't computer. I've noticed in task manager that program becomes slow when there are too many undo steps, it starts with 25MB, after loading the project it goes to 50MB and with each new movement it adds few megabytes of ram in the task manager.
Maybe increasing undo buffer to 500MB or even more could solve the problem or limiting the undo-redo to maximum of let's say 15 steps so it 'forgets' older steps?
-
slex: My guess is that like Anim8or isn't freeing the undo history memory once it surpasses the limit. It's supposed to delete the earliest data when this happens but it doesn't seem to be doing that. I'll see if I can find the cause.
-
Actually, here is a prtscr. memory goes way beyond 100MB, I did very big number of steps in a scene :o
-
The undo code seems to be working properly. It can use a bit more that the limit, but just one undo record more at the most. When it frees history it deletes the earliest records until it is just *above* the limit instead of just *below* it.
I don't see why your project should be that big. Are you using a lot of textures, especially large ones? How many scenes, etc are there? Have you been runnning Anim8or for a long time and the size keeps getting bigger? That *could* mean a memory leak. I always develop using a debug mode that checks for leaks and I don't know of any, but that doesn't mean there aren't any.
Note that the number used for the max size of the undo buffer is just for that, the undo buffer. There are many other things that can use much more memory than this. All geometry is stores at least twice (for the model and for the OpenGL buffers), textures are stored as full size images (i.e. a 4k by 4k RGB .jpg file might use only a bit 1 or 2 MB on disk but in memory it uses almost 100 MB, including mipmaps), and subdivision meshes, while they are very compact on disk, can grow quite large when expanded into memory.
However keys for animation do not use very much memory. I doubt that the length of the animation makes much difference.
-
textures are stored as full size images (i.e. a 4k by 4k RGB .jpg file might use only a bit 1 or 2 MB on disk but in memory it uses almost 100 MB, including mipmaps), and subdivision meshes, while they are very compact on disk, can grow quite large when expanded into memory.
And he is not kidding either,
I made a drawing application that handled large images (I made it just for quick tests) and needed fully uncompressed images in memory so a image would take the full space it required. A 10000 x 10000 32 bit (rgba) sized image took up around 400 Mb in ram.
8 bits per channel = 32 bits
32 / 8 = 4 bytes = one pixel
4 bytes * 10,000 * 10,000 = 400,000,000 bytes
400,000,000 / 1000 = 400,000 Kilobytes
400,000 / 1000 = 400 Megabytes
Also I was using (one of) the oldest opengl function for taking image data from Ram and uploading it to the Vram (glTexSubImage2D) in real-time. That probably spawns nightmares in Steves dreams :P
-
That calculation while correct comes in 2 flavours.
The second is
(400,000,000/1024)/1024=381MB
heh, what is the average texture size people are using here?
My average is 64x64x4 and my largest would have to be 3200x1600x24 360 panorama
Trev
-
Perhaps this is me (or my Little tablet) but I make up a Rig with some objects attached , go to figure editor to manipulate the bones do a sequence all looks good. Next I go to scene to build/Add figure and this is where it all falls down , I have a figure without the rig, I can add sequences to a non -existent rig, but obviously nothing animates. Build 1222
-
Memory 'thing' didn't happen to 1219 dev. version and on 0980 version with the same project. Also, after removing two jpeg files used for eyes and body everything worked without memory increase. Here is the whole project, anyone can use/change the given model for every purpose, without those two .jpg files which are not mine- I downloaded them from internet, just point that 'Slex' made the base model if you want. cheers
-
slex: Thanks for the project. This very well could be a memory leak since it doesn't happen with earlier versions. I'll look into it.
-
slex: can you tell me the image size and format of the two missing textures? I.e. .jpg 1024x1024, .png 64x64, or whatever. I don't think I need the actual images.
-
That calculation while correct comes in 2 flavours.
The second is
(400,000,000/1024)/1024=381MB
heh, what is the average texture size people are using here?
My average is 64x64x4 and my largest would have to be 3200x1600x24 360 panorama
Trev
Yea I was rounding numbers just for simplicity.
As for that res, it depends on what I am doing.
If I am dealing with scans or master copies I usually have resolutions above 5000 x 5000 (like that 10,000x10,000 I mentioned), but If I am just making a simple ground texture it is usually just a 512 x 512 image.
-
Steve, only those two pictures within the zipped file were used on the body. One of the missing pictures is about 600kb, and others are about 15kb.
-
slex: I need to know the image sizes, not the file sizes. It makes a difference on how they are handled inside of Anim8or.
Note: I googled "eye-162183_960_720.png" and was able to download it, so all I need is the image size of "images (2).jpg". (I love Google!)
-
that was a cunning way to find the picture ???, I'll upload all the included pictures in few hours because I'm not at home near the working comp.
-
I also loaded your project and noticed some things.
When I load the object or figure its fine, but when I enter sequence mode it slows down dramatically.
When I press play in sequence it playes at 8fps, yet I can drag the timetrackbar accross the screen and play the animation at probably double that (pretty much as fast as I can rotate round the object in arc rotate, which while slower than in object or figure mode, is still a lot faster that 8 fps)
Scene is also the same.
I noticed that while you said there were no textures, when I downloaded the zip it did have textures, the eye and metal.
I had no problems with these at this time.
Trev
-
steve: here is the missing file, I didn't use it for the texturing nor the file that you already found, file 'texture0' is missing but it's the same as 'untitled 2'.
-
trevor- on my computer(i3 CPU, integrated graphics) it plays in sequence at 30Fps, in scene 16Fps. I've tried to open it with few older versions of anim8or and the results are similar.
The only thing that speeds up the play preview a bit is to hit the wireframe mode button, if everything is hidden except bones then it goes at full speed. It's interesting that moving thru the scene with time slider allows much faster preview
-
The only time I get less than 30 fps for any scene or sequence is with 4 views, flat rendered with lines shown. I have an I7 with a GeForce 960. I noticed that the head has far more faces than necessary.
I suggest reducing the subdivision level to just 1, or simply replacing the head with a simple sphere. If you set the divisions to 16x16 or 32x16 it should look fine.
-
thanks for the idea, interesting- I just changed subdivided head to mesh which gives 30Fps at preview in scene and no lag at all. Scene mode 'likes' meshes :)
update- render time for camera view is almost twice faster when all the subdivisions are converted to meshes
-
Steve, what i7 do you have?
i7 is a catagory and means "Performance", where i5 ="Efficiency" and i3 = "Value"
The Specs of the chip are in its name, i.e. Northwood, IvyBridge, Haswell, Broadwell etc
As for the model, Ill need to try it again later to see if there are any differences between subdivide and mesh at the same polycount.
Trev
-
Oops, I was mistaken. My current development computer is only an i5-2400 3.11 GHz. I don't know the name.
-
I too was mistaken, the name is its manufactoring size (eg, 130nm, 22nm, 22nm, 14nm etc)
You were right to provide the number, as even within each lithography they divvy up the specs.
I havnt closed any other open apps as I am working on them, but converting the subdivide to mesh (same polycount) results in a 0.2 fps increase from 3.6 to 3.8 in scene mode. (I ran it repeatedly and took the average)
OGL is running is software mode at this time because of the other apps open (even though PerfectGold uses DirectX)
When I take a break, I will run the scene again in hardware mode.
However, as steve has already indicated, you have modeled excessive faces on the head, eyes and hands. :P
Trev
-
I guess that the speed of the workspace and render depends on many different factors, and it is obvious that different computers give various effects. If I knock down the polygons on the hands, eyes and head then it wont look smooth and that's not acceptable. Slowed down wireframe mode is the thing that is very strange, it shouldn't be so slow, but I guess that here is the main issue weak integrated graphics card.
-
Wireframe is no different to solid if you use transparent faces.
If you uncheck that then wireframe is faster.
Trev
Hardware mode:
Sequence mode subdivision 31fps
scene mode subdivision 15fps
sequence mode mesh 31fps
scene mode mesh 20fps
scene mode mesh wireframe (No semi-transparent faces) 22fps
-
If the project is saved and reopened it also makes difference, gets a bit faster.