Красивые, но тормозные "ручные" 3d Api, создание Moto 3D API для FPS,QUEST,RPG Поделиться Опции

[Nick-85]

Красивые, но тормозные "ручные" 3D API, написанные полностью на Java можно использовать, например, для создания очень красивых квестов, RPG, стратегий и любых др. типов приложений, в которых допустимо длительное время первоначальной загрузки картинки, а также для полноценного играбильного real-time отображения трёхмерных объектов в небольшой области экрана.
Если вы желаете принять участие в разработке, то просто оставьте своё сообщение в данном топике.

Ниже OFFTOP:
А если вас переполняют негативные эмоции, то вам целесообразно обратиться к психиатру... или к эзотерикам на какой-нибудь bodhi.ru.

[hobbit19]

а что конкретно планируешь сделать?))
в чем помощь нужна?
яву сам хорошо знаешь?

[grafmoto]

Nick-85, ты хочешь написать "ёпен жл" или "директ х" для мотора? а чем тебе:
public super class com.motorola.graphics.j3d.ActionTable
public super class com.motorola.graphics.j3d.AffineTrans
public super class com.motorola.graphics.j3d.Effect3D
public super class com.motorola.graphics.j3d.Figure
public super class com.motorola.graphics.j3d.FigureLayout
public interface com.motorola.graphics.j3d.Graphics3D
public super class com.motorola.graphics.j3d.Light
public super class com.motorola.graphics.j3d.Texture
public super class com.motorola.graphics.j3d.Util3D
public super class com.motorola.graphics.j3d.Vector3D
не устраивает?

[Nick-85]

а что конкретно планируешь сделать?))
для начала полноценный Java 3D API

в чем помощь нужна?
от моделирования / проектирования до собственно программной реализации и тестирования
горячо приветствуются любители заниматься поиском информации в сети

яву сам хорошо знаешь?
базовыми основами Java владею достаточно свободно

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

To hobbit19:
Какие предметные области в контексте рассматриваемой задачи тебе кажутся наиболее привлекательными?

То все желающие:
Если у вас есть желание принять участие в проекте, то обязательно оставляйте своё сообщение в данном топике.

[Nick-85]

To grafmoto:

Рассмотрим, например, метод public Vector3D AffineTrans::transPoint(Vector3D vector3D) ;

-----------------------------------------------------------------------------------------------------------------------
Преобразование вершин:
-----------------------------------------------------------------------------------------------------------------------
Метод affine_trans.transPoint(vec); // ~ 3 сек на 500.000 (PC); на mobile 13 сек на 10.000
Итого:
770 трансформированных вершин / сек
-----------------------------------------------------------------------------------------------------------------------
// 1 сек vs affine_trans.transPoint(vec) ~3 сек (PC); на mobile 1.2 сек на 10.000
rez.x = vec.x*m[0][0] + vec.y*m[0][1] + vec.z*m[0][2] + m[3][0];
rez.y = vec.x*m[1][0] + vec.y*m[1][1] + vec.z*m[1][2] + m[3][1];
rez.z = vec.x*m[2][0] + vec.y*m[2][1] + vec.z*m[2][2] + m[3][2];
Итого:
8333 трансформированных вершин / сек
-----------------------------------------------------------------------------------------------------------------------
// 0.5 сек vs affine_trans.transPoint(vec) ~3 сек (PC); на mobile 0.7 сек на 10.000
rez.x = vec.x*affine_trans.m00 + vec.y*affine_trans.m10 + vec.z*affine_trans.m20 + affine_trans.m03;
rez.y = vec.x*affine_trans.m01 + vec.y*affine_trans.m11 + vec.z*affine_trans.m21 + affine_trans.m13;
rez.z = vec.x*affine_trans.m02 + vec.y*affine_trans.m12 + vec.z*affine_trans.m22 + affine_trans.m23;
Итого:
14286 трансформированных вершин / сек
-----------------------------------------------------------------------------------------------------------------------
// афинное преобразование с переносом
// ; на mobile ~0.3 сек на 10.000
rez.x = vec.x*affine_trans.m00 + vec.y*affine_trans.m10 + affine_trans.m03;
rez.y = vec.x*affine_trans.m01 + vec.y*affine_trans.m11 + affine_trans.m13;
Итого:
33333 трансформированных вершин / сек
-----------------------------------------------------------------------------------------------------------------------
// афинное преобразование без переноса
// ; на mobile ~0.29 сек на 10.000
rez.x = vec.x*affine_trans.m00 + vec.y*affine_trans.m10;
rez.y = vec.x*affine_trans.m01 + vec.y*affine_trans.m11;
Итого:
34483 трансформированных вершин / сек
-----------------------------------------------------------------------------------------------------------------------

