MegaMek Discussion Board

Full Version: New Map Hex Images
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
-.- ............. Ok boss lets prioritize this for me.

1. Complete infantry unit sprites
2. Work on ASF unit sprites
3. Work on Warship unit sprites
4. Where is this COM-White.gif?
5. Work on Tigershark camos
6. Work on remaining skins (havent touched in a long time)
7. Will I ever play HQ/MM ever again?
*Reorder for what is most important Hammer

Are were talking about those camos that look like they have the impression of a stalker in them?  Yeah I think I know how to do that in Gimp but, dont want to step on Tigershark's toes.
(08-12-2016, 05:41 PM)BLOODWOLF link Wrote: [ -> ]-.- ............. Ok boss lets prioritize this for me.

1. Complete infantry unit sprites
2. Work on ASF unit sprites
3. Work on Warship unit sprites
4. Where is this COM-White.gif?
5. Work on Tigershark camos
6. Work on remaining skins (havent touched in a long time)
7. Will I ever play HQ/MM ever again?
*Reorder for what is most important Hammer

Are were talking about those camos that look like they have the impression of a stalker in them?  Yeah I think I know how to do that in Gimp but, dont want to step on Tigershark's toes.

And now you know why I never play...
(08-12-2016, 01:24 PM)SirMegaV link Wrote: [ -> ]Colonel, if you have time this weekend, can you post a 5x5 randomly placed hardware images?

No problem. I have actually thought about this and have a solution I intend to use to (mostly) solve this issue and another issue.  More on that in a bit, pics first.

[Image: HeavyIndustrialB_zpssx9ql7jc.jpg]

You're totally right about clusters of heavy industrial looking like a mess.  However, I think they look pretty decent if their orientation matches as in the below example:
[Image: HeavyIndustrialC_zpsznigmudp.jpg]

And, just because it's been mentioned, here's a screenshot of those in actual use:
[Image: HeavyIndustrialA_zps5ln9uv08.jpg]

The solution I intend to implement in this case is to use the fluff system.  Take the following hex definition:
heavy_industrial:1;fluff:X:Y

X will determine which of the 6 basic heavy industrial tiles to use and Y specifies rotation.



This system is something I very much want to integrate into my implementation of forests and their associated themes.  Currently I have 6 forest themes and 1 jungle for a total of 7 with more to come.  But suppose that you want to use a forest that doesn't match the theme?  Maybe you want to use those vibrant red and orange martian forests on a lunar tileset map or you want to use the jungle palms in the desert but want megamek to treat them as regular woods.

woods:1;fluff:X:Y

Where X specifies which tree set to use and Y optionally lets you set exactly which tree tile you want, instead of a random choice.


The "best" solution I see would be to get megamek to treat heavy industrial zones as it does buildings and set the exits.  The downside is that this would require a whole metric crapton of art (also some code changes to get it to work automatically).  64 tiles per variation that have to interlock seamlessly.  As in: (tanks, pipes, compressors) X (dense, sparse) X 64 = 384 unique tiles.  576 unique tiles if you want to do dense, moderate, and sparse.  I dunno if someone is willing to do all of that, but I'm not.  It would look better than the solution above, but I don't think that it would look so much better that it's worth all that work when there are bigger fish to fry ATM.


(08-12-2016, 01:24 PM)SirMegaV link Wrote: [ -> ]Btw I noticed that you are only using the 'bigger' hardwares.

Well, I felt that 48 varieties was enough.  I could have done the smaller ones as well for 72 varieties, but felt that would be a lot of work for not much gain.  To put it another way, I could make bigger gains by spending that time on something I had yet to work with at all, like jungles or smoke or fortifications.  As for why I chose the bigger industrial stuff over the smaller industrial stuff, that's simply because bigger is better Wink.
Thanks for the screen shot. Yup.. It's really a mess. But if all of them were facing north then it looked slightly better. 384 tiles for interconnecting heavy industrial.. Hm... I have bigger fish to catch too. Hahaha

I think it's back to Arlith initial suggestion, which I think Colonel already done. Are you going to implement it?

