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

Это хорошо, значит я просто слишком мало знаю про вершинные ( равно как и пиксельные ) шейдеры: я в одной книге вычитал, что они не умеют <i>создавать</i> вершины.
Потом, ещё одна проблема: как генерировать текстурные координаты для ландшафта? Ведь если использовать <x,y> как <u,v>, то могут возникнуть сильные искажения, если текстура накладывается на крутые склоны. Ну, теоретически можно их как-нибудь аккуратно вычислить, но что делать, если сцена меняется?

Насчёт огня в Arwen: забавно, когда под скриншотом написано, что это "огонь через систему частиц", когда на самом деле никакого огня не видно. Ну, разве что если подойти очень близко, то над flare''ом можно заметить тоненькую оранжевую струйку.
Потом, почему в тестовой сцене ( test.sc ) billboard в одной из комнат непрозрачен? Он рисуется на чёрном квадратике.

Спасибо, что показали мне, где искать arwen.dsp, я его почему-то не заметил, наверное неправильно распаковывал...

Может вопрос слегка невовремя (при выходе новой вашей книге), но все-же:
Интересно было-бы узнать ваше мнение о книге Рика Пэрента, которую вы переводили. К своему удивлению я не нашел на этом сайте ни одного упоминания о ней, хотя считаю что книга не имеет аналогов (по крайней мере из книжек на русском) по широте охватываемого материала и по количеству ссылок на оригинальные статьи (что компенсирует краткость изложения). Это одна из немногих книг (опять же в России), которую можно отнести к категории "не для чайников". Это, конечно, IMHO.

Если не сложно поделитесь своим мнением об этой книге.

В разделе скачивания есть набор текстур и моделей к сцене , находящейся в основном архиве с исходным кодом в каталоге Arwen/Data

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

Не так давно скачал таки исходники Arwen и почерпнул МАССУ интересного и полезного. :) Пришлось уже два раза переписать базовые классы GameBase под влиянием Arwen. ;) Напрямую код не использовал - как правило перерабатывал его на свой манер - под шаблоны и укладывал в свою объектую модель, тем не менее помогло сильно, особенно с подсистемой Math (как раз проверка на пересечение треугольника и луча, и т.п. вещи, почти полностью почерпнутые из 3D Arwen).
При следующем обновлении GameBase в нём будет масса позитивных изменений, подвижные объекты (монстры) и... ссылки на этот сайт разумеется. ;)

Одно только неприятно - не могу полюбоваться на тестовую сцену скомпилированного Arwen за неимением моделей и текстур. Нельзя ли выложить какой нибудь "минимальный", но достаточно красочный и полный пример комнат с текстурами, порталами и эффектами на сайте, размером от 500Kb до 1Mb?

Кроме того есть вопрос на который уже какой день не могу найти ответа: Как средствами OpenGL определить, что текущая текстура (либо текстура с определенным "именем") испорчена в видеопамяти? Т.е. имея несколько даже небольших текстур записанных в видеопамять с помощью glBindTexture сталкиваюсь с проблемой - если из полноэкранного режима выйти по ALT-TAB на рабочий стол, а потом вернуться обратно половина текстур "портится" и отображает мусор. Помню в Direct3D у поверхностей был такой метод (IsLost или как то так)... В OpenGL возлагал надежды на glAreTexturesResident, но нет, не оно...

И еще пару сотен слов по поводу C++...
Согласен что флейм-варс это глупо... Но опять не могу не возразить. :)
Впрочем возражу только на самые существенные по моему мнению моменты.

> Ну не говоря уже о том, зачем было перетаскивать грабли из С в С++....

Потому что помимо трех перечисленных вами ВТОРОСТЕПЕННЫХ целей, которые ставил перед собой Страуструп была еще одна ОСНОВНАЯ. А именно - сделать язык C++ 100%-но совместимым с C. По сути основной целью было: сделать ООП расширение над C. Страуструп был не дурак и прекрасно понимал что отвоевать место под солнцем у C в его области применения можно только сделав "тот же самый C, но еще лучше". (кстати заметно, что этого места под солнцем несмотря на всё, C++ отвоевал не так уж и много). Отсюда понятны многие моменты, к примеру почему C++ не обладает встроенной объектной моделью. Как и C, C++ "свободен" от всего "лишнего". Программа на C откомпилированная на C++ не должна обременятся чем то еще, кроме пожалуй new и delete в RTL. В остальном программист свободен делать что хочет.

