Fractal Terrains 3 Upgrade just dropped...

[guyanonymous]

I'd agree that the $10 isn't a big hardship, and I'm pleased for better looking rivers, for sure. The additional climate maps etc. are also welcome. I also like the new streamlined interface.

___

I've attached a psd file showing the multi-image allignment issues I've noticed. EDIT: I couldn't attach because of file size, so I've uploaded a zip file to mediafire. It contains the .ftw, the .psd multi-layer crop which uses two .bmp exports, and four full-sized .bmp export files (6000x6000) which fit together in a square and show what I call the 'dark line' (inverse tones?) issue, and 'river-gap' issue which. Here's the link: http://www.mediafire.com/file/dbot44...20right%29.zip

For the PSD: As each image is 6000x6000 pixels, I've just taken a slice of two of them on the sides they meet. The bottom layer is on the left and includes the dark line (that's part of the saved .bmp file). The top layer is on the right. There is no space between the images.

Re: Rivers: If you scroll down, you'll find several examples of rivers that cross the border, and notice there's a 1-2 pixel game on each side of the border (the land is there). I've circled several in red to make this easy The 'river-gap' problem occurs at the top/bottom of images as well.

Re: 'Dark Line' issue: You'll also notice on the right edge of the left image (bottom layer) and on both images at the bottom most edge, there is a one-pixel line that appears to have an inverse light-dark value; the colours are correct, but what's light is dark and vice versa.

In the past, I've just moved the right image over to the left one extra pixel, to overlap the 'dark line' artifact of the left image, it tends to look better (still with river gaps), but not perfect. There is enough of a pattern that becomes apparent as you scroll up and down, as there appears to be one missing pixel. I've not tried inversing the height map for that single pixel yet to see if that's what it actually represents. I believe the bottom right pixel on every image, though, is normal, because the right line and bottom line overlap there, producing a double inverse, or normal pixel.

I saved these, originally, in bmp to avoid compression artifacts.

I'll also upload the original .ftw file I'm using. I output at 6x3, with a resolution of 5000. This, in theory, will let me make a 30000x15000px image, though it's always a couple pixels off because of the 'dark line' artifact. I think it's appearing on the right and bottom of each saved image.

Thanks for taking a look at all this...if this was fixed, it would save me a LOT of time when I merge the multi-files back together, and actually let me automate the process.

p.s., with respect to your comment about 32/64 bit saves not working in the opposite version, it's likely that anyone using a 64 bit version would only use that, and vice versa (unless you end up with a plug-in situation like photoshop with some plugins only working in 32bit and others only in 64).