Back to the refinery, it's a good reference. I'll get to it... After I'm done with some others. Then the image can be added to the random pool. What I plan is, 1 custom x:x hexes heavy industry complex (since 1 hex is +/- 30 meters) with additional single hex accessories. But I won't be doing anytime soon.. Let me work on other stuffs first.
I thought that it was possible to specify some image adjustments in the tileset, like rotating and flipping.  If not, it would be pretty easy to add.  That could help with having different orientations without having tons of different copies of the same image.  Additionally, the tilesets do support image atlases now.  So, instead of having hundreds of small images, we could have several 2000x4000 (or whatever) sheets of tiled icons, and the tileset can handle loading from that sheet.  Probably some day we will add a packaging task that will compile these sheets when releases are made.
(08-13-2016, 08:28 AM)Arlith link Wrote: [ -> ]I thought that it was possible to specify some image adjustments in the tileset, like rotating and flipping.  If not, it would be pretty easy to add.  That could help with having different orientations without having tons of different copies of the same image. 

I don't think so. And yes i think it will not be difficult to add since MM is already doing that to unit images and the rotation can be coded into the map generator. What I'm worried is the editor. You might need to add another control for the editor for the rotation.

Quote:Additionally, the tilesets do support image atlases now.  So, instead of having hundreds of small images, we could have several 2000x4000 (or whatever) sheets of tiled icons, and the tileset can handle loading from that sheet.  Probably some day we will add a packaging task that will compile these sheets when releases are made.

Read something about this previously but I've forgotten. Is it working now? Can I add a bigger image, size maybe 4x4 hexes, anywhere in the map? What about those with weird shapes, like a building shaped like a cross?
(08-13-2016, 01:17 PM)SirMegaV link Wrote: [ -> ]Read something about this previously but I've forgotten. Is it working now? Can I add a bigger image, size maybe 4x4 hexes, anywhere in the map? What about those with weird shapes, like a building shaped like a cross?

There are two separate features, both of which should work.  One is being able to pick a tile out of an atlas (specify one or more individual tiles for a terrain type, pulled from the atlas).

The other is to specify a tile texture that is larger than the hex size (84x72 or whatever), and it automatically tiles that texture to the hexes.  Similar concepts, but they do different things.

You can also now set a board  background for a map, and use the "transparent" theme so that MM doesn't draw anything for a hex, and instead draws a tile from the background.
There is one feature I would love to have added: Colored overlays as part of a theme.

Currently, the only overlay is 'night.' It's a gray color sprite which darkens the pixels of the entire map + units. But what about other colors? For example, the "Snow" theme could have a tag for "Snow.png"; an image which has a set of semi-transparent white spots simulating snowfall. Or "Mars" could have an orange color which slightly tints the map. And so on.
I think there is a bunch of Feature requests here that should be summarized and add to the tracker, stuff gets forgotten and lost on the forums.
(08-13-2016, 01:43 PM)Arlith link Wrote: [ -> ]There are two separate features, both of which should work.  One is being able to pick a tile out of an atlas (specify one or more individual tiles for a terrain type, pulled from the atlas).

The other is to specify a tile texture that is larger than the hex size (84x72 or whatever), and it automatically tiles that texture to the hexes.  Similar concepts, but they do different things.

You can also now set a board  background for a map, and use the "transparent" theme so that MM doesn't draw anything for a hex, and instead draws a tile from the background.

I still don't have access to computer, so let me try to understand..

Method 1: Call it out like a fluff where the fluff image bigger than 1 hex.
Method 2: Call it out like base image where the base image bigger than 1 hex.
Method 3: Use a huge image as board image and use transperant theme over the wanted building area.

