Adding a new option in the creating atlas which will pack the atlas in the z order and this minimizing the draw calls

[rahulkamra]

May be it will take another parameter like which is the main scene http://en.wikipedia.org/wiki/Painter%27s_algorithm

[tconkling]

I'm afraid I don't understand what you're asking. The order that assets are packed into a single atlas shouldn't have any effect on the number of draw calls. Are you referring to multi-atlas output? In this case you might want to use the "optimize for speed" output setting, which will minimize the number of atlases at the possible expense of memory.

[rahulkamra]

Say i have 5 atlas in my project , we can make the the atlas in the order of zindex, As starling using painter algorithm so the most optimized 5 sprite sheet will only have 5 draw calls, Right now the flump does not consider the layout of the objects to make the atlas which can be added. I hope you get the point.

PS: Everything i am talking about hold when you have more than 1 atlas.

[tconkling]

Ah, I see. I don't think this is something that should be added to Flump, as it's pretty case-specific. There's no meaningful z-sort order for many (most?) games, because Flump can't know where specific animations will end up in the display list. And individual animations frequently have textures that are used multiple times, at different z indices.

The best way to minimize draw calls will almost always be to have the application build new texture atlases at runtime, containing exactly those textures that you know you'll need.

[tconkling]

(Incidentally, I think this would be a great feature for the flump runtime: something like FlumpLibrary.optimizeMovies(...movieNames), that creates a new atlas containing only the textures used by those movies)

[aduros]

Flump does know the depth-first order that will be used to render the textures that make up a movie, and it could conceivably use that to prioritize the pack order (instead of largest first). This seems like a rabbit hole though, and may be worse for some applications.

[rahulkamra]

Yes for some cases it might be worse but in most of the cases it will reduce the draw calls by considerable amount

[tconkling]

I'm curious what the situation is where you have so many atlases for a single flump library. The latest version of the exporter allows you to prioritize runtime speed over memory (by not creating new texture atlases until it can't fit a new texture into the largest allowed atlas size) - are you using this setting?

[rahulkamra]

Yes , we are using it and we actually have 3 atlas (around 100 objects)and we end up having 20 + draw calls , this can easily be minimized into 3 draw calls. and on totally another note , is there any new upcoming flump features?

[groves]

Are all of the 100 objects used together, or is there a logical grouping that could split them into separate flas? If they were in flas by usage, it would get the ones used together in the same atlas. That's how we envisioned Flump being used when creating it: group assets into flas by their being used together, and use that to load a minimal set of atlases and animations for a scene.

Apologies if that's a ridiculous suggestion, but I'm not clear on what's in the fla. Any more detail you can provide would be great, to have an idea of how people are using Flump if for nothing else.

As for upcoming features, I don't know of any under active development. Is there something missing that you need?

[rahulkamra]

Currently everything is a part of the scene, and flump can take another parameter which will tell which is the main Movie Clip. This clip will act as a parent clip and tell how to create atlas and the textures which are left will be packaged as per the current implementation . I was looking for more control over packaging , At the moment i cannot control where the texture will end up and thus cannot control draw calls.

And as far as upcoming features is concerned , The most important which i can think of is ATF , this can help to bring down memory by 80%, and this can be an option , plus the runtime does not have the option to play an animation over a specific amount of time , everything is controlled by FPS , I should be able to tween between two KeyFrames with any time duration also there is no looping of the animation between two keyframes.

PS : You guys did an awesome job in creating Flump .

[groves]

The most important which i can think of is ATF , this can help to bring down memory by 80%, and this can be an option

Ahh, I hadn't heard ATF was available. I've opened #53 to track work on it, not that I have time to work on it at the moment myself :bowtie:

plus the runtime does not have the option to play an animation over a specific amount of time , everything is controlled by FPS , I should be able to tween between two KeyFrames with any time duration also there is no looping of the animation between two keyframes.

We kept the API of the runtime svelte to allow these sorts of actions to be implemented by users of the library in the style they prefer. They're all pretty easily accomplished with the methods provided by the runtime.

PS : You guys did an awesome job in creating Flump .

Thanks!