The new features of update 15/16
Monsen
Administrator 🖼️ 46 images Cartographer
I just posted a blog article explaining how to use the new features that arrived with update 15 (which were quickly replaced with 16). Here you can read about how to use the new CONTOURSM command and the new exclusion commands, as well as an overview of the other new command line commands, with a bit of explanation for each.
Check it out.
Check it out.
Comments
It has some really good outline maps of various locations around the world that can work as great coastlines to import.
Links from the Tome of Ultimate Mapping to video content would be nice as well if possible.
I LOVE the new CONTOURSM command. I will have to get the update.
Thanks for great blog Monsen! :-)
As for linking to video content, probably not. There are too many changes in the internet world, making old links stop working or point to completely different things. Whiel the Tome does undergo revisions, it is mostly static. I think links to stuff like videos and otherwise are more properly found in dynamic places, like this forum, or ProFantasy's own website.
COUNTOURSM
- What type of entity does it create? A polygon of straight line segments? Any way to control the sample distance or how closely the segments lay over the edge?
- Does it place the control points (?) at the center of the outer non-transparent pixels (or inner transparent, or somewhere else)? Or a control point on all pixel edges between the transparent/non-transparent pixels?
- The distance/offset option, how does this handle self-intersecting entities? (i.e. image a inlet or bay with a radius of 2 units, if an offset of 3 was used the bay/inlet would be removed. Is that done 'cleanly'? Any concerns etc?
(If non of this makes sense,I could sketch up some images)
EXPORTSETMPPP
Any experience or approximations as to how this value relates to RAM used? Or to export performance?
It handles those self-intersecting entities very well, but note that in your example, if it was a large bay, but a narrow inlet, the inlet would dissapear, and the inlet would basically be a lake, which basically has it's own set of entities, so it will be drawn with it's own polygon. You could then multipoly this "lake" with the main shape to get a hole, or you could set the appropriate fill and sheet and treat it as a lake (This is also how any lake in general will appear)
For EXPORTSETMPP I don't know the spesific memory use, but in my experiences, I can go up to about 60000000 before running into memory issues. Note that you'll only notice if the value is too large if you export a map that requires at least 2 passes. If you use a high value, but with a small export, then CC3+ won't use the entire value, and you won't notice a problem. For complex maps, I am not always able to go this high, and for some maps I need to even drop it down to 20000000. Note that since CC3+ is a 32-bit program, 4GB is the absolute limit here no matter how much you may have installed in your computer, as long as you have enough to let CC3+ actually get it's 4GB for itself without sharing with others, then you can't go further.
Export performance is much better with fewer passes.
1) user picks entities to outline
2) system renders those entities to a 2048x2048 image that bounds the extents of the entities
3) system computes a distance field from the non-background pixels of the image (segmentation is binary; distance field computation is similar to "Distance Transform of Sampled Functions" by Felzenszwalb and Huttenlocher)
4) a contour tracer traces around the distance-value level set of the distance field using an algorithm similar to that described in http://paulbourke.net/papers/conrec/, generating a polyline. All cells in the distance field are evaluated by the end of the process, meaning that the multiple polylines may be created.
5) a polyline simplification process similar to https://en.wikipedia.org/wiki/Ramer–Douglas–Peucker_algorithm is run on the resulting polylines to reduce the number of nodes to a reasonable level and to merge any straight segments.
What does that all mean in terms of your questions?
a) the rendering process for bitmaps in CC3+ is nearest-neighbor interpolation, meaning that if the image is scaled up, there will be aliasing along the edges. Also, any pixel difference is treated as significant, meaning that even a feathery alpha shadow will count as a hard edge for the algorithm.
b) the tracing approximates the continuous edge from the point-sampled image. The point sampling results will vary widely depending on the rendered resolution (as described in 2).
c) if you're familiar with the effects of the striping filter, you will get the same behavior here, except that geometry will be generated in the form of polylines in your drawing instead of pixels in an image.
On the export temporary size, your mileage will vary. The default value (4 million) is chosen for safety because it seems to work well on all systems and precisely replicates effects behavior in CC3 (it also generates lots of passes). I find that a value 10 times the default works in most cases, but Monsen correctly points out that some drawings with many images can cause an out of memory condition. CC3+ has a number of things contending for memory, of which the largest non-export user is the image cache. You can sometimes get a larger export in a single pass by reducing the image cache size, but you if you reduce the image cache size too much, you may well find that your drawing performance becomes what I will charitably call "bad". Sometimes, though, poor performance is acceptable to avoid splitting an effect like point lights.
How large you can make the export image buffers depends on a number of factors, including what you've been doing with the program before starting the export. The larger the image buffer size, the larger amounts of free contiguous memory that the system will require. As you use the program and as images are rendered, memory can get a little fragmented. CC3+ doesn't have a way to compact memory except by a restart of the program, so if you run across a situation where your drawing won't export with large image buffer sizes, a quick exit and restart followed immediately by an export may make things work more smoothly.
Also, as Monsen points out, CC3+ is a 32-bit program. On a 32-bit OS version, you will most likely be limited to 2GB of used memory total; on a 64-bit OS, you will be limited to a maximum of 4GB of available memory. The program is normally going to use a bit less than 100MB for its code and drawing space, leaving the rest for image cache, onscreen image buffers, and export image buffers.
I can't say I'm familiar with everything you said, but you more than answered my questions and I even learned a few things that will help understand CC3+ behavior (esp. memory fragmentation).