Вывод: метод AffineTrans::transPoint медленнее аналогичного на Java в 18.6 раз.

Разница есть - будет картинка грузится 5 сек или 1.55 мин? К тому же на самописном Java 3D API возможен качественный и быстрый real-time 3D рендеринг в небольшой области экрана.

[hobbit19]

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

[grafmoto]

Nick-85, поздравляю! ты переплюнул программеров самой моторолы! только цифры-цифрами, а лучше один раз увидеть, чем сто раз чего-то там. есть визуальный пример?

[Nick-85]

To hobbit19:
Переписать Java - обработчик в прошивке, насколько мне известно, пока что невозможно.
А вот создать новый Java 3D API или переписать в быстрый Java - код уже существующий и стандартизованный Motorola 3D API вполне возможно.

To grafmoto:
Если найдутся желающие, то примеры будут появляться в процессе работы над новым Java 3D API.
А у тебя самого есть творческий интерес к работе в данной области?

[hobbit19]

Nick-85
так всеже прошивку нужно будет патчить для залития измененого Java 3D API.
если да то может пока потренироваться на увеличении размера флекса за счет удаления не нужных языков
тагже можно увеличить размер Heap c 800кб до 1000кб

[Nick-85]

To hobbit19:
To hobbit19 - также можно увеличить размер Heap c 800кб до 1000кб.
На форуме проскакивала информация о том, что Heap обеспечивается 1024 Кб модулем памяти, из них 1024-800=224 Кб отведены под системные
ресурсы. В любом случае, сейчас патчить прошивку возможным не представляется.

[hobbit19]

To hobbit19:
В любом случае, сейчас патчить прошивку возможным не представляется.

Nick-85 в таком случии как плонируешь изменения в тело залить?))

[grafmoto]

hobbit19, я так думаю что никто не собирается заменять реализацию пакета типа com.motorola.graphics.j3d в прошивке. тут идея написать "внешний" пакет для работы с 3d графикой, т.е. который будет идти вместе с приложением, как его часть. только этот пакет будет неизменным для всех создаваемых 3d приложений. Nick-85, интерес конечно есть, только вот в "математике" 3d обработки боюсь я не силен. буду следить за созданием и помогать чем смогу.

[hobbit19]

а почему бы и не заменить ))
судя по словам VILKO прошивку возможно патчить до перезагрузки

[grafmoto]

а почему бы и не заменить ))
судя по словам VILKO прошивку возможно патчить до перезагрузки

...разговор пошел за пределы темы... ;-)

[Nick-85]

To hobbit19 и всем интересующимся:

Обсуждение замены и создания новых native - методов здесь
Ковырнём Прошивку ...

Если реализовать 3D API в ARM коде, то не DOOM-ом единым будут жить мотороловцы.
Но, быстрее и легче портировать в ARM код уже готовый продукт с продуманными интерфейсом и реализацией, чем создавать всё с нуля.
К тому же, чтобы всё залетало достаточно реализовать в ARM коде всего несколько наиболее тяжёлых методов ( трансформация и освещение массива вершин и растеризация массива полигональных поверхностей с использованием методов перспективно - корректного текстурирования
( а, возможно, с использованием метода квадратичных аппроксимаций ), освещения по Гуро и, возможно, mip-mapping и билинейной или даже трилинейной фильтрации ). Добавлю что внести разнообразие в эти два основных метода можно числом значительно превышающим 20.

[hobbit19]

