Сообщения на форуме пользователя Andrey (110 стр.)
GPU PerfStudio | 15 апр. 2008 | 11:17 | #11 |
---|
Executor
Ну у меня она запускалась и на nVidia.
Ну у меня она запускалась и на nVidia.
GPU PerfStudio | 11 апр. 2008 | 20:00 | #4 |
---|
Asgard
ты самую последнюю скачал? если да то у меня тоже не работает. А вот предыдущая работала.
ты самую последнюю скачал? если да то у меня тоже не работает. А вот предыдущая работала.
Не запускаются примеры из OGR-а (windows Vista) | 9 апр. 2008 | 18:13 | #3 |
---|
Vadya1
manifest файл?
отключи попробуй его в опциях линковщика.
manifest файл?
отключи попробуй его в опциях линковщика.
Хранение геометрии в двигле. | 9 апр. 2008 | 11:05 | #18 |
---|
dave
В общем идея правильная но реализация не простая. Тут палка на 2 концах как уже сказали заливка данный в вершинные буфера может загрузить процессор. С другой стороны если в узлах лежит разорванная по материалам геометрия с малым числом полигонов то будет неэффективно рендерить пару сотен полигонов меняя материал. Тут нужно эксперементально смотреть в зависимости от геометрии и материалов как лучше сделать динамический буфер или статический.
Как вариант оставить только отсечение по мешам(Хотя у меня 2 реализации но всетаки я остановился на отсечении на уровня меша). Делать меши не совсем большие или бить большие меши по кускам моделерам. Не обязательно хранить меши именно в листьях. Я к примеру строю Octree для уровня, есть метов FindVisibleObject он ищет список объектов во всех узлах начиная от корневого по сути это уже SceneGraph(Octree это его частный случай). Тут отпадает проблема что мешь нужно разрывать по листьям дерева. Насчет биндинга разных буферов и разных мат ериалов и смены стейтов тоже ситуация усложняется. Все зависит от сложности материалов. Не забывай сортировку по расстоянию для мешей что съэкономи Fill Rate возможно больше чем сортировка по вершинным буферам и материалам. Насчет смены состояний тут нужен свой менеджер состояний.
В общем идея правильная но реализация не простая. Тут палка на 2 концах как уже сказали заливка данный в вершинные буфера может загрузить процессор. С другой стороны если в узлах лежит разорванная по материалам геометрия с малым числом полигонов то будет неэффективно рендерить пару сотен полигонов меняя материал. Тут нужно эксперементально смотреть в зависимости от геометрии и материалов как лучше сделать динамический буфер или статический.
Как вариант оставить только отсечение по мешам(Хотя у меня 2 реализации но всетаки я остановился на отсечении на уровня меша). Делать меши не совсем большие или бить большие меши по кускам моделерам. Не обязательно хранить меши именно в листьях. Я к примеру строю Octree для уровня, есть метов FindVisibleObject он ищет список объектов во всех узлах начиная от корневого по сути это уже SceneGraph(Octree это его частный случай). Тут отпадает проблема что мешь нужно разрывать по листьям дерева. Насчет биндинга разных буферов и разных мат ериалов и смены стейтов тоже ситуация усложняется. Все зависит от сложности материалов. Не забывай сортировку по расстоянию для мешей что съэкономи Fill Rate возможно больше чем сортировка по вершинным буферам и материалам. Насчет смены состояний тут нужен свой менеджер состояний.
Проблема с созданием экспортера для 3ds max9 | 8 апр. 2008 | 10:43 | #12 |
---|
Дядя Саша
>Oxaid
>Я тоже долго парился с экспортерами.
>Остановился на Collada.
>Чего и тебе советую.
пусть человек разберется с экспортом если собирается продвигаться как профессионал. Сторонний стандартизированный и тем более открытый формат, добавить как дополнительный можно успеть всегда.
>Oxaid
>Я тоже долго парился с экспортерами.
>Остановился на Collada.
>Чего и тебе советую.
пусть человек разберется с экспортом если собирается продвигаться как профессионал. Сторонний стандартизированный и тем более открытый формат, добавить как дополнительный можно успеть всегда.
Проблема с созданием экспортера для 3ds max9 | 7 апр. 2008 | 19:44 | #4 |
---|
Oxaid
добавь бибилиотеки
core.lib geom.lib mesh.lib maxutil.lib paramblk2.lib
добавь бибилиотеки
core.lib geom.lib mesh.lib maxutil.lib paramblk2.lib
Диалоговое окно Utility plugin'a 3ds Max | 7 апр. 2008 | 11:15 | #1 |
---|
man32
VM_PAINT обрабатываешь в ID_ENT_CUSTOMPROPS_DlgProc?
VM_PAINT обрабатываешь в ID_ENT_CUSTOMPROPS_DlgProc?
Как скомпилировать STLport под MinGW? | 3 апр. 2008 | 19:04 | #7 |
---|
Monax-At
>так как эта STLport работает одинаково у разных компилей,
врядли
>то как никак переносимость повысится
ты все равно собираешь ее на разных компиляторах. Причем тут переносимость? то что у нее переносимый код это да.
>так как эта STLport работает одинаково у разных компилей,
врядли
>то как никак переносимость повысится
ты все равно собираешь ее на разных компиляторах. Причем тут переносимость? то что у нее переносимый код это да.
Как скомпилировать STLport под MinGW? | 3 апр. 2008 | 17:09 | #5 |
---|
cppguru
>Неужели ты iostreams юзаешь? %)
Я офигел в том что iostream в STLPort внутри напрямую вызывает CreateFile/WriteFile таким образом она не уступает в скорости stdio
вот в стандартной реализации от MS это обертка над stdio. поэтому в тестах fprintf vs std::ofstream fprintf медленней если использовать STLPort
что моженшь сказать по этому поводу?
сам кстати не юзаю iostreams
>Неужели ты iostreams юзаешь? %)
Я офигел в том что iostream в STLPort внутри напрямую вызывает CreateFile/WriteFile таким образом она не уступает в скорости stdio
вот в стандартной реализации от MS это обертка над stdio. поэтому в тестах fprintf vs std::ofstream fprintf медленней если использовать STLPort
что моженшь сказать по этому поводу?
сам кстати не юзаю iostreams
Ландшафт: артефакты на стыках | 2 апр. 2008 | 21:23 | #2 |
---|
BATMEN
BATMEN
У меня такая-же проблема
1) рисовать стягивающие полигоны
2) Hardware Geomorfing в шейдере смещать вершины для стягивания полигонов.
можно вместе решить проблему я остановился на варианте рисолвания стягивающих полигонов.
BATMEN
У меня такая-же проблема
1) рисовать стягивающие полигоны
2) Hardware Geomorfing в шейдере смещать вершины для стягивания полигонов.
можно вместе решить проблему я остановился на варианте рисолвания стягивающих полигонов.
Хранение и рендеринг геометрии | 31 мар. 2008 | 17:29 | #19 |
---|
slava_mib
у меня рендер хранит созданные VB/IB и там это вполне можно реализовать... т.е. при LostDevice он прошелся по массиву созданных VB/IB и все сделал что нужно.
у меня рендер хранит созданные VB/IB и там это вполне можно реализовать... т.е. при LostDevice он прошелся по массиву созданных VB/IB и все сделал что нужно.
Хранение и рендеринг геометрии | 31 мар. 2008 | 17:27 | #18 |
---|
в верху у меня все пока просто и пока устраивает, есть класс DisplayedObject(тут хранится позиция, ограничивающий бокс, узел к которому присоединен объект и т.д.) от него наследуется SceneObject он хранит mesh. от SceneObject наследуется GameObject он хранит данные для игры. класс SceneObject имееет виртуальную функцию Draw и по сути посылает рендеру отрисовку меша с трансформацией. Это не совсем продвинуто и правильно. GameObject не имеет Draw т.к. как я сказал что анимационный сто обычный мешь имеют одинаковый способ отрисовки(предполагается что GameObject имеет анимацию, а SceneObject нет возможно не верно)
Хранение и рендеринг геометрии | 31 мар. 2008 | 17:16 | #15 |
---|
>А как бы это разрулить без привязки к Д3Д?
>Не думаю, что это невозможно.
у меня ничего не привязано. VB хранить число - формат вершин
далее:
для Direct3D Stride для SetStreamSource я храню в массиве элементы которого расположены в порядке объявления форматов вершин.
тогда Stride берутся из массива(заранее заполненного в констукторе рендера) где индекс - формат вершины из VB
для OpenGL немного по другому, там switch по форматам и соответствующие вызовы gl*Pointer/gl*PointerARB
>Не думаю, что это невозможно.
у меня ничего не привязано. VB хранить число - формат вершин
далее:
для Direct3D Stride для SetStreamSource я храню в массиве элементы которого расположены в порядке объявления форматов вершин.
тогда Stride берутся из массива(заранее заполненного в констукторе рендера) где индекс - формат вершины из VB
для OpenGL немного по другому, там switch по форматам и соответствующие вызовы gl*Pointer/gl*PointerARB
Хранение и рендеринг геометрии | 31 мар. 2008 | 16:56 | #13 |
---|
student
ну для Direct3D я просто храню FVF либо IDirect3DVertexDecalration9*
доступны перечисления стандартных наборов форматов вершин часто встречающихся. в зависимости от них создается IDirect3DVertexDecalration9 либо FVF сохраняется.
ну для Direct3D я просто храню FVF либо IDirect3DVertexDecalration9*
доступны перечисления стандартных наборов форматов вершин часто встречающихся. в зависимости от них создается IDirect3DVertexDecalration9 либо FVF сохраняется.
Хранение и рендеринг геометрии | 31 мар. 2008 | 16:50 | #11 |
---|
student
>А зачем вообще здесь лепить абстракции и потом реализовывать буфера для каждого АПИ?
>Повторюсь, почему бы не написать кроссплатформенный класс-аналог Vertex and IndexBuffer , который будет
>являться массивом вершин/индексов с методами вроде Lock() и т.д. и потом всё это напрямую ( ну или с RenderableInfo :) ) пихать
>в рендер?
можнои так.Но я не вижу проблем тебе попробовать это :)
>А зачем вообще здесь лепить абстракции и потом реализовывать буфера для каждого АПИ?
>Повторюсь, почему бы не написать кроссплатформенный класс-аналог Vertex and IndexBuffer , который будет
>являться массивом вершин/индексов с методами вроде Lock() и т.д. и потом всё это напрямую ( ну или с RenderableInfo :) ) пихать
>в рендер?
можнои так.Но я не вижу проблем тебе попробовать это :)