English Новый сайт

Расширенный поиск

[ Новые сообщения · Пользователи · Правила ]
Страница 2 из 7«123467»
Форум » SpaceEngine » Моддинг и дополнения » Улучшенные текстуры Земли (в разработке)
Улучшенные текстуры Земли (в разработке)
SpaceEngineerДата: Пятница, 07.06.2013, 21:37 | Сообщение # 16
Автор Space Engine
Группа: Администраторы
Российская Федерация
Сообщений: 5542
Награды: 54
Статус: Offline
РВС, майл ру не даёт скачать, пишет вы исчерпали лимит. Может лучше гугл диск или яндекс диск?
Ладно, не важно, скачал.


oleg999Дата: Суббота, 08.06.2013, 00:39 | Сообщение # 17
Первооткрыватель
Группа: Пользователи
Российская Федерация
Сообщений: 424
Награды: 2
Статус: Offline
РВС, супер, отличная работа.
РВСДата: Суббота, 08.06.2013, 13:43 | Сообщение # 18
Нет аватара
Первооткрыватель
Группа: Команда SE
Российская Федерация
Сообщений: 330
Награды: 8
Статус: Offline
О, у меня уже собственная тема!
Цитата (Duke)
to PBC: Отличная работа!

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

Спасибо. smile Только вопрос: вы меня за описание сделанного хвалите, или кто-нибудь уже в SE протестировал карту? Я этого не делал, мой контроль качества сводился к прсмотру уменьшенной версии и куска, вырезанного из полной версии, в IrfanView.
Цитата (Duke)
На счёт Антарктики, как раз недавно НАСА представило неплохие карты по этому региону http://habrahabr.ru/post/182222/
Сами данные можно посмотреть здесь http://nsidc.org/data/icebridge/

Интересно, прямо сейчас у меня совсем нет времени, но может пригодиться. И не пришлось бы мне затем опять переделывать юг базовой текстуры! wacko smile
SpaceEngineerДата: Суббота, 08.06.2013, 14:32 | Сообщение # 19
Автор Space Engine
Группа: Администраторы
Российская Федерация
Сообщений: 5542
Награды: 54
Статус: Offline
Я переделываю утилиту CubeMap - давно пора её улучшить, чтобы она создавала тайлы в новом формате (доп. пиксели внутри, а не снаружи).

РВСДата: Воскресенье, 09.06.2013, 17:25 | Сообщение # 20
Нет аватара
Первооткрыватель
Группа: Команда SE
Российская Федерация
Сообщений: 330
Награды: 8
Статус: Offline
Здравствуйте.
Цитата (SpaceEngineer)
Я переделываю утилиту CubeMap - давно пора её улучшить, чтобы она создавала тайлы в новом формате (доп. пиксели внутри, а не снаружи).

Как раз по поводу утилиты.
Сразу скажу, что C++ знаю весьма паршиво, а в чужой программе разбираться вообще бывает всегда сложно, но я там посмотрел исходник в отношении одного интересующего меня аспекта - приведения размера текстуры к степени двойки. Насколько я понял, отвечающий за это блок просто берет среднее прилегающих к целевому пикселей исходной карты.
Я для Целестии занялся этим впервые еще в 2006. Написал прграммку (в тот момент - только для карты высот) и связался по почте с одним из разработчиков Целестии - t00fri (он же - герр Fridger Schrempp). Последовал примерно месяц переписки и совместной разработки, результатом которой стал вот этот набор утилит. 'Обвязка' там t00fri, но математика моя, и даже обозначения переменных остались моими. cool
Потом, когда первый вариант утилит был закончен и оставлен в надежных руках t00fri, на почти полгода все стихло. В конце концов я зарегистрировался на форуме Целестии и предложил всем желающим собственный вариант утилит (на Фортране). t00fri немедленно объявил, что более со мной не сотрудничает, утилиты выпустил, и далее совершенствовал самостоятельно. Тем не менее, в соавторах я там по прежнему значусь. smile
Мой метод изменения размера кажется более нигде в графических программах не используется (мне по крайней мере описания ничего подобного не встречалось), но все равно мне представляется совершенно корректным. Приведу просто свое письмо от июня 2006 с разъяснениями:
Цитата
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

