MTM2.com

<a href=http://www.geocities.com/TimesSquare/Corridor/9018/textures/tutorial.htm>All-in-one texture making tutorial</a> (beta)

Edit: To increase loading time I've replaced all the text and images in this message with a link to an outside webpage containing the very same content. No updates yet.

[This message has been edited by Winterkill (edited 25-10-2000).]

I hope what I've written will be helpful to track makers and will compliment the reference material that has already been produced by the likes of Phineus and Alpine and MIYH and Malibu350 and ObeOne and Guitar Bill and whoever else has produced info on creating terrain textures, I appreciate all of their valuable efforts.

I especially want to thank Guitar Bill for explaining and confirming how the overlap works (quite some time ago on the <a href=http://www.insidetheweb.com/mbs.cgi/mb277312>Traxx forum</a>). While I'm at it I want to thank him again for the freely available Traxx 1.2! And.. lets not forget the ever useful TXraw! And what the heck... thanks for that nifty pod screensaver too.

WOW!... Great post WK, but I just have to finish reading, understanding, and interpreting Stephen Hawking's "A Brief History Of Time" before getting around to absorbing all this info! ("my brain hurts" - Mr Gumby).


------------------
Keep on Monster Truckin'

EmceeMart

First impressions on the fly.

----------
The MTM2 Overlap

Your description of bringing the opposite edges together describes a "tiling" texture. And, your explanation, by and large, is correct. However, when opposite edges are brought together in this way, where do you find the extra 2x2 pixels for the corners? In addition, the same method would not be the case, for instance, for a composite that makes up a curve. In that scenerio, two adjacent textures would swap adjacent edges.

----------
Single seamless textures

Aha. The 2x2 pixel area I was in doubt about is artificially filled using part of the overlap created by moving opposite edges together. Perhaps I'm being picky here, but in some cases I can imagine this being visible...but not nearly so much as unprepared textures.

A note. In order to make a seamless texture, the base graphic must already tile well prior to the overlap. I have a link for this someplace. Oh, here it is . Gee, now I have to read this too.

----------
Source Images

lol, you anticipate me.

Nice set of links, thanks. Oops, here's another but I'll bet you have a problem with it ;-)

----------
Color depth & resizing

Additional notes on "Load track palette" can be found here
http://mtm2.com/~forum/pages/Forum12/HTML/000005.html

----------
Track Palettes

Hmmm.

