LINUX.ORG.RU

Вышел PixelLight 1.0.0

 , , ,


2

3

Вчера был представлен релиз кроссплатформенного фреймворка для разработки 3D-приложений PixelLight.

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

Написан на С++. Основными его достоинствами являются гибкость и расширяемость. Это не только 3D-движок, но еще и законченный фреймворк, позволяющий объединить всё, что необходимо разработчику, не беспокоясь о наличии и версиях внешних библиотек («всё свое ношу с собой»), API или используемой операционной системе. Нижележащие особенности систем и библиотек скрыты за мощной системой компонентов, которая существенно упрощает создание приложений для различных платформ. Этот набор компонентов может применяться для таких аспектов приложения, как рендеринг, звук, физика, сеть, скриптинг и так далее.

Основные особенности:

  • Поддерживаемые платформы: Microsoft Windows (XP, Vista, 7), Linux, Android, Maemo 5 (экспериментально).
  • Подсистемы визуализации: OpenGL, OpenGL ES 2.0, поддерживается отложенный рендеринг.
  • Плагины:
    • гибкая архитектура плагинов;
    • фронтенды: один для собственного GUI PixelLight, один для Qt, и нулевой фронтенд, который используется, например, при рендеринге в фоновый буфер;
    • вывод звука: OpenAL, FMOD и FMODEx;
    • физика: Newton, ODE и PhysX;
    • поддержка множества устройств ввода, например, SpaceNavigator и WiiMote;
    • интеграция стороннего промежуточного ПО, например, SPARK как альтернативный движок систем частиц, или libRocket для интерфейса на HTML и CSS;
    • поддержка Lua и экспериментальных бекендов для Javascript(V8), Python и AngelScript.
  • Продвинутые системы интроспекции, плагинов и компонентов.
  • Плагин для экспорта из Autodesk 3ds Max.

Разработка была начата в 2002 году, первый опубликованный релиз (0.9) стал доступен в августе 2010. Основное внимание в версии 1.0.0 было уделено исправлению ошибок.

В подсистему визуализации была добавлена поддержка тесселяции, объемного рендеринга и инстансинга геометрии. Благодаря сообществу был существенно переработан установщик SDK для Linux (на данный момент существует только в виде .deb пакета) — по заверениям разработчиков, достигнут уровень «искаробочности». Для приложений, созданных с использованием SDK, написаны shell-скрипты, с использованием которых оно может быть запущено без необходимости каких-либо изменений в системе.

С полным списком изменений можно ознакомиться здесь.

Сайт проекта

Linux SDK

Исходный код

>>> Подробности

★★★★

Проверено: boombick ()
Последнее исправление: Silent (всего исправлений: 2)

Омские линуксоиды одобряют.

Ребятки долго запрягали. Но надеюсь быстро поедет.

физика: Newton, ODE и PhysX;

- что-то из этого в Linux работает?

linuxmaster ★★★★
()
Ответ на: Омские линуксоиды одобряют. от linuxmaster

- что-то из этого в Linux работает?

Все неработает!

А ты што думал!

Ониж специально разрабатывали кросплатфоременный движок только для винды!

ПОнимаеш?

anonymous
()
Ответ на: Омские линуксоиды одобряют. от linuxmaster

что-то из этого в Linux работает?

ODE точно работает, ибо Open Dynamics Engine. У Newton точно был SDK под Линукс с so'шками да и исходники открыты.

resurtm ★★★
()

Плагин для экспорта из Autodesk 3ds Max.

Ну ты понял, без блендера тут ловить нечего. Или точнее, некого :)

Aceler ★★★★★
()
Ответ на: комментарий от Aceler

блендер поддерживается плагином assimp(в фреймворке PLAssimp). Я проверял ещё полгода назад, всё работало, так что даже экспортер не нужен

gavlig ★★★
()
Ответ на: комментарий от wingear

не помню, как с ODE, но остальное работает

ode как раз в первую очередь работает. На нем игрушка xmoto сделана.

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

ode как раз в первую очередь работает. На нем игрушка xmoto сделана.

ODE под линуксом работает, но разве xmoto не на box2d?

andreyu ★★★★★
()

Что-то по отзывам этот кросплатформенный фреймворк кросплатформенный в отношении ОС, но на десктопе поддерживает только один видеодрайвер - nVidia (видимо разработчики, как обычно, не осилили спецификации OpenGL). Ну и зачем он такой нужен?

RussianNeuroMancer ★★★★★
()

что делать если у меня Linux 64-битный? как демку-то запустить??? cartoon demo - только 32-битное, не удалось запустить

PLVolumeRenderingDemo:

./PLViewer64
./PLViewer64: 11: shift: can't shift that many
./PLViewerQt64
./PLViewerQt64: 11: shift: can't shift that many

я с огромным интересом смотрю сейчас этот pixellight, хочется сравнить с другими свободными подобными либами

I-Love-Microsoft ★★★★★
()
Последнее исправление: I-Love-Microsoft (всего исправлений: 1)
Ответ на: комментарий от wingear

у меня ноут AMD с HD6320, так вот всего 2 FPS на демке PLVolumeRenderingDemo, и то запустилось после правки скрипта запуска (убрал команд shift - нахрена она вообще нужна если не работает как надо)

в самом деле, вероятно оно умеет только дрова от nVidia - это бред

но я призываю не спешить с оценкой, это первый релиз, если оно в самом деле такое «плагинизированное», то вероятно это хороший задел на будущее - посмотрим

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от ACR

а что не так с несчастными 45-ю метрами саурсфорджа которые у меня по EGDE (МТС СуперБит) скачалось без проблем?

20 метров ресурсы и по 50 и 65 Мб соответственно - там бинарники для 32 и 64

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от RussianNeuroMancer

> Что-то по отзывам этот кросплатформенный фреймворк кросплатформенный в отношении ОС, но на десктопе поддерживает только один видеодрайвер - nVidia (видимо разработчики, как обычно, не осилили спецификации OpenGL). Ну и зачем он такой нужен?

Почему-то мне кажется, что у тебя не точные данные, а предположение. Как и с KWin и gnome-shell. Ты во всех случаях говоришь что это отход от спецификаций, а не баг драйвера.

ZenitharChampion ★★★★★
()
Последнее исправление: ZenitharChampion (всего исправлений: 1)
Ответ на: комментарий от andreyu

ODE под линуксом работает, но разве xmoto не на box2d?

avl@Qosmio:~$ ldd `which xmoto` | grep ode

libode.so.1 => /usr/lib/libode.so.1 (0xb747a000)

avl@Qosmio:~$ ldd `which xmoto` | grep box

AVL2 ★★★★★
()
Ответ на: комментарий от Hackeridze

попробовал демку на проприетарном драйвере AMD на карте HD6320 - оно запустилось, но всего 2 fps - под Linux

но оно еще Mac OS X 10.6+ держит, в доках написано

возможно это какое-то недоразумение что так мало, может пока еще не добрались до AMD-карт, в будущем наверняка да

скачал видео-демку, вижу там объемный свет и тени, динамические карты теней... HDR, прочее прочее... не думаю что движок хуже чем от Valve

думаю на него стоит обратить внимание, скриптование на питоне... придется выучить

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Понятно, стоит повременить...

думаю на него стоит обратить внимание, скриптование на питоне... придется выучить

Вроде же еще на Lua(ИМХО зе бест фор скриптинг, сам его освоил за... 4 минуты для скриптования minetest) можно.

Hackeridze
()
Ответ на: комментарий от ZenitharChampion

Почему-то мне кажется, что у тебя не точные данные, а предположение. Как и с KWin и gnome-shell.

Не помню, что насчёт KWin, но насчёт Gnome Shell есть вполне точные данные.

Ты во всех случаях говоришь что это отход от спецификаций, а не баг драйвера.

Обратите внимание, не я один.

RussianNeuroMancer ★★★★★
()
Ответ на: комментарий от Hackeridze

ну... какой язык для скриптов - это по вкусу уже выбор :)

новость хорошая, даже не знал что такой мощный и фичастый фреймворк есть, надо для одного проекта, там у меня nVidia будет стоять, так что пока сойдет :)

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от RussianNeuroMancer

Помню, когда в бета-версии открытого драйвера добавили поддержку чипсета Radeon R600, я скомпилировал релиз-кандидат нового ядра, новый libdrm, новые драйвер и Mesa. Что же я увидел. Neverball - почему-то когда шейдерная монета наклоняется, у неё белый отблеск. Просто белая заливка, а должна потемнеть или посветлеть, в зависимости от направления. С софтовой отрисовкой с помощью тоже Mesa работало хоть и медленно, но идеально.

Игра в Wine работала, но с 0 FPS и с мерцанием объектов, когда ещё текстура стен пропадала на секунды, и я видел что за стеной. Хороший способ почитерствовать: вывести сетевую игру с таким драйвером на телевизор, и посматривать, сидя за компьютером. Я понял что это за баг, когда попробовал Unreal Tournament 2004: там когда FPS хороший всё хорошо, но стоит ему снизиться, как он неожиданно падал до 0-1, и на секунды пропадали текстуры.

DooM III на софтовом рендеринге хоть и моделировал с 1 кадром в 3 секунды, но идеально, как и должно было быть! Почему-то даже в наши дни я вижу неправильные цвета или артефакты с открытым драйвером. А в 2008 тестовый драйвер приводил к Kernal Panic. В меню логотип игры переместился сверху в самый центр и стал почти чёрным, с едва различимыми бегающими точками из оригинальной анимации картинки, потом загрузка игры и Kernel Panic.

Потом был релиз драйвера ati для этого чипсета. В него вошли все найденные мной баги. Прошло 3 года, баг с падением FPS исправили, и наверное только его. Точечно. Наверное, на баг потому обратили внимание, что в багрепорт просили исправить очень много людей. Баг в Neverball остался. Недавно исправили Kernel Panic в DooM III - я не знаю номера релиза, в каком именно - но он не исправлен до конца: после продолжительной игры всё равно возникает.

Недавно я повторил то действие, последний релиз-кандидат ядра, libdrm, драйвер, Mesa. Даже на последнем на тот момент драйвере наблюдался главный баг открытых драйверов ATi/AMD: несмотря на то, что в Mesa появляется всё больше новых расширений OpenGL, даже в старых играх есть неправильно передаваемые цвета, рваные тени, артефакты! DooM III, Unreal Tournament 2004. Neverball, SuperTuxKart! При этом ещё в 2008 году с софтовой отрисовкой ничего из этого не было, но работало медленно. Значит, баг вовсе в недоделанном Mesa (OpenGL), а в драйвере!

Насчёт скорости. Мой нетбук позволяет играть в Quake III Arena, и в Unreal Tournament 2004. С 1366x768, на максимальной графике, с большим значением FPS. Пробовал бОльшее разрешение на внешнем мониторе, на динамичных сценах UT2004 был низкий FPS. Снизил эффекты - на то и придумали настройки, чтобы не страдать с низким FPS на максимальных эффектах. А значит, на Unreal Tournament 2004 GPU нетбука хватает едва-едва.

А теперь открытый драйвер. UT2004 на максимальной графике, конечно, не работает: эталонный закрытый же едва-едва выдавал необходимый FPS на максимальной графике с моим разрешением экрана. Однако просто снижения уровня графики с максимального до среднего не хватило - не тормозит только когда 800x600. Что ж, может игра, вышедшая за 5 лет до Unreal Tournament 2004, не тормозит? Нет! Quake III Arena тормозит на максимальной графике. Ну ничего себе!

Вывод: открытым драйвером видеокарты можно пользоваться только на рабочих станциях. Там мощность GPU избыточна, в Quake III Arena это тысячи FPS. Если открытый драйвер выдаёт только 50% от них, играть всё равно можно. На нетбуках открытый драйвер противопоказан: ни беспроблемного энергосбережения, ни хорошего FPS. Закрытый ведь позволял запускать неслабые игры... А открытый даже Quake III Arena позволяет играть только на средней графике. Чего уж говорить об играх, вышедших после 2000 года... Остаются только эмуляторы приставок, использующие эффекты с помощью OpenGL, и 2D-игры вроде Braid.

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

ZenitharChampion ★★★★★
()
Последнее исправление: ZenitharChampion (всего исправлений: 1)
Ответ на: комментарий от ZenitharChampion

открытым драйвером ATi

Ныть все горазды, а патч написать? Ну и да, всё время использовал проприетарный драйвер, всё (кроме некоторых вайновских изращений) в принципе работало.

PolarFox ★★★★★
()
Ответ на: комментарий от ZenitharChampion

Вы путаете баги реализации с намеренной реализаций вразрез стандарту, так что сделанные таким образом выводы заведомо ошибочны.

RussianNeuroMancer ★★★★★
()

Я решил что нет смысла гадать на тему поддержки AMD, я не поленился и прямо написал разработчикам этого PixelLight письма с прямым вопросом о AMD видеокартах под Linux.

Как будет ответ - я напишу его сюда.

I-Love-Microsoft ★★★★★
()

Ниасилил...

Объясните для слоупока, вот я хочу сделать пожертвование на разработку какого-то из этих проектов, разработчики наберут необходимую сумму для реализации проекта. Что потом от этого получу я? Мне дадут продукт или дадут мне право купить его? Проект станет всем доступен или только тем, кто пожертвовал или всем?

amazpyel ★★★
()
Ответ на: комментарий от wingear

Вот, мне ответили разработчики PixelLight... быстро они ответили. В общем суть ответа такова - некоторые разработчики PixelLight юзают ноутбуки с AMD и графика соответствующая.

Так что нет никаких проблем в частности сабжа этой новости с AMD, соответственно «не нужно потому что только для nVidia» исключается.

Кстати, вот уже пользуюсь проприетарным драйвером для AMD на ноуте несколько недель, проблем вообще НОЛЬ. Проблем не больше и не меньше чем с nVidia - я удивлен.

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

конкретно не могу сказать, т.е. у каждого проекта свои условия донатов?

amazpyel ★★★
()
Ответ на: комментарий от I-Love-Microsoft

Пишут что есть проблемы с Mesa и драйвером Intel для Windows. Как-то странно, согласитесь?
В сумме получается, что есть поддержка Catalyst и драйвера nVidia, чего всё ещё недостаточно, чтобы брать за основу этот «кроссплатформенный фреймворк для разработки 3D-приложений».

RussianNeuroMancer ★★★★★
()
Ответ на: комментарий от RussianNeuroMancer

Не помню, что насчёт KWin, но насчёт Gnome Shell есть вполне точные
данные.

А вы можете разжевать непонятливым, что там вообще написано? По-моему, полный бред: --- The #version directive must occur in a shader before anything else, except for comments and white space. So the original operation was right. But NV's behavior looks like: --- При чём тут NV?

--- a. only preprocessor codes could be placed before «version» --- А выше написано, что только комменты и пробел могут, значит, в NV мягче требования.

--- b. pragma and extension can't be placed before «version» --- И что? Где тут противоречие с процитированной им же строкой из стандарта?

--- c. the codes between «if» «else» «endif» can't contain no-preprocessor codes. --- И что? При чём тут это вообще? На пьяный бред смахивает. Разъясните плиз.

anonymous
()
Ответ на: комментарий от anonymous

Какие же сволочи убрали ручное форматирование, теперь с этим lorcode ещё возиться. :)

anonymous
()
Ответ на: комментарий от anonymous

При чём тут NV?

При том, что на NV не падало.

значит, в NV мягче требования

Как раз в этом и проблема. Остальное вероятно просто пояснение по пониманию инженерами nVidia данной строки спецификации.

RussianNeuroMancer ★★★★★
()
Ответ на: комментарий от RussianNeuroMancer

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

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от RussianNeuroMancer

При том, что на NV не падало.

А с каких пор NV стал референсной реализацией? На открытых дровах работает? На софтварном рендеринге работает? Как я понимаю, софтварный рендеринг в месе сейчас считается более-менее референсным, но никак не NV.

Тут есть ещё важный момент в том, что то, что он пишет про NV - на самом деле не нарушение спецификации. Он пишет, что в спецификации разрешено перед version ставить только коменты и пробел, но это - требование к пользовательскому ПО, а не к драйверу. В спецификации не написано, что должно происходить в случае, если это требование не выполнено, то есть, это всего лишь неописанное поведение, unspecified behavior. В случае NV, неописанное поведение - нормальная работа проги, а в случае AMD - падение. Я бы не сказал, что AMD тут сильно права. Unspecified behavior != undefined behavior, и это надо чётко понимать. Нельзя читать спецификацию, и на всё, что она не описывает, ставить assert'ы.

anonymous
()
Ответ на: комментарий от anonymous

А с каких пор NV стал референсной реализацией? На открытых дровах работает? На софтварном рендеринге работает?

Не факт, что данный код задействован в случае Mesa. (Я лично не проверял Metacity, но разные code path для разного железа/драйверов/версий драйверов вроде обычная практика; свежий пример.)

Тут есть ещё важный момент в том, что то, что он пишет про NV - на самом деле не нарушение спецификации.

Unspecified behavior != undefined behavior, и это надо чётко понимать. Нельзя читать спецификацию, и на всё, что она не описывает, ставить assert'ы.

Что-то мне подсказывает, что одному из инженеров, пишущих спецификации OpenGL для Khronos Group можно доверять в отношении определения того, что соответствует спецификации OpenGL, а что - нет. Если вы с этим не согласны - вы можете сами ему написать. Он всегда отвечает.

RussianNeuroMancer ★★★★★
()
Ответ на: комментарий от RussianNeuroMancer

но разные code path для разного железа/драйверов/версий драйверов вроде обычная практика

Но тогда бы и он про NV вряд ли говорить стал, а, кроме того, тогда бы и для АМД-драйвера был бы код, который работает с ним.

одному из инженеров, пишущих спецификации OpenGL для Khronos Group можно доверять

Я, в основном, имел ввиду тот пост на слешдоте, на который вы ссылались, а не слова инженера. Там чувак реально хочет, чтобы любая неописанная вещь давала бы ассерт-фейл (ну это его личное пожелание), и думает, что неделание этого есть нарушение спеков - а вот это уже чушь. Только если в спеке будет сказано «если вы нарушаете это требование таким-то образом, то получите такую-то ошибку; если другим - то вот такую», тогда надо делать именно так. Но спеки практически никогда так не пишутся, а люди всё равно делают из них выводы, что называется, в меру своей испорченности.

Инженер, кстати, про которого вы говорите, всё исправил, так что он, видимо, придерживается тех же взглядов, что и я (ну то есть, по-просту, знает, как надо спеки читать, и знает, что они пишутся не для драйверописателей, а для тех, кто просто использует OpenGL в своей проге)

anonymous
()
Ответ на: комментарий от anonymous

Только если в спеке будет сказано

... либо, в критических местах, спек может говорить «the behavior is undefined», давая понять, что так делать не надо. А если он просто ничего не говорит про случай нарушения, и какой-то драйвер не возвращает при этом ошибку - это вовсе не нарушение спеков, а просто лояльная отработка неописанного поведения. Linux, кстати (который ядро) всегда отрабатывает неописанные posix'ом ситуации наиболее лояльно.

anonymous
()
Ответ на: комментарий от anonymous

Но тогда бы и он про NV вряд ли говорить стал, а, кроме того, тогда бы и для АМД-драйвера был бы код, который работает с ним.

А не допускаете, что ситуация такая же, как в случае KWin - ни один из разработчиков банально не пользуется fglrx, хотя для всех других драйверов различные code path есть?

Инженер, кстати, про которого вы говорите, всё исправил

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

так что он, видимо, придерживается тех же взглядов, что и я

...потому что если попробовать с ними взаимодействовать, можно получить ответ в духе «ПНХ». Так что глядя на пример с KWin, теперь я отлично понимаю, почему вместо оформления багрепорта на Metacity, он просто реализовал workaround для предотвращения падения.

это вовсе не нарушение спеков, а просто лояльная отработка неописанного поведения

Что имеем: лояльная обработка неопределённого поведения в драйвере nVidia, привела к тому, что разработчики WINE долгое время считали, что видеодрайвер в Linux только один, а Хуанг - пророк их.

RussianNeuroMancer ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.