Nick-85
так ты плонируешь писать просто игровой движек или всеже править обработчик явы в прошивке тела
второе более рационально))

[DG-SC]

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

[grafmoto]

... интересно RADEON 9600 поддерживает все эти методы обработки :-))) ...

[Nick-85]

To hobbit19:
Java обработчик править я пока не хочу, т.к. не располагаю достаточной для осуществления подобного информацией.


Итак приступаем к делу:
Начнём с самого простого класса Vector3D пакета com.motorola.graphics.j3d.

Vector3D___03.11.05___12.45__.rar   ( 1.06 килобайт ) Кол-во скачиваний: 334

To grafmoto:
Хочу, чтобы ты написал программу для сравнения результатов работы методов оригинального и переписанного классов.
Что требуется проверить на mobile:
1) для всех возможных значений входных данных проверить тождественность результатов работы методов оригинального и переписанного классов; в случае обнаружения нетождественности результатов работы вывести соответствующее сообщение с указанием названия проверяемого метода, входных данных для него и полученных результатов для обоих классов;
2) написать код, производящий сравнительное тестирование скорости исполнения методов каждого класса и отображающий полученные результаты на экране;

[grafmoto]

Nick-85, ок. только лучше прикреплять к сообщению файл, а не в сообщение пихать его текст.

[Nick-85]

Ещё один маленький класс Light... его можно не тестировать :)

Ещё два небольших класса - Texture и Effect3D.

Странно, что никто не обращал внимания на то, что com.motorola.graphics.j3d.Graphics3D - это интерфейс!!! Обнаружил это, когда выяснял где же располагается буфер вершин ( а располагается он в ресурсах класса com.motorola.graphics.j3d.ActionTable, т.к. негде ему больше располагаться ). В статье "Creating 3D content for Motorola phones2.pdf" в приводимом примере имеются следующие строчки кода:

//-----------------------------------------------------
public void paint( Graphics3D ) {
...
if( g instanceof Graphics3D ) {
Graphics3D g3d = (Graphics3D )g;
...
}
//-----------------------------------------------------

Класс javax.microedition.lcdui.Graphics реализует интерфейс com.motorola.graphics.j3d.Graphics3D ?

To graphmoto и hobbit19:
Ваши мысли?

[grafmoto]

Ваши мысли?

drink_drunks;

[hobbit19]

grafmoto
а когда будет готов тестовый мидлет для тестирования классов?))
может в него еще показатель загрузки оперативки внесешь?))

[Navigator]

Nick-85, сами отрисовщики (классы, которые рисуют на экране) тоже переписывать будешь? =)

[Nick-85]

To Navigator:
Navigator - Nick-85, сами отрисовщики (классы, которые рисуют на экране) тоже переписывать будешь? =)
Да, это является основной нашей задачей. Если у тебя есть желание, то можешь посмотреть скорость отрисовки куба с исп. com.motorola.graphics.j3d на небольшой площади экрана - думаю, что ты будешь "приятно" удивлён...

У grafmoto творческий прилив... :)

Вопрос ко всем:
Реализует ли класс javax.microedition.lcdui.Graphics интерфейс com.motorola.graphics.j3d.Graphics3D ?

Дописал я всё - таки пример ( исп. афинное текстурирование ) до статуса "в разработке", но:
( - )
1) растеризация по скорости выполнения не оптимизирована;
2) из - за a)небольшой площади растеризуемых треугольников, B)отсутствия подборки более целесообразной, с точки зрения качества отображения, используемой текстуры, c) небольших ошибках в коде растеризации... я бы сразу не сказал, что объект текстурирован... :)
( + )
1) скорость исполнения аналогично неоптимизированного кода при использовании методов перспективно - корректного текстурирования либо совсем не уменьшится, либо уменьшится на незначительную величину. Аналогично при использовании освещения по Гуро ( Gouraud ).
2) скорость исполнения кода, отвечающего за текстурирование можно значительно повысить.
3) исп. сейчас код для обеспечения афинного текстурирования даёт практически идеальную картинку при отображении на экране относительно больших треугольников.
"Детали" вроде отсутствия освещения, отсечения, наличия левого интерфейса и пр. "мелочи" я пока во внимание не беру.

[4ep]

Выложенный мидлет - зашибись (не то что эти квадратики в тестовых прогах ). Только была-бы поддержка 176*220. :(
Но вот такой вопрос. Спомощью этих переписанных классов можно сделать игру какого уровня (в смысле без тормозов)? Можно ли замутить что-нибудь типа SplinterCell как на SE K500i, или хотя бы 3D шутер ак DOOM (первый DOOM).
И второй вопрос. Можно-ли переписать какой-нибудь класс для более быстрого открытия папок в PhoneManager?

[Navigator]

Nick-85, прикольная демка получилась. К сожалению, я не знаю даже основ построения 3D-изображения, так что если выложишь исходники тестового мидлета — буду благодарен.
Кстати,

я бы сразу не сказал, что объект текстурирован...

мне кажется, что он вообще не текстурирован :) Поправьте, если не так ;)

/*** ADDED ***/
Нет, объект текстурируется — оказывается, Fire надо было нажать два раза, а не один :)
Дальше. Когда я пытался приблизить текстурированый объект — мидлет завис.
Выложи, плииз, исходники мидлета.

[hobbit19]

да мидлет у меня как у Navigator тоже повис))
исходники не прошу но сам мидлет надо исправить

[Akceptor]

4ep,
ввиду поддержки 3Д телефоном ни о какой динамики в играх речи нет. Можно 3Д Шахматы, паззл какой-нибудь и т.д.
Nick-85,
Текстурирование заметно. Тормозит безбожно когда текстуры наложены. Зато красиво. :)
ЗЫ Это ниче что я тут написал или тема только для тестеров? :) Меня просто 3Д прет. :)

[Nick-85]

В предыдущий пост добавлено CUBE DEMO - на этой демке текстурирование более заметно.
Афинное текстурирование теперь работает полностью корректно ( для афинного текстурирования :) ).
Если программа "зависает" нажмите несколько раз цифру 3 ( см. файл ReadMe ).
Чуть позднее я с удовольствием отвечу на все оставшиеся вопросы...

To hobbit19: Всё хотел спросить - Это ты на фотке или Джим Керри? :)

[Nick-85]

To 4ep:

4ep - Но вот такой вопрос. Спомощью этих переписанных классов можно сделать игру какого уровня (в смысле без тормозов)?
4ep - Можно ли замутить что-нибудь типа SplinterCell как на SE K500i, или хотя бы 3D шутер ак DOOM (первый DOOM).
В демках переписанные классы не исп., зато при создании переписанных классов активно исп. кодовые ресурсы демки.
Вообще же, с учётом возможности вносить изменения в код прошивки такие игры как DOOM I-II, Duke Nukem 3D и Quake под Mobile вполне могут стать реальностью; если код практически полностью писать под ARM, то возможно даже что - то вроде Quake II или Drakan - Oder The Flame ( здесь уже только если весь код переписать и оптимизировать под ARM микропроцессоры ).

4ep - И второй вопрос. Можно-ли переписать какой-нибудь класс для более быстрого открытия папок в PhoneManager?
??? Где - то проскакивала мысль о том, что некий букридер быстро открывает папки содержащие даже очень большое число файлов, так что если это так, то ничего из стандартных классов переписывать и не требуется. При наличии желания получить дополнительную информацию предлагаю попытаться обратиться к grafmoto.


To hobbit19:

hobbit19 - да мидлет у меня как у Navigator тоже повис))
hobbit19 - исходники не прошу но сам мидлет надо исправить
Мидлет будет работать до тех пор пока не вылетит... :) в случае не реагирования объекта на ваши действия просто отнесите объект от камеры нажав клавишу с номером 3 ( см. ReadMe.txt ).


To Akceptor:

Akceptor - 4ep,
Akceptor - ввиду поддержки 3Д телефоном ни о какой динамики в играх речи нет. Можно 3Д Шахматы, паззл какой-нибудь и т.д.
Положим мы могли бы писать код только под JVM. Тогда, для больших ( на экране ) объектов мы могли бы выполнять растеризацию либо как Fill Mode + Flat Shading, либо как Affine Mode as Sprite Form + Flat Shading Uses Transparent, для небольших ( на экране ) объектов мы могли бы выполнять качественную полноценную растеризацию с освещением по Гуро. Итого, Doom I - II с небольшими упрощениями для ближних стеночек, потолков и полов, зато с полноценными трёхмерными персонажами, качественной и быстрой текстуризаций всех небольших ( на экране ) декораций и т.п. Либо всё текстурировать 64 x 64, но мне больше нравится I вариант, т.к. он побыстрее и покрасивее.
Akceptor - Nick-85,
Akceptor - Текстурирование заметно. Тормозит безбожно когда текстуры наложены. Зато красиво.
гм... а мне казалось, что всё наоборот... :) в любом случае, в CUBE DEMO текстурирование теперь много более заметно, правда, заодно теперь очень заметны и все "прелести" и "особенности" афинного текстурирования.
Akceptor - ЗЫ Это ниче что я тут написал или тема только для тестеров? Меня просто 3Д прет.
Наверное, можно сказать, что и меня тоже "3Д прет"... :)
Тема как раз и создана для всех желающих принять участие в ( разработке нового ) / (переработке стандаризованного Motorola) Java 3D API и, конечно же для тех, кого "просто 3Д прет".


Для всех тех, кого "3Д прет":

Если вы хотя бы немного умеете программировать на Java и имеете желание принять активное участие в разработке Java 3D API, то обязательно сообщите здесь об этом. Подчёркиваю - Обязательно! Кроме несомненного удовольствия от собственно активного принятия участия в разработке вы также сможете повысить и укрепить свои навыки Java - программиста на такой перспективной и бурно развивающейся платформе, как J2ME.

[hobbit19]

Nick-85,grafmoto прогнал тестовый мидлет на мобиле
все работает вопрос тока как отписываться о результатах?
имхо нужно цыфрами производительность измерять.........

2Nick-85
To hobbit19: Всё хотел спросить - Это ты на фотке или Джим Керри? :)
- а что похож?))

[Nick-85]

To hobbit19:
hobbit19 - Nick-85,grafmoto прогнал тестовый мидлет на мобиле
hobbit19 - все работает вопрос тока как отписываться о результатах?
hobbit19 - имхо нужно цыфрами производительность измерять.........
Работает тестовый мидлет или все методы переписанного класса Vector3D ( в последнем я исп. сомнения к методу unit() )?
В любом случае выкладывайте тестовый мидлет сюда, а также всю полученную информацию о работоспособности и производительности методов переписанного класса.

Схема тестирования производительности методов оригинального и переписанного классов может быть, например, такой:
1) Создаём и инициализируем массив на 50 000 тысяч элементов ( или на сколько хватит динамической памяти ) типа оригинального класса Vector3D.
2) "Засекаем" время начала отсчёта.
3) Для каждого элемента массива вызываем желаемый к тестированию метод.
4) Сохраняем прошедшее с момента последнего "засечения" время.
5) Проводим в соотв. с п. 1 - п. 4 аналогичную операцию для переписанного класса Vector3D.
6) Анализируем полученные результаты, делаем выводы и предположения.
7) Делимся полученной информацией со всеми участниками проекта.
8) Проводим п. 1 - п. 7 для всех желаемых к тестированию методов.

Отписываться о результатах можно в произвольной форме; если захотите по - другому, то примем "стандарную" форму.
P.S.: Тестировать код на Mobile, а не на эмуляторе ( хотя на эмуляторе картина обычно похожая ). :)

После нескольких "поверхностных" тестов пришёл к выводу, что на платформе J2ME играбильный real - time rendering при исп. аппроксимационных методов перспективно - корректного текстурирования на экране 128 x 128 с выс. степенью вер. возможен, при условии, что большую, либо очень значительную часть экрана занимают достаточно большие треугольники ( напр., на ближних стенах, полу, потолке и т.п. ). Подобные оптимизации предполагают очень "жёсткую" реструктуризацию программного кода, поэтому до написания всех желаемых к дальнейшему исп. растеризаторов проводить оную я не хочу.