> Кроме того С никогда и считался языком со строгой типизацией в отличии от С++.

По моему это утверждение неверно. Язык C строго типизирован - все переменные в нём обязательно должны иметь тип данных и не могут быть использованы в контексте где этот тип данных неприемлем (например при передаче в ф-ю). Потенциальные грабли с линкером, который не проверят типы данных и не подозревает собственно даже что это такое - это из другой оперы. Сам язык подразумевает строгую типизацию данных.

> Тогда чем отличается объект от класса ?

А вот этим самым "динамизмом" и отличается. :) Класс - это "застывшая" на моменте компиляции сущность, помогающая избавиться от ошибок, которые можно обнаружить на момент компиляции. Объект в Perl, же, - это просто уловка интерпретатора, соединяющая в синтаксис A->B коллекцию свойств с коллекцией методов. И нет ограничений в рантайме какие методы к каким своствам можно "пристегнуть". Удобно конечно, не спорю. Но насчёт быстродействия и уместности применения динамических моделей объектной структуры данных в высокопроизводительных программах я пока сильно сомневаюсь... Особенно вспоминая записки о битве за производительность у ID software. :) Может конечно objective-c и работает в графической подсистеме маков, но где и как - это вопрос.

> Вы спросите в comp.lang.objective-c про производительность.
> Уверяю Вас несмотря на все проверки с ней все в порядке.

Вы в своей статье привели пример, что хоть и поиск ф-ии по имени в объекте ведется через сравнительно медленный поиск в таблице строк, но можно указатель на метод "застолбить" и использовать его для быстрого вызова метода хоть 10 раз, хоть 100000. У меня только один вопрос - а если у вас "на руках" коллекция из 10000 разнородных объектов у которых надо 10000 раз вызвать метод Show? Хранить где то 10000 указателей на этот метод?

> C#... Извините, но Ваши примеры фактически сравнивают скорость механизма выделения памяти

Не совсем. Там было еще 2 теста другого рода: тест на скорость вызова методов у объектов и тест на огромный цикл вещественых арифметических операций (+, -, sin). В этих тестах C# шел вровень с Borland C++ (незначительное оставание) и где то в полтора раза медленнее чем MS C++. В самом конце я это подчёркивал.

> Почему же тогда большинство библиотек на С++ практически не совместимы друг с другом ?

Например??? О какого рода несовместимости речь?

> Ну он и сделал язык с АТД, но почему называет их объектами, что просто не верно.
> Единственное, что у классов есть от объектов - это убогий механизм виртуальных функций.

Нуу...
Во первых: C++ это пожалуй единственный КОМПИЛЯТОР, который я знаю (кроме C#), который вообще:
- имеет возможность создания АТД
- имеет возможность создания шаблонов
Не думаю что разумно ставить это ему в минус. :) Эти технологии действительно мало чего общего имеют с технологией ООП, но само их наличие - это несомненный ПЛЮС. Однако не надо говорить что "ООП в C++ отстойно, потому что от шаблонов нельзя наследовать". Не надо мешать АТД и шаблоны в одну кучу с ООП. Это совсем другие механизмы программирования, решающие (отчасти) совершенно другие задачи, и решающие их на великолепном уровне, который я не встречал ни в одном другом языке, а знаю я их тоже немало.
Во вторых - ООП в C++ действительно... эээ... "минимален". Наследование и полиморфизм - вот два единственных столпа на которых он построен. Даже в Delphi есть метаинформация в виде TClass из которой можно даже вытаскивать список опубликованных свойств класса (что в конечном итоге используется для автоматической сериализации как вам нравится!), и c этой стороны RTTI в C++ мог бы быть гибче, но... он ведь и разрабатывался черти когда. :) Язык то, не побоюсь этого слова - древний. :) Давно пора уже модернизировать спецификацию (хотя не до динамического пристёгивания методов, упаси бог!). ;)

Кстати навскидку могу подбросить еще одну ветку в костёр неприятия C++ - недавно обнаружил еще одну, забытую мной, особенность языка - в конструкторе нельзя использовать виртуальные ф-ии (как будто бы компилятор не может проинициализировать vtbl до вызова кода программиста). Видимо отсюда вытекает тот фактик что механизм RTTI внутри конструкторов тоже не работает...