>>if you are using Traxx 1.2 (and who isn't?? ;-))

Right now I have three different versions on my menu.

>> PALandACT.zip

We recognize the metalcr2.act/pal, but what's ~traxx12.act/pal ?

----------
Loading Palettes

Given that there is a lot of info to consider, your departmentalized/categorized chapters do the job. My anticipation of your next topic or your foreshadowing of what is to come (two sides of the same coin) follow one another. A person will have to read everything on the page before the big picture will come into focus. Anyone who tries to assemble it from fragments only will defintely run into trouble...and there's nothing for it. No short cuts to a good job.

----------
Palettes for Models and MTM1

>>re: mtm1. Does this mean textures with their own unique palettes will use those palettes?

No, not likely. They don't in mtm2, why would they in mtm1.

>>here's a(n) experiment : edit a .LVL file and replace the "metalcr2.act" line with another, to define a different global palette...Will it work?

My guess : there is an excellent chance that it will. After all, if you can change sky palettes in mtm2, then there should be no reason why a track palette couldn't be altered in mtm1 as well. However, mtm1 models and trucks would then look funky since their palette has now been switched too.

>>which may indicate the track palette limitation is not absolute.

Yes and no. As mentioned elsewhere, in the absence of an appropriately named act file, the game seems to revert to metalcr2.act (in the same way binedit uses metalcr2.act as it's default). But, as you point out, traxx will generate act files for textures missing one of their own. I have not verified cross-version palette creation using traxx. In 1.4, the palettes are created with the same texture base name. So in 1.2 ? In either case, this does not contradict the track palette/metalcr2 palette theories so far. "All" textures (terrain and model) in a track use the track palette, unless they lack their own palette in the pod. It is worth noting that all track palettes share a set of colors fundamental to each other. The traxx created palettes are later used for custom palette creation in 1.4 so the color alteration of textures using no palette is minimal.

My aplogies for getting off the freeware path. And, I welcome corrections if I'm off base with anything.

Lastly, there are a number of game determined palettes (in the lvl file) that work independently of the track. These can be modified apart from the track.

a thread worth keeping track of

----------
Getting colors right

Good. Been there, done that. It's a lot of work but saves frustrations later.

----------
Palette Conversion

Explain file associations. I have never gotten Green Giant's Para palette converter to work. And, objectivity please. I spent a lot of time on this and sure wouldn't want it ignored. But maybe I'm being biased myself. You'll notice that GGPPC is not included since it didn't work =(

----------
Slicing up textures

re: Green Giant's Axe

does the axe do the overlap or no?

>>MTM2 textures must be pre-processed in a photo-paint program before slicing, to add the two pixel borders necessary for seamless rendering in the game.

do tell, please.

Is it worth noting that 1.3 and beyond will do the overlap? Sort of.

But there are problems with overlapping composites too. See ObeOne's dilemma and especially MIYH's (alternate) solution to it.

----------
Templates

Very good. I have a track waiting to try out one of your sample templates.

>>Does this give you any ideas??

Actually, I shelved that long ago. Should get back to it tho.

----------
Creating seamless texture groups

Very good. This is the part we've been waiting for.

Oops, on first read, there seems to be an elipsis or two. I'll check again later.

Nice time line.

Um, why wouldn't you set the grid to 60x60 instead of 15x15?

----------
Utility Plea.

Yes, great idea.

----------

First read, excellent. Please don't mind my redundant commentary.


------------------
<FONT FACE="Arial" SIZE="3"><FONT COLOR="#2828E8">-</FONT><FONT COLOR="#3838E9"> </FONT><FONT COLOR="#4949EB">P</FONT><FONT COLOR="#5959ED">h</FONT><FONT COLOR="#6A6AEF">i</FONT><FONT COLOR="#7A7AF1">n</FONT><FONT COLOR="#8B8BF3">e</FONT><FONT COLOR="#9B9BF5">u</FONT><FONT COLOR="#ACACF7">s</FONT></FONT>


[This message has been edited by Phineus (edited 04-10-2000).]

Looks great Winterkill, I can appreciate how much work went into this.

MTM2 Overlap - A good description of a tough concept. I think it is a tough concept because I don't know of a real world analogy to compare it to. You can't say "it tiles just like..." what? It is something that has to be visualized. I finally understood it one day reading one of Guitar Bill's posts, there was loud *CLANK* in my head and I realized it was the sound of a paradigm shifting without a clutch. My question was always "If two adjacent texutures overlap, which one is on top?" to which I now understand the answer is "It doesn't matter because the part of the texture that is on top is identical to the part of the adjacent texture that is on the bottom." I have tried to come up with an illustration that would show this, can you think of a way? Your illustration does show the "pre-tiling" (great word) effect well on a single tile. Would the illustration be clearer if you used 4 different colored lines instead of just red?

Single Seamless Textures - This is perfect. If no one reads further than this, and could care less about the 'why', they can still easily make a seamless tiling texuture if they just follow these few steps. I remember you describing this in another post once and I really couldn't quite follow it, the illustrations make it very simple to understand though. I think you should stress in the very first step, that you start out with a 60x60 tiling texture, right now it reads like you can start with any size tiling texture and resize it to 60x60 and it will still tile, that's not necessarily true as I think you explain later on.

NOTE to Phin's comment about the 4 pixels (2x2) in the corners being artificially filled - I had the same thought at first glance, but as I 'tracked' the 4 pixels in the upper left of the 60x60 tile through the sequence of illustrations, lo and behold, they end up at the bottom right of the 64x64 tile Perfect! I would have never realized this would happen without this illustration. Good insight Winterkill!

Templates - This section is great! Explanation, tools, instructions, and tips all rolled into one. If anyone has read this far, go back and get those templates! they will save you soooo much time. Should the template size always be a multiple of 60x60? I think you imply that but you may want to be specific if you are always going to fill it the way I suspect.

Creating seamless texture groups - Good lead in paragraph, understanding this section does require the reader to 'get' the seamless texture concept. The first step is similar to the first step in the 'Single Seamless Textures' section in that it implies any size tiling image can be resized to 60x60. You are probably just combining steps and assuming the person following the directions knows 'resizing them to 60 by 60' includes any adjustments needed to maintain tiling.

Hehe, I like the time line, I shudder to think about mine LOL.

Thanks for doing the math for the 5x5 size for grid and border widths. Is there a more general formula for doing say 7x7 or 3x3?

"Now I mean perfect accuracy" Does PSP have a 'snap to grid' function that might help with this alignment? PS does, along with using the arrow keys to 'nudge' the selection over one pixel at a time.

Overall, great illustrations and an excellent technique. A lot of cutting and moving going on, you may want to mention a few 'save your work in progress' points before some of the big changes. The way I have been doing this manually does not work nearly as well, I have mostly relied on Traxx 1.4. I have understood the concept for quite awhile, but have never been able to develop a technique that is exact (i.e. perfect) and as quick as this. While this method may not be as fast as using Traxx 1.4, I think it gives you more control over the outcome.

Thank you for sharing this, I've learned a lot from reading it. Now I'm off to burn it to a CD, I can't bear the thought of this information ever being lost.


[This message has been edited by MIYH (edited 04-10-2000).]

EmceeMart, hehe, thanks, but I sure hope my book is far easier to understand. I'm really shooting for conveying these concepts as simply and effectively as possible.

Phineus, I very much appreciate your critical analysis.

Lest your initial impressions should give the wrong impression, I must state the overlap principal I've demonsrated is not flawed in any way as far as I can tell.

Note to Phin and MIYH, I do need to clarify how the corners are automagically filled, and I will.

corners: "but in some cases I can imagine this being visible..." -Phin

No worries mate, the corner overlap works in this system because corners can't properly overlap four ways in game anyway, in effect the corners are cut in game, and almost irrelevant. See this texture:

<img src=http://www.geocities.com/TimesSquare/Corridor/9018/textures/bwcorn.gif>

It's solid black with solid white blocks in the corners, filling the two pixel corner area. Put it in a track and you see only solid black. With the exception of software rendering, in which you see traces of white on the far horizon (if the corners weren't so contrasting you wouldn't notice anything).

re: ~traxx12.act/pal -- oops, confusing, that is a remnant of something I had switched back and forth on during the course of editing my document. Early on I was calling that palette the traxx12/farmroad palette and it was designed for traxx12 users. Fact is the traxx12 palette and the real farmroad palette differ by one subtle shade on one color, heh, thus there really is a unique 'traxx12' palette. I had planned to put a useful readme.txt in the zip as well.

"A person will have to read everything on the page before the big picture will come into focus. Anyone who tries to assemble it from fragments only will defintely run into trouble...and there's nothing for it. No short cuts to a good job." -Phin

Yessir, a good call. I had written a statement to that effect but deleted during the editing process, in essence saying read it all and read again to get it all. I must say I spent a lot of time recently editing all that I'd written, removing redundancy, adding clarity and working on a chronology that works, I'm glad you and MIYH appreciate the result.

Good point about fiddling with track palettes in mtm1, especially on the matter of trucks. But that has never stopped folks in mtm2. ;-)

"All" textures (terrain and model) in a track use the track palette, unless they lack their own palette in the pod. - Phin

As far as I can tell there is no 'unless', even without a palette they will use the track palette, even if traxx writes the pod giving them metalcr2 (and yes, missing palettes are created with the same texture base name in traxx12).

File associations: good point. Later. ;-)