Обсуждавшийся код (должен быть прозрачнее для понимания, чем текущая версия в утилитах на C++):
Код
      PROGRAM rescaling
C rescale down, less than two times
         IMPLICIT REAL*8 (A-H,O-Z)
         PARAMETER(N0=21600,N=16384)
         parameter(m0=n0*2,m=n*2,o=0.d0)
         integer*2 h1(m0),h2(m0),h3(m0),hi
         real*8 mr
c
         mr=dble(m)/dble(m0)
c
         OPEN(1,file='earth43200.raw',status='UNKNOWN',form='BINARY')
         OPEN(2,file='earth32768.raw',status='UNKNOWN',form='BINARY')
c
         read(1) (h2(i),i=1,m0)
         j00=1
         read(1) (h3(i),i=1,m0)
c
         do j=1,n
          j0=nint(n0*(j-0.5d0)/dble(n)+0.5d0)
          do k=j00+1,j0
           do i=1,m0
            h1(i)=h2(i)
            h2(i)=h3(i)
           enddo
           if(j0.lt.n0)then
            read(1) (h3(i),i=1,m0)
           endif
          enddo
          j00=j0
          y00=mr*(j0-1)
          y01=mr*j0
          y0=dble(j-1)
          y1=dble(j)
c
          do i=1,m
           i0=nint(m0*(i-0.5d0)/dble(m)+0.5d0)
           x00=mr*(i0-1)
           x01=mr*i0
           x0=dble(i-1)
           x1=dble(i)
c
           s1=(x00-min(x00,x0))*(y00-min(y0,y00))
           s2=(min(x01,x1)-max(x00,x0))*(y00-y0)
           s3=(max(x1,x01)-x01)*(y00-min(y0,y00))
           s4=(x00-x0)*(min(y1,y01)-max(y00,y0))
           s5=(min(x01,x1)-max(x00,x0))*(min(y1,y01)-max(y0,y00))
           s6=(x1-x01)*(min(y1,y01)-max(y0,y00))
           s7=(x00-min(x00,x0))*(max(y1,y01)-y01)
           s8=(min(x01,x1)-max(x00,x0))*(y1-y01)
           s9=(max(x01,x1)-x01)*(max(y1,y01)-y01)
c
           h=s5*h2(i0)
           if(s1.gt.o) h=h+s1*h1(i0-1)
           if(s2.gt.o) h=h+s2*h1(i0)
           if(s3.gt.o) h=h+s3*h1(i0+1)
           if(s4.gt.o) h=h+s4*h2(i0-1)
           if(s6.gt.o) h=h+s6*h2(i0+1)
           if(s7.gt.o) h=h+s7*h3(i0-1)
           if(s8.gt.o) h=h+s8*h3(i0)
           if(s9.gt.o) h=h+s9*h3(i0+1)
c
           hi=nint(h)
           write(2) hi
          enddo
         enddo
         close(2)
         close(1)
C
         END

Рисунки, о которых там шла речь в прикреплении.
Моя собственная текущая версия этого кода от 2008 тоже стала весьма непрозрачной, преобразует по этой же методике с произвольного размера к произвольному (первый вариант текстуры с пикселизированным льдом был получен именно ею - может и увеличивать, но лучше не надо biggrin ) и вряд ли представляет интерес. Я из перфекционизма ее использую для вещей типа 86400x43200-->256x128 вместо также изначально мною применявшегося последовательного уменьшения в 2 раза после первичного приведения к степени двойки - намнооого дольше, зато нет потери информации при промежуточных округлениях до целого. Хотя разница практически отсутствует.
В общем, смысл этого длинного послания - предложение подумать о включении всего описанного безобразия в код. Видимой разницы скорее всего тоже не будет. mellow
PS
Цитата (РВС)
PS Если уж речь зашла о том, что пока не очень актуально, то все те же полярные льды с появлением воды нельзя будет рисовать на дне, для начала нужна еще одна маска, закрашиваемая рисунком льдов на участках непрозрачности. А в будущем она - с фрактальной границей на учасках частичной прозрачности и трехмерными торосами - вместе с трехмерными облаками! И к процедурным планетам это, разумеется, относится.

