Video memory leak

[gNikro]

Many vertex buffer never disposed.
For example: AnimationSubGeometry.as create vertex buffers, but never dispose them. May be in another place same situation. I will investigate that more.

[gNikro]

Actualy it should be fixed by #563 https://github.com/away3d/away3d-core-fp11/blob/5c8c16d1d9748898c070cbc6bb5202e9b5c1b548/src/away3d/animators/ParticleAnimationSet.as
BUT, right now even if u call Object3DContainer.disposeWithChilds animators didnt dispose. Animator is internal class of mesh. I really cant image situation when i need animator outside of mesh after disposal of mesh. Actually application context should provide that logic. If u need some meshes after container disposed just remove them from container. Same with animator just set it to null for specific. Its looks like mistake in architecture Container3d.dispose is not actualy dispose it "removeFromParent". Mesh dispose same, ofc if flash can free vram by GC like with ram it maybe OK, But right now if i call dispose of Object3DContainer, i will lose links of childs of that container and they will never dispose. If i call dispose of Mesh, it will be same i just lost link on animator for ever and it never free vram

Of course I can only talk about it, but I think that the Away3D team should as something to solve this problem ....

[rob-bateman]

the explaination for not disposing animators automatically is quite simple. Animators can be shared between meshes and therefore aren't disposed with a mesh.

It similar to our policy on disposing geometry data, which we don't try to do automatically when disposing a mesh because it could be being used by other meshes

Of course, we could create some complex logic to monitor all this stuff and count references etc... but this is not the away3d way. we want to keep things straightforward in the api and keep processing and "magic" behaviour to a minimum. As long as the user is aware that they have to clean up after themselves, we feel it is a better solution, keeping control for these sorts of steps in the hands of the user.

[gNikro]

But why in situation when u clone mesh animator cloned. So if u want to share animator between 2 mesh u should remove animator from mesh, then clone mesh, then add animator if u dont want to create unused clones of animator. Isnt better to do for dispose same logic. Animator can be removed from Mesh before dispose if it shared. Share animator is less common than the standard operation like dispose or clone of mesh. So it easy to do that manually actions few time in project then dispose every child or animator always when u dispose container or mesh.

Just think how it for some one who use away for first time. He Load objects, add particle animation and after fev minuts of application work have exception because ram or vram is over. And ofc he will think "What? I call dispose why memory isnt free" he does not even know about Object3DContainer.dispose is just "remove from parent" etc..

[rob-bateman]

I don't think we can reliably implement what you are suggesting without complexities arising. Better to have the developer aware from the start they have to manage their animators than try and second guess what they require.

[gNikro]

also sprite didt have method to free memory :)