to PBC: Отличная работа!

РВС, супер, отличная работа.

На счёт Антарктики, как раз недавно НАСА представило неплохие карты по этому региону http://habrahabr.ru/post/182222/
Сами данные можно посмотреть здесь http://nsidc.org/data/icebridge/

Я переделываю утилиту CubeMap - давно пора её улучшить, чтобы она создавала тайлы в новом формате (доп. пиксели внутри, а не снаружи).

Dear Fridger,

OK, let's try to describe the 'rescaling.f' program.
First of all, mathematics.

The pixels of initial map are numbered by indices i0=1..m0, j0=1..n0; the pixels of target map are numbered by indices i=1..m, j=1..n, m0=2*n0, m=2*n Let's introduce geometrical coordinates x=0..m and y=0..n. Then the center of the pixel (i, j) have the coordinates (i-0.5, j-0.5), the center of the pixel (i0,j0) have the coordinates (m*(i0-0.5)/m0, n*(j0-0.5)/n0). The nearest to the pixel (i, j) of the target map is the pixel (round(m0*(i-0.5)/m+0.5), round((n0*(j-0.5)/n+0.5) of the initial map. The left border of the pixel (i, j) is the line x=x0=i-1, the right border is the line x=x1=i, the upper border is the line y=y0=j-1, the lower border is the line y=y1=j, the left border of pixel (i0,j0) is the line x=x00=m*(i0-1)/m0, and so on (see attached sketches). The area of the pixel (i, j) is equal to S=1*1=1. It can overlap up to 9 pixels of the initial map (they are numbered 1,2,...9), and no less that 4.
The elevation is scalar function of coordinates: h=h(x, y). I suppose that it is constant inside of each pixel of initial map. Then I attribute to the pixel (i, j) of the target map the mean value of elevation over it's area: h=integral(h(x, y)*dS)/S=integral(h(x, y)*dS)=h(i0-1, j0-1)*S1+h(i0, j0-1)*S2+h(i0+1, j0-1)*S3+h(i0-1, j0)*S4+h(i0, j0)*S5+..., where S1, S2,... are the areas of overlappings of pixels 1, 2, ... and (i, j). S1=(x00-min(x0,x00))*(y00-min(y0,y00)), and so on. Areas S2, S4, S6, S8 in my program are computed by a bit simplified formulas, which may lead to negative values, if the corresponding pixels are really not overlapped. But such items are rejected. The items with zero weight are rejected too, this is not really necessary, but, in principle, accelerate the program a bit, since one comparison is executed faster, that one floating multiplication and one floating addition. Of course, again, most time is spending on I/O indeed. Finally, the result is converted back to 16-bite integer (by rounding off!). That's all.
Now programming. If I could load the entire map into memory, I don't need anything other that a cycles by j and i. But I was forced to read initial data string-by-string (always having the line (j0-1) in h1, j0 in h2 and (j0+1) in h3) and loading the next string when required. The variable j00 hold the line number of initial file after the previous pass.

Speaking about the factor 1/65536 in 'nm16.cpp', I really don't understand its origin. The normal itself is a fully geometrical object, the gradient is unrelated to any rescaling and is to be computed in the given units of measurement (meters in this case) for the function (height) and coordinates. Only the result needs to be fitted into one-byte precision.

I will search for some possibility to clear my programs of non-standard extensions.

I attach also examples of (GLOBE-based) tiles, 32k, level5. This is Hawaii and a portion of Antarctica with shoreline, height exaggeration is 1.7. No this horrible artifacts you describe, isn't it?

As for 'cheap method' of tile optimization, I suggested only a test. Undoubtedly, for available to all implementation the specialized program is required. For ex., my 'normvirt' do such tile analyzes ;-).

With best regards, Robert

PS Если уж речь зашла о том, что пока не очень актуально, то все те же полярные льды с появлением воды нельзя будет рисовать на дне, для начала нужна еще одна маска, закрашиваемая рисунком льдов на участках непрозрачности. А в будущем она - с фрактальной границей на учасках частичной прозрачности и трехмерными торосами - вместе с трехмерными облаками! И к процедурным планетам это, разумеется, относится.

Я переделываю утилиту CubeMap...

Сразу скажу, что C++ знаю весьма паршиво, а в чужой программе разбираться вообще бывает всегда сложно, но я там посмотрел исходник в отношении одного интересующего меня аспекта - приведения размера текстуры к степени двойки. Насколько я понял, отвечающий за это блок просто берет среднее прилегающих к целевому пикселей исходной карты.