Кстати, возвращаясь к этому.
Может, мысль тривиальна и очевидна, или наоборот глупа, но ведь не нужна еще одна маска! Достаточно считать, что там, где в маске - суша, а уровень рельефа ниже 0 - лед. Тогда на процедурных планетах можно генерировать рельеф без всякой оглядки на климат, затем в зонах отрицательных температур воду в маске заменять на сушу, в переходной области делать некую границу. И на поверхности воды рисовать текстуру льда. А когда придет время smile , перейти к трехмерному льду можно будет, не переделывая все вокруг из-за этого. И для Земли ничего придумывать не потребуется - маска со льдом уже есть.

Добавлено (09.06.2013, 17:25)
---------------------------------------------
Все время забываю об этом написать, а следует - вдруг по незнанию кто-нибудь время потратит зря. В srtm_ramp2.world.86400x43200.bin и gebco_bathy.21601x10801.bin данные big endian, в сделаном мной объединении - little endian. Учитывайте.
Прикрепления: 2101827.zip(29Kb)


Сообщение отредактировал РВС - Воскресенье, 09.06.2013, 17:26
KludДата: Понедельник, 10.06.2013, 02:55 | Сообщение # 21
Космический пилот
Группа: Пользователи
Российская Федерация
Сообщений: 117
Награды: 4
Статус: Offline
Цитата (SpaceEngineer)
Я переделываю утилиту CubeMap...


Hi !

Владимир, если не очень сложно, добавь возможность создать текстуру участка поверхности,
то есть не всю сразу,а участка по заданным координатам, как, например, в Орбитере.
Чтобы добавлять участки высокого разрешения.
SpaceEngineerДата: Понедельник, 10.06.2013, 19:36 | Сообщение # 22
Автор Space Engine
Группа: Администраторы
Российская Федерация
Сообщений: 5542
Награды: 54
Статус: Offline
Цитата (РВС)
Сразу скажу, что C++ знаю весьма паршиво, а в чужой программе разбираться вообще бывает всегда сложно, но я там посмотрел исходник в отношении одного интересующего меня аспекта - приведения размера текстуры к степени двойки. Насколько я понял, отвечающий за это блок просто берет среднее прилегающих к целевому пикселей исходной карты.


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

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

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

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

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

Да, это в планах. Сейчас такое тоже можно сделать, но для этого придётся создать полноразмерную текстуру и вставить в неё в фотошопе требуемый участок, что для больших разрешений неприемлемо.


РВСДата: Четверг, 13.06.2013, 18:22 | Сообщение # 23
Нет аватара
Первооткрыватель
Группа: Команда SE
Российская Федерация
Сообщений: 330
Награды: 8
Статус: Offline
Здравствуйте.
Цитата (SpaceEngineer)
Не совсем. Для преобразования в кубическую текстуру используется билинейная интерполяция. При этом "привдение к степени двойки" делается в большую сторону - т.е. текстура 86400*43200 считается как бы текстурой 131072*65536. Билинейная интерполяция коррекстно "растягивает" текстуру, а уменьшение нигде не используется.

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

Ага. Т.е. я не вполне разобрался в коде, для кубической текстуры все обстоит лучше. Но вот маленькую текстуру я тоже себе (из своей карты 'со льдами') сделал сам, думая, что просто не правильно что-то задал для утилиты, и проще на это не тратить усилий. В таком случае, для этой мелкой подзадачи мой алгоритм таки может иметь смысл. smile
Цитата (SpaceEngineer)
Ваш код, насколько я понял, разработан специально для насовских текстур разрешением 86400*43200, и приводит к степени двойки в меньшую сторону (65536*32768)?

