Is there a way to have a GUITexture use only part of its texture map, either by assigning it texture coordinates or a rectangular boundary within the map?
I want to allow multiple GUITextures to use different portions of the same texture map, but my attempts have only resulted in the entire map being shown by the camera. I don’t think that pixel inset or border properties can help here.
The alternative as I see it is to use geometry in my menu screens rather than GUITextures, since they can have UVs.
This is an awful hack that you may ignore when someone posts a better answer
Could you overlay multiple cameras, as small insets in the corners, for different parts of the GUI? and then display the GUI texture large enough that only the desired portion fits in each camera?
It’s extremely helpful to be able to cut power-of-2 images up into multiple images–especially for GUI items.
See the picture below. Often GUI items are not ideally suited to being a power of 2 (128 x 256, etc), but a quick workaround in other engines is to simply specify which portion of a bitmap to use.
Referencing the attached image, you’d use the Cyan section of the image for one GUI texture and tell a second GUI texture to use the red portion–and so on. You specify which portion to use for each GUI element by specifying the starting x,y pixel and then the size of the sub-image.
For instance, the Cyan area would use a starting pixel value of 0,0 and an image size of 178x208. This method is similar to what Joachim demonstrates for Animating Textures with UVs, but we just need a method of applying it to GUI textures. Does this functionality exist somewhere in Unity yet?
One workaround is to use geometry and mess with the UVs. The second workaround is to just squish your bitmaps into an even power-of-two image, but then you’re working in one resolution for design, then you have to convert it to a different size every time you want to test it out. Neither option really matches Unity’s typical elegance. I suppose a final option would be to simply force all your GUI elements into power-of-2 dimensions, which is a pretty silly restriction.
I guess it’s partially a work-flow issue. We’ve found it very efficient to put all our GUI images into a single 1024 x 1024 bitmap and then just cut out the portion we need for each GUI element.
OK. One workaround I’ve found so far is that you can use use at least 4 corners of an image as separate GUI textures by manipulating “Pixel Inset” and “Borders”.
For instance, if you wanted to use a 200 x 100 pixel portion of your main image in the bottom right corner of a 256x256 bitmap you’d set it like this:
Pixel Inset
Xmin -100
Ymin -50
XMax 100
Ymax 50
(that defines the size of the map as 200 x 100)
Left Border 0
Right Border 200
Top Border 0
Bottom Border 100
(That tells it to onl use the bottom right 200 x 100 pixels)
However, if we have that kind of functionality, it can’t be too hard to open up access in a script that would let us scoot that defined display area to somewhere other than one of the four corners currently allowed by the “Border” options.
This will really be a huge feature for implementing our shell if anyone can help us figure out how to access those pixels. Otherwise we have to chop up all our buttons and frames into individual bitmaps.
Are other people really using different bitmaps for each state of each button? It seems like we must be missing something.
Sidenote: On the ^2 issue, I’ve been oversizing my GUI textures with transparent edges. It wastes a bit of texture space, but it does the trick for me.
Yep, that’s also what i do when i want pixel exact results:
If 487x467 for instance just take a transparent 512x512 texture and place it properly and if the texturesize is getting too large then just break it up into smaller chunks. This is standard work in Director when porting stuff from win to mac as sw3d on Mac can only handle up to 512x512 texture sizes… :O/
Yes, but that’s just so wasteful, and it shouldn’t be hard at all to be able to use all that wasted space. Furthermore, it dramatically increases workflow to be able to throw all your buttons into a single bitmap. Your design and adjustment time is drastically decreased when you’re working with 1 bitmap rather than 75 (for our buttons alone).
The other thing that would be nice is multi-layer PSD files allowing you to turn the layers on and off from within Unity - like how you can to construct menus in DVD Studio Pro.
Although frankly I must say that I am just happy to have native PSD support at all!
@bigbrainz
There are for sure situations where you’re interested in using optimal ressources but there are also situations where it’s a nobrainer wasting a little bit of memory for a transparent area. And it’s done quickly…
But i agree the best method for efficient work is yours.
I’m sure part of the problem is that we have this feature in our other engine so we’re very used to that workflow, and all our assets already exist in that format. Otherwise, we’d probably just design the whole interface to fit better into ^2 format. But having been liberated once, it’s hard to go back I guess .
OK. So another power-of-2 workaround idea to improve the workflow on images that don’t lend themselves to a ^2 size. Perhaps Unity could give us a checkbox that would tell Unity to automatically resize images to a ^2 size when it pulls it into the engine, but leaves the original file intact.
For instance, then we could work on our 640x480 splash screen in the proper perspective, and then Unity would handle squishing it to 512x512 on its own then scale it back to 640x480 when it’s time to display it without us having to mess up our workflow.
.