AA in itself can't really be the issue. All turning on AA does is making CC3+ export a slightly larger image than requested, so the imagemagick processing after export can generate AA by reducing it down to the requested size.
Now, what I did notice is that when I export at 5000x5000, it is completed in a single pass, but if I bump it to 33% antialias, the resulting size increase leads to a 2-pass operation. Is that what you see as well?
My suspicion is that something weird is happening with the color key with that gigantic entity, but in this case, because turning on antialias forced it to become two-pass, it became divided over two smaller ones instead which was then handled correctly.
Yea, seems to be matching up with my findings then. It is basically just an image size issue, the AA thing just happened to show the way to the real issue.
It will only happen for people having increased their max pixels per pass then, since otherwise a work image of the problematic dimensions will never be created.
If you use SIMPLIFY on the problem poylgon at a scale of 0.3 it works fine at the original settings. Maybe this is a node placed not quite on top of another somewhere in that coastline? smaller than 0.3 is no good.
A 'certain amount of being too close' might seem to be causing the problem in this particular map.
Although, I don't see how the difference between one and two passes would help that.
This is an embed external element. It can be deleted using the delete key or the backspace key. To view the full element, press the preview button below.
If you use SIMPLIFY on the problem poylgon at a scale of 0.3 it works fine at the original settings. Maybe this is a node placed not quite on top of another somewhere in that coastline? smaller than 0.3 is no good.
A 'certain amount of being too close' might seem to be causing the problem in this particular map.
Although, I don't see how the difference between one and two passes would help that.
Thing is, I didn't do anything to the coast that I can remember. Man, still having overly complex coasts. 😑
I'm pondering 'Voltaavia' (LOL on the name) and whether there are large cities still extant---as that land was blasted to hell and back a thousand years ago. And need to add the underwater cities for Alcara.
This is an embed external element. It can be deleted using the delete key or the backspace key. To view the full element, press the preview button below.
A comment about overly complex items not filling correctly: The polygon scan converter in CC3+ has some problems when trying to handle a polygon made of a large number of nodes with many spans (places where the polygon is intersected by a horizontal line) and where the screen-space size is very small over a large distance (numeric precision drops off causing the scan converter to believe incorrect things). Basically, it runs out of numeric precision and/or span buffer memory, which causes it to panic and exit before it gets too far.
As Sue suggested, SIMPLIFY with a smallish number should get rid of the nodes that are very close together, which reduces the total amount of calculations and also reduces the local precision loss. Generally, I would say that you should keep your geometry as simple as you can artistically tolerate. It speeds up the display processing and reduces the likelihood of errors like spikes and the weird vertical and horizontal banding.
There was a bug back in 2021 that was causing INSNODE and DENODE to behave badly for polygons with more than 8191 nodes and the fix for that may be near the root of this problem (now it doesn't crash, but the misbehavior can be seen). Recent CC4 work suggests that there may still be a bug drifting around in that code relating to a long-ago (circa 1995) translation from 16-bit code to 32-bit code.
It would be nice if I could implement a few toys for this kind of thing like a SIMPLIFY that drops a polygon to a maximum number of nodes and/or a visual SIMPLIFY with a slider to reduce guesswork about how much to SIMPLIFY things. I certainly won't have time for that any time soon, though, and definitely not for CC3+.
In this case, that would be the coastline polygon that was having the fill problem. And pretty much every polygon you can stomach, really... SIMPLIFY eliminates the "least important" nodes first, so it shouldn't affect the visual appearance too much. If all of the nodes in your polygon are a greater distance apart than the specified amount, then the polygon shouldn't be affected at all. I didn't spit out the before and after information (how many nodes were reduced), which might give folks more confidence in the results (or might just clutter the process: engineers want different things than artists).
A whole-drawing SIMPLIFY would probably simplify a general drawing cleanup (more things for the wish list). Possibly something to evaluate all polygons in the drawing against the apparent screen-space limits and suggest a suitable operation to perform.
Too many digressions from your thread, sorry. so back to the map appreciation!
The map is nicely done. That's a lovely use of the style and a good rendition of your original map. I had problems at first understanding that the text around the compass rose was the map title, but that's a me problem, I suspect. As I get older and my visual acuity drops, I find it harder to distinguish similar-hued items like the blue labels on the blue ocean. A small mostly-transparent light-colored outer glow on the sea labels might make them pop.
This is an embed external element. It can be deleted using the delete key or the backspace key. To view the full element, press the preview button below.
A comment about overly complex items not filling correctly: The polygon scan converter in CC3+ has some problems when trying to handle a polygon made of a large number of nodes with many spans (places where the polygon is intersected by a horizontal line) and where the screen-space size is very small over a large distance (numeric precision drops off causing the scan converter to believe incorrect things). Basically, it runs out of numeric precision and/or span buffer memory, which causes it to panic and exit before it gets too far.
As Sue suggested, SIMPLIFY with a smallish number should get rid of the nodes that are very close together, which reduces the total amount of calculations and also reduces the local precision loss. Generally, I would say that you should keep your geometry as simple as you can artistically tolerate. It speeds up the display processing and reduces the likelihood of errors like spikes and the weird vertical and horizontal banding.
There was a bug back in 2021 that was causing INSNODE and DENODE to behave badly for polygons with more than 8191 nodes and the fix for that may be near the root of this problem (now it doesn't crash, but the misbehavior can be seen). Recent CC4 work suggests that there may still be a bug drifting around in that code relating to a long-ago (circa 1995) translation from 16-bit code to 32-bit code.
It would be nice if I could implement a few toys for this kind of thing like a SIMPLIFY that drops a polygon to a maximum number of nodes and/or a visual SIMPLIFY with a slider to reduce guesswork about how much to SIMPLIFY things. I certainly won't have time for that any time soon, though, and definitely not for CC3+.
It speeds up the display processing and reduces the likelihood of errors like spikes and the weird vertical and horizontal banding.
Ha, and all this time I thought it was something I did to mess up a map. In the begining I ended up with spikes all over the place.
Comments
Wow!
Thanks, Sue.
NEVER would have thought of that.
Oh, just saw...yes, will report
SENT
😁
Cal
Thanks :)
It seemed an unlikely cause. Never had that happen to me before, but I never export without AA.
AA in itself can't really be the issue. All turning on AA does is making CC3+ export a slightly larger image than requested, so the imagemagick processing after export can generate AA by reducing it down to the requested size.
Now, what I did notice is that when I export at 5000x5000, it is completed in a single pass, but if I bump it to 33% antialias, the resulting size increase leads to a 2-pass operation. Is that what you see as well?
My suspicion is that something weird is happening with the color key with that gigantic entity, but in this case, because turning on antialias forced it to become two-pass, it became divided over two smaller ones instead which was then handled correctly.
Probably right. Here is one I exported without AA, but at 7000 - meaning 2 passes.
Yea, seems to be matching up with my findings then. It is basically just an image size issue, the AA thing just happened to show the way to the real issue.
It will only happen for people having increased their max pixels per pass then, since otherwise a work image of the problematic dimensions will never be created.
I don't understand why it's not been noticed before. Other maps have Color Key effects and some of them must have been rendered in one pass.
If you use SIMPLIFY on the problem poylgon at a scale of 0.3 it works fine at the original settings. Maybe this is a node placed not quite on top of another somewhere in that coastline? smaller than 0.3 is no good.
A 'certain amount of being too close' might seem to be causing the problem in this particular map.
Although, I don't see how the difference between one and two passes would help that.
Thanks guys, I'll look into it. Meanwhile, though not finished with the terrains, here's an update.
It's starting to look even more impressive with just that one depth contour in the ocean.
Thing is, I didn't do anything to the coast that I can remember. Man, still having overly complex coasts. 😑
Last time, though, you weren't using a Color Key to cut huge and complex shapes out of the sea.
I wouldn't say it was overly complex - just that somewhere there are two nodes just a fraction closer than 0.3 map units.
Well, thinking about text...
Gets a little lost?
Not sure about dark ocean color.
If it's readable (which it definitely is) and you like it, that's good enough.
I like the dark ocean, but that is only my take on it.
A few changes, but steady as she goes...
I'm pondering 'Voltaavia' (LOL on the name) and whether there are large cities still extant---as that land was blasted to hell and back a thousand years ago. And need to add the underwater cities for Alcara.
Each time I see it I don't think it can look better, but then it improves again.
I think the labels might be a little large now, but again that is personal taste. It depends how large you print or use the map.
OK, unless I can get more critique, we'll call this one done...
and for comparison, the original map...
Things that are bugging me
😁
Position of 'The Endless Sea'
The type font for the countries. Might want to change all Times Roman
There are many small rivers along all coasts unseeable...should change to size 2.
Oh, and text for 'Hoarfrost Bay' is unseeable.
heh
You could use the rivers any size - just make a new drawing tool based on the Rivers Amazonian one.
Already did heheheheh. You, Ralf and Remy have taught us well.
😁
Cal
I agree that this style looks better than the Darklands for this map.
A comment about overly complex items not filling correctly: The polygon scan converter in CC3+ has some problems when trying to handle a polygon made of a large number of nodes with many spans (places where the polygon is intersected by a horizontal line) and where the screen-space size is very small over a large distance (numeric precision drops off causing the scan converter to believe incorrect things). Basically, it runs out of numeric precision and/or span buffer memory, which causes it to panic and exit before it gets too far.
As Sue suggested, SIMPLIFY with a smallish number should get rid of the nodes that are very close together, which reduces the total amount of calculations and also reduces the local precision loss. Generally, I would say that you should keep your geometry as simple as you can artistically tolerate. It speeds up the display processing and reduces the likelihood of errors like spikes and the weird vertical and horizontal banding.
There was a bug back in 2021 that was causing INSNODE and DENODE to behave badly for polygons with more than 8191 nodes and the fix for that may be near the root of this problem (now it doesn't crash, but the misbehavior can be seen). Recent CC4 work suggests that there may still be a bug drifting around in that code relating to a long-ago (circa 1995) translation from 16-bit code to 32-bit code.
It would be nice if I could implement a few toys for this kind of thing like a SIMPLIFY that drops a polygon to a maximum number of nodes and/or a visual SIMPLIFY with a slider to reduce guesswork about how much to SIMPLIFY things. I certainly won't have time for that any time soon, though, and definitely not for CC3+.
I have no idea which polygon to use SIMPLIFY on.
Cal
In this case, that would be the coastline polygon that was having the fill problem. And pretty much every polygon you can stomach, really... SIMPLIFY eliminates the "least important" nodes first, so it shouldn't affect the visual appearance too much. If all of the nodes in your polygon are a greater distance apart than the specified amount, then the polygon shouldn't be affected at all. I didn't spit out the before and after information (how many nodes were reduced), which might give folks more confidence in the results (or might just clutter the process: engineers want different things than artists).
A whole-drawing SIMPLIFY would probably simplify a general drawing cleanup (more things for the wish list). Possibly something to evaluate all polygons in the drawing against the apparent screen-space limits and suggest a suitable operation to perform.
Too many digressions from your thread, sorry. so back to the map appreciation!
The map is nicely done. That's a lovely use of the style and a good rendition of your original map. I had problems at first understanding that the text around the compass rose was the map title, but that's a me problem, I suspect. As I get older and my visual acuity drops, I find it harder to distinguish similar-hued items like the blue labels on the blue ocean. A small mostly-transparent light-colored outer glow on the sea labels might make them pop.
It speeds up the display processing and reduces the likelihood of errors like spikes and the weird vertical and horizontal banding.
Ha, and all this time I thought it was something I did to mess up a map. In the begining I ended up with spikes all over the place.
Probably when
OK,
Followed some critique and changed as necessary:
Hey all,
Here's the current game version of this map.
Text changes are good.