На данный момент разобрался с сортировкой прозрачных моделей. Без этой сортировки всё выглядело так, как в изображении во вложении (сейчас уже всё нормально
- эта картинка из тестов) - т. е. монстры спереди закрывали своей прозрачной частью монстров сзади. Ибо WPF не умеет смешивать полупрозрачные треугольники в произвольном порядке - ему этот порядок надо задать. (Кто-нибудь может сказать, как получать прямую ссылку на картинку не тогда, когда она будет загружена через вложение, а во время редактирования поста? И ещё чтобы не использовать сторонние хостинги картинок.) Ну и так как у меня плоские модели, то можно было ограничиться не сортировкой десятков тысяч треугольников, а всего лишь сортировкой моделей (одна стена - одна модель, один монстр - одна модель). Ещё, кстати, надо будет поработать над тем, чтобы объединить модели с одинаковыми текстурами в одну - чего-то там в МСДН пишут, что так производительность лучше будет. Но это потом. У меня для производительности прорисовка ограничена радиусом в 6-7 клеток лабиринта. Да и дальше "факел" игрока не достаёт.
Кстати, в игре, похоже, никакой трёхмерки нету. Ну или там на каждый кадр своя текстура для стены. Вобщем, освещение там - просто заранее подготовленная текстура. У меня же освещение реальное, так что эффект жёлтого пятна на стене, когда стоишь к ней вплотную, получается "бесплатно". Ну так вот, факел игрока светит на расстояние где-то 5-6 клеток с квадратичным затуханием. Ну а ещё плюс "бесплатного" освещения в том, что факелы на стенах, которые в оригинале были просто спрайтами, будут трёхмерными и также давать естественный свет (прикручу к ним свои источники света). Так что можно будет издалека их увидеть - картинка будет гораздо интереснее, чем в оригинале.
Пришлось попотеть, чтобы монстрики появлялись на случайном месте, но ИМЕННО НА КЛЕТКЕ СПЕРЕДИ. Т. е. не будет такого, как в оригинале, когда монтры появлялись прямо на той клекте, где стоял игрок, так что можно было драться даже повернувшись вплотную к стене. Ещё, кстати, там такая выходка в и гре, что когда игрок поворачивается, то он находится в центре клетки, а когда стоят прямо, то его отодвигает немного назад. Именно поэтому при утыкании в стену виден пол и потолок и монстры могут напасть и прямо у стены. У меня монстры смогут напасть только если спереди игрока есть свободная клетка.
Так как каждый монстр - прямоугольник из кучи полигонов с текстурой, то пришлось на каждую ориентацию игрока прописать эту ориентацию прямоугольников.
Остался один баг - из-за случайного места появления монстра на клетке, эти монстры могут налепиться в кучу - т. е. один почти на месте другого. Как это обойти пока не придумал, ибо простое "расталкивание" не поможет - надо учитывать мой алгоритм построения прямоугольников этих монстров и их размещение в зависимости от ориентации игрока (в какую сторону повёрнут). Что-нибудь попозде придумаю, может быть. Игре это не мешает.
Теперь работаю над редактором монстров и дорабатываю редактор карт по части выбора набора монстров, которые будут появляться в каждой клетке.
Из-за особенностей обработки всей трёхмерной модели в WPF, похоже, что полупрозрачных стен (типа стёкол, которые я хотел ввести) или не будет, или будет очень мало (одна-две-три на уровень). Все полупрозрачные объекты приходится сортировать (т. е. либо менять их координаты, либо удалять их и создавать их же, но уже на новом месте) по удалённости от точки обзора камерой игрока, а т. к. эта камера постоянно в разных местах, то придётся сложный алгоритм выдумывать, да и сортировка будет время отнимать. А полупрозрачные стены в SitD - это как минимум решётка, тестура которой должна иметь прозрачные области между прутьями.
Кстати, я не знал, что Cell Key может открывать бронзовую дверь.
HQx алгоритмы решил перенести из игры в редактор, т. к. они ресурсоёмки и лучше "укрупнять" текстуры при создании карты и монстров в редакторе, чем в реальном времени в игре. Т. е. в редакторе нужно будет выбрать текстуру с маленьким разрешением, а редактор сам уже укрупнит её и положит в игру с большим разрешением. Игра же будет загружать уже готовую текстуру без всякой обработки.
Добавлено позже:Вот пруф, что лабиринт - это быстро)
http://www.youtube.com/watch?v=036pSIyMuyU&feature=youtu.be
Смотреть с 1:00 - обрезать было некогда 
Я бы там не спешил с выводами. У вас лабиринт просто в 3Д-редакторе нарисован (Блендер, Макс) или генерируется на лету по какому-то алгоритму? У меня генерирование всей модели уровня идёт от уровня вершин, треугольников, нормалей, направлений обхода (для обозначения внутренних и внешних поверхности треугольников), расстановки источников света и текстурирования - т. е. я не рисую в Блендере лабиринт по готовым кирпичикам. Чего я не делаю, так это не рендерю модель - это делает WPF и Direct3D за меня.
Естественно, если у вас есть готовые библиотеки отрисовки трёхмерных тайлов (у меня тайлы - это стены, потом на уровень выше идут клетки из шести стен), как я для себя написал, например, то процесс дальше идёт быстро. Но эти библиотеки надо же ещё написать и отладить.
Просмотр сообщений
- эта картинка из тестов) - т. е. монстры спереди закрывали своей прозрачной частью монстров сзади. Ибо WPF не умеет смешивать полупрозрачные треугольники в произвольном порядке - ему этот порядок надо задать. (Кто-нибудь может сказать, как получать прямую ссылку на картинку не тогда, когда она будет загружена через вложение, а во время редактирования поста? И ещё чтобы не использовать сторонние хостинги картинок.) Ну и так как у меня плоские модели, то можно было ограничиться не сортировкой десятков тысяч треугольников, а всего лишь сортировкой моделей (одна стена - одна модель, один монстр - одна модель). Ещё, кстати, надо будет поработать над тем, чтобы объединить модели с одинаковыми текстурами в одну - чего-то там в МСДН пишут, что так производительность лучше будет. Но это потом. У меня для производительности прорисовка ограничена радиусом в 6-7 клеток лабиринта. Да и дальше "факел" игрока не достаёт.
