Здравствуйте, Хвост, Вы писали:

Х>Здравствуйте, gandjustas, Вы писали:

G>>И что есть в с++ для управления ресурсами? Наверное хорошый пул потоков или "зеленые" треды? А может там есть выделение памяти в хипе за O(1)?
Х>пул потоков обычно нативный, причём здесь С++? зелёные треды очень хороши для серверов, ага))) хип за O(1) ? в С++ можно аллоцировать память в хипе вообще один раз и на всю жизнь, и обеспечить свой микроменеджмент, при етом рефакторинг кода сведётся фактически к find/replace.
Ну как всегда все вручную...
Только при ручном управлении ресурсами сложность программы может оказаться такова, что за всю жизнь не напишешь.

Х>>>ух-хаха, я вообще не использую shared_ptr, представляешь? удивительно, да?
G>>И что же ты используешь?
Х>для шареных объектов? ты знаешь, если грамотно реализовывать софт, и продумывать время жизни, то оказывается и не так уж много мест где одним и тем же объектом владеют (именно владеют) сразу несколько других, в подавляющем большинстве случаев есть какой-то холдер объектов, который раздаёт объекты другим, причём время жизни етих других много меньше времени жизни холдера. Всё ето потому что shared_ptr ето недетерминизм, т.е. время жизни объекта не определено, нельзя взглянуть на код и сказать — вот в етом месте объект мёртв. Ето плохо. Довольно редко но всё же такие ситуации возникают, тогда можно взять shared_ptr или лично я использую обёртку вида intrusive_ptr над ручным вызовом mySubsystem->release(object). Но есчё раз — ети ситуации очень редки. 99.9% объектов в хипе у меня живёт в std контейнерах, auto_ptr'ах, пулах и аренах. Шарятся множество объектов разных типов, но вот шарятся с семантикой владения пара-тройка, и то ето не необходимость, а скорее кривость.
Да уж. Легче объявить совместное владение объектами кривостью, чем признать что это родовая травма в С++.

G>>>>А вообще-то есть статистика. Так вот проблемы с утечками памяти в unmanaged появляют гораздо чаще проблем с производительностью в managed.
Х>>>есть статистика, что на десктопах пользователей подавляющее большинство приложений — unmanaged, ето на мой взгляд самая лучшая статистика.
G>>Эта статистика очень слабо связана с техническими аспектами. Обсуждали уже сотню раз.
Х>конечно, ты вот наверное не застал времена былинные, а вот я тебе расскажу, в году едак в 96-м, когда вышла жава, С++ хоронили все кому не лень, в 98-м, когда вышла студия с J++, миллионы мух кинулись на жаву, "С++ устарел, на дворе Pentium II с 32 мб, а жаве и 4 мб с головой, и не надо думать об утечках памяти, тысячах реализаций строк, системной работе с потоками, с гуём, всё межплатформенно, блаблабла.... рай на земле... етц", был и свой сильверлайт, только назывался java applet, так вот, жаве уже второй десяток давно пошёл, а на десктопах её всё как-то не особо, и жаваапплетами интернет не полон, а десктоп полон нативными С++ приложениями, а интернет нативным С++ флешем, хотя вот жава она ведь по-твоему намного лучше с++, верно? задумайся почему всё ето так, пойми и осознай, что производительность — ето ресурс, и будет им во веки веков, и процессор, который быстрее в два раза другого, стоит в 3 раза дороже, и юзер выберет программу которая может выполнять три функции параллельно а не две.
Юзеры выбирают программы, которые решают их задачи. Большенству плевать что такая же программа будет выполняться в 10 раз быстрее. Причины, по которым софт на десктопах нативный далеки от технических.
Задумайся, почему в бизнес-приложениях нативного почти нет, хотя производительность там гораздо важнее и гораздо тяжелее добиться высокой производительности в крупных бизнес-системах.
Задумайся почему веб практически полностью отказался от нативных приложений в пользу managed.
Ты осознаешь что бизнес- и веб-приложений на данный момент на несколько порядков больше, чем десктопного софта?

