[mjn.mixael]

The problem with just raising the bmpman limit is that it's not limiting missions, it's limiting interface (mainhalls to be specific) and so raising it by 500 won't be enough to load all the EFF frames simultaneously. To get around this, I have to use a streaming format which is only ANI at the moment. (Horrid quality)

[niffiwan]

ahh - thanks for that info - I was completely unaware of the mainhall problem

[Rodo]

Few Notes: I changed the head animation system to use generic_anim's instead of the anim_play framework so this could possibly fix the head.ani stuttering please check that.

I think you nailed it.

[jr2]

Concerning hitting the bmpman limit 5 possible solutions:

• Unload the eff everytime the animation finishes (Bad for cases where theres much reuse)
• Write a separate handler with dynamic limits (lots of work)
• Same as 2 but push everything into gl textures and dont keep the data in memory (high vram usage)
• Load every frame individually and unload it everytime the next frame is displayed (isnt this what causes the .ani stuttering?)
• Sort of a hybrid of 2 and 4 and the old bmpman where you load some frames ahead of time render them while loading more and killing old unused ones

DISCUSS!!!

Question..

Why is the bmpman limit there?  High memory usage?  If so, would it be possible to use some sort of high quality compression like h.264 and just raise the limits by however much memory is saved?  I mean, you would of course increase CPU usage, however, how much CPU could a head animation at ridiculously small resolution take?  And, in the mainhall, it's not like the game is running, so if your rig can handle full-screen h.264 video playback, that shouldn't be a problem, right?  FWIW, x264 is a free encoder for h.264.

* jr2 prepares for the possibility of not knowing what he was talking about and being beat with the non-working plasma rifles... 

[niffiwan]

x264 is GPL'd - so we can't include it in FSO (to the best of my knowledge)

As for the BMPMAN limit - read what taylor said (many years ago now I admit...)

[Fury]

[Captain Obvious] FSO badly needs a streamable container which takes up only one slot regardless of how many frames the container contains. [/Captain Obvious]

Are there really no other readily available container formats with compatible license other than those two obscure PNG derivatives?

[niffiwan]

Few Notes: I changed the head animation system to use generic_anim's instead of the anim_play framework so this could possibly fix the head.ani stuttering please check that.

I think you nailed it.

The stutter is gone for me as well 

[jr2]

[Captain Obvious] FSO badly needs a streamable container which takes up only one slot regardless of how many frames the container contains. [/Captain Obvious]

Are there really no other readily available container formats with compatible license other than those two obscure PNG derivatives?

Hmm... http://en.wikipedia.org/wiki/Container_format_(digital) 

Matroska (MKV) (not limited to any codec or system, as it can hold virtually anything. It is an open standard and open source container format).

>>  http://en.wikipedia.org/wiki/Matroska

CoreCodec owns the copyrights and trademarks for the Matroska specification, but the specifications are open to everybody. The Matroska project is an open standard which is free to use and the technical specifications are available for private and commercial use. The Matroska development team licenses its libraries under the LGPL, with parsing and playback libraries available under BSD licenses.

Is that feasible?

EDIT: Also,

Containers for h.264: .mp4, .mkv, .mov.

x264 – H.264/MPEG-4 AVC implementation. x264 is not a codec (encoder/decoder), it is just an encoder (it cannot decode video).

 

On August 26, 2010 MPEG LA announced that H.264 encoded internet video that is free to end users will never be charged royalties.[10] All other royalties will remain in place such as the royalties for products that decode and encode H.264 video.[11] The license terms are updated in 5-year blocks.[12]

http://en.wikipedia.org/wiki/X264
http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC
http://en.wikipedia.org/wiki/Open_source_codecs_and_containers
http://en.wikipedia.org/wiki/Matroska
http://en.wikipedia.org/wiki/Digital_container_format
http://blog.superuser.com/2011/11/07/video-conversion-done-right-codecs-and-software/

[The E]

No, jr2, those are not really options available to us.

h264 video would be nice, but AFAIK we'd have to write our own decoder (since libavc and similar are GPL).
mkv would be nice, but without h264, using it makes little to no sense.

The only real options we have (and it would be only slightly worse than mkv/h264) would be to either roll our own mng implementation, or allow ogg video streams as another option for ani replacement.

[mjn.mixael]

the problem of ogg is lack of transparency.

[The E]

Which is not a problem for head anis, and an art design issue anywhere else.

[mjn.mixael]

that is a very short sighted assumption. 

I'll explain when I'm not on my phone.

EDIT: Explanation.

I don't want to be boastful, but you need to consider my credibility here. While you have read and possibly created some of the code as well as having made or added a few anims to FSO, I have worked with FSO's anims to the limits. I've created over 400 anims (.ani and .eff) and, as far as I know, I've made the only fully functioning 3D mainhalls. I know what I'm talking about.