p.p.s., Is it possible to feather the tools in this release? Or use a different brush (other than a circle/oval of your dimensions)? If not (and I don't think it is), please consider those features for the future if they can be worked in.

[waldronate]

The dark edge at bottom and right has been there since day one (the first bug report is from 2000). It's not to say that it's correct behavior, but it's unlikely to go away any time soon.

The gaps in the river is a buglet caused by the river hitting the edge of the map. It's supposed to be clipped at the edge, but it seems that FT is just dropping the last segment. Grids have the same issue, but in that case it can be eliminated by turning off adaptive grid resolution and bumping up the number of segments. These issues are easy enough to correct onscreen in FT, but those tricks don't work on export to CCx.

If you're using the multiple file export feature, have you tried using a bit of overlap between images (say 10% or so)? That way the rivers at the edge won't have a problem with missing their last segment and the black line can be eliminated fairly simply. Not ideal, I understand.

I would rather just export a huge single image, but the problem is that FT would have to compute a strip of the image, draw the raster overlays, draw the vector overlays, and then write out that strip. The clipping issue can cause problems with this operation, unfortunately.

A suggestion was made to have a different file format for the 64-bit and 32-bit versions that would incompatible with each other, but I am of the opinion that there should at least be an upgrade path from 32-bit to 64-bit. Making that work would result in a file format that was compatible between the two versions with the possible exception of data sizes.

The tools should already be feathered. The circular painting tools should start at 0 at their edge and rise to the user-specified value at the center. For the more advanced users who want to try something different, FT offers the brush preset file. If you save a brush preset file and then open that file in Notepad, you may find that it's a simple text field that contains a number of interesting values. If you've ever used the Edit Paintbrush Settings dialog in Wilbur and saves a preset, then this set of features will look familiar (FT and Wilbur share a brush engine). The part that might be of most interest to you is the "FileName" field that lets you specify an image file to use as a brush. I recommend setting up a brush you like in Wilbur and saving the brush preset into the FT folder. Then you should be able to use that brush in Wilbur. I forgot to port over the UI for the brush parts into FT, but the engine is there and it works the same (I think brushes are upside-down in FT realtive to Wilbur, but that's a minor thing).

[guyanonymous]

Thanks for considering things.

I'd thought about the overlap, but then I've still got to manually move the images exacting number of pixels rather than just align them beside each other. Is it possible to change this from a % to an absolute value (e.g., 5 pixels)?

Is the dark edge (bottom & right) actually a valid row of the exported image tile? Or is it an extra row of pixels that can safely be deleted? The visual pattern (an obvious line) that appears when I just delete those single rows, suggests to me that it was supposed to be a 'real' line.

I agree 100% about exporting a huge single image being the ideal.

I'm glad to hear some feathering is already there. I'll check out the brush preset file, though I've never used it in Wilbur. When using an image as a brush, does it have to be b/w, or can it be grey scale and have transparency? I'm envisioning painting on a pattern of mountains ripped from reality.

[waldronate]

The dark edge is an artifact of a lack of data at the edges of the map (there's nothing to the right of the map to compute a normal from and the computation seems to get the wrong sign in those places). It may also be caused by a curved projection hitting the edge of the map data and coming into uninitialized data. The altitude data should be valid data, but the intensity computation for the shading is wrong.

The brush image can be any file. It will be interpreted as a grayscale raster ranging from 0 (0 intensity) to the specified altitude value (255 intensity). Real images of mountains and craters are usable as stamps. I don't recommend dragging the brushes, though. I don't recall if it properly handles transparency/alpha channels or if it's just a straight intensity computation, though.

I tried a 64-bit build, but Visual Studio was not being cooperative. I'll probably have to completely rebuild the project from scratch with VS2010 in order to get it to work. That sort of thing is somewhat low on the priority list at the moment, though.

[Redrobes]

Was it a VS issue with the x64 build or something about the app code that is the issue. I'm using VS compiler (cl V 14 as part of the x64 SDK) to build all my x64 stuff and its as stable as rock. In fact I would say that its more so than the x86 and that's not bad either.

[waldronate]

There's something in the project files for FT that the environment doesn't seem to like. The x64 build of Wilbur comes out of the same compiler just fine and a lot of that code is the same.

[Redrobes]

Ok. I have to admit I run my compiler from a short cut to a bat file which sets up the environment for 64 bit building and I have another to run up the x86 compiler. So I run with separate environments. Well, if its something you want to chat about in PM or on the user convo or something then let me know and ill go through what I have or do if it would help out get it sorted. Oh I should say also that I dont use the VS projects as I run out of makefiles so maybe I bypass those kinds of project and settings issues as well. I just use the VS IDE to kick off the make and use its editor which I still think is the best out there. But I always think that the VS project format really sucks. It seems to need updating all the time and you cant go back to an earlier format without pulling it out of some code repository or something. I like to see all the settings I am using instead of the dialog panels with them all on.

[guyanonymous]

I'd be more than happy to beta test a 64 bit version... just sayin'

[guyanonymous]

My quick experiments with: 6x3 at 5500, w/ 10% overlap allowed me to crop each image down to 5000, and they but up together nicely at first glance. I'll do more experiments later. Doing this for 18 images for each of 5-6 layers, though, is very time consuming.

[guyanonymous]

Is anyone else having issues when defining the colours to use for altitude rendering? In the previous version, I could select, for land, the highest peak colour and the lowest peak colour, and (for the most part) it would create a range of colours in between. Usually this was done with white as the high-point, and black as the low point. Now, however, it fails miserably; things tend to just get filled in with black despite colours being chosen.