View Full Version : On a Possible Method for Forcing Icosahedral Maps onto the Equirectangular Projection
01-17-2014, 04:19 PM
So. A really long time ago, back when I had hair on my head and both of my eyes, I posted a method (http://www.cartographersguild.com/sci-fi-modern-mapping/1533-regina-jewel-spinward-main.html) for mapping an icosahedral map of the sort that RPGs like Traveller are so enamored of to a sphere in a 3d app.
Even back in those days of hoary antiquity I was looking for a means to map that surface onto an equirectangular map(plate carée or latlong for the technical). Given the prevalence of apps like G.Projector and Flex Projector, both of which require equirectangular maps as input, this was very desirable. Even the Flexify filter, with its many available input projections, chokes on interrupted projections on input.
At long last I may have found the means. Maybe.
Looking at the Wikipedia, I found this page on Tissot Indicatrices (http://commons.wikimedia.org/wiki/Category:Map_projections_with_Tissot%27s_indicatri x/Templates). Included on that page was the povray source code used to generate the templates. I puzzled at this, then I realized the magic of the spherical camera.
Unfortunately, I can't figure out how to export a uv-mapped object to povray. Wings3D exports to povray, but the uv-mapping seems to be lost.
Are there any less antique programs(you know, the kind that can import Wavefront .obj objects, for example) that can do this spherical camera thing? Freely available? For the mac?
01-18-2014, 12:41 PM
On a suggestion from reddit, I tried using texture bake in Blender. That has it's uses, but this isn't one of them. It basically just bakes the uv-mapped texture onto another identical uv-mapped image. Useful, if you're trying to speed up procedural noise or add shading from a complex model onto a low-poly version; not so hot if you're trying to repro the texture image.
Back to povray.
Turns out Wings3D has a direct povray exporter. This seems to export the geometry successfully, and at least the code, to my highly inexpert eye, seems to include fun things like uv-mapping vectors and indices. It just doesn't seem to successfully export the uv-mapped textures. I haven't found a workaround yet that actually works. Crud.
I've just downloaded a java obj2pov app from github(that was a nightmare:x). I'll give that a try. Hopefully it will export a working uv-map.
Barring that, I'm hoping for some povray advice or possibly another tack.
01-18-2014, 01:06 PM
Every experiment is successful if you learn something from it. This experiment was successful. I've learned that the java obj2pov program doesn't work any better than the Wings3D export. Waaah:((!
The uv coordinates seem to be there, but there doesn't seem to be anything telling povray where to look for the texture image. How is the image found?
More research is in order. This is beginning to feel like the pursuit of undomesticated fowl:sad:.
01-20-2014, 03:15 AM
It's alive, it's alive!!!
Once I got over the problem of getting the properly uv-mapped icosahedron model to render in povray, it was smooth sailing.
Since the image was basically mapped from inside the center of the sphere, it did come out in mirror image. Simply selected the entire image in my favorite raster image editor and flipped it vertically.
The uv-image I was using was pretty low-res, so there was some stretching of pixels near the poles. Ugly, but since the purpose is really to make the geometry available, I'm not too sensitive to the aesthetics of the image.
I'll get into details later, but it's getting a bit late.
I used the icosahedral pov file exported from Wings3D with some small modifications to make it... work. First off, at least in my instantiation of MagaPOV, rad_def.inc kills the script, so that gets commented out. The entire global settings block, for some reason I haven't figured out, results in a black screen, so that goes bye-bye. I removed the light_source, but in retrospect that makes no difference for good or ill...
Most importantly, I moved the camera to <0,0,0>, changed it from perspective to spherical and commented out everything between location and look_at. I changed look_at to <0,0,1)> I also changed the ambient rgb in finish to <1,1,1> 'cause it was a bit dark.
After arriving at this combination through trial, error and foul language, I had that nice mirror image map of Regina. Cool!
I now had something very useful. I could port this into gplates and digitize the continental coastlines to some appropriate accuracy or I could load it into G.Projector or Flex Projector and convert it into all manner of convenient projections. I'm so happy. To celebrate, here's a screenshot of Regina in gplates, ready for digitizing, a Robison projection of Regina, made with g.projector, and a compressed copy of my final successful pov-file... I'm going to try this again with a different map as a test, but I'm highly confident.
01-20-2014, 10:48 AM
I'm so glad you got it to work! Congrats, it looks great (and really useful!) :D
01-24-2014, 01:22 PM
So I'm still kind of playing with this prefatory to releasing a very long blog post on it.
Turns out the include worked fine once I set the System Includes in Preferences. It didn't do anything in this case, but it doesn't kill the renderer. One less thing to comment out.
The global_settings were fine. The
ambient_light rgb <0,0,0> bit simply made everything dark. The first way to fix this is to set the rgb vector for ambient_light to <1,1,1>. The other way, which is a bit more flexible, is to move the position of the light to <0,0,0>. For a light_source, the position vector is the first vector in the block. You'll find if you render as-is, without altering the light type, you'll get a nice day/night map of your world. Cool, but if what you want is a simple map of the entire surface, it pays to comment out the parallel and point_at lines. Upping the color rgb vector will also make the map nice and bright. I prefer the ambient, because it's difficult to find the proper value for the color rgb vector and ambient tends to make the map look less... "muddy."
After doing this several times, I find I can readily get it done in less than 15 minutes. You know, if I'm not spending hours documenting each step and puzzling out what the next step should be.
01-27-2014, 06:25 PM
I've released a blog post with detailed instructions here (http://astrographer.wordpress.com/2014/01/26/tutorial-for-forcing-icosahedral-maps-onto-flat-maps/)!
02-03-2014, 01:48 AM
Excellent work! I've never had to deal with converting from icosahedral maps, so I hadn't considered how hard it might be. Thanks for sharing your method.
Powered by vBulletin® Version 4.2.2 Copyright © 2014 vBulletin Solutions, Inc. All rights reserved.