>>Does this give you any ideas??
(hover you mouse over that pic ;-))


Creating seamless texture groups: I must admit that section could use more work.

Um, why wouldn't you set the grid to 60x60 instead of 15x15? -Phin

Shaddup and doit! hehe, kidding. It's much more convenient having smaller units when you are working at high magnification, and it works well for my step by step instructions. If you were at 60 then you'd have to add a lot more initial border space to rely on using the grid for alignment purposes, and you'd have to move your pieces much further.


MIYH, good idea on the illustrations, I will work on that.

"Single Seamless Textures - This is perfect. If no one reads further than this, and could care less about the 'why', they can still easily make a seamless tiling texture if they just follow these few steps." - MIYH

Wanting to illustrate this concept is what started this whole thing, and I hope this section will be used by many a 'common' track maker. Though purists often scoff, great tracks can be made using only square textures if the maker can arrange them nicely (no transitions other than straight lines between different textures). Pelltje is a good example, and I have two tracks which will be released using only square textures, one is my first - I spent so much time on it I refuse to trash my efforts. ;-) I'd prefer any new track with new square textures than one with stock textures yet again.

"I think you should stress in the very first step, that you start out with a 60x60 tiling texture, right now it reads like you can start with any size tiling texture and resize it to 60x60 and it will still tile, that's not necessarily true as I think you explain later on." - MIYH