Здравствуйте, samius, Вы писали:

S>Заметно, если вспомнить foreach по перечислителю-структуре и по перечислителю-классу.
Это никак не связано с размещением. Разница в скорости сводится к возможности инлайнинга: для структур компилятор и JIT знают точный тип аргумента, в отличие от паттерна, постренного на абстрактном IEnumerable<T>. С лямбдами такой разницы не будет — попробуй на досуге сравнить скорострельность "автогенеренной" лямбды с ручным замыканием, выполненным поверх структуры в стеке.

S> Но что-то я не замечал, что бы большинство занимались ручной реализацией перечислителей на структурах. Т.е. в большинстве случаев приемлемо (и лямбда с замыканием на хипе и перечислитель на интерфейсе), а если профайлер скажет что беда, недолго переписать низкоуровневыми средствами критичный кусок.
Это верно.

S>Да не, можно найти тысячу ситуаций (искувственных и натуральных), где разница в способе размещения замыкания будет заметна. Взять хотя бы тот же расчет координат в GIS-ах. Да, точно! В таких нагруженных случаях пользоваться лямбдой вообще неуместно, потому говорить о разнице между размещением замыкания лямбды на стеке и хипе как-бы неуместно. Боюсь что больше будет заметна разница лямбд на делегатах (в C#) и лямбд на виртуальных функциях (Nemerle и F#).
Я пока не в курсе, нужны ли вообще лямбды в расчётах координат в GIS. Хотя, если вспомнить про то, что лямбды умеют сворачиваться не только в делегаты, но и в Expression Trees, то они могут напрочь порвать реализацию на С++ путём компиляции в шейдерные операции для выполнения в GPU

Здравствуйте, Хвост, Вы писали:

Х>ну ещё раз, их либо пересчитывать в псевдо-екранные нужно при каждом сдвиге/масштабировании карты (ето если у нас есть псевдоекранные координаты только видимой области) либо пересчитать все координаты (т.е. и те что вне зоны видимости) во внеекранные заранее, тогда можно пользовать аксселлерированые преобразования, но ето как я уже писал шило на мыло.
Еще раз. Если мы в "плоском" режиме, не проецируя геометрию на шарик, либо проецируя на шарик текстуру, то псевдо-экранные координаты считаются один раз. Сдвиг и масштабирование не потребует полного пересчета, т.к. позволит домножить на матрицу, что можно отдать железу. Для того чтобы понять, лежит объект на экране или нет, пересчитвать его координаты в экранные нет нужды! Достаточно иметь рамку экрана в псевдоэкранных координатах и пространственный индекс в родных координатах объекта.
В случае с шариком тоже поможет промежуточная система координат. Однако, она уже не будет аффинно преобразовываться в экранную, но экономия в расчетах все еще будет при повторе прорисовки объекта.

S>>А я говорил, что только промежуточные, а потом манипуляция матрицей. Потому 1000 раз зум-аут/зум-ин не повлияют на координаты. В любом случае координаты объекта при смене вида меняться не должны. Координаты примитива — пожалуйста. Объект неизменен при прорисовке.
Х>дык объект то и неизменен, вид примитива и меняется, т.к. матрица трансформации при 1000 раз зум-аут/зум-ин накапливает ошибку.
А, вона ты о чем Так- конечно. Тут и зумать не надо. Потаскал карту мышкой в режиме пана и объекты разбежались кто-куда (набежала погрешность на сдвигах).
Такой эффект решается запоминанием предыдущего положения и направления "наблюдателя" и применения коэффициентов к нему. Тогда при 1000 зумов или 1000 панах меняются туда-обратно не коэффициенты матрицы, а коэффициенты, которые требуется применить к предыдущему положению "наблюдателя", фактически к запомненной ранее матрице вида. Сразу про накопление ошибки в матрице на множестве итераций туда-обратно можно забыть.

S>>Но повторить худо-бедно такой пролет на векторных данных можно. Естественно, будет зависеть от обилия данных и способа проекции (либо проекция текстуры, либо плоский рендеринг по спроектированным с шарика на плоскость координатам). С шарика на плоскость тоже можно схалтурить и поручить железу.
Х>да, можно, если учесть неточности железки и соответственно с этим написать алгоритм пролёта.
Какие неточности железки? Пиксель туда-сюда?

S>>Софтовые трансформации тоже можно сократить введением промежуточной системы координат. Даже на шарике.
Х>про проблемы с промежуточную систему координат вроде написал
Нету там проблемы. Одна экономия в расчетах координат повторной прорисовки примитива при смене вида. Что на железе что на софте.

S>>Так что запас по производительности есть и значительный. Потому не вижу неподъемных для C# задачь.
Х>В принципе задачу можно реализовать и на C#, но куча визуальных ништяков отомрёт.
Например?

Х> G>И что есть в с++ для управления ресурсами? Наверное хорошый пул потоков или "зеленые" треды? А может там есть выделение памяти в хипе за O(1)?

Х> пул потоков обычно нативный, причём здесь С++? зелёные треды очень хороши для серверов, ага)))