Ну это был самый первый рабочий вариант кода от 2006 г., написанный под совершенно конкретные файлы. Я его привел, потому что он понятнее, и потому что у меня сохранилось (в письме) уже готовое его описание. С тех пор функциональность расширена (уменьшение корректным осреднением любых RAW-ов с отношением сторон 2:1 (тоже непринципиальное ограничение) к любому новому размеру), но для SE в ней нет необходимости.
Цитата (SpaceEngineer)
Вообще код CubeMap такой страшный, что мне было даже стыдно его выкладывать:)

Теоретически все такие утилиты нужны один раз в жизни, сделать текстуру и забыть про них, так что все их совершенство сводится к тому, работают ли они точно как задумано, а оптимальность, читаемость, переносимость и бог знает что еще - имеют только эстетическое значение для своего автора. smile На практике конечно приходится гонять их раз за разом. smile
Цитата (Duke)
На счёт Антарктики, как раз недавно НАСА представило неплохие карты по этому региону http://habrahabr.ru/post/182222/

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

SpaceEngineer, в качестве отправного пункта посмотрим на вот это. Здесь мы имеем заливку дна тем самым желто-серым цветом с нанесением затенения в соответсвии с подводным рельефом (преувеличеным так на пару порядков). Смотрится, по-моему, вполне неплохо. Но в затенении никакого реализма нет и в помине. biggrin Вообще, насколько я понимаю, дно океана практически сплошь покрыто илом, исключением являются только мелководья с кораллами и растительностью, которых по площади совсем не много. Дно перекрасить по маске технически совсем просто - хотя и тут можно опасаться проблем с береговыми линиями. Может этого будет достаточно? Если нет, можно добавить то же затенение и/или шум (не умею ни того, ни другого, но наверно научусь, особенно если тут посоветуют какие-нибудь источники smile ). Следующей Google предлагает картинку отсюда. Рисунки подвергать многократному увеличению малой кровью уже не выйдет. Давайте обсудим, что точно требуется. Кстати, а Каспийское море тоже осушать? smile
DukeДата: Четверг, 13.06.2013, 20:31 | Сообщение # 24
Нет аватара
Первооткрыватель
Группа: Команда SE
Антарктика
Сообщений: 419
Награды: 2
Статус: Offline
Цитата (РВС)
Что же, Duke, спасибо за наводку, но толку все равно не вышло. Прежде всего - то новое, о чем идет речь в видео - карта подледного рельефа, в котором сейчас нет необходимости. Что было бы полезно - хорошая маска береговой линии Антарктиды. Я попытался воспользоваться вот этим их продуктом, считая сушей все, высота чего больше 0. Результат и правда походит на искомую маску, но качество ее еще ниже, чем у содержащейся в BMNG. Так что текстура 'со льдом' и рельеф с батиметрией остаются такими, как есть сейчас.
Жаль. Судя по этому http://nsidc.org/icebridge/portal/ порталу по радарным снимкам карту побережья собрать наверно возможно, но это очень много работы. Кстати, фтп сервер с данными у них похоже этот ftp://n4ftl01u.ecs.nasa.gov/
P.S.: Вспомнил что относительно недавно видел ещё этот http://www.add.scar.org/home проект связанный с антарктикой. После бесплатной регистрации там можно скачать некоторые дополнительные данные.


Сообщение отредактировал Duke - Четверг, 13.06.2013, 20:51
SpaceEngineerДата: Пятница, 14.06.2013, 14:55 | Сообщение # 25
Автор Space Engine
Группа: Администраторы
Российская Федерация
Сообщений: 5542
Награды: 54
Статус: Offline
Цитата (РВС)
Давайте обсудим, что точно требуется. Кстати, а Каспийское море тоже осушать?


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

Каспийское море вроде бы выше уровня моря? Если его осушить, 3D вода в SE его не покроет. То же самое для озёр, рек и прочик внутренних водомов. По идее, к маске воды нужна ещё некая карта высот воды - задающея уровень поверхности воды в данном месте над уровнем моря.

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