Good idea, but I've found resizing seamless tiling textures seldom ruins their seamlessness, stress on the 'seldom'. ;-)

Anyway.... This whole thing is not complete, but I had to get it out here already! ;-) Upon reading it after posting it I noticed things I should add or change. One thing still needing work is cross-referencing within the document, anticipating, etc. I also didn't have time to polish up a final section, which contains links to all previous texture tutorials I'm aware of (and various pages at mtmg) and relevant postings. Which I might also reference within the body of the text.

I will be updating this soon and I will keep an update log here (so don't burn it yet MIYH!). Thanks much for the questions and feedback guys, I will be doing what I can to answer/integrate it all. I'll be back.

[This message has been edited by Winterkill (edited 04-10-2000).]

>>Does PSP have a 'snap to grid' or 'nudge' the selection

Not that I've found yet. I really should start using photoshop or photopaint more often.


>> I must state the overlap principal I've demonsrated is not flawed in any way as far as I can tell

I wasn't suggesting anything to the contrary. Just raising a question that came to mind. Furthermore, if MIYH says the math is correct, then you can bet your last buck that it is. I don't need anything better than that.....but please do elaborate.


>>Drag and drop on GGPPC.

Well, what do you know....


>>re: ~traxx12.act/pal -- oops,

All this track palette talk led me to try out a few things. I made a texture set using your template (so far so good) but was concerned about the colors. I settled on the heights palette, and pasted into Traxx (more in sec). The textures looked terrible after the paste job, but I loaded up the palette and voila, just like psp.


>>Traxx 1.4 pasting

Recall ObeOne's dilemma .

I made a 300x300 composite based on your template. Then treated the whole as one single texture. I added the border, clipped the bottom to the top and vise versa, repeated for sides, and now I had 304x304. Paste into Traxx, laid them out in a track, and alignment was good. The only reason I mention this is that it reduced the amount of "pre-processing" that needed to be done.

Preliminary conclusion. Traxx slices the middle overlapping fine but does not take care of the outer edges. It would be good if somebody could confirm this. Or maybe I should go grab Obe's image and try.


>>Creating tiling textures

I used ObeOne's new tutorial (had to test out that one too) as a starting point, and found that I could create tiling textures just fine, then use the info here to create the template. Overall, a good complementary article. Note. I used psp not photoshop, so I had to interpret some of his instructions before I could use them.

>>(hover you mouse over that pic ;-))

