Сообщения на форуме пользователя Andrey (129 стр.)
Direct3D GeForce 6600 GT проблема с большим вершинным буфером. | 8 окт. 2007 | 13:29 | #2 |
---|
ilusha_nil
э... драйвер интрументальный тот что с PerfHUD 5.0 поставлялся и он достаточно свежий.
э... драйвер интрументальный тот что с PerfHUD 5.0 поставлялся и он достаточно свежий.
[OpenGL] Передача нескольких текстур в шейдер | 8 окт. 2007 | 13:27 | #5 |
---|
DoPinG
может нужно другие конатнты передавать?
GL_TEXTURE0_ARB...GL_TEXTURE3_ARB
и каков результат glGetUniformLocationARB(progObj[SPECULAR], "reflectionMap") ? что выдает?
Правка неправильно высказал про передачу текстур.
может нужно другие конатнты передавать?
GL_TEXTURE0_ARB...GL_TEXTURE3_ARB
и каков результат glGetUniformLocationARB(progObj[SPECULAR], "reflectionMap") ? что выдает?
Правка неправильно высказал про передачу текстур.
Правка: 8 окт. 2007 13:34
Direct3D GeForce 6600 GT проблема с большим вершинным буфером. | 8 окт. 2007 | 13:15 | #0 |
---|
Привет всем!!
Создаю большой вершинный буфер для травы 48168960 байт (45 метров) траву рисую DIP на 8192 полилка после обхода
дерева в листьях которого группа травинок с 1 текстурой. По максимальному значению индекса выходит около 1800000 т.е. по D3DCAPS9 все ок.
В результате разных запусков на GeForce 6600 GT (на 7300/7600 пробовал 1 раз)
наблюдались странные вещи от причудливых узоров до полного отсутствия порчи текстуры вот скрин:
поясняющие проблему. Ближе к концу вершинного буфера(в этому случае позиция листьев построенного дерева групп травинок
будет на большем расстоянии от начала координат т.е. в конце сцены) трава вдобавок не рисуется вообще.
В отладки рендера
на NVIDIA PerfHUD 5 выяснилось что DIP вызывается, а травы внутри его нет вдобавок почему-то ограничивающий бокс групп травинок
почему-то большой, хотя программно, если посмотреть в отладке, он вполне корректный, как и отсечение его посредством Frustum Culling'а.
вот 2 скрина при отладке в NVPerfHUD на 1 показано корректная отрисовка группы травинок на другом с ошибкой.
Еще заметно сильное снижение FPS при повороте таким образом что становятся видны те листья с травой которые имеет неправильный
ограничивающий бокс. DXDebug на это ничего не говорит. Убрав практически все кроме отрисовки травы ситуация не изменилась
вот санскритом показывающий результат.
К тому-же еще подпортился вывод текста через ID3DXFont. Вдалеке не видна трава в дальних
листьях дерева.
Иногда получается вылечить это уменьшив размер вершинного буфер до 34406400 байт(32 метра). Но это конечно не выход
На дубовых как я понял картах ATI 9600/X300SE/X1300 такого происходите и трава рисуется полностью в любом положении камеры
на сцене. В случае OpenGL рендера трава рисуется корректно на любой карте.
Что я делаю не так? Спасибо всем заранее. С уважением Андрей.
Создаю большой вершинный буфер для травы 48168960 байт (45 метров) траву рисую DIP на 8192 полилка после обхода
дерева в листьях которого группа травинок с 1 текстурой. По максимальному значению индекса выходит около 1800000 т.е. по D3DCAPS9 все ок.
В результате разных запусков на GeForce 6600 GT (на 7300/7600 пробовал 1 раз)
наблюдались странные вещи от причудливых узоров до полного отсутствия порчи текстуры вот скрин:
поясняющие проблему. Ближе к концу вершинного буфера(в этому случае позиция листьев построенного дерева групп травинок
будет на большем расстоянии от начала координат т.е. в конце сцены) трава вдобавок не рисуется вообще.
В отладки рендера
на NVIDIA PerfHUD 5 выяснилось что DIP вызывается, а травы внутри его нет вдобавок почему-то ограничивающий бокс групп травинок
почему-то большой, хотя программно, если посмотреть в отладке, он вполне корректный, как и отсечение его посредством Frustum Culling'а.
вот 2 скрина при отладке в NVPerfHUD на 1 показано корректная отрисовка группы травинок на другом с ошибкой.
Еще заметно сильное снижение FPS при повороте таким образом что становятся видны те листья с травой которые имеет неправильный
ограничивающий бокс. DXDebug на это ничего не говорит. Убрав практически все кроме отрисовки травы ситуация не изменилась
вот санскритом показывающий результат.
К тому-же еще подпортился вывод текста через ID3DXFont. Вдалеке не видна трава в дальних
листьях дерева.
Иногда получается вылечить это уменьшив размер вершинного буфер до 34406400 байт(32 метра). Но это конечно не выход
На дубовых как я понял картах ATI 9600/X300SE/X1300 такого происходите и трава рисуется полностью в любом положении камеры
на сцене. В случае OpenGL рендера трава рисуется корректно на любой карте.
Что я делаю не так? Спасибо всем заранее. С уважением Андрей.
Правка: 8 окт. 2007 13:30
Отдельные функции матлибы перестали линковатся в release | 4 окт. 2007 | 16:02 | #3 |
---|
Ghost2
либа то у него собирается нормально. Но не получается ее использовать, т.е. линковщик не находит функций и методов.
если не сложно сделай тестовый консольный проект
и попробуй использовать эту библиотеку. На Visual C++ 2003 все линкуется. Вот примерный код:
Sbtrn. Devil
>Может, полный ребилд?
не помогает.
либа то у него собирается нормально. Но не получается ее использовать, т.е. линковщик не находит функций и методов.
если не сложно сделай тестовый консольный проект
и попробуй использовать эту библиотеку. На Visual C++ 2003 все линкуется. Вот примерный код:
#include "phMathLib.h" int main(int argc, char* argv[]) { VECTOR3D a(1.0f, 1.0f, 1.0f); VECTOR3D b = a + VECTOR3D(2.0f, 3.0f, 4.0f); VECTOR3D c = MathUtils::Cross(a,b); return 0; }
>Может, полный ребилд?
не помогает.
глюки с бинарными файлами | 27 сен. 2007 | 19:07 | #18 |
---|
pentagra
>Так ты про размеры хедеров говоришь :) я подумал, что ты про размер файла в который пишут :))
я говорил про рамер исполняемого файла проекта который использует std::fstream или FILE *
>Так ты про размеры хедеров говоришь :) я подумал, что ты про размер файла в который пишут :))
я говорил про рамер исполняемого файла проекта который использует std::fstream или FILE *
глюки с бинарными файлами | 27 сен. 2007 | 11:53 | #14 |
---|
BLo
строки.
строки.
глюки с бинарными файлами | 26 сен. 2007 | 20:04 | #11 |
---|
pentagra
>А можно поподробнее про размер файла? Это с чего он больше будет?
ну там есть вызовы виртуальных функций там есть исключения(вроде-бы) и это просто враппер над FILE * по крайней мере под Windows можешь глянуть исходники
как то жделал тест fprintf против std::ofstream& operator << дак fprintf выиграл. Я в движках чаще вижу FILE * чем потоки. Лучше написать свой враппер со своими типами.
>А можно поподробнее про размер файла? Это с чего он больше будет?
ну там есть вызовы виртуальных функций там есть исключения(вроде-бы) и это просто враппер над FILE * по крайней мере под Windows можешь глянуть исходники
как то жделал тест fprintf против std::ofstream& operator << дак fprintf выиграл. Я в движках чаще вижу FILE * чем потоки. Лучше написать свой враппер со своими типами.
глюки с бинарными файлами | 26 сен. 2007 | 13:11 | #1 |
---|
d3dNOOB
попробуй так
я бы использовал обычный FILE * / fopen/fwrite от потоков ввода вывода толку мало только размер файла больше и скорость медленней.
попробуй так
// запись ofstream ofile;ofile.open("out.bin",ios::binary ios::binary | ios::out); // зачитка ofstream ofile;ofile.open("out.bin",ios::binary ios::binary | ios::in);
Правка перепутал коментарий
Правка: 26 сен. 2007 13:49
Протестируйте демку Early DepthStencil | 26 сен. 2007 | 13:06 | #24 |
---|
Сообщение в консоле
Vendor: ATI Technologies Inc.
Renderer: SAPPHIRE RADEON 9600 ATLANTIS x86/MMX/3DNow!/SSE2
OpenGL version: 2.0.6847 WinXP Release
GLEW version: 1.3.5
Vendor: ATI Technologies Inc.
Renderer: SAPPHIRE RADEON 9600 ATLANTIS x86/MMX/3DNow!/SSE2
OpenGL version: 2.0.6847 WinXP Release
GLEW version: 1.3.5
Renderer: ATI
FBO unsupported.
Run application.
На клавиатуру не реагирует.
DELPHI (Оцените мой двиг и напишите что хотелибы вы видить в нём) | 24 сен. 2007 | 14:22 | #10 |
---|
0xDEADBEEF
>А вершины при таком подходе вручную трансформировать(Scale, Rotate etc.)?
конечно лучше перенести в шейдер поворот и т.д. но это более сложная реализация тут надо смотреть по быстродействию, если Lock/Unlock/glMapBufferARB и т.д. + запись данных из RAM занимает основную часть времени то перенос трансформаций в шейдер может ничего не дать.
>А вершины при таком подходе вручную трансформировать(Scale, Rotate etc.)?
конечно лучше перенести в шейдер поворот и т.д. но это более сложная реализация тут надо смотреть по быстродействию, если Lock/Unlock/glMapBufferARB и т.д. + запись данных из RAM занимает основную часть времени то перенос трансформаций в шейдер может ничего не дать.
Аварийный выход из программы | 24 сен. 2007 | 12:19 | #6 |
---|
Scorpion_Max_St
для Win32 вместо catch(...) испоьзуй __try...__except
для Win32 вместо catch(...) испоьзуй __try...__except
DELPHI (Оцените мой двиг и напишите что хотелибы вы видить в нём) | 24 сен. 2007 | 12:16 | #5 |
---|
SVSD_VAL
для начала нормально.
оптимизируй движок. не иcпользуй glBegin/glEnd особенно в отрисовке частиц!!!!!.
добавляй тени. добавляй бамп-маппинг и т.д.
делай его более гибче. что-бы больше параметров грузилось из файла. Более детелазированный ландшафт. Лоды...
архитектура там пока не навороченная.
для начала нормально.
оптимизируй движок. не иcпользуй glBegin/glEnd особенно в отрисовке частиц!!!!!.
добавляй тени. добавляй бамп-маппинг и т.д.
делай его более гибче. что-бы больше параметров грузилось из файла. Более детелазированный ландшафт. Лоды...
архитектура там пока не навороченная.
Проблемы с матрицами | 21 сен. 2007 | 16:26 | #8 |
---|
netkeep
не используй double
не используй double
как сделан ландшафт в FarCry? | 20 сен. 2007 | 20:47 | #27 |
---|
Aroch
>зачем каждый раз SetStreamSource? если DIP итак позволяет все это делать
читай мой пост я говорил 1 раз перед отрисовкой...
heihachi
завтра подумаю... ухожу уже... или дам свою нумерацию что-бы не думать а ты потом сообразишь.
>зачем каждый раз SetStreamSource? если DIP итак позволяет все это делать
читай мой пост я говорил 1 раз перед отрисовкой...
heihachi
завтра подумаю... ухожу уже... или дам свою нумерацию что-бы не думать а ты потом сообразишь.
как сделан ландшафт в FarCry? | 20 сен. 2007 | 19:33 | #22 |
---|
heihachi
выглядит все вот так: OffsetVertex - смещение в вершинном буфере в вершинах;
StartVertex - стартовывй индекс вершины;
TotalNumVertex - сколько вершин учавствуют в отрисовке;
NumPolygons - отрисовываемых полигонов
>P.S. Неужели тут ни кто не пишет на С#?
а что это даст? Отменит знания алгоритмов?
выглядит все вот так: OffsetVertex - смещение в вершинном буфере в вершинах;
StartVertex - стартовывй индекс вершины;
TotalNumVertex - сколько вершин учавствуют в отрисовке;
NumPolygons - отрисовываемых полигонов
>P.S. Неужели тут ни кто не пишет на С#?
а что это даст? Отменит знания алгоритмов?