РВСДата: Суббота, 15.06.2013, 06:02 | Сообщение # 26
Нет аватара
Первооткрыватель
Группа: Команда SE
Российская Федерация
Сообщений: 330
Награды: 8
Статус: Offline
Цитата (SpaceEngineer)
Просто закрасить желто-коричневым наверое будет достаточно. Можно использовать карту высот, чтобы сделать вершины подводных хребтов более светлыми/желтыми например. Тогда при взгляде из космоса с отключенными облаками и водой получится наглядное представление рельефа дна.

Так, ясно. Буду экспериментировать. smile А пока на всякий случай вот версия той же моей маски вод с реками севернее 60грд., но без льда. Можно использовать с немодифицированными текстурами BMNG, или с жидкой водой.
Цитата (SpaceEngineer)
Каспийское море вроде бы выше уровня моря? Если его осушить, 3D вода в SE его не покроет.

Каспийское море ниже уровня океана. Если Прикаспийскую низменность залить до уровня океана, Астрахань уйдет под воду, и астраханцы будут недовольны. biggrin А если залить по маске только само море, они будут недовольны нависающей над ними стеной воды. biggrin
Цитата (SpaceEngineer)
То же самое для озёр, рек и прочик внутренних водомов. По идее, к маске воды нужна ещё некая карта высот воды - задающея уровень поверхности воды в данном месте над уровнем моря.

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

Запрос в Гугль 'самые низкие участки земной поверхности' выдал симпатичную страничку. Карта высот воды - мне кажется, перебор. Если без фанатизма, самое простое, что приходит в голову - сделать для планет с гидросферой возможными области с локально сдвинутым уровнем океана - круглые, задаваемые координатами центра и радиусом линейным или угловым - или прямоугольные, задаваемые коодинатами противолежащих углов, или еще как-нибудь. На Земле для Каспия в SolarSys.sc тогда надо будет добавить нечто вроде ключа
Код
Local_sea_level ( 41.9 50.3 650. -27.16 ) // grd grd km m

и еще несколько подобных для других мест. А на процедурных планетах при помощи такого можно будет ваять объекты наподобие глубоченного кратера в сердце иссушенного материка, слегка затопленного на донышке biggrin , или наоборот высокогорных озер.
Что до рек и озер, глобальные данные об их глубинах вряд ли существуют. Фантазируя, можно представить себе нечто вроде использования значения альфа-слоя там, где рельеф выше уровня океана, в качестве глубины - тогда Амазонка в центре будет глубиной 255 см biggrin , ну или 510. Но никакой уверенности, что даже если это сделать, оно будет смотреться хорошо. Может просто рисовать некую 'жидкую пленку' без глубины? А степень заполнения ею - в зависимости от величины альфа.
SpaceEngineerДата: Суббота, 15.06.2013, 10:53 | Сообщение # 27
Автор Space Engine
Группа: Администраторы
Российская Федерация
Сообщений: 5542
Награды: 54
Статус: Offline
Цитата (РВС)
Если без фанатизма, самое простое, что приходит в голову - сделать для планет с гидросферой возможными области с локально сдвинутым уровнем океана - круглые, задаваемые координатами центра и радиусом линейным или угловым - или прямоугольные, задаваемые коодинатами противолежащих углов, или еще как-нибудь. На Земле для Каспия в SolarSys.sc тогда надо будет добавить нечто вроде ключа

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

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

Когда будет сделана 3D вода, сто процентов на форуме станут спрашивать, а почему на Земле реки и озёра не 3D. На процедурных планетах вся вода пока на одном уровне, но и там рано или поздно появятся реки и озёра.


РВСДата: Суббота, 15.06.2013, 15:14 | Сообщение # 28
Нет аватара
Первооткрыватель
Группа: Команда SE
Российская Федерация
Сообщений: 330
Награды: 8
Статус: Offline
Цитата (SpaceEngineer)
А не проще ли тогда уж сделать карту высот сравнительно небольшого разрешения? Эфект тот же, преимущества в виде удобства очевидны.