Correct?
(08-13-2016, 01:17 PM)SirMegaV link Wrote: [ -> ][quote author=Arlith link=topic=2338.msg16822#msg16822 date=1471091334]
I thought that it was possible to specify some image adjustments in the tileset, like rotating and flipping.  If not, it would be pretty easy to add.  That could help with having different orientations without having tons of different copies of the same image. 

I don't think so. And yes i think it will not be difficult to add since MM is already doing that to unit images and the rotation can be coded into the map generator. What I'm worried is the editor. You might need to add another control for the editor for the rotation. [/quote]

I have 3 reservations about using such a system in megamek.  These can all be addressed though.

First, it needs to be specifiable inside the tileset itself which tiles can be automatically flipped, mirrored, and rotated.  It's fine to do these things to the heavy industrial zones above, but it will absolutely not work with something that is intended to go in a specific direction.  Roads would make a fine example, and anything with a shadow or isometric design would be another.  It's also important to note that when working with images that fill the whole tile (like base tiles), flipping and mirroring will work completely fine, but rotating, in either multiples of 60 or 90, will not work well with automatic behaviors.  I suggest adding a variable to the tile definition with the options "None" "Flip" "Mirror" "Flip+Mirror" "Rotate30" "Rotate60" "Rotate90" "All".  For examples:

super * "fortified:1" "" "Foo/Fortified.png" "None"
base 0 "" "" "Foo/Level00.png" "Flip+Mirror"
super * "heavy_industrial:*" "" "Foo/AirconB01.png" "All"


The other reservations have to do with visual quality issues.  Megamek currently does not support partial transparency in its automatic rotation of units.  It also uses a fairly sub par interpolation method.  To illustrate, consider the following screenshots:

[Image: RotationCompareA_zpslngrbwdq.jpg]

And at double size:
[Image: RotationCompareB_zpswek5r6q8.jpg]

The P TRK MBT ETC is a png test file to make the problems very clear.  The Archer is included in the game.  The leftmost image is megamek drawing the image upright.  The middle image is megamek's built in rotation.  The right image was rotated in gimp using the sinc (lanczos3) interpolation method.

The lack of partial transparency destroys the visual quality of the grid, and has a severe effect on the antenna/lasers, toes, and hands of the archer.  Another place where it hurts, but is not shown here is anything with a long straight edge, like most tanks.  The poor quality interpolation leaves the middle archer looking sorta dingy and it loses some detail there.

I don't know how much work it would take to support partial transparency in this application, but it would improve the overall visual quality of the game.  Implementing better interpolation for rotations sounds like it might be pretty complicated, but gimp itself is gpl3 so most of the legwork is already done.


All of that being said, I would absolutely support an option in the editor to force flipping/mirroring/rotation of a graphic in the editor to allow for greater user customization of their maps.



Of course, these are just my own thoughts and recommendations and shouldn't be interpreted as demands.
Thanks for testing Colonel. I guess I will still convert my unit images to png format just in case the rotation get enhanced. Hammer, sorry, I'll be updating the images.. :p
(08-14-2016, 12:17 AM)SirMegaV link Wrote: [ -> ]Method 1: Call it out like a fluff where the fluff image bigger than 1 hex.
Method 2: Call it out like base image where the base image bigger than 1 hex.
Method 3: Use a huge image as board image and use transperant theme over the wanted building area.

I think there's a slight misunderstanding with Method 1.  The point with method 1 is basically to make the packaging/file management easier.  There can be issues having 100's or 1000's of small files, so instead of having 100 or 1000 small 84x72 images,  we could stick them into one or several very large images.  Then, that one image is loaded into memory, and the individual images are "cut-out."  Basically everything works the "normal" way, except you have each individual tile coming from one big atlas/map of hex art. (if you've ever looked at "skins" for 3D models, it works in the same way, there's some 2D texture that then gets mapped onto the 3D model.)

Otherwise, I think you understand the gist of Method 2 and 3.
(08-14-2016, 02:51 AM)ColonelSandersLite link Wrote: [ -> ]I have 3 reservations about using such a system in megamek...

Thanks for the comments.  I generally approach this with an eye towards coding, and not towards aesthetics, so your input is valued.

My thought was to have all of the rotation/flipping done only by tileset definition.  So, in your example, it seemed like you specifying flags that indicated whether MM was allowed to flip/rotate.  Instead, in my head, I was thinking something like:

Code:
base 0 "" "" "Foo/Level00.png:FlipX;Foo/Level00.png:FlipX;Foo/Level00.png:FlipX:Rotate30;Foo/Level00.png:FlipY"

So, this would allow the tileset author to explicitly use the same image, just in a transformed manner, but *only* at the authors specification.

As for the scaling, it's possible, and I believe easy, to change the scaling method.  The issues with the scaling method have never  been brought to my attention.  When performing scaling, Java has several built-in methods, and the possibility of implementing your own method.  We've just used Java standards (which are probably quite old).  I could check on what ever presets are available.

I'm not certain that I understand the partial transparency issue completely.  However, I bet this is an issue with how the camos are applied.  I'm pretty sure the unit icons should support transparency, but that information may get lost when the camo is composited onto the unit icon (that code is quite old).
You've got a bug in your code there Tongue.  Kidding aside, your version of that is more explicit, and mine is more streamlined.  Both have their advantage.

Yours can do something mine can't:
Code:
super * "road:1:11" "" "Foo/Roads/Paved/Road11.png"
super * "road:1:13" "" "Foo/Roads/Paved/Road11.png:flipY"
super * "road:1:25" "" "Foo/Roads/Paved/Road11.png:flipX:flipY"
super * "road:1:41" "" "Foo/Roads/Paved/Road11.png:flipX"

Certainly useful.



Mine provides a much more streamlined method of defining a tile with a lot of rotational variations.  For example:
Yours:
Code:
#Exploded for readability reasons!

super * "heavy_industrial:*" ""

"
    Foo/HeavyIndustrial/AirconB.png;
    Foo/HeavyIndustrial/AirconB.png:flipX;
    Foo/HeavyIndustrial/AirconB.png:flipY;
    Foo/HeavyIndustrial/AirconB.png:flipX:flipY;

    Foo/HeavyIndustrial/AirconB.png:rotate30;
    Foo/HeavyIndustrial/AirconB.png:flipX:rotate30;
    Foo/HeavyIndustrial/AirconB.png:flipY:rotate30;
    Foo/HeavyIndustrial/AirconB.png:flipX:flipY:rotate30;

    Foo/HeavyIndustrial/AirconB.png:rotate60;
    Foo/HeavyIndustrial/AirconB.png:flipX:rotate60;
    Foo/HeavyIndustrial/AirconB.png:flipY:rotate60;
    Foo/HeavyIndustrial/AirconB.png:flipX:flipY:rotate60;

    Foo/HeavyIndustrial/AirconB.png:rotate90;
    Foo/HeavyIndustrial/AirconB.png:flipX:rotate90;
    Foo/HeavyIndustrial/AirconB.png:flipY:rotate90;
    Foo/HeavyIndustrial/AirconB.png:flipX:flipY:rotate90;

    Foo/HeavyIndustrial/AirconB.png:rotate120;
    Foo/HeavyIndustrial/AirconB.png:flipX:rotate120;
    Foo/HeavyIndustrial/AirconB.png:flipY:rotate120;
    Foo/HeavyIndustrial/AirconB.png:flipX:flipY:rotate120;

    Foo/HeavyIndustrial/AirconB.png:rotate150;
    Foo/HeavyIndustrial/AirconB.png:flipX:rotate150;
    Foo/HeavyIndustrial/AirconB.png:flipY:rotate150;
    Foo/HeavyIndustrial/AirconB.png:flipX:flipY:rotate150;

    Foo/HeavyIndustrial/AirconB.png:rotate180;
    Foo/HeavyIndustrial/AirconB.png:flipX:rotate180;
    Foo/HeavyIndustrial/AirconB.png:flipY:rotate180;
    Foo/HeavyIndustrial/AirconB.png:flipX:flipY:rotate180;

    Foo/HeavyIndustrial/AirconB.png:rotate210;
    Foo/HeavyIndustrial/AirconB.png:flipX:rotate210;
    Foo/HeavyIndustrial/AirconB.png:flipY:rotate210;
    Foo/HeavyIndustrial/AirconB.png:flipX:flipY:rotate210;

    Foo/HeavyIndustrial/AirconB.png:rotate240;
    Foo/HeavyIndustrial/AirconB.png:flipX:rotate240;
    Foo/HeavyIndustrial/AirconB.png:flipY:rotate240;
    Foo/HeavyIndustrial/AirconB.png:flipX:flipY:rotate240;

    Foo/HeavyIndustrial/AirconB.png:rotate270;
    Foo/HeavyIndustrial/AirconB.png:flipX:rotate270;
    Foo/HeavyIndustrial/AirconB.png:flipY:rotate270;
    Foo/HeavyIndustrial/AirconB.png:flipX:flipY:rotate270;

    Foo/HeavyIndustrial/AirconB.png:rotate300;
    Foo/HeavyIndustrial/AirconB.png:flipX:rotate300;
    Foo/HeavyIndustrial/AirconB.png:flipY:rotate300;
    Foo/HeavyIndustrial/AirconB.png:flipX:flipY:rotate300;

    Foo/HeavyIndustrial/AirconB.png:rotate330;
    Foo/HeavyIndustrial/AirconB.png:flipX:rotate330;
    Foo/HeavyIndustrial/AirconB.png:flipY:rotate330;
    Foo/HeavyIndustrial/AirconB.png:flipX:flipY:rotate330
"

That's just for one tile.  If you're using multiple tiles for variety, the number of lines to define all variations is going to increase by a factor of the total number of tiles used.  For example, I'm using 6 of SirMegaV's industrial tiles for visual variety, making that code just 1/6th of the total actually needed.

Mine:
Code:
super * "heavy_industrial:*" "" "Foo/HeavyIndustrial/AirconB.png" "All"

In case it wasn't clear (it probably wasn't), in the examples in the previous post, the rotation number provided means to rotate to all multiples of that number.  To put it another way, "Rotate90" means to allow 0, 90, 180, and 270 degree rotations for all cardinal directions.  "Rotate60" would be every hex side.  "Rotate30" encompasses both.