Они гениальны для серверов. Erlang это только доказывает. Возможность ненапряжно выделить несколько тысяч процессов/потоков, если надо, рулит

Здравствуйте, Хвост, Вы писали:

Х>Здравствуйте, MxKazan, Вы писали:

MK>>Здравствуйте, Хвост, Вы писали:

Х>>>тут недостижимого на C# то что отрисовка на акселлераторе занимает меньшую часть времени отрисовки кадра, основное время — трансформация примитивов из одной координатной системы в другую, тут даже такая вещь как проверка индекса на допустимый диапазон при обращению к массиву даёт проседание в 30%, куда здесь C# тулить?
MK>>Ой да ладно. Ты пробовал или снова "боксинг"?
Х>что да ладно? про индексы ето факт, если ты про C# то ессно не пробовал, потому как не взлетит очевидно.
Ну не надо так откровенно сливать.
Приведи тест где заметны эти 30%.

Как ты можешт рассуждать о производительности .NET, если не писал на нем ничего?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>>Заметно, если вспомнить foreach по перечислителю-структуре и по перечислителю-классу.
S>Это никак не связано с размещением. Разница в скорости сводится к возможности инлайнинга: для структур компилятор и JIT знают точный тип аргумента, в отличие от паттерна, постренного на абстрактном IEnumerable<T>. С лямбдами такой разницы не будет — попробуй на досуге сравнить скорострельность "автогенеренной" лямбды с ручным замыканием, выполненным поверх структуры в стеке.
Попробую на досуге.

S>Я пока не в курсе, нужны ли вообще лямбды в расчётах координат в GIS. Хотя, если вспомнить про то, что лямбды умеют сворачиваться не только в делегаты, но и в Expression Trees, то они могут напрочь порвать реализацию на С++ путём компиляции в шейдерные операции для выполнения в GPU
Нужны или нет незнаю, но всунуть их насильно туда можно, но не нужно.
А идея с шейдерами мне понравилась. Но не ради порвать C++, а ради реализации полезных фич.

Мне бы сразу в голову пришла идея.

Апроксимировать проекцию набором треугольников, и внутри тотуголика использовать афинный мапинг.

Преимущества
1. Данные мапятся на плоскость треугольника единожды и кешируются.
2. все трансформации как апаратно так и совтово очень простые (афинные).
3. хорошо ляжет на апаратное ускорение.

Здравствуйте, Хвост, Вы писали:

S>>А я говорил, что только промежуточные, а потом манипуляция матрицей. Потому 1000 раз зум-аут/зум-ин не повлияют на координаты. В любом случае координаты объекта при смене вида меняться не должны. Координаты примитива — пожалуйста. Объект неизменен при прорисовке.
Х>дык объект то и неизменен, вид примитива и меняется, т.к. матрица трансформации при 1000 раз зум-аут/зум-ин накапливает ошибку.

