sry to be so picky, but this can't be right. first, the aspcet ratio does not end up in 2:1. i think that's important for a sphere. second, the equator-pixels are distorted, too.

let me illustrate what i mean:

<img src="http://dl.dropbox.com/u/6200498/dist.jpg" border="0" />

in addition, it should look something like this qarp, although the poles (top and bottom) have to be shrunk instead of stretched:

<img src="http://dl.dropbox.com/u/6200498/cosp.jpg" border="0" />

i discovered this when using a non pow2, 400px by 400px bitmap in the source-sprite:

<img src="http://dl.dropbox.com/u/6200498/noise.jpg" border="0" />

the effect gets more the bigger the image gets. pow2 is ok, but non pow2 not.

yeah, that's a good technique newt. the point of this whole matter though was to use procedurally generated textures (noise2). generating random planets is pretty easy. fire up noise2 a couple of times, load it into a sprite's animation. for every planet, set animation & texure to the 3dobject like you said.

yo Animmaniac, thanks alot for your example. It shows the effect pretty well with the contained texture, but it does not work with with other textures.

prr-sphere-mapping-03b.cap

I get the feeling that canvas is not as reliable as it should be. If i change to different textures the processed output looks different everytime. It's odd...

Maybe it's best to wait for an update of Noise2 with integrated distortion.

Sorry, but I'm not totally following your thinking. If you apply the Lambert cylindrical equal-area projection in that rectangular texture you will only get some distortion near the equator line.

And that's the whole point: 'some' distortion. I'm trying to minimize the polar distortion as seen in unprocessed textures. And therefore the pixels towards the poles have to shrink. I know that it will still look distorted, but way less.

Pretty interesting that we get an almost undistorted projection when we first do the sinusodial prjection and afterwards the "rhombic" one. But as we found out, there is too much loss of texture quality (especially with no supersampling at all).

Something that came into my mind while reading your last paragraph is that the original output from Noise2 is a square image. And thinking over this whole subject i realized that we've been working with rectangles the whole time. "Reconstructing" an imaginary square is impossible, too. Now what happens if we shrink down the square to half its height, but not dividing it by 2. Instead a sine-function comes into play. What do you think of this?

something like this:

<img src="http://dl.dropbox.com/u/6200498/moon.jpg" border="0" />

polar distortion is there, but less than with an unprocessed texture.

furthermore... thanks again for your time, and sorry for me being so neurotic on this topic <img src="smileys/smiley23.gif" border="0" align="middle" />

Here is the projection without distortion at the poles:

sphere-mapping-01.cap

However bear in mind that is impossible to distort this texture to fit perfectly a sphere without seems or distortion. If your goal is to achieve a sphere with an uniform noise you will need to generate the noise with the proper detail density across the poles in a way that it wraps perfectly.

did you just simplified the formular from page 1? impressive to see that it's possible with less variables!

although it's pretty cool, i think that the far more simple approach of "lambert cylindrical equal-area projection" (also on page 1) suitable for this case.

basically it must be something in the direction Rojo posted.

Not sure if tillable will work with non power of two in Noise2.

Edit:

However, you can I think you can stretch the output, and noone would probably be able to tell the difference.

lol, you're right. the noise itself tiles pretty well, but it won't fit spheres if not power of two ;)

For sine interpolation:

Lerp(0,IM.GetImageHeight, (1+Sin(LoopIndex("j")*180/IM.GetImageHeight))/2)

But that still won't eliminate the distortion at the poles.

Paul Brouke's method eliminates the pole distortion but causes seams because parts of the image are discarded.

<img src="http://local.wasp.uwa.edu.au/~pbourke/texture_colour/texturemap/sketch.gif" border="0"> The area in that shape is the only part of the image that is preserved.

The libnoise website it has some sphere textures that are distorted in a way similar to pbrouke's method but I think that it was generated special for spheres.

http://libnoise.sourceforge.net/examples/textures/index.html

Also the Photoshop method just blurs the texture near the poles, it would still have the pole distortion.

the new formular is not correct either:

<img src="http://dl.dropbox.com/u/6200498/sinus2.jpg" border="0">

the examples given from libnoise represent what i'm looking for, because the more we go towards the poles the less detailed the texture has to be. so wrapping a cylinder around it does it imho.

you're right, paul bourkes approach is be correct, but it is lossy.

and yeah, screw photoshop. construct is the place to be ;)

i won't forget your solution and ideas newt, it might come in handy in the future.

with lucids help in the chat it turned out out that some sort of cosp plays a role in this matter:

