Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

множество изображений и алгоритм их отрисовки и выгрузки из памяти.

289
23 ноября 2011 года
Jeyson
207 / / 20.04.2000
Здравствуйте. Продолжаю тему подложки. Повторюсь, что нужно натянуть карту города на прямоугольник и показать ее в качестве фонового изображения (текстура см. уроки от NeHe). Думаю пойти следующим образом:
1. Картинка режется на множество файлов 256х256.
2. Только видимые на экране картинки отрисовываются на своем прямоугольнике.
3. Те что скрываются за экран должны выгружаться из памяти.

Не могу сообразить как это реализовать. Координаты окна есть. Выгрузка и подгрузка изображений должна происходить при зумировании и при панарамировании. Никакого 3D нет. Вид только сверху. При мелком масштабе картинка вообще видна не будет, поскольку будет порядка 25000 таких картинок, и памяти просто не хватит.

Подскажите с алгоритмом, мож даже кто это реализовывал. Туплю уже неделю...
Спасибо.
277
23 ноября 2011 года
arrjj
1.7K / / 26.01.2011
Ну иногда делают несколько текстур разного качества и в зависимости от масштаба биндят и отрисовывают соответствующие.
(например при максимальном увеличении достаточно карту города размером (ну не знаю например) 2048x2048 на подложку выводить. При минимальном зуме не только отрисовывать видимые но и соседние текстуры в памяти хранить. в OpenGl есть например glDeleteTextures в dx - хз. картинки всё время считывать с харда)
9
23 ноября 2011 года
Lerkin
3.0K / / 25.03.2003
Не знаю, я бы попытался сделать так.
Разбить исходную текстуру на минимально необходимые фрагменты. К примеру, 512х512 (по привычке, кратное 2-ке). Пирамиду mipmap уровней строил бы динамически только для тех фрагментов, которые в "фокусе". Вывод нужного уровня для отображаемого фрагмента будет привязано к зуму: т.е. чем меньше зум, тем более высокий уровень (уменьшение качества) из пирамиды отображается. Фильтрация - по вкусу.

Какие плюсы вижу:
Даже при выводе всей картинки, затраты памяти минимальные для такого "фрагментированного" подхода. И можно еще уменьшить (см.ниже).
При необходимости, можно строить пирамиду для нескольких фрагментов при любом исходном уровне их детализации.

Какие минусы:
Построение mipmap пирамиды требует некоторого времени и памяти. Для слабой граф.платке (скорость, память), придется все это дело просчитывать заранее и хранить в файле. При этом, загрузка при каждом зуммировании так же, не способствует быстродействию.

В плане алгоритма определения отображаемых участков идеи нужны?

P.S. Думаю создание, загрузка, обработка и удаление текстуры проблем не вызывает? Кстати, минимальный размер фрагментов определяется качеством исходного изображения.
9
23 ноября 2011 года
Lerkin
3.0K / / 25.03.2003
Если 3D нет, то вся кухня с определением видимости намного проще и быстрее. Но раз требуется зум, панорамирование и перемещение по карте, то с frustum будет интереснее.
289
24 ноября 2011 года
Jeyson
207 / / 20.04.2000
Цитата: Lerkin
Не знаю, я бы попытался сделать так.
Разбить исходную текстуру на минимально необходимые фрагменты. К примеру, 512х512 (по привычке, кратное 2-ке). Пирамиду mipmap уровней строил бы динамически только для тех фрагментов, которые в "фокусе". Вывод нужного уровня для отображаемого фрагмента будет привязано к зуму: т.е. чем меньше зум, тем более высокий уровень (уменьшение качества) из пирамиды отображается. Фильтрация - по вкусу.


В плане алгоритма определения отображаемых участков идеи нужны?



Спасибо за ответы. Я так почти и делаю. Разобью картинку (кстати тоже будет вопрос как их разбить программно, ручками резать 25 тыс картинок не впечатляет) на фрагменты 512х512. Для простоты (иду от простого к сложному) качество будет одно для всех, просто чтобы комп не грузить при определенном масштабе вообще ничего рисоваться не будет, а вообще на будущее надо строить пирамиду.
Нужен как раз алгоритм как отобразить только то что видно на экране и как это выгрузить из памяти когда за пределами экрана (в процессе зумирования и панарамирования).
Исходные данные:
- координаты верхнего левого угла видимой части изображения в программе
- координаты нижнего правого угла видимой части изображения в программе
- точка вставки изображения
- сколько строк и столбцов в изображении (кол-во эл-тов 512х512 по строкам и столбцам)
Нужен как раз алгоритм, если с кусками кода - вообще здорово.
Спасибо

9
24 ноября 2011 года
Lerkin
3.0K / / 25.03.2003
По поводу резки изображения на фрагменты. Тут 2 пути вижу.
1. Загрузка из исходного (оригинального) файла изображения определенного фрагмента. Особо плюсов не вижу, а из минусов - жесткая привязка к конкретному формату изображения, определенная сложность такой процедуры, скорость загрузки и тяжкое определение по координатам отображаемого окна.
2. Сформировать файл своего формата, состоящий из таких фрагментов даже с просчитаной пирамидой. Ну, по типу DDS-файла. Плюсов - полно. минусы - конкретно от реализации. С форматами сжатых текстур DXT1-5 знакомы? Ну, и совсем без mipmap'а будет смотреться... ну, не профессионально, что ли. ;)

Я бы выбрал второй вариант. По формату "фрагментного" файла есть такие мысли. В нем должна присутствовать простейшая индексная таблица, содержащая смещения на блоки каждого фрагмента - так получим гибкость формата при различных размерах фрагментов и доп.информацию (пирамиду, формат сжатия и прочее). Кстати, а формат блока фрагмента тупо с DDS содрать, и велосипеды не придумывать.
289
26 ноября 2011 года
Jeyson
207 / / 20.04.2000
Спасибо за ответы. Буду думать. А пока возникла еще одна задача.
Мне необходимо разбить исходную картину на отдельные файлы 512х512. Пусть это будет отдельная программа. Последовательность действий предполагаю следующую:
1. Загружаю изображение
2. Построчно прохожу его выделяя области 512х512.
3. Каждую область сохраняю в отдельный файл.
Подскажите пожалуйста как это сделать. Лучше с исходником или со ссылкой где это можно посмотреть. Гугл не помог.
Спасибо
289
26 ноября 2011 года
Jeyson
207 / / 20.04.2000
Цитата: Lerkin

Сформировать файл своего формата, состоящий из таких фрагментов даже с просчитаной пирамидой. Ну, по типу DDS-файла. Плюсов - полно. минусы - конкретно от реализации. С форматами сжатых текстур DXT1-5 знакомы? Ну, и совсем без mipmap'а будет смотреться... ну, не профессионально, что ли. ;)

Я бы выбрал второй вариант. По формату "фрагментного" файла есть такие мысли. В нем должна присутствовать простейшая индексная таблица, содержащая смещения на блоки каждого фрагмента - так получим гибкость формата при различных размерах фрагментов и доп.информацию (пирамиду, формат сжатия и прочее). Кстати, а формат блока фрагмента тупо с DDS содрать, и велосипеды не придумывать.



Для меня это темный лес. Пока реализовываю тупо. Что можно почитать про индексные таблицы, DDS и т.д.?

Знаете кого-то, кто может ответить? Поделитесь с ним ссылкой.

Ваш ответ

Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог