Linderdaum 3d engine для Linux/*nix-систем

отлично

Cсылка?

http://www.linderdaum.com

проект (в разных формах) уже с 2002-го года. сейчас мы активно готовимся к next-gen воксельной графике, пока не забывая старые добрые полигоны.

Ну...
Красиво.
Главное, чтобы не прожорливо.
Поможем, чем сможем.

>под линуксом не так много всего для гейм-дева
Cube engine навскидку помню. А ещё совсем надавно мелькали новости про 3Д игрушки и движки с ними прилагались.

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

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

>без сомнения, движки есть.

И не мало. на вскидку - Irrlight , Ogre. Хотя игроделом и комп. графикой вообще не увлекаюсь.

А по теме - сайт не открывается.

>А по теме - сайт не открывается.

Сорри. временный баг. На сайте не вижу ссылок на приложения использующие эту библиотеку. Обычно, когда библиотеку пишут не для приложений - она либо учебная, либо сферическая в вакууме. И ещё - с чем связано изобретения собственно скрипт-движка? Чем lue, python, etc не угодили?

> на вскидку - Irrlicht, Ogre

И то, и то - это только rendering engines. тут же в разработке полный набор инструментов, а не только рендеринг. Развивать тему не буду, т.к. сказал, что мы здесь не сравниваем возможности.

Примеры приложений включены в СДК (это одна "настольная" игра и одна аркада). Идея в том, что всё является конфигурируемым и полностью управляемым в данных. Можно своими руками "подкрутить" настройки объектов (во встроенном редакторе, прямо in-game, или во внешнем редакторе, использующем движок - сейчас такой разрабатывается) или просто написать свой класс (на скрипте), расширяющий что-то из движка, вообще не используя gcc или другой native-компилятор. Например, любая настольная игра пишется минут за тридцать (только не надо вспоминать АИ в шахматах - я не про это :) ) В новый релиз СДК войдёт больше сэмплов.

> чем не угодили lua, python

На многих форумах спрашивают, зачем придумывать свой скрипт-движок. скажу так : основная проблема - это не сам скрипт. на чём писать - действительно, дело вкуса и удобства. основная проблема в том, как этот скрипт связан с host-application и как полностью автоматизировать процесс экспорта всех классов и методов в скрипт. что luabind, что tolua (например) требуют, чтобы по вашему исходнику вы написали бы некоторую спецификацию. мы же потратили время на то, чтобы нехорошо ссылаться на трейд-марки, но приведу аналог - UnrealScript + UCC. там прямо по С++-ным заголовкам генерируется весь код связывания. надо сказать, что именно эту систему мы и повторяли. иными словами, у нас в скрипте можно напрямую наслдеоваться от C++-ных классы. Возможно, это и слишком круто для скрипта. более того, в этом случае нужен и свой дебаггер - иначе отладка проблематична (сейчас мы и работаем над доводкой всей системы до удобного состояния).

Ещё отмечу, что проблема с питоном - скорость исполнения. У нас в виртуальной машиной пока осталось одно тонкое место - вызов методов (это довольно тяжеловесная оперцаия из-за маршалирования параметров), который станет заметно быстрее, когда наконец доделаем таблицу виртуальных методов (на этапе тестирования использовалось символьное связывание, а не по индексу методов). В общем, это не классический интерпретируемый скрипт, а компилируемый в байт-код. Зачем ? Гейм-дев вещь специфическая и ни .NET, на Java пока на все платформы не перенесены. Соглашусь, что ситуация меняется и пятнадцатилетний Unreal в скором времени может стать неактуальным. Возвращаясь к Lua, скажу, что и к ней (используя наши средства) довольно просто сгенерировать готовый код привязки (используя тот же luabind).

Помочь можно, опыта портирования игр под Linux/FreeBSD, cmake и других систем сборки достаточно. Только есть ли смысл? Есть список написанных на нем опенсорсных игрушек?

Кроме того, необходимость регистрации на форуме (даже чтобы просто почитать), отсутствие контактов на сайте и публичного доступа к VCS отталкивают.

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

По поводу доступа к сырцам - на сайт регулярно выкладывается девпак со свежими сырцами. Данные обновим в грядущем релизе

> По поводу доступа к сырцам - на сайт регулярно выкладывается девпак со свежими сырцами.

Это несколько противоречит с первым постом в теме. Кроме того, как пикажете слать патчи, в свой VCS все это загонять?

0.5.89 с сайта в принципе нормально собирается под FreeBSD за исключением Src.User, в котором начинаются windows-специфичные вещи. В 0.5.89а разделения реализации Linux/Windows - специфичных вещей я вообще не нашел, include <windows.h> прям в общем коде, ковыряться не стал.

Еще вопрос - оно сможет работать без FMOD и CG Toolkit? Эти блобы под FreeBSD собрать не удосужились, так что звиняйте.

И вопрос насчет (опенсорсных) продуктов, использующих движок, остается открытым.

1. с FMOD, по идее, работать должно - под win32 проблем нету CG Toolkit - это что ? (с аббревиатурой CG только С for Graphics от nVidia ассоциируется)

2. да, про win-специфичные вещи мы знаем. более того, вовсю от них избавляемся - там эти #include<windows.h> без #ifdef-ов в большинстве своём "по недосмотру" :) в новом релизе всё будет лучше. просто не хочется напрягать людей и выкладывать только движковый сырец без примеров.

с патчами пока никак, думаем над поднятием VCS - просто хостинг в текущем состоянии не поддерживает.

вообще спасибо за советы. вопрос был не в том, как собрать - я уже собирал клиентский консольный пример с движком под линукс полтора года назад. да и вообще, с 98-го года программирую с использованием gcc, делал что-то даже на svgalib'е. просто, к сожалению, так сложилось, что графику на линуксе не жаловали, поэтому до последнего времени мы и не лезли на открытые системы.

по поводу проектов - двиг начался исключительно для своих разработок, в т.ч. коммерческих. вот на подходе редактор, которым , в принципе, могли бы воспользоваться сторонние люди. мы просто не могли тратить время на пиар (и вообще всё не так быстро, как хотелось бы), поэтому несмотря на то, что возраст движка немногим меньше того же Irrlicht и OGRE, не всё так радужно с распространением.

> с FMOD, по идее, работать должно - под win32 проблем нету

Я имел в виду _без_ FMOD.

> CG Toolkit - это что ? (с аббревиатурой CG только С for Graphics от nVidia ассоциируется)

Да. http://developer.nvidia.com/object/cg_toolkit.html

> с патчами пока никак, думаем над поднятием VCS - просто хостинг в текущем состоянии не поддерживает

Для read-only доступа как минимум в Mercurial можно просто выложить репозиторий как есть в www. И обновлять из центрального по крону или как удобно.

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

Ага, значит я неправильно понял фразу `требуются заинтересованные в 3d-графике участники'.