Этот момент мне не совсем ясен, можно подробнее ? Ошибка в матрице по отношению к чему? какая именно ошибка ?

Трансформацию можно хранить не в матрице а как набор трансформаций Rotation(from radians) * translation( x,y) * scale(s)

Здравствуйте, minorlogic, Вы писали:

M>Мне бы сразу в голову пришла идея.

M>Апроксимировать проекцию набором треугольников, и внутри тотуголика использовать афинный мапинг.

M>Преимущества
M>1. Данные мапятся на плоскость треугольника единожды и кешируются.
M>2. все трансформации как апаратно так и совтово очень простые (афинные).
M>3. хорошо ляжет на апаратное ускорение.

Но и эффект будет не тот, как в рендеригне без мапинга изображения. В GIS случаются немонотонные заливки, там важны толщины и структуры линий, значки (иконки). Все это поплывает при аффинном мапинге кэшированного изображения.

Здравствуйте, Хвост, Вы писали:

Х>Здравствуйте, gandjustas, Вы писали:

G>>И что есть в с++ для управления ресурсами? Наверное хорошый пул потоков или "зеленые" треды? А может там есть выделение памяти в хипе за O(1)?
Х>пул потоков обычно нативный, причём здесь С++? зелёные треды очень хороши для серверов, ага))) хип за O(1) ? в С++ можно аллоцировать память в хипе вообще один раз и на всю жизнь, и обеспечить свой микроменеджмент, при етом рефакторинг кода сведётся фактически к find/replace.

Предполагаю что имелся ввиду memory pool

Здравствуйте, minorlogic, Вы писали:

M>Здравствуйте, Хвост, Вы писали:

S>>>А я говорил, что только промежуточные, а потом манипуляция матрицей. Потому 1000 раз зум-аут/зум-ин не повлияют на координаты. В любом случае координаты объекта при смене вида меняться не должны. Координаты примитива — пожалуйста. Объект неизменен при прорисовке.
Х>>дык объект то и неизменен, вид примитива и меняется, т.к. матрица трансформации при 1000 раз зум-аут/зум-ин накапливает ошибку.

M>Этот момент мне не совсем ясен, можно подробнее ? Ошибка в матрице по отношению к чему? какая именно ошибка ?
Имеется ввиду, что если матрицу подвергнуть череде преобразований, так что последнее преобразование должно вернуть матрицу в исходное состояние (например, зум-аут и зум-ин на ту же величину), то мы получим матрицу, которая в точности не будет совпадать с исходной за счет погрешности вычислений. При повторении погрешность может убежать.

M>Трансформацию можно хранить не в матрице а как набор трансформаций Rotation(from radians) * translation( x,y) * scale(s)
Вот именно. Погрешность не накопится в случае, когда есть исходная матрица X (всегда одинаковая) и набор параметров (поворот, масштаб, сдвиг).

Здравствуйте, samius, Вы писали:

S>Здравствуйте, minorlogic, Вы писали:

M>>Мне бы сразу в голову пришла идея.

M>>Апроксимировать проекцию набором треугольников, и внутри тотуголика использовать афинный мапинг.

M>>Преимущества
M>>1. Данные мапятся на плоскость треугольника единожды и кешируются.
M>>2. все трансформации как апаратно так и совтово очень простые (афинные).
M>>3. хорошо ляжет на апаратное ускорение.

S>Но и эффект будет не тот, как в рендеригне без мапинга изображения. В GIS случаются немонотонные заливки, там важны толщины и структуры линий, значки (иконки). Все это поплывает при аффинном мапинге кэшированного изображения.

Скорее всего ты неправильно меня понял.

M>>1. Данные мапятся на плоскость треугольника единожды и кешируются.

Имелось ввиду не кеширование растра , а кеширование спроецированных данных. GIS Data(Vector data(lat lon)) -> Projection Data(Vector data)
Projection Data — может быть и Equiretangular а может и на сферу.


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

