А что вам мешает подложить в SBuilder спутниковый снимок и чётко по линии границ отрисовать флаттен? Или ватерполигон с высотой -28 (он сам и будет флаттеном работать.).
А файлик дефолтный Вы ничем не откроете, как вариант — сделать свой меш с таким-же именем и заменить дефолт.
А я уже придумал решение… Неее Со спутникового снимка не получилось бы… Потому, что границы и контур побережья дефолта с реальным спутниковым снимком совершенно не совпадут… Мне нужно было гнать воду именно по линии границ дефолтного берега. Я же не собираюсь делать сцену 1000х1000 км.. И лишь в определённом месте провести её по контуру берега фототеррайна…
Кстати файлик этот ххххх.bgl — я нашёл… Открыть то его можно без проблем TMfViewer-ом Но, только чисто открыть… Что я и сделал для начала. Редактированию не подлежит. Вы совершенно правы… Таким образом открыв его и поскринив собрал пазлы из этих скринов в фотошопе..) Затем сохранив эту картинку загрузил её бэккграундом в SB… Калибровал по координатам подсмотренным из того же TMfViewer-а… Приаппендил к этому делу свой фототеррайн… И вот, что получилось…
Spoiler
Конечно же, таким образом, невозможно соблюсти абсолютную математическую точность по координатам сетки Земля то круглая.. И FSX, в отличии от своего предшественника — это знает… Но так, ведь .., прям уж вот.., математическая нам то и не нужна..) Тем более, что чёткий берег по линии фототеррайна будет «рисоваться» в фотошопе цветом…
Теперь останется только нарисовать, максимально приближенно свою воду и всё остальное по этим контурам… И сохранив этот файл под тем же названием , заменить дефолт… Подробный анализ показал, что этот файл содержит в себе всё, что касается моего полуострова по периметру сетки LOD 5… Все дефолтные линии, все дефолтные водоёмы, и даже флаттен самого порта… Собрав всё это, «как было», но уже по нужным мне траекториям и альтитудам, смею предположить, что заменю им дефолтный хххх.bgl всего этого LOD-а На мой взгляд -это, более-менее грамотный выход из положения.. Конечно же не самый грамотный. Заменять дефолт- не есть хорошо… Но, покуда разработчики Х-а нас ограничили в возможностях, придётся менять… Лучшего варианта решения вопроса я не нашёл ни в SDK, ни на форумах…
Marlboro
24.01.2016 в 10:02
И не могу отказать себе в удовольствии похвастаться результатом…
Вот какими бывают берега…. Не вровень с водой по высоте. ,,,а, покатые…
Spoiler
Beckar
24.01.2016 в 12:13
Неее Со спутникового снимка не получилось бы… Потому, что границы и контур побережья дефолта с реальным спутниковым снимком совершенно не совпадут…
Зато с ORBX Vector совершенно точно совпадут, и те у кого он установлен ( очень у многих) будут раздосадованы дефолтным нереалом и станут кидать тапки в разработчика.
Marlboro
24.01.2016 в 12:22
Зато с ORBX Vector совершенно точно совпадут
Хорошо.. Я приобрету его.. Надеюсь там Каспий корректен…
Но суть проблемы не в очертаниях побережья Каспия. Речь шла о превышении водной поверхности конкретного «моря»… У этого аддона и высота морей корректная?
Beckar
24.01.2016 в 12:38
Вектор, это береговые линии, реки, дороги. Высота Каспия будет зависеть от установленного меша.
Marlboro
24.01.2016 в 12:59
Вектор, это береговые линии, реки, дороги. Высота Каспия будет зависеть от установленного меша.
Сдаётся мне, что Вы,,, что то путаете…
Разве мэш может как то изменить высоту симовсих водоёмов?!
Мэш «работает» только на земной поверхности сима… А высота водоёмов, при этом так и останется неизменной, пока не изменить её самому… При этом альтитуда моих кастомных водоёмов берётся из данных карт генштаба.. То есть из реальных данных
И потом…. По поводу вектора….
Он в силах перекрыть даже фототеррайн???
Если кому то, из пользователей ORBX захочется побродить пешком по побережью каспия, и на расстоянии 200-300 км от моего порта вдруг обнаружить, что там линия берега не совсем совпадает с векторными данными его ORBX… ….мне будет очень жаль его разочарований… Вообще то сим для полётов, а не дотошных исследований геоданных
P.S. В конце концов я дублировал дефолтные побережья, и подстровишись под все аддоны угодить всем — просто нереально. Согласитесь
Marlboro
06.02.2016 в 14:13
…ПРОДОЛЖЕНИЕ.
восемь текстур (количество зависит от погодных условий в данном регионе;
А Вам ничего не известно об ограничениях Resamle?
Например, по общему суммарному весу всех фалов источников..?
Скажем, у меня карты не маленькие. И, все сезоны компилировать отказывается… По одной, с назначением конкретных месяцев, — без проблем… Не хотелось бы для каждого сезона компилировать отдельную бгл… Ещё большой вопрос, как они потом между собой будут уживаться (в смысле сменяться)
P.S. Оговорюсь сразу, предвидя вопрос… Компилирую «натравливанием» инф файла на resample Не в SBuilder…
ANRI
06.02.2016 в 14:19
А Вам ничего не известно об ограничениях Resamle?
Например, по общему суммарному весу всех фалов источников..?
Скажем, у меня карты не маленькие. И, все сезоны компилировать отказывается… По одной, с назначением конкретных месяцев, — без проблем… Не хотелось бы для каждого сезона компилировать отдельную бгл… Ещё большой вопрос, как они потом между собой будут уживаться (в смысле сменяться)
P.S. Оговорюсь сразу, предвидя вопрос… Компилирую «натравливанием» инф файла на resample Не в SBuilder…
Маленькие карты со всеми сезонами — а-ля много фототерров, покрывающих весь регион.
Marlboro
06.02.2016 в 14:39
Маленькие карты со всеми сезонами — а-ля много фототерров, покрывающих весь регион.
Андрей… Я думал об этом. Но есть проблема. В симе (в FSX) эти карты между собой плохо стыкуются. Довольно заметная разделительная полоса стыковки. Как будто есть некоторая прозрачность на крайних пикселах…
Хотя обрезаю в фотошопе без галочки сглаживания при кадрировании
Marlboro
06.02.2016 в 14:57
Маленькие карты
Прошу прощения.. Всё тянет Resample… (но памяти жрёт )..Виной всему — моя невнимательность…
Я нарушил регистр… October писал через «k»
ANRI
06.02.2016 в 15:11
Андрей… Я думал об этом. Но есть проблема. В симе (в FSX) эти карты между собой плохо стыкуются. Довольно заметная разделительная полоса стыковки. Как будто есть некоторая прозрачность на крайних пикселах…
Хотя обрезаю в фотошопе без галочки сглаживания при кадрировании
Обрезанные соседние карты должны стыковаться с перехлестом в один пиксел. Т.е. у них на стыке ряд пикселов дублируется на обоих картах.
В 9-ке, карты стыкуются без перехлеста, у них четко 256 пикселов в лоде, но просветы появляются на следующем мипмапе, что микрософтовцы решили исправить в следующей версии…
В 10-ке, карты по 255 пикселов натягиваются на лод, им не хватает одного ряда пикселов на границах карт, потому и «некоторая прозрачность»…
Экспериментируй и смотри результаты не в симе, а в TMF (прилагается к SDK).
Создав карту (просто двухцветную, в виде шахматной доски), скомпилировав бглку фототерра и открыв её в просмотре,
скриншотишь, открываешь в Photoshop, с внимательно сравниваешь изменения RGB по всему полю с RGB заданных в исходной карте-шахматке.
В идеале, любая точка скомпилированной карты не должна потерять свой RGB.
У меня это получалось… Собственно, именно так и открыл 255 pxl/lod…
Marlboro
06.02.2016 в 15:52
В идеале, любая точка скомпилированной карты не должна потерять свой RGB.
Так, всё таки есть в 10-ке правило для обрезки карт чётко по границам сетки лод?
И что это за лод..? В девятке по Lod 8
И, почему у меня карты потеряли RGB по правому краю?! Блэнд маска — абсолютно чёрная! «000000» В идеале — там вообще ничего не должно быть. С левым краем — всё понятно… Это я сам так назначил… Хотя… И тут не понятно, почему не 100% -ная прозрачность… Правда в симе этого нет. Это TmfViewer так показал
А на правой границе подразумевалась абсолютная линейная прозрачность.Но она — не абсолюная Тебе известен ответ?
Spoiler
Marlboro
06.02.2016 в 16:48
В общем тут тоже всё нарезается по сетке Lod 13
Вопрос только…… Критично ли их обрезать специально?
В SDK не нашёл упоминания об этом…
Spoiler
ANRI
07.02.2016 в 14:34
Так, всё таки есть в 10-ке правило для обрезки карт чётко по границам сетки лод?
И что это за лод..? В девятке по Lod 8
В 10-ке — LOD21
В 9-ке — LOD15
Вопрос только…… Критично ли их обрезать специально?
увидишь на асфальте мой логин — вот он достойный результат компилирования карты с помощь таблицы без потери качества и четкости в разрешении 0,14 m/pxl, а можно и в два раза лучше.
увидишь на асфальте мой логин — вот он достойный результат компилирования карты с помощь таблицы без потери качества и четкости в разрешении 0,14 m/pxl, а можно и в два раза лучше.
Андрей… Ну, без таблицы итак никуда… Честно,говоря, я даже не знаю вот, как там без этой таблицы что то рассчитывать. И качал всё строго по этой таблице, и обрезал, масштабировал….Всё по ней…Правда я пользовался предыдущей версией данной таблицы. Там были твои рассчёты для FS2004 с зумом 17, и для FSX с зумом 19
Конечно. С удовольствием бы сейчас воспользовался новой таблицей с новыми рассчётами. Проблема только в том, что максимальный зум нужных мне космоснимково — 19 Да и качества такого у них никогда не было и не будет…
А уж 22…. Я думаю нам на нашем материке такое счастье никогда не улыбнётся..)
У меня теперь вопрос закрался, в связи с твоим пояснением…
Я, откалибровав карту по твоей таблице, — был вынужден «подвигать» её маленько, чтобы привести точнее к реальным координатам.. (ориентируясь на реальные коодинаты объектов, точек в Google Earth)
Одним словом,в итоге у меня координаты калибровки карт сильно изменились, относительно тем, что рассчитывала таблица. Сохранены только пропорции карт, ну и их фотошоповские размеры
Вопрос в следующем. Нельзя было этого делать?
Marlboro
07.02.2016 в 15:52
Ну, и, собственно, о качестве…
Spoiler
На втором скрине: — слева фотоподложка, справа фототеррайн
ANRI
08.02.2016 в 05:29
Я, откалибровав карту по твоей таблице, — был вынужден «подвигать» её маленько, чтобы привести точнее к реальным координатам.. (ориентируясь на реальные коодинаты объектов, точек в Google Earth)
Одним словом,в итоге у меня координаты калибровки карт сильно изменились, относительно тем, что рассчитывала таблица. Сохранены только пропорции карт, ну и их фотошоповские размеры
Вопрос в следующем. Нельзя было этого делать?
Чтобы не ошибиться, лучше сначала масштабировать и обрезать карту (сохранив исходник),
потом скомпилировать и закинув в сим, уточнить необходимый сдвиг карты в нужных направлениях В ПИКСЕЛЯХ уже обработанный карты.
Возвращаемся к исходнику, масштабируем, ставим направляющие для обрезки с учетом сдвига в пикселях, обрезаем.
michael21
08.02.2016 в 09:19
Добрый день всем!
Извиняюсь за оффтоп, но нужна ваша помощь.
Скиньте пожалуйста кто нибуть сылочку на инструкцию по SDK.
У меня просто нету FSX и не могу установить SDK чтоб взять оттуда.
А в SDK от Prepar3D, не вижу такой инструкций.
Может и есть где-то на форуме сылочка, но я не мог найти.
Заранее спасибо. И за понимание тоже. )))
Marlboro
08.02.2016 в 13:17
Чтобы не ошибиться, лучше сначала масштабировать и обрезать карту (сохранив исходник),
потом скомпилировать и закинув в сим, уточнить необходимый сдвиг карты в нужных направлениях В ПИКСЕЛЯХ уже обработанный карты.
Возвращаемся к исходнику, масштабируем, ставим направляющие для обрезки с учетом сдвига в пикселях, обрезаем.
Точно! Андрей… Вспомнил Именно так я и поступил Я долго думал, и, в итоге, решил двигать её не по координатам а в фотошопе её клонированный слой относительно основного. Именно таким вот образом. В итоге и координаты «табличные» и пропорции. Изменилась лишь информация самого изображения.
Меня спутал мой недавний опыт сдвигания фотоподоложки, а не фототеррайна… Это я координаты рефпонита фотоподложки так подгонял … Прошу прощения.. Устаю, голова не работает)
Marlboro
09.02.2016 в 12:25
Желаешь качество — применяй таблицу
,,,без потери качества и четкости…
Не смог таки я отказать себе в любопытстве, и попробовать использовать новую формулу, Андрей, и вот, что думаю…
Скажем для очень больших фототеррайнов, компилировать 0,30 м/пкс, и, даже 0,59 м/пкс — удовольствие слишком «дорогое», и, не совсем рациональное. Да.. Качество фототеррайна выигрывает кратно у фототеррайна, компилированного по старой таблице 1,19 м/пкс…
Но вес….! Скажем, по моей территории 0,59 м/пкс один только фототеррайн с сезонами получился бы в 3-4 Gb… Может и больше. Не могу знать, так, как пришлось бы нарезать карту на фрагменты в пределах 30 Gb каждый, чтобы сохранить её в расширении ***.BMP Не стал я этого делать, по вышеописанной причине.
Но… При этом… Попробовал 0,30 м/пкс, полагая, что могу скомпилировать фототеррайн, вместо фотоподложки… То есть на маленькой территории, исключительно самого порта
А тут, вдобавок к излишнему весу (примерно на 1 GB со всеми сезонами), фототеррайн очень сильно проигрывает по качеству фотоподлоджке..
Очень сильно…
Вот скрины….
Spoiler
При этом… Прошу обратить твоё особое внимание, что,,,,
Карту порта для фотоподложки я скачивал в зуме 20, и затем, уменьшил её размер ровно на 50 %…
А для фототеррайна 0.30 м/пкс она , так же была скачана в зуме 20, но уменьшена по значениям таблицы (думаю, это , не больше, чем 25%)
P.S. В ***inf файле расстояния между пикселями ( xDim.., yDim ) вводил то, что сформулировала таблица…
Качество компрессии (CompressionQuality) — 100…
Думаю оставить всё по старинке…. Т.е (1,19 м/пкс) Потому, как, даже и при таком раскладе, один только фототеррайн у меня будет весить не меньше 700 — 800 МВ
michael21
09.02.2016 в 12:31
фототеррайн очень сильно проигрывает по качеству фотоподлоджке
А скажите пожалуйста какая между ними разница?
ANRI
09.02.2016 в 12:37
Алик, только не забывай назначение подложки и фототерра — у них разные задачи.
Даже на подложке в зависимости от удаления от тебя можно «играть» разрешением.
А уж на фототерре и подавно. Не нужно всё грести под одну гребенку, играй…
Marlboro
09.02.2016 в 12:40
А скажите пожалуйста какая между ними разница?
А Вы правильно выделили контекст с ответом
Marlboro
09.02.2016 в 12:48
Алик, только не забывай назначение подложки и фототерра — у них разные задачи.
Даже на подложке в зависимости от удаления от тебя можно «играть» разрешением.
А уж на фототерре и подавно. Не нужно всё грести под одну гребенку, играй…
На самом деле, меня, в основном, сильно обеспокоил тот факт, что я, скомпилировав фототеррайн используя твою старую таблицу, сыграл против себя, проиграв в качестве.
Есть такое. Несомненно. Но не настолько сильно, Андрей. Потому, как конечный общий вес будущего продукта — отнюдь немаловажная деталь. В конце концов для обзора с высоты глиссады — 1,19 м/пкс — вполне приемлемая картина. Во всяком случае в девятке мы о таком даже и не мечтали, согласись
Склоняюсь оставить как есть…
Marlboro
09.02.2016 в 12:59
To Anri,,,
Хотел попросить тебя, как нить на досуге, поразмыслить над формулой значений пиксельных расстояний в градусах. Мне вот кажется, что «собака порыта» именно там.
Возможно, эти значения должны бы быть иными. Может — поменьше. Может — наоборот… Скорее — поменьше Лично мне — на поиски ответов на этот вопрос не хватит ни знаний, ни опыта. Я понятия не имею, как их формировать. Тебе — это известно несомненно…
А я уже придумал решение… Неее Со спутникового снимка не получилось бы… Потому, что границы и контур побережья дефолта с реальным спутниковым снимком совершенно не совпадут… Мне нужно было гнать воду именно по линии границ дефолтного берега. Я же не собираюсь делать сцену 1000х1000 км..
И лишь в определённом месте провести её по контуру берега фототеррайна…
Кстати файлик этот ххххх.bgl — я нашёл… Открыть то его можно без проблем TMfViewer-ом Но, только чисто открыть… Что я и сделал для начала. Редактированию не подлежит. Вы совершенно правы… Таким образом открыв его и поскринив собрал пазлы из этих скринов в фотошопе..) Затем сохранив эту картинку загрузил её бэккграундом в SB… Калибровал по координатам подсмотренным из того же TMfViewer-а… Приаппендил к этому делу свой фототеррайн… И вот, что получилось…
Конечно же, таким образом, невозможно соблюсти абсолютную математическую точность по координатам сетки Земля то круглая.. И FSX, в отличии от своего предшественника — это знает…
Но так, ведь .., прям уж вот.., математическая нам то и не нужна..) Тем более, что чёткий берег по линии фототеррайна будет «рисоваться» в фотошопе цветом…
Теперь останется только нарисовать, максимально приближенно свою воду и всё остальное по этим контурам… И сохранив этот файл под тем же названием , заменить дефолт… Подробный анализ показал, что этот файл содержит в себе всё, что касается моего полуострова по периметру сетки LOD 5… Все дефолтные линии, все дефолтные водоёмы, и даже флаттен самого порта… Собрав всё это, «как было», но уже по нужным мне траекториям и альтитудам, смею предположить, что заменю им дефолтный хххх.bgl всего этого LOD-а На мой взгляд -это, более-менее грамотный выход из положения.. Конечно же не самый грамотный. Заменять дефолт- не есть хорошо… Но, покуда разработчики Х-а нас ограничили в возможностях, придётся менять… Лучшего варианта решения вопроса я не нашёл ни в SDK, ни на форумах…
И не могу отказать себе в удовольствии похвастаться результатом…
Вот какими бывают берега…. Не вровень с водой по высоте. ,,,а, покатые…
Зато с ORBX Vector совершенно точно совпадут, и те у кого он установлен ( очень у многих) будут раздосадованы дефолтным нереалом и станут кидать тапки в разработчика.
Хорошо.. Я приобрету его.. Надеюсь там Каспий корректен…
Но суть проблемы не в очертаниях побережья Каспия. Речь шла о превышении водной поверхности конкретного «моря»… У этого аддона и высота морей корректная?
Вектор, это береговые линии, реки, дороги. Высота Каспия будет зависеть от установленного меша.
Сдаётся мне, что Вы,,, что то путаете…
Разве мэш может как то изменить высоту симовсих водоёмов?!
Мэш «работает» только на земной поверхности сима… А высота водоёмов, при этом так и останется неизменной, пока не изменить её самому… При этом альтитуда моих кастомных водоёмов берётся из данных карт генштаба.. То есть из реальных данных
И потом…. По поводу вектора….
Он в силах перекрыть даже фототеррайн???
Если кому то, из пользователей ORBX захочется побродить пешком по побережью каспия, и на расстоянии 200-300 км от моего порта вдруг обнаружить, что там линия берега не совсем совпадает с векторными данными его ORBX… ….мне будет очень жаль его разочарований… Вообще то сим для полётов, а не дотошных исследований геоданных
P.S. В конце концов я дублировал дефолтные побережья, и подстровишись под все аддоны угодить всем — просто нереально. Согласитесь
А Вам ничего не известно об ограничениях Resamle?
Например, по общему суммарному весу всех фалов источников..?
Скажем, у меня карты не маленькие. И, все сезоны компилировать отказывается… По одной, с назначением конкретных месяцев, — без проблем… Не хотелось бы для каждого сезона компилировать отдельную бгл… Ещё большой вопрос, как они потом между собой будут уживаться (в смысле сменяться)
P.S. Оговорюсь сразу, предвидя вопрос… Компилирую «натравливанием» инф файла на resample Не в SBuilder…
Маленькие карты со всеми сезонами — а-ля много фототерров, покрывающих весь регион.
Андрей… Я думал об этом. Но есть проблема. В симе (в FSX) эти карты между собой плохо стыкуются. Довольно заметная разделительная полоса стыковки. Как будто есть некоторая прозрачность на крайних пикселах…
Хотя обрезаю в фотошопе без галочки сглаживания при кадрировании
Прошу прощения.. Всё тянет Resample… (но памяти жрёт
)..Виной всему — моя невнимательность…
Я нарушил регистр… October писал через «k»
Обрезанные соседние карты должны стыковаться с перехлестом в один пиксел. Т.е. у них на стыке ряд пикселов дублируется на обоих картах.
В 9-ке, карты стыкуются без перехлеста, у них четко 256 пикселов в лоде, но просветы появляются на следующем мипмапе, что микрософтовцы решили исправить в следующей версии…
В 10-ке, карты по 255 пикселов натягиваются на лод, им не хватает одного ряда пикселов на границах карт, потому и «некоторая прозрачность»…
Экспериментируй и смотри результаты не в симе, а в TMF (прилагается к SDK).
Создав карту (просто двухцветную, в виде шахматной доски), скомпилировав бглку фототерра и открыв её в просмотре,
скриншотишь, открываешь в Photoshop, с внимательно сравниваешь изменения RGB по всему полю с RGB заданных в исходной карте-шахматке.
В идеале, любая точка скомпилированной карты не должна потерять свой RGB.
У меня это получалось… Собственно, именно так и открыл 255 pxl/lod…
Так, всё таки есть в 10-ке правило для обрезки карт чётко по границам сетки лод?
И что это за лод..? В девятке по Lod 8
И, почему у меня карты потеряли RGB по правому краю?! Блэнд маска — абсолютно чёрная! «000000» В идеале — там вообще ничего не должно быть. С левым краем — всё понятно… Это я сам так назначил… Хотя… И тут не понятно, почему не 100% -ная прозрачность… Правда в симе этого нет. Это TmfViewer так показал
А на правой границе подразумевалась абсолютная линейная прозрачность.Но она — не абсолюная Тебе известен ответ?
В общем тут тоже всё нарезается по сетке Lod 13
Вопрос только…… Критично ли их обрезать специально?
В SDK не нашёл упоминания об этом…
В 10-ке — LOD21
В 9-ке — LOD15
Не критично, для дилетантов…
Желаешь качество — применяй таблицу http://www.avsim.su/…ayna-49716.html
По этой сслылке http://www.avsim.su/…c00ef3a3b35.bmp
увидишь на асфальте мой логин — вот он достойный результат компилирования карты с помощь таблицы без потери качества и четкости в разрешении 0,14 m/pxl, а можно и в два раза лучше.
Андрей… Ну, без таблицы итак никуда… Честно,говоря, я даже не знаю вот, как там без этой таблицы что то рассчитывать. И качал всё строго по этой таблице, и обрезал, масштабировал….Всё по ней…Правда я пользовался предыдущей версией данной таблицы. Там были твои рассчёты для FS2004 с зумом 17, и для FSX с зумом 19
Я думаю нам на нашем материке такое счастье никогда не улыбнётся..)
Конечно. С удовольствием бы сейчас воспользовался новой таблицей с новыми рассчётами. Проблема только в том, что максимальный зум нужных мне космоснимково — 19 Да и качества такого у них никогда не было и не будет…
А уж 22….
У меня теперь вопрос закрался, в связи с твоим пояснением…
Я, откалибровав карту по твоей таблице, — был вынужден «подвигать» её маленько, чтобы привести точнее к реальным координатам.. (ориентируясь на реальные коодинаты объектов, точек в Google Earth)
Одним словом,в итоге у меня координаты калибровки карт сильно изменились, относительно тем, что рассчитывала таблица. Сохранены только пропорции карт, ну и их фотошоповские размеры
Вопрос в следующем. Нельзя было этого делать?
Ну, и, собственно, о качестве…
На втором скрине: — слева фотоподложка, справа фототеррайн
Чтобы не ошибиться, лучше сначала масштабировать и обрезать карту (сохранив исходник),
потом скомпилировать и закинув в сим, уточнить необходимый сдвиг карты в нужных направлениях В ПИКСЕЛЯХ уже обработанный карты.
Возвращаемся к исходнику, масштабируем, ставим направляющие для обрезки с учетом сдвига в пикселях, обрезаем.
Добрый день всем!
Извиняюсь за оффтоп, но нужна ваша помощь.
Скиньте пожалуйста кто нибуть сылочку на инструкцию по SDK.
У меня просто нету FSX и не могу установить SDK чтоб взять оттуда.
А в SDK от Prepar3D, не вижу такой инструкций.
Может и есть где-то на форуме сылочка, но я не мог найти.
Заранее спасибо. И за понимание тоже. )))
Точно! Андрей… Вспомнил Именно так я и поступил Я долго думал, и, в итоге, решил двигать её не по координатам а в фотошопе её клонированный слой относительно основного. Именно таким вот образом. В итоге и координаты «табличные» и пропорции. Изменилась лишь информация самого изображения.
Меня спутал мой недавний опыт сдвигания фотоподоложки, а не фототеррайна… Это я координаты рефпонита фотоподложки так подгонял … Прошу прощения.. Устаю, голова не работает)
Не смог таки я отказать себе в любопытстве, и попробовать использовать новую формулу, Андрей, и вот, что думаю…
Скажем для очень больших фототеррайнов, компилировать 0,30 м/пкс, и, даже 0,59 м/пкс — удовольствие слишком «дорогое», и, не совсем рациональное. Да.. Качество фототеррайна выигрывает кратно у фототеррайна, компилированного по старой таблице 1,19 м/пкс…
Но вес….! Скажем, по моей территории 0,59 м/пкс один только фототеррайн с сезонами получился бы в 3-4 Gb… Может и больше. Не могу знать, так, как пришлось бы нарезать карту на фрагменты в пределах 30 Gb каждый, чтобы сохранить её в расширении ***.BMP Не стал я этого делать, по вышеописанной причине.
Но… При этом… Попробовал 0,30 м/пкс, полагая, что могу скомпилировать фототеррайн, вместо фотоподложки… То есть на маленькой территории, исключительно самого порта
А тут, вдобавок к излишнему весу (примерно на 1 GB со всеми сезонами), фототеррайн очень сильно проигрывает по качеству фотоподлоджке..
Очень сильно…
Вот скрины….
При этом… Прошу обратить твоё особое внимание, что,,,,
Карту порта для фотоподложки я скачивал в зуме 20, и затем, уменьшил её размер ровно на 50 %…
А для фототеррайна 0.30 м/пкс она , так же была скачана в зуме 20, но уменьшена по значениям таблицы (думаю, это , не больше, чем 25%)
P.S. В ***inf файле расстояния между пикселями ( xDim.., yDim ) вводил то, что сформулировала таблица…
Качество компрессии (CompressionQuality) — 100…
Думаю оставить всё по старинке…. Т.е (1,19 м/пкс) Потому, как, даже и при таком раскладе, один только фототеррайн у меня будет весить не меньше 700 — 800 МВ
А скажите пожалуйста какая между ними разница?
Алик, только не забывай назначение подложки и фототерра — у них разные задачи.
Даже на подложке в зависимости от удаления от тебя можно «играть» разрешением.
А уж на фототерре и подавно. Не нужно всё грести под одну гребенку, играй…
А Вы правильно выделили контекст с ответом
На самом деле, меня, в основном, сильно обеспокоил тот факт, что я, скомпилировав фототеррайн используя твою старую таблицу, сыграл против себя, проиграв в качестве.
Есть такое. Несомненно. Но не настолько сильно, Андрей. Потому, как конечный общий вес будущего продукта — отнюдь немаловажная деталь. В конце концов для обзора с высоты глиссады — 1,19 м/пкс — вполне приемлемая картина. Во всяком случае в девятке мы о таком даже и не мечтали, согласись
Склоняюсь оставить как есть…
To Anri,,,
Хотел попросить тебя, как нить на досуге, поразмыслить над формулой значений пиксельных расстояний в градусах. Мне вот кажется, что «собака порыта» именно там.
Возможно, эти значения должны бы быть иными. Может — поменьше. Может — наоборот… Скорее — поменьше Лично мне — на поиски ответов на этот вопрос не хватит ни знаний, ни опыта. Я понятия не имею, как их формировать. Тебе — это известно несомненно…