Напоследок, заинтригованный, я просто не могу не спросить - может подкинете ссылку на хорошее описание языка objective-c? :)

Вот-вот выйдет книга "Расширения OpenGL"
Насчет проекта Arwen - в архиве исходников engine.zip в есть проект - Arwen/Arwen.dsp
Если у Вас возникают проблемы со сборкой этого проекта - укажите какие именно.

Про ландшафт - в большинстве случаев достаточно хранить только высоты и м.б. текстурные координаты. Все остальное легко вычисляется в вершинной шейдере.

2ReaVer:
Насчет следующей части - пока точно не знаю, идет работа.
Вот-вот вый

Андрею. Если вы используете OpenGL, то в нем, в отличии от Direct-a, есть специальный режим рисования GL_SELECT, который устанавливается функцией glRenderMode. Основной смысл режима – при каждом движении мыши вы виртуально (без вывода на экран) рисуете сцену в очень маленьком viewporte – квадрат в несколько пикселей (ловушка) вокруг позиции мыши. OpenGL возвращает вам имена объектов, попавших внутрь ловушки. О присвоении имен объектам см. функции glSelectBuffer, glInitName, glLoadName, glPopName, glPushName. Для задания области отбора см. gluPickMatrix.

Здрасте...
Несколько вопросов:
1. Когда будет следующая книга ( вторая часть Графики Трехмерной..... )? Жду-недождусь.
2. Пытался скомпилировать проэкт "Arwen", ничего не получилось, лишь заблудился во всех этих файлах... Нельзя ли выложить .dsp/.vcproj файлы? Спасибо.
3. Какие существуют способы отображения ландшафта? Стандартный способ ( карта высот ) требует СЛИШКОМ много места ( Direct3D требует явно заданные координаты вершин, нормали, текстурные координаты ): 32 байта на вершину, 4x4 вершины на кв. метр, 1000000 кв. метров на кв. километр: 512 Мб. А если ограничить область, видимую одновременно, то придется отказаться от открытых пространств, что противоречит сути игры.

Андрею: то, что вам нужно, называется Picking. На эту тему есть даже пример в DirectX9 SDK, суть его довольно проста: либо вычисления производятся в объектном пространстве, проверяя каждый полигон на столкновение с лучом, затем выбтрается самый ближний к точке обзора, либо производится в экранных координатах, где проверить столкновение луча с многоугольником гораздо проще.

2ALX:
>Так что ООП C++ реализует в полной мере
Какое ООП ?
В понимании Страуструпа, что ли ?
Почему же тогда большинство библиотек на С++ практически не совместимы друг с другом ?

>Насчёт АТД. САМ СТРАУСТРУП ТАК И ПИШЕТ что "одной из целью создания C++ была возможность
>создания программистом своих собственных типов данных, >с которыми можно было бы работать так же
>просто как и с примитивными типами, но при этом чтобы >они не уступали им в своей эффективности

Ну он и сделал язык с АТД, но почему называет их объектами, что просто не верно. Единственное, что у классов есть от объектов - это убогий механизм виртуальных функций.
ПОсмотрите книгу А. Александреску - там автор через template-ы реализует множество вещеей, которые в ОО-языках легко реализуются без всяких макросов(т.е template-тов). Просто за счет тогоЮ, что в них НОРМАЛЬНЫЕ ОБЪЕТЫ, а не АТД.

>В C для этого достаточно было просто не подключать >заголовочный файл модуля, где ф-я определена.
>При этом компилятор, не видя определения ф-ии полагает >что ф-я имеет произвольное число параметров,
>каждый из которых - int (по умолчанию)

Так С никогда не назывался языком со строгой типизацией , в отличии от С++. Поэтому сравнение тут бессмысленно. Я пытался показать, что эта типизация сделано в С++ криво (и вообще только мешается).

>Что касается в целом контроля корректности введенных >программистом выражений попробуйте в C,
>например, такое: ((void (*)())0)(); :)))

Опять - С - это язык без строгой типизации. В нем это можно. В нем Вам не обещали type safety.

А насчет того, что он унаследовал много всего плохого от С - а на фига тогда это было все это наследовать.
Получается, что заявлено одно, а в реальности - совсем другое. А на попытки указать на это несоответствие вспоминают о "тяжелом наследии языка С". А кто все это притащил в С++, как не сам Страуструп ?