Здравствуйте, gandjustas, Вы писали:

G>Стандартные аллокаторы в С++ требуют прохода по списку свободных блоков памяти при выделении\освобождении, эта операция имеет алгоритмическую сложность O(n). При интенсивных операциях выделения\освобождения работает очеень медленно.
Ты пожалуйста ссылку дай на стандарт С++, где написано что именно так работает "стандартный аллокатор С++".

G>Не разводи демагогию, давай факты.
Симметрично!

Здравствуйте, minorlogic, Вы писали:

M>Здравствуйте, samius, Вы писали:

S>>Но и эффект будет не тот, как в рендеригне без мапинга изображения. В GIS случаются немонотонные заливки, там важны толщины и структуры линий, значки (иконки). Все это поплывает при аффинном мапинге кэшированного изображения.

M>Скорее всего ты неправильно меня понял.
Похоже на то

M>>>1. Данные мапятся на плоскость треугольника единожды и кешируются.

M>Имелось ввиду не кеширование растра , а кеширование спроецированных данных. GIS Data(Vector data(lat lon)) -> Projection Data(Vector data)
M>Projection Data — может быть и Equiretangular а может и на сферу.
Теперь кажись понял. Но тут мы получаем дополнительную задачу разбиения примитивов по треугольникам с разными преобразованиями. Например, если взять полигон-контур России, то он размажется по многим треугольникам, аппроксимирующим эллипсойд. Сразу получим проблему стыков частей такой фигуры по границам аппроксимирующих треугольников. Без введения дополнительных точек не представляю как решать.
Нужен gluTess, либо своя реализация теоретико-множественных операций над точками, ограниченных контурами полигонов. Решается. Да и порядочный GIS должен иметь такую штуку в арсенале.

M>А кешированеи отрендренной текстуры на треугольник это допольнительная фича, так сказать по требованию. Напрмиер при быстром показе мы может отрисовать закешированный растр и потом когда будет время отрендрить заново с лучшим качеством.
Угу. Пойдет в качестве "быстрого" варианта.

Здравствуйте, samius, Вы писали:

M>>Имелось ввиду не кеширование растра , а кеширование спроецированных данных. GIS Data(Vector data(lat lon)) -> Projection Data(Vector data)
M>>Projection Data — может быть и Equiretangular а может и на сферу.
S>Теперь кажись понял. Но тут мы получаем дополнительную задачу разбиения примитивов по треугольникам с разными преобразованиями. Например, если взять полигон-контур России, то он размажется по многим треугольникам, аппроксимирующим эллипсойд. Сразу получим проблему стыков частей такой фигуры по границам аппроксимирующих треугольников. Без введения дополнительных точек не представляю как решать.
S>Нужен gluTess, либо своя реализация теоретико-множественных операций над точками, ограниченных контурами полигонов. Решается. Да и порядочный GIS должен иметь такую штуку в арсенале.

Теперь похоже правильно.
Действительно появляются 2 дополнительные задачи.

1. Триангуляция (разбивка на треугольники) проекции.
2. сопряжение на краях треугольников, особенно фигур лежащих на границе.

Задача 1 решена давно для распространенных проекций.
Задачу 2 можно решать очень по разному, можно подсмотреть например как это сделанно в Google Earth и т.п.

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

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, gandjustas, Вы писали:

G>>Стандартные аллокаторы в С++ требуют прохода по списку свободных блоков памяти при выделении\освобождении, эта операция имеет алгоритмическую сложность O(n). При интенсивных операциях выделения\освобождения работает очеень медленно.
CC>Ты пожалуйста ссылку дай на стандарт С++, где написано что именно так работает "стандартный аллокатор С++".
Стандарт C++ не определяет реализацию выделения памяти. Во всех известных мне реализациях С++ работает именно так.

G>>Не разводи демагогию, давай факты.
CC>Симметрично!
Я уже приводил код, где GC работает быстрее алокатора С++.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Расскажи это лисперам. В лиспе исторически замыкания создавались копированием используемых переменных.