Actually, I had checked the file name. Never noticed the mouseover. Yoore too funny.

>>Shaddup and doit!

Ok, sorry boss.

>>Anyway.... This whole thing is not complete...

Suggestion, if you kept the code, repost the update to a new thread. It's long and it might add to clarity. This can stay or be deleted at your preference/convenience.

..which brings up the idea of an FAQ for the bbs or archiving the more valuable posts or converting to web pages. I wouldn't mind hearing thoughts on this too.

Lotsa good stuff here Phineus.

About Para and file associations, have a look at part two <a href=http://www.geocities.com/TimesSquare/Corridor/9018/utilities/para.htm>here</a>.

"...FAQ for the bbs or archiving the more valuable posts or converting to web pages..."

I've thought about this but haven't got any solid recommendations. I think the valuable posts should be archived but also kept alive at the same time. I really like these 'alive' topics, which do in fact exist as static webpages, as long as the server and database survive. As long as certain forums don't get flooded I think the categories themselves serve well enough as a FAQ of sorts, being not too impractical to wade through. I know some things I've posted were planned to be static web pages at some point, like this one, but serve well enough here for now.

Looks great. Well done. I've used those methods to associate file types before without a problem. Don't know what went wrong with para, but everything looks to be in working order on your page, which I've saved to hdd, and which could use a post or link from utilities.

Which reminds me, I think my utility section needs updating.....

--------------


update on obe's dilemma

Working with his first texture, ccbase, it was found to be a poor tiling texture to begin with thus rendering all tiling attempts problematical.

Working with the second texture, ccbase2, it was suspected that that did not tile well either. However,

* using the straight resize and paste into traxx method resulted in clearly visible outer seams.

* using the method described on that page by MIYH, satisfactory results were obtained.

* using a method adapted from wk's description above (i.e., pre-processing the outer edges and pasting into traxx), again satisfactory results were obtained.

I think it is safe to conclude that traxx does not process the outside edges of a composite graphic for the two pixel overlap.

------------------
<FONT FACE="Arial" SIZE="3"><FONT COLOR="#2828E8">-</FONT><FONT COLOR="#3838E9"> </FONT><FONT COLOR="#4949EB">P</FONT><FONT COLOR="#5959ED">h</FONT><FONT COLOR="#6A6AEF">i</FONT><FONT COLOR="#7A7AF1">n</FONT><FONT COLOR="#8B8BF3">e</FONT><FONT COLOR="#9B9BF5">u</FONT><FONT COLOR="#ACACF7">s</FONT></FONT>


[This message has been edited by Phineus (edited 05-10-2000).]

I've spent the last few days working my way through WK's excellent tutorial and have been over the moon with the results! I should have a complete texture set ready to post in the next few days, along with some notes touching on a few comments alrady made.. meanwhile back to work.

------------------
Keep on Monster Truckin'

EmceeMart

yes i found the tutorial very useful....

Unfortunately i haven't been able to do any of the stuff here yet because i've been busy getting the hmtm2ubb up and running and HMTM2 back up online....

Thanks for that link wk - guess i have to update my utilities section again???? 130 utilities - this is getting outta hand lol

Just Wonderin: What does everyone think of my MTMG like message board?
Its at my web page
or http://hmtm2.netfirms.com/cgi-bin/Ultimate.cgi
if anyone wants a free forum you can just email me



------------------
<IMG SRC="http://hac-man.tripod.com/mysig.gif" border=0>

Very good job indeed WK, I could not have said it better mysels.

Just a small adition from my part, something I do to make seamless textures (besides traxx 1.4...;-))

I also make 60x60 tiles, when opened in Photoshop I select all pixels and copy the selection to the clipboard. After that I resize the image into 64x64 and paste the 60x60 clipboard into the 64x64 bitmap, thus preventing the corners......

This way it's just 3 handlings..... ;-)))

Hope this helped (a bit)

[This message has been edited by OOPS (edited 27-10-2000).]