Если у вас есть вопросы или замечания по данной статье, пишите их здесь.

Это сообщение отредактировал(а) $tatic - 30.6.2007, 19:52

$tatic, спасибо за статью. Продолжение будет?

Конечно. Вот сейчас я написал и отправил на форум вторую часть статьи. Прошу ее также обсудить.
Следует отметить, что для корректной работы необходимо исправить код файла Renderer.java, а именно строку

на

В противном случае у программы будет неопределенное поведение.
Предлагайте свои идеи будущих статей.

Статья прикольная, была бы возможность кинул плюс.
Мона ещё написать что нить про OGL3 там привьювка.... вообщем пособирать и изложить, было бы интерестно ;)

За статью респект!

Все сделал как в статье.

Теперь замечания и придирки.
В общем все отлично и все мои замечания и придирки это мелочи.

1. У тебя в примере в классе глфрэйм обьявлена  GLCanvas canvas; а потом в конструкторе снова GLCanvas canvas = new GLCanvas(); нада оставить что то одно, получается два конвала один создается второй так и висит не созданный  хотя ошибки и нет.

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

все.

Теперь вопрос: картинка у нас статичная  - чайник, тогда почему каждый раз разные показания счетчика кадров, от чего они зависят?

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

А вообще $tatic, респект и уважуха  такую тему поднял и развил, модераторам JAVA раздела будет теперь куда отправлять новичков с вопросами о 3D в Java.

Ждем продолжения, ты главное не останавливайся!  

Да и еще, в статье предлагается использовать джаву 1.6, но могу сказать что и на 1.5 данные примеры работаю на ура  а вот с 1.4 не пошло...)))

Это сообщение отредактировал(а) Hidrag - 2.7.2007, 09:35

Большое спасибо за отклики!
Теперь рассмотрим ваши вопросы и предложения ;)


К сожалению по OpenGL 2.x Longs Peak и OpenGL 3.0 Mount Evans конкретной информации довольно мало даже на opengl.org. Дело в том, что ARB все еще работает над интерфейсом и пересматривает все еще раз (можно их только похвалить за это, не стремятся выпустить недоделанную спецификацию). Но даже та информация, которая уже доступна, думаю достойна скорее отдельной статьи, правда все же лучше читать это в оригинале, нежели в переводе. Тем более, к тому времени как будет готов перевод, думаю уже выйдет релиз 


Исправил (удалил объявление локальной переменной).


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


Не следует забывать, что данное приложение работает на платформе Java, которая использует автоматическое управление памятью. Таким образом, во время работы программы периодически происходит отработка сборщика мусора. Вот график использования памяти за первые 30 секунд работы приложения (получен при помощи NetBeans Profiler 5.5).

Розовым цветом показана выделенная JVM куча памяти, фиолетовым - используемая память в данный момент времени.
Как видно, виртуальная машина выделяет приложению память из кучи системы с запасом (а выделение системной памяти происходит достаточно медленно, использование заранее выделенной памяти намного эффективнее, этим и объясняется выигрыш Java перед C++ в некторых тестах). Примерно это 5 Мб.
Периодически происходит постоянное создание объектов (в частности, объекта GLUT), и когда общий объем использованной памяти доходит до ~1.8 Мб, происходит срабатывание Garbage Collector'а. Объем использованной памяти при этом падает до 1.5 Мб. Таким образом, во время периодического срабатывания GC происходит некторое снижение FPS. Однако, с течением времени текущий FPS приложения постепенно увеличивается до некоторого предела. Предположительно, это связано с работой JIT-компилятора и runtime-оптимизации приложения. Однако, это лишь мои предположения.



Ну, определение системного времени занимает ничтожное время в работе приложения. Основные ресурсоемкие методы - это (за исключением процесса создания окна) естественно методы display классов Renderer и FPSMeter (соответственно 86% и 12% полного времени работы приложения). Причем основное время затрачивается в них на вычисление и отрисовку чайника (com.sun.opengl.util.GLUT.evaluateTeapotMesh) и отрисовку строки FPS. Все эти сведения можно легко узнать, выполнив профайлинг (это очень полезно, особенно в таких ресурсоемких приложениях).


Интересно то, что в файлах jogl.jar и gluegen-rt.jar в манифестах указано:

Однако, поскольку Java 1.4 уже морально устарела, думаю, что это не слишком критично, тем более, что теперь есть такие удобные вещи как generics (1.5) и поддержка скриптов (1.6). Последнее очень удобно было бы использовать в играх...

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

Это сообщение отредактировал(а) $tatic - 2.7.2007, 19:15

 resolved


$tatic, спасибо за исчерпывающий ответ!   

$tatic, а что насчет продолжения? Может сделать цикл статей по OpenGL в жаве? Может быть что-то вроде создания простенького 3D движка? Я конечно понимаю, что OpenGL будет везде похож, т.к. сама Java вызывает нативные функции OpenGL, реализованные на данной платформе, но сам Java-way может внести в программу что-то особенное (например какие-то паттерны проектирования), и вот об этом и хотелось бы почитать, о том, что получится, если применить Java-way к OpenGL и играм.

P.s. статья - крутЪ

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

$tatic, 


Так и есть, это буфер. Потому как на том этапе в Renderer.display() мы еще не имеем:



З.Ы.: Статья замечательная, автору респект.

Это сообщение отредактировал(а) TXC - 23.9.2008, 21:42

Статья интересная, это факт. Однако один момент мне не понятен по причине обычной неопытности.
$tatic, мог бы ты чуть детальнее описать следующий абзац:

В частности, что такое нативные библиотеки?..

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

Спасибо.

PS Литературу листаю, однако не все так просто...

Still, 

это обычные виндовые DLL или линуксовые so, написанные на С++ и других языках, которые компилируют напрямую в native code. 

arilou, спасибо, ясно.
Ну и соответственно для Java это библиотеки jar, в частности jogl'а для данного примера.

$tatic, А как быть с кросплатформеностью того приложения, которое использует Jogl? Как я понял Jogl поставляется в виде двух платформонезависимых jar-ов + для каждой платформы свои нативные библиотеки. Если я хочу чтобы моё приложение работало везде мне нужно просто скачать полный комплект нативных библиотек для всех платформ с сайта, далее всех их подключить  к своему проекту. В ходе выполнения программы код из jogl.jar каким -то образом сам будет определять на какой платформе запущено приложение и дергать соответствующие функции из соответствующей нативной библиотеки для этой платформы. Правильно думаю или нет?