ГВ>Ну, поскольку я знаю твою манеру ведения дискуссии, то обращаю внимание на слово "исторически". А если точно, то я отсылал к common lisp чёрт-те какой давности. В современных диалектах, AFAIK, это уже не так.

Демагог, есть демагог. Нет никакого исторического наследния CL. CL — это стандарт вышедший таким каким он есть.

И вообще, твои слова банальная демонстрация некомпетентности. Лисп изначально имел сборщик мусора и стало быть делать урезанные в нем не имело никакого смысла.

Здравствуйте, samius, Вы писали:

S>Здравствуйте, Хвост, Вы писали:

Х>>ну ещё раз, их либо пересчитывать в псевдо-екранные нужно при каждом сдвиге/масштабировании карты (ето если у нас есть псевдоекранные координаты только видимой области) либо пересчитать все координаты (т.е. и те что вне зоны видимости) во внеекранные заранее, тогда можно пользовать аксселлерированые преобразования, но ето как я уже писал шило на мыло.
S>Еще раз. Если мы в "плоском" режиме, не проецируя геометрию на шарик, либо проецируя на шарик текстуру, то псевдо-экранные координаты считаются один раз. Сдвиг и масштабирование не потребует полного пересчета, т.к. позволит домножить на матрицу, что можно отдать железу. Для того чтобы понять, лежит объект на экране или нет, пересчитвать его координаты в экранные нет нужды! Достаточно иметь рамку экрана в псевдоэкранных координатах и пространственный индекс в родных координатах объекта.
S>В случае с шариком тоже поможет промежуточная система координат. Однако, она уже не будет аффинно преобразовываться в экранную, но экономия в расчетах все еще будет при повторе прорисовки объекта.

S>>>А я говорил, что только промежуточные, а потом манипуляция матрицей. Потому 1000 раз зум-аут/зум-ин не повлияют на координаты. В любом случае координаты объекта при смене вида меняться не должны. Координаты примитива — пожалуйста. Объект неизменен при прорисовке.
Х>>дык объект то и неизменен, вид примитива и меняется, т.к. матрица трансформации при 1000 раз зум-аут/зум-ин накапливает ошибку.
S>А, вона ты о чем Так- конечно. Тут и зумать не надо. Потаскал карту мышкой в режиме пана и объекты разбежались кто-куда (набежала погрешность на сдвигах).
S>Такой эффект решается запоминанием предыдущего положения и направления "наблюдателя" и применения коэффициентов к нему. Тогда при 1000 зумов или 1000 панах меняются туда-обратно не коэффициенты матрицы, а коэффициенты, которые требуется применить к предыдущему положению "наблюдателя", фактически к запомненной ранее матрице вида. Сразу про накопление ошибки в матрице на множестве итераций туда-обратно можно забыть.

S>>>Но повторить худо-бедно такой пролет на векторных данных можно. Естественно, будет зависеть от обилия данных и способа проекции (либо проекция текстуры, либо плоский рендеринг по спроектированным с шарика на плоскость координатам). С шарика на плоскость тоже можно схалтурить и поручить железу.
Х>>да, можно, если учесть неточности железки и соответственно с этим написать алгоритм пролёта.
S>Какие неточности железки? Пиксель туда-сюда?

S>>>Софтовые трансформации тоже можно сократить введением промежуточной системы координат. Даже на шарике.
Х>>про проблемы с промежуточную систему координат вроде написал
S>Нету там проблемы. Одна экономия в расчетах координат повторной прорисовки примитива при смене вида. Что на железе что на софте.

S>>>Так что запас по производительности есть и значительный. Потому не вижу неподъемных для C# задачь.
Х>>В принципе задачу можно реализовать и на C#, но куча визуальных ништяков отомрёт.
S>Например?

Здравствуйте, Хвост, Вы писали:
както неудачно нажал отправить, предыдущее сообщение можно удалить