I don't think that either one of those options is wrong.  Honestly, my ideal would be to support both.  The functions to actually do the work would be the same for both and under the hood, the parser could interpret the example of my version above to just be a more concise method of doing the same thing as the example of your version immediately above that.



As to the partial transparency issue, my guess has to do with the age of the code, which you've mentioned, combined with megamek using all gifs back then.  Since gifs don't support partial transparency, it would not have been a real issue back then.


My allergies are acting up pretty badly today, so if some part of that is gibberish, just let me know and I'll clarify.
(08-14-2016, 09:19 AM)Arlith link Wrote: [ -> ][quote author=SirMegaV link=topic=2338.msg16846#msg16846 date=1471148272]
Method 1: Call it out like a fluff where the fluff image bigger than 1 hex.
Method 2: Call it out like base image where the base image bigger than 1 hex.
Method 3: Use a huge image as board image and use transperant theme over the wanted building area.

I think there's a slight misunderstanding with Method 1.  The point with method 1 is basically to make the packaging/file management easier.  There can be issues having 100's or 1000's of small files, so instead of having 100 or 1000 small 84x72 images,  we could stick them into one or several very large images.  Then, that one image is loaded into memory, and the individual images are "cut-out."  Basically everything works the "normal" way, except you have each individual tile coming from one big atlas/map of hex art. (if you've ever looked at "skins" for 3D models, it works in the same way, there's some 2D texture that then gets mapped onto the 3D model.)

Otherwise, I think you understand the gist of Method 2 and 3.
[/quote]

Excellent. Understand 95%. Is method 1 implemented? If yes where can I find the sample? It will certainly make life a lot easier. Just need to see the sample codes especially when calling non square images.
(08-14-2016, 02:03 PM)SirMegaV link Wrote: [ -> ]Excellent. Understand 95%. Is method 1 implemented? If yes where can I find the sample? It will certainly make life a lot easier. Just need to see the sample codes especially when calling non square images.

Yes it's implemented, but I'm not sure if there is an example, unfortunately.
Akjosch added this in PR#155 https://github.com/MegaMek/megamek/pull/155

"In particular, declaring an image as "image.png(X,Y-W,H)" will load image.png, then return a rectangle of size (W,H) cut at pixel position (X,Y) from the image, enabling relatively easy tile maps and image atlases."

[Image: hwcUwXN.png]

So at the end of a line in your tileset where you declare to use ...../beige_plains.gif(X,Y-W,H)"

The X and Y will be the upper left corner of that megaman image missing his head (red).
W and H will be the height and width of the image that you will be telling MM to cut out and use starting from that upper left corner (yellow).

So, we can have all of our images on one big huge sheet now simplifying the file paths a lot in the tilesets and less folders in the hexes folder.
(08-14-2016, 02:28 PM)Arlith link Wrote: [ -> ]Yes it's implemented, but I'm not sure if there is an example, unfortunately.
Noooooooooo..... Feature lost in space.....

EDIT: Just saw what bloodwolf wrote. Will try to understand.
Was trying out method 1, using an atlas for the 'chatacter' fluffs (see below.. not sure if you can see or not since it's all back against transparent background).

So the tileset codes will be something like:

super * "fluff:1040401101" "" "SirMegaV-Hexes-Ground/FluffSystem-04-Alphanumeric-01-Character-1-00.png(0,0-84,72)"
super * "fluff:1040401102" "" "SirMegaV-Hexes-Ground/FluffSystem-04-Alphanumeric-01-Character-1-00.png(85,0-84,72)"
super * "fluff:1040401103" "" "SirMegaV-Hexes-Ground/FluffSystem-04-Alphanumeric-01-Character-1-00.png(170,0-84,72)"
super * "fluff:1040401104" "" "SirMegaV-Hexes-Ground/FluffSystem-04-Alphanumeric-01-Character-1-00.png(255,0-84,72)"
super * "fluff:1040401105" "" "SirMegaV-Hexes-Ground/FluffSystem-04-Alphanumeric-01-Character-1-00.png(340,0-84,72)"
super * "fluff:1040401106" "" "SirMegaV-Hexes-Ground/FluffSystem-04-Alphanumeric-01-Character-1-00.png(425,0-84,72)"
super * "fluff:1040401107" "" "SirMegaV-Hexes-Ground/FluffSystem-04-Alphanumeric-01-Character-1-00.png(510,0-84,72)"
super * "fluff:1040401108" "" "SirMegaV-Hexes-Ground/FluffSystem-04-Alphanumeric-01-Character-1-00.png(595,0-84,72)"
super * "fluff:1040401109" "" "SirMegaV-Hexes-Ground/FluffSystem-04-Alphanumeric-01-Character-1-00.png(680,0-84,72)"

OK.. found out that the atlas method might not be suitable for all situation. Assuming that i wanted to spell the word "CAT" onto the map using the map editor, first I'll have to open the FluffSystem-04-Alphanumeric-01-Character-1-00.png using a graphic editor to locate the top left most of each character's pixel coordinate. Then I'll have to search for the fluff code in the .tileset using the coordinate. Only then will I locate the fluff code and apply it on the map editor.

But if I use each character individually, I can just browse the character images using explorer, get the filename and search the .tileset for the proper fluff code to apply. I think this is easier to use. Plus the .tileset code will be easier to write too.. e.g. below.

super * "fluff:1040401101" "" "SirMegaV-Hexes-Ground/FluffSystem-04-Alphanumeric-01-Character-1-01.png"
super * "fluff:1040401102" "" "SirMegaV-Hexes-Ground/FluffSystem-04-Alphanumeric-01-Character-1-02.png"
super * "fluff:1040401103" "" "SirMegaV-Hexes-Ground/FluffSystem-04-Alphanumeric-01-Character-1-03.png"
super * "fluff:1040401104" "" "SirMegaV-Hexes-Ground/FluffSystem-04-Alphanumeric-01-Character-1-04.png"
super * "fluff:1040401105" "" "SirMegaV-Hexes-Ground/FluffSystem-04-Alphanumeric-01-Character-1-05.png"
super * "fluff:1040401106" "" "SirMegaV-Hexes-Ground/FluffSystem-04-Alphanumeric-01-Character-1-06.png"
super * "fluff:1040401107" "" "SirMegaV-Hexes-Ground/FluffSystem-04-Alphanumeric-01-Character-1-07.png"
super * "fluff:1040401108" "" "SirMegaV-Hexes-Ground/FluffSystem-04-Alphanumeric-01-Character-1-08.png"
super * "fluff:1040401109" "" "SirMegaV-Hexes-Ground/FluffSystem-04-Alphanumeric-01-Character-1-09.png"

Pro and con... unless I'm not using correctly...
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15