С демками я пока завязываю и переключаюсь на Motorola J3D API.
Последняя демка с перспективно - корректным текстурирование as is, т.е. "в лоб" без исп. аппроксимации - работает очень медленно... выкладываю её здесь.

P.S.1: Качать рекомендую версию с пометкой wall т. к. в ней перспектива видна более чётко + немного более лучшее качество отображения накладываемой текстуры. Версия с пометкой Ero присутствует только для внесения разнообразия в творческий процесс - не рекомендую ждать от неё чего-то сверестественного как в плане качества, так и в любых др. планах :) ). Вообще же, вы можете сами запросто запихать в архив любую текстуру ( для этого достаточно заменить соответствующий файл с расширением .jpg в архиве *.jar ).
Наблюдающийся "шум" на текстурах - из-за ошибок округлений... подправлю позже...

P.S.2: Если кто-то желает получить возможность исп. на Mobile просмотрщик некоторого 3D графического формата ( из-под файловой системы телефона ), то напишите сюда поддержку какого графического формата вы бы хотели получить и почему. Ссылка на описание формата является желательной. Предлагать на рассмотрение желательно форматы файлов, как минимум, с поддержкой освещения, текстурирования и, взм., анимации.

[RedAV]

А можно спросить - что делает секретная кнопка 9?
Еще - можно ли сделать мидлет 2 в 1:
I - вращение куба средствами стандартного API
II - вращение куба средствами Вашего переписанного / оптимизировнного API
для наглядного сравнения :) (имеется ввиду - куб вращается сам, не ручками)

[Mike_cool]

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

[Nick-85]

To RedAV:
RedAV - можно спросить - что делает секретная кнопка 9?
Если я скажу, то она перестанет быть секретной... :)
RedAV - Еще - можно ли сделать мидлет 2 в 1:
RedAV - I - вращение куба средствами стандартного API
RedAV - II - вращение куба средствами Вашего переписанного / оптимизировнного API
RedAV - для наглядного сравнения :) (имеется ввиду - куб вращается сам, не ручками)
Предлагаю сделать по-другому. Я выложу мидлет II кот. вращается практически "без ручек" :)
А ты найдёшь мидлет типа I ( на форуме где-то тут был ) и сравнишь результаты. Идёт?

[Nick-85]

( 06.12.05 ) ( 21.45 )
(+) dynamic light enabled

[hobbit19]

Nick-85
а сколько тебе еще осталось классов переписать чтобы можно было на основе их игру сделать с нормальной графикой?))

[Nick-85]

To hobbit19:
С нормальной графикой - а телефончики с GeForce 4800 уже в продаже? Ну тогда мона и с нормальной... :)
Под Motorola при полном обсчёте без всяких трюков на Java с "нормальной" это Fill Mode + Flat Shading максимум, либо вообще "каркасный" режим. А вот если исп. пререндер, то хоть обратную трассировку лучей, хоть попиксельное освещение...

To ВСЕМ:
Игру можно было бы хоть сейчас пытаться реализовывать ( для начала её концепт - арт ), если бы был хоть один писатель - фантаст или просто человек, обладающий "творческим" мышлением. Есть у кого-нибудь какие-либо соображения по этому поводу?
Отталкиваться можно, например, от жанра игры и от общего описания мира в кот. происходят её основные события.
Желающим высказаться - забудьте про технические ограничения! Заняться урезанием мы всегда успеем... :)

hobbit19, начнём с тебя.
Какую игру ты бы хотел заполучить на свой мобильный телефон?
Твои идеи и предложения по поводу желаемой к созданию игры?

P.S.: Если бы Vilko или кто-либо другой создал API для исполняемых файлов, генерируемых неким С/С++ компилятором, то можно было бы очень быстро перегнать готовый Java проект в код пригодный для восприятия соотв. компилятором, и => в соотв. исполняемый фаил.

[hobbit19]

Мне хотелась бы по типу Doom_RPG
или типа принца персии 4 который только вышел но на 650 не идет.