Х>>>ну ещё раз, их либо пересчитывать в псевдо-екранные нужно при каждом сдвиге/масштабировании карты (ето если у нас есть псевдоекранные координаты только видимой области) либо пересчитать все координаты (т.е. и те что вне зоны видимости) во внеекранные заранее, тогда можно пользовать аксселлерированые преобразования, но ето как я уже писал шило на мыло.
S>>Еще раз. Если мы в "плоском" режиме, не проецируя геометрию на шарик, либо проецируя на шарик текстуру, то псевдо-экранные координаты считаются один раз. Сдвиг и масштабирование не потребует полного пересчета, т.к. позволит домножить на матрицу, что можно отдать железу. Для того чтобы понять, лежит объект на экране или нет, пересчитвать его координаты в экранные нет нужды! Достаточно иметь рамку экрана в псевдоэкранных координатах и пространственный индекс в родных координатах объекта.
давай тезисами опишу проблемму
чтобы трансформировать на железе — нужно иметь псевдо-екранные координаты (ето ещё не проблемма)
для того чтобы работать со всей геометрией — нужно иметь её всю в псевдо-екранных координатах (тут проблемма — резко возросшее число геометрии для трансформации)
если не всю — а только видимую, то необходимо постоянно пересчитывать в псевдо-екранные координаты геометрию, появляющуюся во вьюхе при скролле/зуме (тут проблемма — какой тогда смысл в трансформациях на железе если нужно постоянно трансформировать в псевдо-екранные координаты новую видимую геометрию)

S>>>>А я говорил, что только промежуточные, а потом манипуляция матрицей. Потому 1000 раз зум-аут/зум-ин не повлияют на координаты. В любом случае координаты объекта при смене вида меняться не должны. Координаты примитива — пожалуйста. Объект неизменен при прорисовке.
Х>>>дык объект то и неизменен, вид примитива и меняется, т.к. матрица трансформации при 1000 раз зум-аут/зум-ин накапливает ошибку.
S>>А, вона ты о чем Так- конечно. Тут и зумать не надо. Потаскал карту мышкой в режиме пана и объекты разбежались кто-куда (набежала погрешность на сдвигах).
S>>Такой эффект решается запоминанием предыдущего положения и направления "наблюдателя" и применения коэффициентов к нему. Тогда при 1000 зумов или 1000 панах меняются туда-обратно не коэффициенты матрицы, а коэффициенты, которые требуется применить к предыдущему положению "наблюдателя", фактически к запомненной ранее матрице вида. Сразу про накопление ошибки в матрице на множестве итераций туда-обратно можно забыть.
всё верно, просто код становится чуть менее тривиальным, но ето не проблемма.

S>>>>Но повторить худо-бедно такой пролет на векторных данных можно. Естественно, будет зависеть от обилия данных и способа проекции (либо проекция текстуры, либо плоский рендеринг по спроектированным с шарика на плоскость координатам). С шарика на плоскость тоже можно схалтурить и поручить железу.
Х>>>да, можно, если учесть неточности железки и соответственно с этим написать алгоритм пролёта.
S>>Какие неточности железки? Пиксель туда-сюда?
ну вообще-то не пиксель, а поболе, заметно глазу.

Здравствуйте, samius, Вы писали:

S>Теперь кажись понял. Но тут мы получаем дополнительную задачу разбиения примитивов по треугольникам с разными преобразованиями. Например, если взять полигон-контур России, то он размажется по многим треугольникам, аппроксимирующим эллипсойд. Сразу получим проблему стыков частей такой фигуры по границам аппроксимирующих треугольников. Без введения дополнительных точек не представляю как решать.
S>Нужен gluTess, либо своя реализация теоретико-множественных операций над точками, ограниченных контурами полигонов. Решается. Да и порядочный GIS должен иметь такую штуку в арсенале.
+1, только хотел отметить про gluTess, что он настолько тормозной (даже для не-реалтайм триангуляции) что даже и пытаться не стоит, есть реализации на порядки быстрее.