Image Packing - inefficient?

#1 If it's 256 wide, and you have "filterpad" true, I think that makes it 257, which causes the engine to put it into a 512 wide bitmap. Just my guess.

Edit: after looking at the image again, it looks smaller than 256 wide, so I'm probably totally wrong.

#2 Russell,

Could you please send me the full-res image for reproducing this.

The packing routine is fairly intelligent as well as having a whole bunch of options for fine tuning it as explained in the documentation.

Jason mentions something very important which is the "filterPad" which adds a single-texel border around your frames resulting in an original 256x256 image being 257x257 therefore not fitting within a 256x256 texture but again, as Jason mentions, it doesn't appear that way from the image.

As explained in the doco, you can also get it to dump out a detailed log on what it did with the image-frames and this can help understand what decision it took and why.

Either way, send me the image and I'll see what I can find out.

- Melv.

#3 Sorry Melv... been slammed wrapping up the Adventure Kit. How do I get this image to you?

#4 You can send it to melv dot may at gmail.com

- Melv.

#5 Got your email Russell!

- Melv.

#6 I have a same problem with the square picture 1024x1024 (Cell mode, size 256x256), when all cels is full.
Result: using of the 2048x1024 texture page. With picture that isn't used all cells - all right.

#7 Russell,

So I just had a quick look at the image you sent me and looking at the respective image-map configuration, it's a "KEY" mode image?

The one you've sent me doesn't have any color-key framing as does the one at the top of this thread. Are you using the one I've got or the color-keyed one? Obviously the one I've got wouldn't work too well in "KEY" mode. If color-keyed, could you send me that one?

- Melv.

#8 Igor,

As per the image-map doco, have you tried turning on the image-map logging to see exactly what TGB is doing? It reports very detailed information in this regard.

Look at the "Image Maps.pdf" file (approx page 26) for "$prefs::T2D::imageMapShowPacking". Set this to true (in "games\common\preferences\" either "prefs.cs" or if not there, "defaultPrefs.cs").

When you run your game, it should output what it did into the console. If you can find the appropriate image-map definition and post it here, we can look at it to see if there's anything odd. If you also post your image-map configuration as well it would help.

BTW: Don't post the whole "console.log", just the specific image-map output.

Look for something like the following:

********* Packing ImageMap: 'otherObjectImageMap' *********
Frame Input: 0000 is 0064(w) x 0064(h)
Frame Output: 0000 is 0064(w) x 0064(h) - Relocated Src:(0000,0000) to Dst:(0000,0000) on Page 0000)
Texture Page: 0000 is 0064(w) x 0064(h) and contains 0001 frames
Fitted in 0001 texture(s) in 0007 iteration(s) occupying 4096 texel(s) with 0 unused texel(s).
Fit Percentage is therefore 100.00%
Percentage change from original is 100.00%
Total Time Taken: 0.015 sec(s)

... and the image-map ...

datablock t2dImageMapdatablock(otherObjectImageMap)
{
	imageName = "~/levelEditor/data/Images/ggLogo";
	imageMode = full;
	filterPad = false;
};

- Melv.

#9 Thanks for the quick answer!

I'm find the problem: it is 'filterPad' was true. Turning to false fix the problem.

Thanks!

#10 Melv, yes, it's keyed. I'm using SuperPNG to open them and retain the alpha'ed area. I'll send you the image as a .psd so you can see the keyed area and the alpha channel.

#11 @Igor: Glad it's working. :) For your info; TGB will automatically turn-off "filterPad" if your image-maps are in "FULL" mode because it's not needed.

@Russell: Thanks, I'll look at it as soon as I get it.

- Melv.

#12 Any chance of sending me the file Russell so that I can help out?

- Melv.

#13 @Melv - Maybe a little programmer to artist translation here is in order. You do realize that the PNG that Russell sent you *is* keyed? The red key value is in the RGB channel, but the alpha channel is knocking that out. TGB seems to find that ok on most images, but some it packs like crap... like the example he sent you.

#14 Melv... just sent you the .psd so you can have both the keyed areas and the alpha channel.

#15 Tom,

Okay, no probs; I presumed because I couldn't see it in Photoshop that it was just not there. I'll go and try it, sorry for the confusion. I'll blame the long days at work this time; I need to think up some better excuses!

Got a whole day off work tommorrow so it's come in at a good time; It'll be the first thing I look at in the morning.

- Melv.

#16 As long as it's fixed in 1.1.2 i'm a happy camper! ;)

#17 Tom,

Whilst you're "here", could I ask that you post me the changes you made for your adventure kit and exactly why they worked for you. I'd hate for them to not get in the next release or at least some change to address the issues you had.

I've already got the idea of having an equivalent of "castRay()" called "castLine()" but I want to ensure that I've got all the facts.

- Melv.

#18 Guys,

So I finally got to look at this problem this morning and I understand what is happening here. I'll first say what you can do to ensure that you get the packing results you expect; simply set...

preferPerf = "0";

... or uncheck the "Prefer Speed" option in the image-map editor.

So what's happening here is that the "performance" setting is just a nice way to describe what you can typically get when using this setting. The alternative isn't necessarily bad performance. So what TGB is doing when this setting is on is to try to ensure a few parameters are tweaked to an optimal setting such as...

- As many objects on as few texture-pages as possible
- Least discontinuity between width/height (best axis-balance)

When this setting is off, it simply tries to use the minimal amount of texture ram it can. Its optimal settings are...

- Least Wasted Texel Area
- Best Axis-Balance.


The "best axis-balance" is in there for a very good reason. Without this setting, the packing routine may actually achieve a slightly better packing but the "problem" is that you get extremely wide/tall textures and running at the maximum allowed texture-size in any direction has caused some issues on some cards. What you'd find is that this would be the case a majority of the time.

What is happening, at least with this set of frames, is that the best axis-balance is winning the battle over wasted-space (when in "performance mode").

These rules work well a majority of the time but in the end, as many objects on a single page and ignoring the least-wasted area, isn't necessarily going to give you best performance, hence the exposed flag.

I'm kinda' intreaged on how I can tweak the "performance" setting to also take into account the obvious case of wasted space here and I'm going to look at that later today when I get back from visiting relatives as this code was written over a very short period of time and I don't think it's ever been revisited.

There's definately a case of improvement here and I do appreciate the heads-up. One thing that we could do is report the wasted-space in the editor or even show the resultant texture-pages and respective information in the image-map builder.

In terms of a fix; if there's any way I can improve this (and I think there is) without possibly incuring other losses or creating other cases similar to this then I'll do an update and post back here.

Thanks again,

- Melv.

#19 Posted this as Issue#2001 in Mantis.

- Melv.

#20 Hey Melv,

will texture pages be shared between image maps some time? In another thread you mentioned that this wouldn't be so hard to implement. In some cases this could save a lot of texture memory (for example if you've got very small cell sizes, you might get whole image maps for free). From what I see in t2dImageMapDatablock::unloadTextures() the automatic resource management shouldn't need any modifications for that.

-Michael