Сообщения на форуме пользователя Andrey (30 стр.)
DirectX9... инициализация... ERROR... | 28 июня 2011 | 12:29 | #11 |
---|
> Direct3D9: (ERROR) :Final Release for a device can only be called from the
> thread that the device was created from.
освобождения устройства делай в том же потоке что и создавал.
>Инициализация D3D в отдельном потоке... дополнительный флаг: D3DCREATE_MULTITHREADED
Это не имеет отношения к ошибке. Этот флаг ставится если ты будешь обращаться к устройству из разных потоков, тогда устройство создается с критической секцией на вызовах методов.
Collada или свой? | 28 июня 2011 | 10:11 | #24 |
---|
Если ты не писал плагивы к 3DS Max то лучше экспорт в Collada, далее конвертация в свой бинарный формат.
RPGman
> PlayerDark
> > Вроде бы выяснили, что стрипы не дают серьезного прироста скорости?
> Пруф?
Запусти демку nvTristrip из nVidia SDK 9.52 на различных картах.
DX9. параметр NumVertices в DrawIndexedPrimitive | 17 июня 2011 | 14:26 | #23 |
---|
>скажем что мы имеем буфер из 100 вертексов, а рисовать нам нужно один треугольник индексы которого 50; 51; 52. MinIndex ставим 50, NumVertices 3 и в конвеер >попадет всего три вертекса. Из вертексбуфера с 0 по 51 и с 53 по 100 ничто не попадает в конвеер.
> Но если имея тот же треугольник у него индексы следующие: 0; 50; 100 то MinIndex нужно ставить 0, а NumVertices 100.
>Правильно?
Нет, нужно 101, всего подается 101 вершина(100 - 0 + 1), из них через индексный буфер выбирается всего 3, я же писал в 15 посту как правильно считать NumVertices.
DX9. параметр NumVertices в DrawIndexedPrimitive | 17 июня 2011 | 13:25 | #20 |
---|
> при этом DXDebug вообще напрочь молчал.
Максимальный уровень отладки ставил? Если не помогает то D3DCREATE_SOFTWARE_VERTEXPROCESSING.
DX9. параметр NumVertices в DrawIndexedPrimitive | 17 июня 2011 | 10:28 | #15 |
---|
> Объясните пожалуста про NumVertices в DrawIndexedPrimitive.
>Меняю его как вздумается а изменений никаких.
>На GeFoce 6600 GT. Рисовал в экранных координатах без освещения куб с 24 вершинами. При любом значении параметра результат один и тот же. А когда >попробывал несколько мешей загрузить из файла при форвардном свете вело себя по разному. Либо работало, либо криво рисовало, ливо вообще ком вырубало.
nVidia видюхи по моему опыту ошибки в параметрах IDirect3DDevice9::DrawIndexedPrimitive пропускают, либо исправляют тут-же на лету, либо просто игнорируют параметры MinIndex(3 по счету), или NumVertices(4 по счету).
В результате рисуется правильно при условии что не включен режим DXDebug.
(С чем связано игнорирование ошибки мне не ясно. Вроде бы жесткая спецификация от Microsoft на Direct3D Run Time и на поддержку со стороны драйвера. Может nVidia недовольна прекращением совместной разработки шейдерного языка?)
С параметром MinIndex, все просто - берется просто индексный буфер c начального индекса и читается последовательно по 3 индекса по ним 3 вершины и треугольник готов. Соответственно число вершин не учитывается, есть же текущий вершинный буфер, текущий индексный и число примитивов.
в таком режиме работы этот вызов просто копия glDrawElements.
Следует учесть что все-таки все параметры нужно указывать правильно, и как сказал bush это нужно для оптимизации и не спроста там так много параметров, кстати в Direct3D10/Direct3D11 убрали NumVertices и MinIndex.
Пример из практики: Если индексный буфер содержит минимальный индекс > 0 и ты его не укажешь то на видюхах от Intel, ATI - будет ошибка.
Выход - пере создать индексный буфер отняв от каждого индекса самый минимальный, это значение передай в BaseVertexIndex(2 параметр), тогда MinIndex == 0.
NumVertices считается просто и безошибочно
minIndex = findMinIndex(indexBuffer);
maxIndex = findMaxIndex(indexBuffer);
NumVertices = maxIndex - minIndex + 1
Попробуй на ATI и Intel, свалится если что-то не так.
Для такого-же поведения на nVidia включи DXDebug если в этом случае будет нормально рисоваться, то попробуй создать Direct3D Device c флагом D3DCREATE_SOFTWARE_VERTEXPROCESSING, (если сложная сцена будет тормозить ничего не проверишь, убери текстурироание и шейдеры) тогда точно свалится.
3d модель в Opengl | 16 июня 2011 | 12:17 | #1 |
---|
http://code.google.com/p/lib3ds/
http://people.cs.kuleuven.be/~ares.lagae/libobj/index.html
по obj еще поищи сам.
:: КОНКУРС СТРАТЕГИЙ: Финал [Голосование завершено!]! | 16 июня 2011 | 10:17 | #1333 |
---|
>Andrey очень низко оценил мою игру. Хотелось бы услышать его отзывы по проектам и что именно не понравилось в моей игре (чтобы исправить).
Ну собственно.
1) Ну собственно тяжеловат звук. Хотя музыка хорошая. Звук прерывается при повторе(ну это мелочи).
2) Нету новизны что-бы сильно зацепило. Мое мнение конечно.
3) Я долго не мог понять почему строители долго ходили ходили так и ничего толком не смогли собрать построить. Запускал несколько раз. Соответственно пункты увлекательность реиграбельность занижены.
4) Не очень впечатляющая и красочная графика.
Big V
> Мою тоже... Хочу знать что именно фейлового в моей игре...
К сожалению она просто не запустилась.
Delphi4, VCL, multithread. Проблема в background. | 7 июня 2011 | 10:23 | #2 |
---|
> 1. Графика "замерзает": прекращается всяческая отрисовка на экране
может и не нужно рисовать в background ? пускай выполняются все пункты "Главная thread" кроме 3 в случае когда приложение в режиме background,
Заодно не будет накопления очереди выделенных буферов, т.е. уйдет проблема:
>"всё очень быстренько отрисовывается в ускоренном режиме, до тех пор, пока не "рассосётся" очередь из выделенных буферов. "
т.е. можно просто не рисовать в фоновом режиме, но не прекращать обработку данных. Убери зависимость обработки данных от от рисовки в главном потоке.
экспортер бипеда 3d max | 7 июня 2011 | 10:10 | #1 |
---|
>почему не правильно считает ?
что это значит? Кости пробовал точками рисовать? Скелет правильно рисуется?
>AngAxis
может лучше кватернион?
Упрости модель до 2 костей, быстрее найдешь ошибку.
Отрисовать VBO кусками....(сдвиг) | 3 июня 2011 | 10:37 | #8 |
---|
>а в некоторых есть лишние треугольники, понимаю что неправильно рассчитываю диапазон отрисовки, может кто подскажет как его рассчитать?
>Где ((RangeList[j].Start)*3*sizeof(integer)) - сдвиг относительно начала массива, и
>(RangeList[j].Count)*3 - соответсвенно количевство выводимых вершин.
RangeList[j].Count - число примитивов?
RangeList[j].Start - стартовый индекс? зачем на 3 умножаешь? или имеется ввиду "стартовый треугольник"?
ты упрости модель до 2 квадратов. Выведи их за 2 раза по 2 треугольника, как раз как раз поймешь где ошибка.
вот тебе пример:
есть 2 квадрата по 6 вершин.
1 квадрат: 0, 1, 2, 2, 3, 0 - 2 треугольника по 3 вершины
2 квадрат: 3, 2, 4, 4, 5, 3 - 2 треугольника по 3 вершины
glDrawElements( Mode,2 * 3, GL_UNSIGNED_INT, nil);
glDrawElements( Mode,2 * 3, GL_UNSIGNED_INT, pointer(2 * 3));
Вроде не ошибся.
кстати по идее у тебя должно выполняться условие:
RangeList[j].Start / 3 = RangeList[j - 1].Count
если mode = GL_TRIANGLES
PS_1_1 - не поддерживается ... | 31 мая 2011 | 10:27 | #67 |
---|
Поставь SDK к примеру старше октября 2009. Скомпиль с флагом D3DXSHADER_USE_LEGACY_D3DX9_31_DLL.
По крайней мере у меня твой шейдер скомпилился:
sampler2D ShadowMapSampler; sampler2D LightTexSampler; sampler2D ColorTexSampler; float Ambient = 0.3f; struct MainV2P { float4 Position : POSITION; float4 TexCoord0 : TEXCOORD0; float4 TexCoord1 : TEXCOORD1; float2 TexCoord2 : TEXCOORD2; }; float4 MainPS(in MainV2P IN) : COLOR { //Read in values for shadow, light texture and color texture float4 Shadow = tex2D(ShadowMapSampler, IN.TexCoord0); float4 Light = tex2D(LightTexSampler, IN.TexCoord1); float4 Color = tex2D(ColorTexSampler, IN.TexCoord2); //Compute lighting amount float4 I = (Light * Shadow) + Ambient; //Color of texture * lighting amount return Color * I; }
Microsoft (R) Direct3D Shader Compiler 9.29.952.3111 Copyright (C) Microsoft Corporation 2002-2009. All rights reserved. // // Generated by Microsoft (R) D3DX9 Shader Compiler 9.15.779.0000 // // fxc /Tps_1_1 /EMainPS /LD /Gpp /Zpc test.ps // // // Parameters: // // float Ambient; // sampler2D ColorTexSampler; // sampler2D LightTexSampler; // sampler2D ShadowMapSampler; // // // Registers: // // Name Reg Size // ---------------- ----- ---- // Ambient c0 1 // ShadowMapSampler s0 1 // LightTexSampler s1 1 // ColorTexSampler s2 1 // ps_1_1 def c1, 1, 0, 0, 0 tex t0 tex t1 tex t2 dp3 r0, c1, c0 mad r0, t0, t1, r0 mul r0, t2, r0 // approximately 6 instruction slots used (3 texture, 3 arithmetic)
QindieGL (эмулятор OpenGL через Direct3D9) | 26 мая 2011 | 10:59 | #12 |
---|
Отличный проект, когда будешь добавлять поддержку шейдеров? хотя-бы Добавь поддержку GL_ARB_fragment_program/GL_ARB_vertex_program уже Doom III будет работать.
Рендер: Отсечение и сортировки | 20 мая 2011 | 13:44 | #7 |
---|
>А что лучше для шутера, октри или квадтри? Склоняюсь к квадтри (отношение линейных размеров мира к высоте около 100:1)
А если многоэтажные высокие дома и большой город? будешь долго обходить внутри узлов находящихся на высоте, а так можно сразу откинуть проверив верхний узел но опять таки выигрышь будет если у тебя сотни узлов и тысячи объектов.
Вообще все тестировать нужно. Возьми разные реализации замерь время обхода на CPU и сам решишь что лучше. Посмотри свою сложность сцены, сколько геометрии в кадре, сколько объектов и т.д.
Для шутера вообще лучше PVS и не грузить CPU всякими обходами и т.д.
Рендер: Отсечение и сортировки | 20 мая 2011 | 13:21 | #5 |
---|
>В прямом смысле? Т.е. в каждом апдейте по-новой забиваем некий контейнер указателями на объекты?
Это уже детали реализации, естественно, Update делается для статических объектов при изменении камеры.
В хороших движках такой Update занимает несколько мс(2-4) не более. Тут все зависит от того как организуешь структуры данных, как это все будешь хранить в памяти.
Рендер: Отсечение и сортировки | 20 мая 2011 | 12:57 | #2 |
---|
> Как вы в рендере совмещаете сортировку по мешам/текстурам/шейдером и отсечения?
Отсечение делает менеджер сцены, но не рендер.
>Почти каждый кадр вызывается обновления с перестройкой при необходимости октри/квадтри.
обновление чего? В сложных сценах много чего всего разного. Системы частиц, анимированные и динамические объекты и т.д.
>1. Мы можем в классе октри выставлять/сбрасывать флаг "видимость" для каждого объекта, рисовать в классе рендера с сортировкой.
>2. Мы можем рисовать в классе октри, тогда мы меньше объектов посылаем на проверку, но как сделать сортировку, не знаю.
ну вообще правильней не мешать иерархию сцены с рендерингом. Octree хранить данные для отрисоки
т.е. лучше разделить Update + Render.
вот примерная схема:
1) Обходишь дерево сцены применяя различные алгоритмы Occlusion Culling, Frustum Culling
2) Формируешь список видимых объектов.
3) Из них делаешь некий набор рендер операций которые хранят в себе IB,VB,material(shaders+rasterop+textures), стартовую вершину, стартовый индекс,число примитивов + набор флагов с условиями(с флагами универсальней)
4) сортируешь их по своему условию.
5) кидаешь их в рендер.
Тут нужно разработать эту структуру RenderOp что-бы она была универсальной и подходила для всех различных объектов.
> Еще, как думаете, для единичных тяжелых элементов типа:
> 1. Ландшафт с крупными блоками, при небольшом количестве блоков (< 200)
> 2. Водоемы
> 3. етс
> Просто делать проверку ААББ на пересечение фрустума и не мудрить?
Ну особо дерево тут прироста не даст. можно еще тест на сферу сделать - быстрее.