Когда мне в первые расскащзали про objective-c, я очень удивлялся зачем, ведь есть такой удобынй С++. Через несколько лет я это понял.
И Вы в том же C# можете найти кучу возможностей, которые могли бы заметно улучшить жизнь программиста на С++, но почему их в С++ нет (кто мешал добавить хотя бы какую-то поддержку метаинформации).

ЗЫ. Я не хотел разводить flame wars. Просто в Вашем сообщении было много интересных мест, которые хотелось прокомментировать со своей точки зрения.

2ALX:
ССылочку на Ваш сайт сечас добавлю

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

>Если вкратце, то различие между ООП и простым
>"объективизмом" в том что объектные языки риентированы >на объекты, а ООП языки - на классы. Другими
>словами у ООП языков в отличие от объектных строгая >типизация данных.

Тогда чем отличается объект от класса ?
Я провожу грань между АТД (где никакой виртуальности и возможности переопределения не надо и главное - это быстродействие) и объектами (где главное - это гибкость)
Какое отношение типизация имеет к ООП (кроме того, что мешает) ?

>Проверять
>постоянно есть ли у объекта те или иные методы >обременительно как для программиста, так и для
>производительности программы.

Вы спросите в comp.lang.objective-c про производительность. Уверяю Вас несмотря на все проверки с ней все в порядке. Более того в Маках весь интерфейс написан на objective-c и с быстродействием все в порядке.
Так что это просто ничем не обоснованное утверждение, IMHO

>Насчёт C# здесь распространятся не буду
Я прочитал Ваш спор, особенно про сравнение скорости.
Извините, но Ваши примеры фактически сравнивают скорость механизма выдкеления памяти, что всегда является критическим местом. И если эти операции буферизовать (что и делает сборка мусора), то естественно получается выйгрыш по сравнению с С++, где по delete надо сразу же освободить память.
Попробуйте для теста взять серезную расмчетную задачу по геометрии (только не используя КривойХ) и посмотрим какое быстродействие будет тогда.
Вообще мое мнение о "ТупомС" - я надеюсь что это дрянь быстро сдохнет и мелкомягкие выродки на этом сильно просядут.

>Впервые слышу что к парадигме ООП относят такие >"фишки" как persistance или делегирование. Всюду
>где читал в основе её были только 3 вещи: >наследование, полиморфизм и инкапсуляция данных

Дело скорее всего в том, что книжки и примеры, по которым Вы (как и я) учили ООП были ориентированы на С++ (а не на Smalltalk)
persistence действительно явно в ООП не входит, но это настолько удобное и мощное понятие, что во всех системах, основанных на гибких языках это делается легко и просто. А в С++ его надо делать ручками для каждого класса.
Делегирование это как действительно относится к ООП, в Smalltalke используется постоянно, а о нем многие не знают именно потому, что в С++ его нормально реализовать практически невозможно.

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

C++ справляется только с тем, что есть ООП с точки зрения С++. Реализовать какие-либо вещи, которые требуют наличия метаинформации или не вписиываются в жесткую типизацию (как то же делегирование) в С++ просто игнорируют (или не знают вообще).
А насчет множественного наследования - в питоне оно есть, более того там можно на ходу добавлять объекту новый родительский класс, методы и переменные. И никаких проблем с множественным наследованием (в отличи от С++) у него не возникает.
На ходу можно добавлять новые методы в компилируемый objective-c

2Andrey:
Не знаю, сам пока что с этим не сталкивался

Здравствуйте.
Я пишу небольшой 3D-редактор в VC6.0.
Какой Вы бы мне посоветовали наилучший алгоритм для выбора объектов курсором мыши?

2LeonSOft:
К Вашему сведению я тоже знаю несколько языков.
Насчет знания С++ - давайте не будем пиписьками меряться, а ?
Я лично в Вашем ответе не нашел ни одного довода, зато много расставленных пальцев.
Я высказал свое мнение, во второму овпросу - это о том, что не надо как баранам следовать дурацким примерам.
Чем это похоже на "почему все на иномарках ездят, ведь наши жигули,москвичи,волги так хороши" я не вижу.
Объясните - с конкретными фактами, а не пальцами.

To LeonSoft
Вы -то хоть чего-нить в своей жизни написали?Почему анонимно?
А то сплошные эмоции....Создайте что-нибудь свое, а то называть все бредом каждый умеет...