Suggestion: 64-bit rendering
Gathar
Traveler
Hello,
I recently wanted to print my map, or save it in high resolution, and I experienced many crashes from CC3+. And I am obviously not the only one with this issue. The problem would be much less common if CC3+ was developed in 64-bit and could use all the memory available on modern computers. Alas, it is not, and I've read that it relies on software layer that may not be either. So the porting cost is huge.
But recently, I realized that I did not need a 64-bits version of CC3+, but I only needed a 64-bits version of a renderer for CC3+ files. No UI, no interactivity, just a command line tool that take as input a FCW, and renders it in the desired format.
I guess that most of the rendering code must be specific to CC3+, and must not rely too much on the underlying CAD tool, am I right? If so, I believe that the cost of creating such a renderer and port it to 64-bits might be an order of magnitude cheaper than the full port, while reaching most of the benefits of the port. I've participated in the porting of two big applications written in C++ to 64-bits, and people were usually surprised that it did not take as long as they feared (admittedly, it greatly depends on the source code quality).
Am I right or am I on the wrong track? What do you think? Would people be interested by such a tool?
I recently wanted to print my map, or save it in high resolution, and I experienced many crashes from CC3+. And I am obviously not the only one with this issue. The problem would be much less common if CC3+ was developed in 64-bit and could use all the memory available on modern computers. Alas, it is not, and I've read that it relies on software layer that may not be either. So the porting cost is huge.
But recently, I realized that I did not need a 64-bits version of CC3+, but I only needed a 64-bits version of a renderer for CC3+ files. No UI, no interactivity, just a command line tool that take as input a FCW, and renders it in the desired format.
I guess that most of the rendering code must be specific to CC3+, and must not rely too much on the underlying CAD tool, am I right? If so, I believe that the cost of creating such a renderer and port it to 64-bits might be an order of magnitude cheaper than the full port, while reaching most of the benefits of the port. I've participated in the porting of two big applications written in C++ to 64-bits, and people were usually surprised that it did not take as long as they feared (admittedly, it greatly depends on the source code quality).
Am I right or am I on the wrong track? What do you think? Would people be interested by such a tool?
Comments
CC3 rendering (not just in +, it's always been like this) for very large, very detailed maps is absolute garbage. It's the one thing about the program that I truly find consistently, hair-pullingly problematic, and have never really found a good solution for. I can't go above 6000 x 4000 with 25% AA in vanilla CC3 with my main mapping project, and repeated attempts to render a quick little rush-job test map I made in CC3+ with the new default style at those same settings all crashed - which is a bit odd, considering that said map was FAR less detailed than the map that I can (usually) render in CC3 without a crash as long as I don't try to go above those resolution/AA numbers.
Now, I'm aware that CC3+ still isn't COMPLETELY done; what we've purchased is sort of an early adopter release, I believe? Which is why it's still not available for purchase from the front page. That said, if the rendering is mainly an issue of the memory limitations imposed by it being a 32-bit program, is there much hope of the rendering situation improving with further refinements to CC3+? I've kind of been assuming there really isn't any such hope.
I have no idea if a 64-bit rendering tool, separate from the main program, is even remotely possible, but if it is, I heartily endorse the idea.
It does not depend on the number of entities in the drawing.
CC3+ has superior export to CC3 - we've removed bugs and the resolution is higher.
If you drawings crash on printing or export, please try them on a lower resolution; if they still crash, there is another issue and you should report this to tech support. Likewise, some effects require way more memory - try rendering your drawing with effects off and if it works, turn effects on 50% a time until you find the culprit. Some of our older templates have a lot of effects.
Finally, to make the best use of system memory, clear the CC3+ cach and close down other applications.
A 64-bit renderer is the bulk of the work of rewriting the whole program, which won't happen for a long time.
Looking forward to being able to test out my map in CC3+, heh. Can't yet because it's built in an annual style. I haven't tested + extensively, so the problems I had with rendering my quick little default test map could have been a fluke. I'll play with that some more later.
But for the moment, in regular CC3, I'll try what you've suggested... the best I've been able to get is 6000 x 4000 resolution with 45% AA with effects off.
What do you mean, turn effects on 50% at a time? Do you mean like, select effects individually (the check box), rendering repeatedly with only one or a couple selected, so that I can try and narrow down which ones drag it down so much?
And, the number of sheets has an impact on the rendering? I wasn't aware of this either. The map I'm concerned with has 35 sheets total (counting the Common sheet). Would knocking out a few of those make an appreciable difference? Of course, I do legitimately need most of them, so there aren't many I could get rid of.
I am interested to know - why do you need a greater than 6000x4000 bitmap?
FYI, I just tried to print without tuning any option, and the program crashed. As far as effects are concerned, I just used the effects provided in the default Schley overland style, just tuning some parameters. So I don't think it can be caused by that.
I also may want to provide a zoomable and scrollable map on the screen that remains clean even when zoomed. I'm sad to hear that. Is the difficulty/cost related to the work of extracting the renderer from the rest of the code, or is it related to porting to 64-bits? If it is the second option, I might find some time to give it a try for you, if you could provide me with the source code (with any kind of NDA or other paperwork you would feel necessary, of course).
The real reason I want more resolution is for anti-aliasing. To be precise, I would say that I want to be able to export in "higher resolution and/or higher AA", because increasing either option helps with the jagginess and muddiness of the lines.
Here is a slice taken out of an image of my full map, post-export (6000x4000 with 25% AA): http://i.imgur.com/fJBR7uZ.jpg
and here is a test-render of a "rectangular section PNG" of the same area rendered by itself (the settings were 4000 x3000 and 50% AA): http://i.imgur.com/XurCDpk.png
You can easily see the difference in visual quality by looking at the smoothness of various objects - the lines forming the white and black city dot symbols and the dark gray dotted line representing regional borders look much smoother in the second image. Rivers and text also look better. Of course, the second image is much much smaller, which is why I'm able to be render it at much higher AA even though the res isn't much smaller. But I still want my map to look like this ultimately, like the second image, or at least close to it, in quality. Even though it's a big map (which it has to be because it's a map of an entire country). So I'm continuously looking for any ways to make the rendering better.