Now, the first thing that comes to mind is that transparency is a retail used feature with anims. It's also a feature I've used extensively. Think CB Anims.. what if I want a logo anim with a seamless background to match the interface? Best way to do it is to render the animated logo on a transparent background (or full green for .ani). I've also used this for ship/weapon select anims so that they are transferable to any interface style and just just FS2 style.

Now, for mainhalls. You can not do 3D mainhalls without transparency and have it look good. You just can't. Retail Bastion uses transparency for the cranes, as do I. I also use transparency to blend all the doors and misc anims onto the background seamlessly.

All in all, transparency is an essential thing to be used for a lot of anims throughout FSO. Calling it an art direction issue is extremely short sighted and, frankly, I'm shocked that you, of all people, would say that.

[The E]

You are, of course, correct, and I didn't mean to belittle your efforts or desires. I also realize, upon rereading my post, that I worded it in an unnecessarily clumsy way.

I am just saying that ogg video as an option would be a good thing to have, not that it was the only, or even best, option.

[Droid803]

Tbh I don't think that

There is currently a limit of 4,750 bitmaps that can be loaded at one time. THAT LIMIT WILL NOT BE INCREASED AGAIN. The limit was calculated (by myself) based on the code changes to bmpman, the largest texture map using mission available at the time, plus an extra buffer factor for the future.  In theory, if the effect and model producers followed certain rules (which almost no one knows at this point), then it would actually be possible to drop that limit to a lower level given the changes to bmpman.

Is a valid reason for me anymore. To me it's sounding like "EVERY PIRATED SONG IS WORTH $800,000 IN  LOST PROFIT! This was calculated (by myself) based on statistics, the largest amount of money we've successfully sued for, plus an extra buffer in case we want to sue for more."

It's totally failing to address (or predict) a number of things. Yes, getting rid of tilerape would help, but for every animated glowmap you add, you have to de-tile 3 ships... For every new explosion effect with 50 frames, you need to what, de-tile 5-7 ships? Clearly model producers at this point are the least of the problems - each of my ships uses two, maybe three textures.? Same with Spoon's in WoD, and we can still hit the limit!?

It still hasn't been explained why a bmpman limit exists in the first place. It's certainly not memory because I can shove 4750 textures which are 8192^2 in there and it'll happily accept all of them...until I run out of video memory, crash, and burn. So what's the real reason for this (completely arbitrary) cap of 4750?

[The E]

It still hasn't been explained why a bmpman limit exists in the first place. It's certainly not memory because I can shove 4750 textures which are 8192^2 in there and it'll happily accept all of them...until I run out of video memory, crash, and burn. So what's the real reason for this (completely arbitrary) cap of 4750?

Are you seriously saying that you have several Terabytes of RAM available on your machine?

[Kobrar44]

This is irrelevant. Bmpman limits are supposed to prevent something from happening. What is that eactly and would gates to hell open if the limits were simply pulled?

[Droid803]

It still hasn't been explained why a bmpman limit exists in the first place. It's certainly not memory because I can shove 4750 textures which are 8192^2 in there and it'll happily accept all of them...until I run out of video memory, crash, and burn. So what's the real reason for this (completely arbitrary) cap of 4750?

Are you seriously saying that you have several Terabytes of RAM available on your machine?

No, but I'm saying that since it only cares about texture count and not texture size it's worthless as a memory controller, because you can just as easily run out of memory by shoving massive textures in there.

[mjn.mixael]

Bmpman with a limit is not an inherently bad thing. The problem here as it relates to EFFs and the interface is that we are using a screwdriver to hammer a nail. Bmpman wasn't built with the idea to store each frame of an animation as a separate handle (which is evidenced by how. anis work). Concurrently, .eff wasn't built to always be a huge set of image files to be loaded.. it is (according to the mantis ticket I linked above) an incomplete-ish feature... but one that works very well in most cases.

[Valathil]

I've been studying the code and found something interesting. You guys ever seen the "Fast-unloading ...." stuff in the log. It seems that after a Texture is successfully put into OpenGL we dump the image from system memory anyway. Have I missed something? And if not that speaks even more as the limit not being representative of memory limitations. I also want to chime in in respect to loading/streaming. You cant have both the fastness of preloading everything and the low memory requirement of streaming at once I just wanted to say that so we need to decide what we want with the animations. To me it looks like the head.ani problem was because every frame was loaded individually a.k.a. streamed. SO if we want to preload we have basically 3 options. Either increase the bmpman limit, kill all animations after playing and always reload them, or load animations with a system outside bmpman which is basically the same effect as increasing the limit WITHOUT increasing the limit.

Also i just noticed theres a HUD section in the mod.tbl i moved the setting there but i wont release an updated build just for that but keep it in mind for the future

[mjn.mixael]

Valathil, I'd love to hear your thoughts on these previous discussions. One solution to this problem was the implementation of the MNG format. Its a container and, I assume, would work like ANIs in regard to bmpman slots. It allows transparency and compression. The problem is the format is somewhat lacking in available tools.. so yeah, give the threads a once over, I'd love to know your thoughts on it.