Reply With Quote
Oh, thanks Joe....I'll have a think and contribute!
Fractal Terrains Pro Features
It seems that the folks over at ProFantasy are interested in input as to desired features for their Fractal Terrains Pro product. http://forum.profantasy.com/comments...&page=1#Item_0 is the discussion topic over at their forum.
Oh, thanks Joe....I'll have a think and contribute!
I'll go have a look as well since I seem to be getting deeper into using it.
GW
GW
One's worth is not measured by stature, alone. By heart and honor is One's true value weighed.
Current Non-challenge WIP : Beyond Sosnasib
Current Lite Challenge WIP : None
Current Main Challenge WIP : None
Completed Maps : Various Challenges
Don't forget to get any Fractal Terrains feature requests that you might have into the forum over at ProFantasy. Or post them here. Either way, the request period is starting to wind down...
I'm putting it here, now that you've said it's ok...and keep in mind, I do enjoy the current version, but I see many areas that could be improved to make it more useful and more enjoyable.
In no particular order...
1. proper saving of files (ideally, I could save 30000 x 15000 pixel map without lines/glitches/etc. as a jpg/png/tiff/bmp OR include an automatic mechanism to re-join the individually output files...and don't hide away things like "saving as jpg/bmp" behind hard-to-determine ctrl schemes (like having to hold down ctrl to change to saving as bmp files)...keep it in the open with menus or gui-options. I'm tired of having, after rejoining 32+ files for each layer of my map, to touch up every border on the rivers layer because rivers don't meet).... any chance of psb support for these massive files?
2. My pipedream is to be able to identify fault-lines at the beginning of map generation, then have the program simulate continental drift...and the resulting land-height shifts, mountain and volcano generation etc. Time consuming, sure, but more realistic - hope so! That could be as simple as identifying original landmass shapes, direction and rate of movement, and an amount of time that has passed....calculate the movements, 'guestimated' changes where land masses meet (which moves up/down/over/under etc), and then apply the smoothing and erosion that may have happened over time. Dreaming too hard?
3. A quick way to output only land mass, or only water mass areas (with the rest of the map transparent or a definable colour
4. For individual import/export areas (i.e., terrain colour/texture files) to rememember the last loaded files and folders locations (recent files...).
5. A way, for each terrain generated, to store a variety of map views. That way I could, in one file, return to my "North American continent" view, or "City #33 view" etc.
6. Lots of people are doing it - included the functionality that creates the html and individual image files for a google map-style display....super bonus points if it allows me to add symbols for individual locations etc.
7. The ability to place vector or other image overlays at specific locations on the map which remain individual and re-positionable entities (on layers?) (e.g., stars for cities, words for labels, or the map of a city, compass rose) which show up between specific zoom ranges....for example, at "the whole map" stage, you see a label for countries that you've created, from 60-80% of the map on screen, you also see a star and label for each city, and at 30-60, you see the roads you've layed out (using overlays), and 0-30 you start seeing the city maps you've created and placed...or trees you've added (vector or transparent pngs). (Of course this all gets output in the google-map-style setup for zooming in and out, etc).
8. a 64 bit version for those of us who like LARGE maps with lots of detail....and want to generate with more detail etc. than the current version can handle without choking and crashing and dying catastrophically (and without warning you a value may cause problems as it does now). I suspect that many of the users on here have more than 3GB or ram...we want to use the full power (speed/memory) of our computers to make our lives easier.
9. a better river-overlay system (true vector output?)...
10. an export scripting language for (non-programmers) that lets you cue up exports (i.e., export map with these settings showing only land, now only water, now rivers, now overlay layers as above, now outlines of land...etc) to allow repeatability and comprehensive data-sets to work with in photoshop etc.... I typically save most of those versions right now, and then join the individual files together to make my large file FOR EACH save, and then can import them into photoshop...full-size saves (30000x15000 would make me ecstatic) for each type would be wonderful. Right now it's easy to make a mistake, forget a setting (or to hold ctrl to save bmp) and all that....and having to reset your settings each time is frustrating. I'd love to combine this with #5 above, to generate the standard files for my "Atlas"...which I could then import and apply scripts to in PS...to get my consistent-look Atlas pages generated without unnecessary (and easily missed/forgotten/messed up) steps.
11. some way to "nudge" your map to make minor shape adjustments.....
12. That ability to set your starting position as a seamless-full-world map.... or forget seamless, and just go for a section of the world as the starting point at full-res (i.e., just an island or continent).
13. make sure all map projections work properly, especially when saving at ALL resolutions...
14. A brush with adjustable feathering, and brush size adjustments that are a) smoother and more fluid to do on the fly (with a graphics tablet?), b)consistently display on the screen .... and perhaps have store-able presets?
15. forgot to mention reasonable upgrade price (i.e., 1/3-1/2 of new)
16. a raise for Waldronate
17. More variables (with labels and good explanation of function) that can be controlled - especially if some can be in layman's terms (i.e., land mass size, mountain height, lake frequency, lake size, volcano frequency) and the ability to save those preference files for future use on other new maps
18. a dream...? give it a height map from another map (greyscale) and have it generate an algorithm to give you a similar map (i.e., same proportion of water to land, height range and distribution -are height changes gradual or rapid, clumped like a mountain range, or stretching out over the width of a continent...or apply those ratios to #2 above
19. I'd love it if rotating the 'glove' to get different views didn't produce edge artifacts at the original sides/top/bottom of the map....it's a globe and should be truly seamless.
20. Rotating this globe should shift the climate info (i.e., ice packs at northern and southern poles) AND/OR (your choice) the view.... when I'm first creating my map (or later in it's life if you want to simulate a global catastrophe) I may want North America to become the new South Pole, I may just want a different view while the South Pole remains the South Pole climate-wise, or I may want to do both.
21. Climate that is based on a bit more science (i.e., ocean current/wind-flow and the Earth's rotation should be added to the algorithm so that it moves behind just land height/latitude).
22. Give me control over "how real" it is. Allow me to adjust 'precision of calculations' so that I can do quick renders or ones I leave running over night for exacting detail...with a proper indicator (I'm good with a checklist) of which stage it's on and an estimate of calculations remaing (i.e., completed 15/139439 calculations) for each stage....EDIT: Perhaps if the continental drift stuff gets working, a simulate by year/decade/century/millenium to adjust precision....
23. lake/river formation based on climate
I know not all things above are going to happen - but I'd love to see as many of them as possible down the road!
Thanks for the chance to contribute ideas/requests.
Last edited by guyanonymous; 01-15-2011 at 10:32 PM. Reason: added to #22
The processing pipeline currently involves calculating a whole image in-memory and then writing this image to disk. FT is 32-bit only, meaning that there is a hard limit on file size (it seems to be around 64 MPixel) imposed by the OS and memory. Implementing larger files sizes would require a restructuring of the pipeline to include overlapped render and write operations as well as a way to let the OS render onto these large images. It shouldn't be an insurmountable problem, but I wouldn't expect to see it implemented any time soon.Originally Posted by guyanonymous
If I can find good documentation on the proprietary PSD/PSB file formats then I might be able to include it (the ideal discovery would be a library that writes such files, of course).
Yes.
Interesting feature request. How would you envision the user interface for this working?
I'll throw this on the list of requests, but it's less likely to get attention soon than some of the others.
FT currently implements the "Add View" feature on the View menu that will save the current map projection and center to a list of named views. These view can be restored by selecting from the list.
This feature is already on the request list but hasn't bubbled its way to the top.
This feature is already on the request list, but is not on the immediate work list. You may have noticed that each river segment has an importance attribute (OK, you can't see it, but it's there) that affects the visibility of rivers hbased on zoom level. Only major river sections show up a whole-world zoom with more detailed river segments appearing as the zoom increases.
There are many, many places in FT that have the unfortunate characteristic of using a non-specific integer size in file I/O. Changing to a 64-bit version makes these file I/O operations generate improper results. I don't have a comprehensive test suite for FT, so I"m likely to miss some corner cases. People get pretty vocal when that happens, meaning I'd prefer to avoid it if possible.
The CC2 output from FT is a true vector output. Did you have a different format in mind?
It's a good suggestion, but unlikely to be implemented in the short term.
COuld you describe how you would like to see such a feature operate, especially with regards to what parts get nudged and how a user would indicate those parts?
I don't understand this request.
Could you describe which projections are not operating properly, especially how resolution dependence affects the projection?
A better brush engine is on the feature list. The biggest problem that the brush system currently has in FT is that lack of hardware acceleration. Hardware is finally getting to the point where acceleration of floating-point textures is nearly universal. However, there is a small but vocal minority of people who insist on running the software on machines four or more years old. Maintaining two sets of software for two different paths is expensive and time consuming, especially for a tiny part-time software team.
I'm not sure which version of FT you're running, so I'm not sure if the current implementation of brush presets in the FT beta meets your desires for part B or not.
I don't have any control over either of these items, unfortunately.
I do agree with the general sentiment, but I'm not sure how the user-specified elements would be made to translate to the internal computation system. My biggest problem is that I can't make breaking changes to the calculation algorithms. I can add new or alternate paths, but the existing saved worlds need to keep working from version to version (there was a breaking change required to fix a bug around version 1.23, and it was quite painful for many folks).
This is a pretty difficult operation because it requires both histogram and spatial statistical matching. I'll put it on the list, but don't expect to see anything like this in the near future.
I don't understand this request. Could you provide an example?
Again, I'm not quite sure what you'r asking here. Is the idea that you can reproject an external binary file on-the-fly to allow for a movement of the N/S axis?
Better climate models have been on the wish list since day one. It's a non-trivial problem to solve. I have some code that could work for the problem, but I haven't integrated it into FT at this point. The biggest problem historically was getting the tradeoff between execution speed and fidelity of the results. I think machines are fast enough these days (plus there are some better algorithms that have appeared over the years) that I might be able to get good-enough results. However, there are lots and lots of features on the list that might be ahead of this one.
The effectiveness of the calculations is usually a function of the resolution of the world editing data. Developing scalable algorithms is a fairly complex task in most situations. The continental drift calculation, for example, would provide "scalability" solely in terms of the time step at which the calculations would run. The idea would be that smaller time steps would provide better fidelity. This assumption isn't quite correct, however, because the smaller time steps can result in some otherwise tiny effects to enter into the simulation, potentialy changing the results radically compared to the larger time step. To the best of my knowledge, this effect is true for most discrete-time simulations with random or semi-random components. I have had folks become incensed then they get different results by using a "better" time constant and who then change constants further to make things "better", changing their results yet further, and eventually go yell at my boss about what an incompetent I am because I'm clearly not using the "perfect" equations they provided. Or maybe that was just a one-time bad experience.
The river flow computations that lead to river results have the option to be based on local rainfall. The lake computations are done without the benefit of evaporation. Lakes and rivers in FT don't interact because rivers are a pure slope-based computation and lakes are a pure basin-based computation. A true fluvial computation including evaporation requires a good global computation model. The number of partial differential equations that need to be solved at the same time is quite large, yielding an extremely slow result. Reducing the resolution of computations is possible, but things like rivers and lakes can move around quite a bit with vary resolutions, especially with fluvial erosion tossed in.
Requests are always welcome.
Wow...thanks fro the comprehensive reply...
Here's a few notes/responses to some of the above...
1. I found this on adobe's forums just now... (PSB is necessary for files beyond a certain size - but I can't remember if file size only or also resolution-limited. I think PSD only go up to 2GB in size).
2. If the 'Yes' means its coming, you've almost guaranteed the first update customer
3. Perhaps preference files (the program should remember where they are) for saving/outputting images of the maps. These could include check-boxes to include: a) texturing on/off, b) height map on/off, c) climate on/off, d) render oceans / render lakes / render rivers / render land ... and perhaps a colour setting for those areas not rendered (allow choice of colour, with presets calculated to be as far from the normal colours on the map as possible so that it can be selected easily, and transparency)
4. fair enough...though it drives me nuts that I load a map, then have to navigate to a different folder to load the climate colours, and if I want to load another map, it resets the folders in the climate-colour area...and so onI can live though, I do in many programs
5. I did not know this. I'll have to explore that. Thank you.
6. Well, where do I send the CO2 to enhance bubblage
7. I follow that. I think the on-screen benefit of this gets lost when output at full res because river width doesn't vary. Once exported, the 1 pixel rivers tend to dominate everything. I wonder if there is a way (colour gradients/shading?) to simulate river width as it might vary from it's head to it foot. A tiny creek looks the same as an epic river in terms of width/size (not length, of course) which breaks up the realism a bit. Keep in mind, I'm exporting to an ed size of around 30000px in width usually, so my frustrations may be specialized to me. What about the possibility of placing eps/transparent png objects at set locations/resolutions?
8. I just dream of being able to save larger/full size maps in one go as opposed to 32+ with a painful rejoining at the end. At the edges of each tile there are often inconsistencies from the saving (e.g., rivers don't connect with the neighbouring tile having 1 blank pixel at the edge of a tile)...this happens in jpg (artifacts cause more inconsistencies) and bmp (fewer issues). If that could be worked around, and a separate instance that rejoins the tiles into the huge image, I could live with that. I actually uploaded a program a friend wrote for me to do this, but it's a java command-line dealio. If we could just specify the final size we want, and the program does the tiling/rejoining in the background so that we dont' have to do the math of figuring out how many tiles/resolution of each etc, that would be great, as right now, a miscalculation leaves parts of the map cutoff, and sometimes you end up with a tiny map in the middle of huge black borders (if memory serves). http://www.cartographersguild.com/sh...8525#post58525
9. I don't use CC2. Does this vector save open up in illustrator/photoshop as paths etc? I guess an eps output or something like that would be what I should have requested (a vector format traditional imaging programs can open).
10. ...
11. Hey, I'm broad strokes, you're fine detailsI'm not sure how this could really be implemented, especially in terms of high detail. I guess I'm just looking for an easier, more fluid way to adjust land mass shapes while maintaining the same degree of smoothing/roughness as the rest of the map (for altitude changes, land texture, and especially coast line roughness. A feathering setting for the brushes may help (pressure sensitivity with the wacom tables would be great)....
12. I've gotta re-install FT Pro on my new-at-Christmas setup and check. What my memory is telling me, is that when you zoom in, beyond a certain point, landscape features begin to lose meaning right now. This may be a cross-over memory from other mapping programs, but might not. Maybe it's just rivers, or maybe its more (or nothing)... It also may be something I'm noticing as I make my massive oversized maps (texture only goes so far etc?).... It's kinda like your description of the river setup above (varying amount of rivers shown depending on zoom). I'd like the land to develop another level of detail as you get closer....right now the large-scale roughness/noise/texturing doesn't transition to small-scale noise/texturing. Now I'm thinking again about the 'google maps' style export, and, really, if you could identify, as the user, different settings for noise etc (along with the river variation etc) to appear on the different zoom levels saved out, that would be marvellous. I'm going to have to reload and get playing again (Winter is my mapping time), and I'll try to figure out a better explanation while I confirm my own thoughts on this one.
13. Now I'll have to go scouring my old posts, as I know it's come up in the past. I seem to remember finding success (without export glitches, surprisingly huge black borders) on outputs other than the Equiangular projection). I remember you fixed (the beta) river issue, but I didn't revisit other projections after that. (here's a thread where it was discussed a couple years back... http://www.cartographersguild.com/sh...top-of-my-maps)
14. I haven't done too much since river-fixing-Beta came out (other than verifying that the river stuff was better on the default projection I was using).
15/16.
17. This would be a challenge. Consider, however, that every single ounce of pain Canon SLR owners went through when Canon redesigned their lens mount for AF: they now have the most versatile mount in the business, which allows for brighter lenses (it's a wider mount) and for converters to use almost every other brand of lens in the world on it in manual mode...sometimes it just has to be done. Could the 'old' algorithm be included for opening and viewing older files (for export etc)., and the new one for all new files created? I guess it's a balance of benefits from a newly designed structure, and grafting things on to the old one (and sometimes shoehorning them in?).
18. I figure I have another 40 years or so before I croak...someday!
19. glove should have read globe. Right now when you create a map and change the rotation on rectangular projections that show the whole world, the left right/top bottom edges (when you actually see them meeting now that they aren't the edges of the original map) don't actually line up nicely for the noise/texturing and I believe (memory could be faulty) rivers... the end result is an imaging artifact going in a straight line through your map (maybe noticeable more at the resolutions I'm working with). I'd like to be able rotate the globe like a ball without any seams showing up anywhere in the image when projected flat.
20. Another poor explanation by me. If I generate a map, and there is land at the north pole, it is usually in an ice zone (let's pretend those are the way my default climates were set). I would like to be able to shift the land mass positions so that the land that was formally my north pole is now at the equator and would therefore receive a different climate. This would be in addition to just changing the view so that the north pole is in the center of the map, and still has the north pole climate. One changes your veiwing position, the other changes the land's position around the globe while maintaining the globe's polar orientation adn your position. I don't think that explanation is much better, but here's hoping...(hmm....if I said I wanted to simulate a planet's orbit and polar orientation shifting so that it's poles moved into equatorial positions, changing the planet's climate, would that help?)
21. Music to my ears. I think that finding that balance is a challenge for sure. Could you maintain both the old and new algorithms and or allow a sliding control for 'accuracy' which would allow users of slow and fast computers to achieve that balance of time/quality?
22. Maybe that's what I'm wanting then ...I can't remember the term without re-installing and checking...but when you create a new map, there's a detail setting...I think the limit (4GB? from the 32 bit deal) is 5-6000. I think this is referred to as detail/resolution/accuracy, or affects those things. If I set it beyond that, the program accepts the input but will consistently crash (if crashes are likely to occur, having program defined ranges for user settings would be nice!). Would being able to increase this (2x,3x?) take care of my 'land doesn't look great when really zoomed in' issue above? I get what you're saying about the tiny/large steps...what about parallel algorithms (when needed) which are then compared and combined at certain stages?
If the 'small' step algorithm moves at 10 year increments, and the large at 1000 year increments (or whatever makes sense in a geological time), we can start with the land in X year.
At X+1000, the small step algorithm has gone through 100 steps, the large 1. The two are combined in some way, then the next iteration takes place. I'm envisioning some sort of mesh overlays that track a grid of positions. Each point in the matrix is matched up between algorithms which is how they can be recombined. If point A moves x,y in the long step, and a,b in the small, the meshs could be warped in some way to ensure they still match up in a 'plausible' way...
Please keep in mind I'm a layperson who likes logic, but doesn't program and hasn't done any statistical analysis/study in 15 years. I'm likely suggesting impossibles.
23. Would it be possible to a) have rivers form as they do now, but when they encounter suitable zones (climates/heigh field areas) they may form a lake... and b) placement of 'starter' ground springs which can form lakes (in flat areas) or rivers above when they move out of the flat zone or start on a slop or area inhospitable to a lake. This could give us oases etc? I get the time/calculation thing too. It would be one thing at a global level and viewing scale, another when you zoom in. This is where the 64bit, no memory limitation thing would come in for those of us wanting to ramp the detail up to 6000000.
___
I was initially frustrated with some of the shortcomings of FT (the river issue, projections, output)...and didn't find much help/support on the company website. I encounter this often in creative programs as I love to test the limits of things (I'm a lover of the extreme wide angle/macro, infrared film, etc in photography, for example) Your openness and always honest and positive help on here kept me working through and developing workarounds. Your detailed response (you could have just said, "thanks, added to list" and left) is an excellent example of this ethic; you are the main reason I'll likely grab the next release of FT Pro.
If you scroll down in the thread I mentioned (http://forums.adobe.com/thread/588226), you'll find that people have posted links to the pdf describing the file formats to save you the effort of having to contact adobe etc and request it.
The "Yes" for number 2 was, sadly, in response to the "Dreaming too hard?" question. Tectonic generation has been on the wish list for a long time but isn't likely to get implemented soon.
Placing markers, text and vector graphics onto FT maps has also been on the wishlist for a long time. That's more properly the domain of the Campaign Cartographer line of tools. It would also take a pretty significant amount of effort to implement and isn't likely to make it into the product soon. It's one of the problems of having a single part-time contract developer on the project: there's not a lot of time available to do the work and the complex features are more likely to get pushed out.
There has been a request for SVG output as a common vector format. Do you think that might meet your needs?
The multi-file export misfeature was an idea from version 1.0 about 12 years ago now. I was never particularly happy with how it turned out, but it seems to work well enough for what many folks seem to want from it. It really doesn't work well for stitching multiple files together, as you found out.
If I'm not mistaken, SVG is pretty standard these days an most vector programs can handle it.
I look forward to seeing what you can shoehorned in there in the time they give you...
I just finished re-installing and I might just get going with this stuff again in the next few days...talking about this from memory has gotten my creative juices going again. Thanks!
Posting Permissions