Владимир, если не очень сложно, добавь возможность создать текстуру участка поверхности,
то есть не всю сразу,а участка по заданным координатам, как, например, в Орбитере.
Чтобы добавлять участки высокого разрешения.

Не совсем. Для преобразования в кубическую текстуру используется билинейная интерполяция. При этом "привдение к степени двойки" делается в большую сторону - т.е. текстура 86400*43200 считается как бы текстурой 131072*65536. Билинейная интерполяция коррекстно "растягивает" текстуру, а уменьшение нигде не используется.

Для генерации же маленькой базовой текстуры (512*256) используется просто уменьшение в baseDownSize раз, усреднением пикселей в квадратах baseDownSize*baseDownSize пикселей. Т.е. утилита может уменьшать только в целое число раз. Финальное приведение к размеру 512*256 нужно делать в фотошопе или другом редакторе, сгенерировав текстур несколько большего размера (например 1080*540).

Ваш код, насколько я понял, разработан специально для насовских текстур разрешением 86400*43200, и приводит к степени двойки в меньшую сторону (65536*32768)?

Вообще код CubeMap такой страшный, что мне было даже стыдно его выкладывать:)

На счёт Антарктики, как раз недавно НАСА представило неплохие карты по этому региону http://habrahabr.ru/post/182222/

Взять текстуру цвета Земли, удалить с неё голубой океан, заменить на какой-то арт, изображающий дно. Можно с гораздо меньшим разрешением, чем остальная поверхность - детальные текстуры движок сгенерирует сам.

Что же, Duke, спасибо за наводку, но толку все равно не вышло. Прежде всего - то новое, о чем идет речь в видео - карта подледного рельефа, в котором сейчас нет необходимости. Что было бы полезно - хорошая маска береговой линии Антарктиды. Я попытался воспользоваться вот этим их продуктом, считая сушей все, высота чего больше 0. Результат и правда походит на искомую маску, но качество ее еще ниже, чем у содержащейся в BMNG. Так что текстура 'со льдом' и рельеф с батиметрией остаются такими, как есть сейчас.

Давайте обсудим, что точно требуется. Кстати, а Каспийское море тоже осушать?

Просто закрасить желто-коричневым наверое будет достаточно. Можно использовать карту высот, чтобы сделать вершины подводных хребтов более светлыми/желтыми например. Тогда при взгляде из космоса с отключенными облаками и водой получится наглядное представление рельефа дна.

Каспийское море вроде бы выше уровня моря? Если его осушить, 3D вода в SE его не покроет.

То же самое для озёр, рек и прочик внутренних водомов. По идее, к маске воды нужна ещё некая карта высот воды - задающея уровень поверхности воды в данном месте над уровнем моря.

Ещё смущает тот факт, что SRTM карта высот начинается не от нуля, а от -902 метров (или сколько там). Я так и не понял, с чем это связяно. То ли действительно где-то на Земле есть такой провал, не заполненный водой, то ли высоты в SRTM карте отсчитываются от поверхности эллипсоида, а не геоида.

Если без фанатизма, самое простое, что приходит в голову - сделать для планет с гидросферой возможными области с локально сдвинутым уровнем океана - круглые, задаваемые координатами центра и радиусом линейным или угловым - или прямоугольные, задаваемые коодинатами противолежащих углов, или еще как-нибудь. На Земле для Каспия в SolarSys.sc тогда надо будет добавить нечто вроде ключа

Что до рек и озер, глобальные данные об их глубинах вряд ли существуют. Фантазируя, можно представить себе нечто вроде использования значения альфа-слоя там, где рельеф выше уровня океана, в качестве глубины - тогда Амазонка в центре будет глубиной 255 см , ну или 510. Но никакой уверенности, что даже если это сделать, оно будет смотреться хорошо. Может просто рисовать некую 'жидкую пленку' без глубины? А степень заполнения ею - в зависимости от величины альфа.

А не проще ли тогда уж сделать карту высот сравнительно небольшого разрешения? Эфект тот же, преимущества в виде удобства очевидны.

Движок всё равно будет использовать текстуру.

Но если ее начать в лоб уменьшать, в пикселы у берегов станут подмешиваться значения из пикселов на суше, поверхность воды искривится вверх, и береговая линия может существенно сместиться.