Сообщения на форуме пользователя Andrey (4 стр.)
3DSMax Export Bounding box + Animation | 21 ноя. 2012 | 15:19 | #2 |
---|
1) Попытаться применить к мешу модификатор, если это возможно.
2) попытаться вычислить самому BoundingBox используя Native 3DS Max API. В IGame может что-то есть но я слабо знаком с ним. Ну IGame это толстая оберртка над Native 3DS Max API
Но будет ли BoundingBox корректный после применения модификатора?
в Native 3DS Max API берутся меши с узлов используя время текущего кадра. По крайней мере я так экспортировал морфичую анимацию, но я не помню есть ли в той модели модификатор skin Стало быть, если вызвать построения ограничивающего бокса у меша для данного кадра, то он по идее будет корректный.
Mesh* maxMesh = mesh->GetMaxMesh(); maxMesh->buildBoundingBox(); ... Box3 d; mesh->GetBoundingBox(d);
Windows vs MacOS | 21 ноя. 2012 | 12:50 | #39 |
---|
Render Target - DirectX 9 - AMD RADEON [Решено] | 20 ноя. 2012 | 18:59 | #27 |
---|
INDICES_PER_SPRITE == 6 ?
VERTICES_PER_SPRITE = 4 ?
индексируешь спрайты как? Наверное так: {0,1,2,2, 3,0 } {4, 5,6,6,5,4}
Render Target - DirectX 9 - AMD RADEON [Решено] | 20 ноя. 2012 | 12:43 | #22 |
---|
> Ну так если ошибка в драйвере - чем поможет DXDebug ?
Ничем. Но тут случай что nVidia в драйвере глотает ошибки, и программист видя корректный результат, думает что это переносимо. Но на ATI или XBox это может не работать.
> Это как тесселяция на AMD крашится, если не всё указать как надо ?
ничего не могу сказать по этому поводу.
Render Target - DirectX 9 - AMD RADEON [Решено] | 20 ноя. 2012 | 12:33 | #20 |
---|
> Direct3D9: (ERROR) :Invalid index in the index stream: 424
Ну понятно. Классика :) nVidia на ура игнорирует ошибки в параметрах, и все рисуется ну и начинается гон что ATI/AMD отстой.
вот тут я подробно написал свои исследования. Попробуй копать отсюда.
http://www.gamedev.ru/code/forum/?id=148800&page=2#m15
в Direct3D10/11 с этим все намного проще.
Render Target - DirectX 9 - AMD RADEON [Решено] | 20 ноя. 2012 | 11:56 | #14 |
---|
> на граф картах Nvidia все шикарно
1) Запустить на nVidia DxDebug с полным Debug Output Level.
2) Если не поможет DxDebug + D3DCREATE_SOFTWARE_VERTEXPROCESSING(Если позволит быстродействие)
Direct3D Runtime обычно пишет ошибку(при отладочной версии). Ему абсолютно пофигу на то что реализовал вендор в дровах. nVidia точно плюет на некоторые неверные параметры. Как они могли нарушить спецификацию не понятно. Может из-за того что разошлись после совместной разработки с Microsoft шейдерного языка.
Большое число DIP, маленькие буфера, fps нормальный. Теория батчинга не работает? | 17 ноя. 2012 | 22:36 | #7 |
---|
> а если тоже самое, что в первом посте рисовать, но за один дип, то сколько фпс?
> 65
Вертикальная синхронизация отключена ? 8000 * 32 = 256000 поликов 65 при FPS. Что-то маловато. причем шейдеров сложных нету. Что за видюха ?
как проверить попадание треугольника при растеризации в указанный прямоугольник на экране? | 17 ноя. 2012 | 16:42 | #5 |
---|
> И получи деление на ноль, если не повезло?
Проверки делать нужно естественно.
как проверить попадание треугольника при растеризации в указанный прямоугольник на экране? | 17 ноя. 2012 | 15:29 | #3 |
---|
1)Трансформируй координаты вершин треугольника в экранные
2) проверяй принадлежность вершин в заданном прямоугольнике
SoftGL: Water (комментарии) | 14 ноя. 2012 | 17:58 | #26 |
---|
Офигенно!
OpenGL - Массив вершин и свойства материала | 14 ноя. 2012 | 17:37 | #7 |
---|
> Пиксельный шейдер произведет интерполяцию
Ок, это наверняка делает растеризатор. Но к растеризатору "ближе" пиксельный шейдер вот я и сказал так. Понятнее так.
OpenGL - Массив вершин и свойства материала | 14 ноя. 2012 | 10:31 | #2 |
---|
> Вот собственно и вопрос - как вывести этот объект используя характеристики
> материала(Ambient, Emission, Specular и т.д)
Пишешь вершинный шейдер передаешь туда константы (Ambient, Emission, Specular) рассчитываешь цвет(освещение) передаешь результат в пиксельный для интерполяции. Это и будет для каждой вершины. Пиксельный шейдер произведет интерполяцию в пределах треугольника, используя значения цвета в вершинах, но это будет грубо смотреться.
Но лучше это делать в пиксельном.
Если без шейдеров, то смотри всякие glMaterial*, glEnable, но лучше не делаеть этого. Наверняка железо современное.
GL Optimisation (glUniform?) | 11 ноя. 2012 | 22:52 | #10 |
---|
for(unsigned int i = 0; i < lights.size(); i++) { ... if(cur > MAX_LIGHTS) break; }
unsigned int numLight = std::min(MAX_LIGHTS, lights.size()); for(unsigned int i = 0; i < numLight ; i++) { ... }
position[cur] = lights[cur]->GetPosition(); ambient[cur] = lights[cur]->GetAmbient(); diffuse[cur] = lights[cur]->GetDiffuse(); specular[cur] = lights[cur]->GetSpecular(); attenuation[cur] = vec3(lights[cur]->GetAttenuation()); spotDirection[cur] = vec3(lights[cur]->GetSpotDirection()); spotExponent[cur] = lights[cur]->GetSpotExponent(); spotCosCutoff[cur] = lights[cur]->GetSpotCosCutoff(); transforms[cur] = lights[cur]->GetTransform();
> map<string, float>
от жесть...
for(unsigned int i = 0; i< textures.size(); i++) { URenderer::GetInstance()->BindTexture(textures[i].first, textures[i].second); URenderer::GetInstance()->Uniform1(textures[i].first->name, textures[i].second); } |
1) проверяй id текстуры.
2) не вызывай повторно glActiveTexture, если не поменялся ее stage
Естественно используй только UBO, никах glGetUniformLocation в кадре и std::map
Вообще у тебя и на CPU просадка будет. Судя по коду и подходу к реализации.
>в URenderer логика зашита + не люблю глобальные функции и тем более не хотелось протаскивать какой-либо объект по >всем другим, сделал рендер синглтоном, но согласен, писать каждый раз не очень. Хотя дельфины пишут begin...end, вместо >фигурных скобок) теперь представляю каково им )
Вообще-то ты слишком низкоуровневую функциональность типа
URenderer::GetInstance()->Uniform4(
Пусть шейдер хранить свои параметры. А класс рендера будет ставить шейдер и обновлять его параметры, но возможно не все.
Все вот эти вызовы типа ->Uniform4 не имеют смысла как ты будешь использовать UBO,так-же и имена констант не будут нужны в кадре.
Менеджер сцены(или менеджер источников света) должен собрать список объектов и список источников которые его освещают. Имея доступ к константам(в кадре без поиска по имени через glGetUniformLocation), он обновит все параметры, при выставлении шейдера рендером, эти константы пойдут в видюху за один вызов.
На чём, в основном, создают игры для Android? | 6 ноя. 2012 | 16:06 | #39 |
---|
>system Exceptions RTTI Library
Library
> no no no
Я не понял вообще ничего не держит? memcpy ? malloc? snprintf и т.д.
.::jimon::.
+100 про STL RTTI и всякую лабедень
Кстати, CodeBlocs часто падает на Mac OS. Версия последняя.
Какой профит от форвард контексов в OGL? | 6 ноя. 2012 | 11:00 | #1 |
---|
>дописал VAO
сделай пустым пиксельный шейдер сделай много DIP в кадре может увидишь профит на стоимости множественного переключения gl*Pointer или glAttribPointer против одного вызова glBindVertexArray
>убрал функции glEnable(GL_TEXTURE_**).
можно и в старом контексте убать FFP(glAlphaFunc, матричные функции, glTexEnv и т.д.) и все рисовать шейдерами. Эта функция в современной графике обессмыслена.
>Так в чем же профит?
Якобы заявленная "стабильность" поддержки убогого API, включение многих расширений в так называемое ядро, типа не используешь ядро расширения могут быть другие, хотя я не верю в это. Ведь код реализации расширения одинаков, просто скрыт под маской нового контекста. Убрали старые функции убрали старые расширения убрали FFP, стали выкидывать GL_INVALID_OPERATION при вызове старого хлама.
Ведь нетрудно предположить что например указатели glBindBuffer и glBindBufferARB могут быть одинаковы, по крайне мере на Windows это так. Гляну как нибудь на Mac OS.