The Trouble With Texture Terrains

Terraformer_Author · May 2014

Ok - so - the story thus far...

"Our hero - in an attempt to perfect the art of creating texture climates for Fractal Terrains 3 - has come yet two steps closer - and one step back - to actually accomplishing something. As you "might" recall from a couple of previous discussions - with the generous input of Joe Slayton's tidbits of useful guidance - I have developed a set of rather flacid, yet informative test textures using a rehearsed procedure in the GIMP - pictured below with the resulting output...

Terraformer_Author · May 2014

Ok - somewhat charming yet painfully off the target. Well - I then decided to get bold - and I developed a series of composite textures in an app called "IMAGE INC." by Cybia (I highly recommend it - it's free) using my original GIMP made texture climate swatches as overlay and base fodder. ANYWHO...I used a difference cloud render (600 x 600) as a trans map (alpha map) to see how the difference map would disperse tonal changes in the base image and overlay images. Mind you the map that was outputted was NOT pretty - but it wasn't meant to be a map that I was going to develop - I just wanted to see the effect of using a difference cloud to "stain" the textures realistically - below is the result along with a control map with normal default texture climates...

Terraformer_Author · May 2014

I know - I know - The Cold Areas look like crapola, I am aware of this - wasn't trying for master mapper here - just wanted to see what was going on...

Well - what conclusions can I draw from this - firstly - much more subtle color differences on the layers of course are needed - but I think that aside from maybe tightening up the cloud patterns on the trans map, using the difference cloud approach have yielded interesting results for incidental terrain colorations - but it's still a log way from being where I would like it to be (below shows what I did in IMAGE INC to get these). I'll have to teach myself how to do this in the GIMP instead of IMAGE INC so that I can write a tutorial AFTER I have refined this to where it looks halfway passable - and if somebody wants to try this in Photoshop, then let me know the steps that you are taking insomuch as layering, masking, ect., So that when I start writing the T1 manual I can stick it in there for photoshop users also (I'm strictly a GIMP guy myself). If get outstanding results because you are naturally smarter than me - and you write up a tut - then whisper me and I'll provide an addy, or let me know where to snag and bag it. Suggestions - ideas - pointers - advise - and religious guidance is always welcome on this effort - INPUT PLEASE?...

I'm thinking along the lines of refining the transmap map. I tried applieing a fog effect but that doesn't have a tileable option in the GIMP. I'll also have to see if I can distribute the scripts for the Photo Effects in GIMP for GIMP users if the license will allow for distribution - if not - a link will have to do (which troubles me because there's no such thing as a truly permanent website, lol.). I have to develop a method that I can follow in a step by step way that will allow me to crank out Texture Climates by the oodles - yet have amazing results (I won't settle for less that amazing, lol).

I can pretty much tell that bringing these textures up to a dynamic standard with require LOTS of layering - time to hit the GIMP tutorials on layering (I never really had much call to layer anything before - this is a good opportunity to getts meez an edumacashun, lol.)

jslayton · May 2014

I have this sneaking suspicion that you'll find that the scale of the features needed in a texture set will vary with the desired scale. If you're using features that are 20 pixels across in the texture, then they will be 20 pixels across in the final map. If, for example, you use a whole-world 1000 pixel wide map on a 40000km circumference world, then the 20 pixel feature on the texture input will be about 40000/1000*20=800km on the world image. That's a HUGE feature. It looks like the tool that you're using in the bottom image uses a mask to blend the two images. I would recommend using an input mask with more octaves of noise (or just pump up the contrast) to avoid that smooth appearance in the blending.

My goal in providing the texture climate tool was to provide for what amounts to symbol fills with a reasonable amount of control for the end user. The symbols can be abstract blocks of pattern, meaningful symbols, solid colors (although solid blocks gives just the same effect as the basic climate shader), or anything else; one climate color maps to a repeating block of pixels. At one point I had considered an indirect method that used a system much like the image climate shader to determine the input to select the texture to use. This system would be a major problem to control, however, because there would be two largely disconnected things for users to manipulate (one image indexed by rainfall and temperature that provides colors to use to index a set of images). I had considered a whole suite of things to try, but they were largely difficult to control and didn't give results too much better than the basic climate:texture mapping.

Terraformer_Author · May 2014

Good Points all. I suspected that the smaller the texture swatch - the longer the stretch...I'm outputting a basic HD rez of 4096 per map (Global Map). If the features on the textures change proportionally with the resolution of the overall map - then one would assume that only solid colors would yield universal consistancy of appearance irregardless of scale. I guess - for what I like as an individual user - the traditional Image Climate shader is what I would be inclined to stick with, but I would still like to crack this nut for other users though.

The two major sticky points - trouble spots with what I am trying to accomplish here is resolution and aspect ratio.

Terraformer_Author · May 2014

In 3d modelling - in order to put a texture on a 3D model made up of polygons and vertices - you would normally create a UV texture map to "wrap" onto the model - and then you could use the texture map template to "paint" to create the model's textures. That way the textures stay consistant in dimensional position point for point - no matter how you might scale the model - or even deform it (example below) - it's a shame that there couldn't be a way to do that in Fractal Terrains for surfaces that would allow for more textural / coloration variety, yet maintain proper resolution and aspect ratio (these aren't my images - but they are ok to use for analytical / diagramatic purposes - i.e. "fair use".).:

JimP · May 2014

Yeah, the 3D body mapping like DAZ uses... I looked at that and, got a headache. But it would be great if we could do similar with Fractal Terrains.

Terraformer_Author · May 2014

Well - in a way the image climate shader (not the "Texure Climate Shader") is like that - it pins a "point for point" match on the map surface to the Image climate. I don't think that you could call the new "Texture Climate" shader a replacement of the Image Climate function - because I don't think that that would work. Like Joe said - it's another way of topographically labeling zones - but not a way of assigning effectively realistic coloration.

JimP · May 2014

Okay. Mostly I'm trying to puzzle things out.

jslayton · May 2014

The image climate shader uses the same notion of a table with average temperature along one axis and average rainfall along the other. The default climate shader and texture climate shaders have a table with about 17 potential output values (the default shader colors each climate type with a solid color, while the texture climate uses a repeating image pattern for the same task). In contrast, the image climate shader provides as many potential output values as there are pixels in the image; a 1000x1000 image provides potentially a million different "climate" types.

Terraformer_Author · May 2014

Posted By: jslaytonThe image climate shader uses the same notion of a table with average temperature along one axis and average rainfall along the other. The default climate shader and texture climate shaders have a table with about 17 potential output values (the default shader colors each climate type with a solid color, while the texture climate uses a repeating image pattern for the same task). In contrast, the image climate shader provides as many potential output values as there are pixels in the image; a 1000x1000 image provides potentially a million different "climate" types.

I knew that both depended upon the climate zone premise - true - but I had always assumed that the Image Climate function was more flexible / consistent in that it more directly related climate zone (X,Y) points of value reference to (x,y) image color coordinates on the image file - i.e. - The translation from image pixel to climate coordinate was somehow a much more direct, straight forward process with minimal fudging of results. I assumed that with an increase in pixilation (scale) of edit - FT Pro / FT3 somehow compensated for that, in that it - via some mechanism of redistribution by scale re-adjustment - would still give "somewhat" accurate image to climate zone assignments (with perhaps larger transitional areas). I noted how similar the process of image to climate zone "resembled" typical UV mapping by material group (i.e.. "climate zones").

Still - as long as FT Pro / FT3 computes color to climate to where the accuracy of translation is still sufficiently in the right ballpark - I still "personally" prefer using it - as it does seem to give more believable results with the right Image Climate file. I am still going to keep hitting on creating "Texture Climate" packages though - because others will find more use for it - and it DOES hold a LOT of promise as an informational / topical tool.

Besides - if your World settings (Primary, Secondary, and Temperature) and lighting adjustments (Intensiy) are such that your rainfall and temperature settings are telling groupings of pixels what their temperatures and rainfall distributions ought be - based upon an areal mean distribution of (x(sub n) , y (sub n)) values - defined or suggested by these outside operations / parameters - then wouldn't the climate zones stay more or less (roughly) consistent anyway irregardless of editing resolution?

jslayton · May 2014

Posted By: Terraformer_AuthorBesides - if your World settings (Primary, Secondary, and Temperature) and lighting adjustments (Intensiy) are such that your rainfall and temperature distributions are telling groupings of pixels what their temperatures and rainfall distributions ought be - based upon an areal mean distribution of (x(sub n) , y (sub n)) values - defined or suggested by these outside operations / parameters - then wouldn't the climate zones stay more or less (roughly) consistent anyway irregardless of editing resolution?

I'm not sure what you mean here. The Image Climate shader has no notion of climate zones in the sense of the regular climate shader and the texture climate shader: it is purely a color lookup based on rainfall and intensity. If the Image Climate shader input is in fact the default climate color map, then I suppose it's possible to say that the colors would be "climate zones". The basic climate types that map rainfall and temperature will show their names in the View Properties window regardless of the shader being used or how many apparent color gradations are shown.

Note also that there are climate types in FT (e.g. Hills and Mountain) that cannot be generated from a rainfall/temperature table. These climate types allow for additional flexibility with regards to use of the texture climate shader.

Terraformer_Author · May 2014

Oh - ok - NOW I get it, lol. Ok - I was speaking strictly in terms of FT3 referencing temperature, rainfall, Albedo, light, greenhouse, axial tilt, location of poles (In Earth's case - the North pole is at Lat. 90 degrees, Long. 0 - mean global rainfall is 39 inches per annum - axial tilt is 23.4 degrees - average surface temp is 15 degrees Celsius)., etc. - And how these variables basically define where the climate zones are - and where the colors on the image climate file - cross referenced with it's climate template - should go on the map.

I edited / corrected my last remark to say "settings" instead of repeating the word "distributions" (my foul up, lol).

You were saying that changes in map resolution = different resulting interpretations of the Image Climate shader by FT Pro / FT3 - / different results on the map - correct?

jslayton · May 2014

Changes in the Image Climate shader input image will affect the number of apparent climate zones, yes. Each pixel on the input image is effectively its own climate zone for coloring purposes with that shader.

The variables that feed into the temperature equation (incident light, greenhouse effect and so on) determine the base temperature for the planet. The axial tilt determines the temperature distribution. The temperature and land/ocean position determines the rainfall. Both temperature and rainfall have a random component and a user-paintable component as well.

As an amusing aside, the north pole isn't at lat 90, lon 0 (nor is the south pole at lat 90, lon 0). The poles are at lat +/-90, lon [all of them] because all of the longitude lines converge at the poles. As an illustration, if you put a house with a window on every wall at the north pole, every window will face south, even though the walls are facing different directions.

Terraformer_Author · May 2014

Posted By: jslaytonChanges in the Image Climate shader input image will affect the number of apparent climate zones, yes. Each pixel on the input image is effectively its own climate zone for coloring purposes with that shader.

The variables that feed into the temperature equation (incident light, greenhouse effect and so on) determine the base temperature for the planet. The axial tilt determines the temperature distribution. The temperature and land/ocean position determines the rainfall. Both temperature and rainfall have a random component and a user-paintable component as well.

As an amusing aside, the north pole isn't at lat 90, lon 0 (nor is the south pole at lat 90, lon 0). The poles are at lat +/-90, lon [all of them] because all of the longitude lines converge at the poles. As an illustration, if you put a house with a window on every wall at the north pole, every window will face south, even though the walls are facing different directions.

I was thinking about doing something on Grids in the T1.0 Manual - I did look the north pole co-ords up on BING because I wanted to be sure and I kept getting "90 deg LAT, 0 deg LONG, but yeah - your correct from that perspective.

I was thinking that I would expand the image climates - and also do some Texture Image packs. Bottom Line - I just need to get them to where they don't look like poo doo, lol. I might study the Texture Climate images that you've done Joe to figure out the approach that you took to cropping these and maybe blurring them because somehow you made it work and I've been racking my brain on trying to basically do the same thing - if you have a procedure specifically, I'd like to know. I also need to study FT3's grid function in depth a little more to get the jist of how to lay those out properly.

Another thing is that I'd like to add some notes in there (The Manual) on how NOT to get square craters when doing "Planetary Bombardment". If you've got some thoughts on that - then that would be great.

I wish that you could plug in .lgt sets for Temperature, Rainfall, and Climate Zone Coloring palettes like you can for Altitudes. I've found quite a few interesting examples on the net and I was thinking about doing an NOAA palette for Rainfall. I know that you can save and load palettes for those - I just need some clarifications on what areas of those files I can edit the RGB values on / need some pointers on how to edit the temperature and rainfall palette files (.lgt)? I can do new Altitude files in my sleep - but I need to look at the text versions of outputted / saved Temp and Rainfall files to know which areas of those I can plug new sets of RGB values into.

ProFantasy Community Forum

The Trouble With Texture Terrains

Comments