Если подойти с тем самым фанатизмом, против которого я выступал в прошлом сообщении, то srtm собственно и есть такая карта. Но если ее начать в лоб уменьшать, в пикселы у берегов станут подмешиваться значения из пикселов на суше, поверхность воды искривится вверх, и береговая линия может существенно сместиться. Наверно надо сделать специальный алгоритм уменьшения, где в качестве значения пиксела будет браться не усредненное значение накрытых им исходных пикселов, а минимальное. unsure Что же, задание в очередь. А у меня сейчас опять на работе завал.

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

Ну об этом я даже смутно догадываюсь. smile Чем еще GPU заниматься, как не текстуры перемалывать? smile
SpaceEngineerДата: Воскресенье, 16.06.2013, 13:19 | Сообщение # 29
Автор Space Engine
Группа: Администраторы
Российская Федерация
Сообщений: 5542
Награды: 54
Статус: Offline
Цитата (РВС)
Но если ее начать в лоб уменьшать, в пикселы у берегов станут подмешиваться значения из пикселов на суше, поверхность воды искривится вверх, и береговая линия может существенно сместиться.

Ну уменьшать её не надо значит. Генерировать реки, использую карту высот и маску воды. Генерировать поаерхность воды по маске, но если высота больше 0, делать какое-нибудь углубление в рельефе и генерировать поверхность воды по старому уровню карты высот. Может быть получится таким образом сделать речные русла и чаши озёр.


РВСДата: Понедельник, 17.06.2013, 23:52 | Сообщение # 30
Нет аватара
Первооткрыватель
Группа: Команда SE
Российская Федерация
Сообщений: 330
Награды: 8
Статус: Offline
Так мы пожалуй приходим к использованию немодифоцированной карты SRTM в качестве карты высот рельефа и водной поверхности, и карты GEBCO в ее исходном разрешении, но пересчитанной в связи с другой привязкой, в качестве карты высот дна. wacko Но мне кажется, можно без такого обойтись. Об этом ниже.
У меня пока ничего законченного, я потихоньку собирал разные файлы, которые должны понадобиться для Великого Осушения Океанов, и занимался всякими смежными вопросами. Побочные результаты:
1) В версии маски без льдов, выложенной на днях, я по недосмотру немного недоудалил имеющийся в исходнике артфакт, и в результате у берега Антарктиды там несуществующий островок (или скорее одинокая льдинка). Вот исправленная маска.
2) На карте SRTM значение -907 находится в точке с координатами 23,75 ю.ш., 70.48 з.д., в бухте у чилийского городка Antofagasta (я сперва по координатам посмотрел это место в Googe Earth, запомнил примерное положение и характерной формы мыс на севере). В Celestia там при соответствующем освещении виден блик, а в SE имеется ямка в водной поверхности размером в один пиксель. Если эту точку исключить, то наинизшей поверхностью, как и должно быть, становится уровень Мертвого моря -434. Но более внимательная инспекция показала, что цепочки пикселей с отрицательными значениями в SRTM нередко (хотя отнюдь не повсеместно) встречаются вдоль береговых линий. Это грозит еще усугубить сложности там при создании 'осушенной' карты, и дополнительно затрудняет создание карты уровней поверхости. Но поживем-увидим.
3) Странность в антарктических водах для SRTM, о которой я уже упоминал, когда описывл изготовление гибрида SRTM и GEBCO. В некотором секторе по долготе у водной поверхности положительная высота. Это можно увидеть, даже просто открыв Bump\neg_y\1_1_1.png в IrfanView и задав гамма-коррекцию 1,44. Вызывает подозрение, что высоты здесь действительно отсчитаны от эллипсоида, а не геоида, но отсутствует область с отрицательными высотами, которая должна была бы быть. В общем, мне кажется, можно просто (в случаях, когда это вообще имеет значение) здесь задавать нулевую высоту по маске, как я и делал, когда получал гибрид.


Сообщение отредактировал РВС - Вторник, 18.06.2013, 00:04
Форум » SpaceEngine » Моддинг и дополнения » Улучшенные текстуры Земли (в разработке)
Страница 2 из 7«123467»
Поиск:

>