<img src="http://dl.dropbox.com/u/6200498/cosp.jpg" border="0" />

which is this:

cosp(0,IM.GetImageHeight,LoopIndex("j")/IM.GetImageHeight)

but it exaggerates the distortion i tried to work against.

i can imagine that a sine-interpolation would be needed here.

something like this:

Lerp(0,IM.GetImageHeight, Sin(LoopIndex("j")/IM.GetImageHeight))

But it's just a pixel mess.

OK, i almost got it.. long story short:

"Lambert cylindrical equal-area projection"

The technique seems to do the job, hopefully.

The X-pixels are untouched and Y-pixels get compressed towards the poles via Sin... But as you can see there is still something wrong with the formula. My guess is that there is some PI missing somewhere:

<img src="http://dl.dropbox.com/u/6200498/cylindrical.png" border="0">

Please have a look at the cap: sphereTex2.cap

Hey Arsonide <img src="smileys/smiley1.gif" border="0" align="middle" />

I think that Noise V2 does it's job pretty well, thx for that! Of course it might be easier to further post process an image than to recode that plugin once more for C1. I can imagine this sort of update for a potential C2 plugin if you're into that one day.

Edit:

Then again you could also use color filters on the distort map.

I didn't get that. Do You think that this is a benefit over meshes?

Edit2:

This whole thing is driving me mad. <img src="smileys/smiley11.gif" border="0" align="middle" /> It seems that there isn't a 'perfect' mapping solution, because the poles consist of 1 point each; which is impossible to map.

Buuut i think your canvas/sprite distortion solution is more elegant. With a little effort i might change your example to have pitch/yaw/roll.

One more question though:

Is it possible to increase the distortion mesh quality? I tried to double the X/Y values but it gave me weird effects like little white dots and a whole different "tiling" of the texture. Multisampling is a showstopper also.

Edit3:

It's me again... Sadly, distorting a sprite/canvas does not solve the problem of mangled poles. Seems like i have to dive in a bit further and search for some other solutions.

Thanks alot for your replies!

I agree, Rojo, the formula i googled all day long does not look promising enough. Maybe i was confused by all the mapping techniques that are availabe. Another formula i stumbled upon was the Mercator Projection

Perhaps this is the place to be.. dunno i'm confused..

In general you're right newt, but i wanted to physically distort the sprite (texture) because it should be mapped onto a real 3d sphere (via textureSetter). And the whole point of this tool i'm developing is to output an INI which is then loaded into my space-game which should work procedurally. The containg planets/suns consist of 3d-meshes, because i find them easier to handle (e.g. roll, pitch, yaw right away).

So any ideas on how to push those damn pixels in an appropriate way are more than welcome.

EDIT:

I like to illustrate that thing a bit further by pointing to the follow article which shows the progress in photoshop (sigh..)

spherical mapping

Basically it's just:

1) Rectangular to Polar

2) Polar to Rectangular

3) Flip Image / Rotate 180 degr.

4) Rectangular to Polar

5) Polar to Rectangular

Hi folks!

Currently I'm coding a GUI-frontend for the Noise Plugin, which i really like to share with you once it's finished. One cool feature I had in mind was to prepare (polar distort) a texture to be correctly mapped on a 3D sphere. My ingredients are a Image Manipulator to read the original pixels from the generated noise and an Array in 2:1 dimension to process the fancy math. Sadly, I can't figure out how to port the following code into construct. Maybe you can help me. <img src="smileys/smiley19.gif" border="0" align="middle">

This is what I've done so far:

<img src="http://dl.dropbox.com/u/6200498/loop.png" border="0">

This is the code I'm trying to translate:

for (j=0;j<image.height;j++) {
     theta = PI * (j - (image.height-1)/2.0) / (double)(image.height-1);
     for (i=0;i<image.width;i++) {
          phi  = TWOPI * (i - image.width/2.0) / (double)image.width;
          phi2 = phi * cos(theta);
          i2  = phi2 * image.width / TWOPI + image.width/2;
          if (i2 < 0 || i2 > image.width-1) {
              ?newpixel = red;                         /* Should not happen */
          } else {
              ?newpixel = imagein[j*image.width+i2];
          }
          imageout[j*image.width+i] = image.newpixel;
     }
}

hi there =D

my ideas for c2 would be flowless usability in the first place.

in detail:

• tab stops should function like one expects
• mass alt-tags as user guide or context sensitive help where it's reasonable
• node-based editing as an optional way of editing events/dependencies etc.

furthermore:

• some licence model that makes the community coders happy as well
• ... there might be more ideas in my head, but currently i'm too lazy to write them all down ;)