Компьютерная графика

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Компьютерная графика » Дзен » Найденные ошибки, опечатки, пожелания


Найденные ошибки, опечатки, пожелания

Сообщений 1 страница 30 из 68

1

Постим сюда

0

2

Нашел небольшую ошибку в статье про SSAO.

Когда мы получаем псевдослучайную нормаль, относительно которой надо повернуть вектор:
vec3 plane = texture2D ( rotateMap, gl_TexCoord [0].xy * 512.0/4.0).xyz

Мы же восстанавливаем норамль из текстуры, поэтому надо
vec3 plane = 2.0 * texture2D ( rotateMap, gl_TexCoord [0].xy * 512.0/4.0).xyz - vec3(1.0)

И еще вопрос: что означают числа

for ( int i = 0; i < 8; i++ )
    {
        vec3    sample  = reflect   ( rndTable [i].xyz, plane );
        float   zSample = texture2D ( depthMap, gl_TexCoord [0].xy + radius*sample.xy / z ).x;

        zSample = zFar * zNear / (zSample * (zFar - zNear) - zFar );
       
        float   dist = max ( zSample - z, 0.0 ) / distScale;   
        float   occl = 15 * max ( dist * (2.0 - dist), 0.0 );
       
        att += 1.0 / ( 1.0 + occl*occl );
    }
   
    att = clamp ( att / 8.0 + 0.45 (это, наверно "bias"), 0.0, 1.0 ) * attScale;

0

3

1. Это похоже действительно ошибка
2. Это просто подобранные коэффициенты
distScale - управляет характерным расстояниям, на котором мы учитываем затенение.
0.45 - это дейсвтительно bias

0

4

Steps3D написал(а):

distScale - управляет характерным расстояниям, на котором мы учитываем затенение.

После долгих опытов с этим шейдером, я бы сказал что расстояние, которое надо учитывать задается в
vec3    sample  = reflect   ( rndTable [i].xyz * distance, plane )

PS: огромное спасибо за статью. Наконец-то сделал этот эффект :)

0

5

Насколько я помню для функции reflect нужно сдавать только единичные вектора
Ошибку с
vec3 plane = 2.0 * texture2D ( rotateMap, gl_TexCoord [0].xy * 512.0/4.0).xyz - vec3(1.0)
уже поправил, сейчас выложу

0

6

У кого какие примеры к статьям не работают, особенно интересуют не работающие,плохо работающие примеры по параллаксу

0

7

в статье о DoF http://steps3d.narod.ru/tutorials/depth … orial.html в конце есть два скриншота, они одинаковые (оба dof-1), при этом на сервере лежит файл dof-2

Так же главная страница (да и небось не только она) не проходит валидацию, а ссылочка на неё есть...

Отредактировано st0ke (2008-11-25 18:58:20)

0

8

Спасибо, исправил

0

9

Нашел несколько ошибок в статье "Интеграция скриптов на Lua с С++" в шаблонных враперах.

1. В callLua0 (lua-templ.h) в строке 170 пропущен индекс, из-за чего при использовании этого шаблона происходит ошибка компиляции:
           
             fromLua      ( lua, res ); заменить на fromLua (lua, -1, res)

2. Этот же шаблон callLua0 построен таким образом, что при вызове нам нужно специфицировать вручную тип возвращаемого значения (например, целым): callLua0<int>(L, "myFunc"), что не удобно, и отличается от вызовов подобных функций callLua1,2 и 3. Можно этот шаблон сделать по тому же подобию, что и callLua1, 2 и 3 т.е. тип возвращаемого значения передавать через аргументы:

template <typename R>
bool callLua0 ( lua_State * lua, const char * funcName, R& res )

3. В этих же шаблонах callLuaX отсутствуют функции, которые ничего не возвращают. Например, для callLua0 можно было бы сделать перегрузку (подобное можно сделать для всех callLuaX):

bool callLua0 ( lua_State * lua, const char * funcName )
{
            lua_getfield ( lua, LUA_GLOBALSINDEX, funcName );
lua_pcall    ( lua, 0, 0, 0 );                   

return true;
}

4. Все шаблоны определены как обычные функции, что не позволяет их использовать в разных С++ модулях. Одно из решений, определить их как static или даже static inline.

5. Не очистка стека после вызова callLuaX. Можно было бы вызывать lua_pop() в callLuaX после вызова fromLua.

После всех исправлений и усовершенствований у меня получилось примерно вот что:

//для вызова луа функций, которые не возвращают значения (без агрументов)
static inline bool callLua0 ( lua_State * lua, const char * funcName )
{
lua_getfield                 ( lua, LUA_GLOBALSINDEX, funcName );
lua_pcall                     ( lua, 0, 0, 0 );                   

return true;
}

//для вызова луа фукнции, которая возвращает 1 значение (без агрументов)
template <typename R>
static inline bool callLua0 ( lua_State * lua, const char * funcName, R& res )
{
lua_getfield     ( lua, LUA_GLOBALSINDEX, funcName );
lua_pcall        ( lua, 0, 1, 0 );                   
bool ret = fromLua                     ( lua, -1, res );   
lua_pop    (lua, 1);
return ret;
}

//тоже самое для callLua1
template <typename R, typename A>
static inline bool callLua1 ( lua_State * lua, const char * funcName, R& res, A arg )
{
lua_getfield ( lua, LUA_GLOBALSINDEX, funcName ); 
toLua            ( lua, arg );                      
lua_pcall    ( lua, 1, 1, 0 );                   
bool ret = fromLua ( lua, -1, res );   
lua_pop    (lua, 1);
return ret;
}

template <typename A>
static inline bool callLua1 ( lua_State * lua, const char * funcName, A arg )
{
lua_getfield ( lua, LUA_GLOBALSINDEX, funcName );   
toLua          ( lua, arg );                      
lua_pcall     ( lua, 1, 0, 0 );
return true;
}
//и так далее...

0

10

Большое спасибо, вечером посмотрю и исправлю

0

11

Добрый день!
В Вашей статье "Расширения NV_transform_feedback и EXT_transform_feedback" (http://steps3d.narod.ru/tutorials/nv-tr … orial.html)
есть небольшая опечаточка - glEbdTransformFeedbackNV вместо  glEndTransformFeedbackNV

C ув. =[ 0r@ngE ]=

Отредактировано =[ 0r@ngE ]= (2009-03-30 16:49:14)

0

12

Ваши 3 последних обновления на главной странице не приехали по rss ):
Это хорошо видно по ссылке http://steps3d.narod.ru/rss

0

13

И снова в RSS пусто ):

+1

14

Предлагаю сменить название раздела - "Программирование CUDA" на "Программирование GPGPU". ATI недавно предоставила драйвера для использования ATI Stream на пользовательских картах. Грядёт OpenCL. Как-то не кошерно ограничиваться одним производителем и одной технологией.

Отредактировано Booster (2009-06-29 18:30:40)

0

15

StepsFramework/3D/Vector4D.h:
Очень странный код функций length(), lengthSq(), distanceToSq() и distanceTo().
В них напрочь отсутствует какое-либо упоминание четвертой компоненты вектора.

PS: Судя по съехавшему форматированию в определении этих функций - это последствия копипаста.

Отредактировано matr (2009-10-27 11:26:05)

0

16

Спасибо, исправил и обновил архив

0

17

"О зыках", а не "О языках" хотят поведать нам здесь: http://steps3d.narod.ru/humour.html

0

18

Рекомендую так же добавить в ссылки (и, возможно, на главную) http://dabroz.scythe.pl/
Какое-то время назад блог стал вестись на английском и там есть очень интересные вещи по применению OpenGL 3.x (например, про полноценный мультисемплинг в deferred shading'е)

0

19

Алексей, есть пожелание разместить ваши библиотеки и фреймворк в каком-нибудь публичном репозитории SVN/Git/Mercurial,
чтобы отслеживать изменения было удобнее.

0

20

Я, в принципе, готов предоставить SVN хостинг. С какой-то вероятностью даже PHP, но надо будет память нарастить VPS'у

0

21

crsib написал(а):

Я, в принципе, готов предоставить SVN хостинг. С какой-то вероятностью даже PHP, но надо будет память нарастить VPS'у

Я не предлагаю весь сайт целиком перевозить, а только разместить framework и libtexture где-нибудь на sf.net, bitbucket.org, code.google.com, etc.

0

22

Давайте разместим фреймворк в svn - будет действиетльно удобно.
Мне в принципе все равно где, только навреное перед размещением нужно будет исходники немного "причесать"

0

23

Как вариант, я так же могу предоставить instance trac'a с удобной вики для статей (и возможностью переноса туда старых статей без каких либо проблем). Вики великолепно работает с Latex, GraphViz, имеет интеграцию с SVN и разделом закачек.

0

24

"Нашел очень интересную статью:

Pitfalls of Object-Oriented Programming

Кстати из этой статьи следует, что использование стандартных контейнеров STL, основанных на красно-черных деервьях, для работы с действительно большими объемами данных очень плохо. В подобных случаях B/B+/B*-деревья будут горазлдо эффективнее."
Опечатки.

0

25

steps3d написал(а):

Кстати из этой статьи следует, что использование стандартных контейнеров STL, основанных на красно-черных деервьях, для работы с действительно большими объемами данных очень плохо

Вы видимо не очень внимательно читали эту статью. А точнее презентацию. А она, как и все подобные работы SCEE R&D является просто перлом оптимизаторской мысли. Но с жесткой привязкой к конкретному железу. А точнее, даже модулю железа. В данном случае к PPU. Правда и Q&A отдел там дерет так, что описанное является просто детским лепетом.

Дык вот. В этой статье Сонивцы пропогандировали две вещи - реорганизаци кода с целью улучшения branch prediction и линеаризацию памяти с агрессивным подходом к кешериванию (опять же, все хорошо только в ос реального времени. Появление тяжелой многопоточности (и уж боже упаси многозадачности) приводит к тому, что после переключения потоков ранее выполненный префетч оказывается бесполезным.) Нигде и не было речи ни о красночерных из STL (при том что от его использования отказываться авторы отнюдь не торопились), использование которых даже не стандартизированно и уж тем более о B деревьях. Речь шла не о снижении обращений к памяти (дерево обходилось полностью, что делает это невозможным), а о жестком, тщательно оптимизированном кешировании данных.

0

26

А у Вас есть сомнения, что красно-черные деревья для большого числа элементов (100К и выше) очень неэффективны с точки зрения кэша ?
Один из пунктов данной статьи, IMHO что надо структуры данных оптимизировать для кэша при больших объемах данных
У STL с этим очень плохо

0

27

Steps3D написал(а):

что красно-черные деревья для большого числа элементов (100К и выше) очень неэффективны с точки зрения кэша

У меня серьезные сомнения, что B-деревья будут сильно эффектвней в описанном в статье случае. И уж тем более на операциях вставки/удаления. Они используются только там, где операции чтения/изменения происходят значительно чаще операций вставки/удаления. И используют их только тогда, когда объем данных не помещается в оперативную память. О кеше там ни слова - деревья не бывают cache-friendly.

Steps3D написал(а):

Один из пунктов данной статьи, IMHO что надо структуры данных оптимизировать для кэша при больших объемах данных

Бгг. 11к нод - сранительно малый объем данных. Во-вторых проблемы с кешем при использовании "дерева" начинались с 3-го элемента и происходили от невозможности префетча не линейно расположенных данных. Ни о каком уменьшении обращений к памяти не шло - дерево в любом случае обходилось полностью. Речь шла о возможности предсказания обращения к памяти.

Steps3D написал(а):

У STL с этим очень плохо

Что значит у STL? У стандарта? Там сказанно - "делайте не кеш-френдли код"? У векторов? У списков?
Никто, нигде и никогда не говорил, что ассоциативные контейнеры должны использовать только красно-черные деревья. Гарантируется только ассимптотика операций над контейнером. Красно-черные деревья выбираются из расчета оптимальной производительности в общем случае. Естественно, что алгоритм, заточенный для частного случая скорее всего будет быстрее. Только вот работа программиста нынче не очень дешева. И для большинства простых ситуаций тот же std::map великолепно подойдет. А вот когда становится понятно, где приложение упираемся в производительность, тогда и надо менять generic алгоритм/контейнер на специфичный. И при адекватном использовании С++ делается это абсолютно безболезненно.

0

28

У меня серьезные сомнения, что B-деревья будут сильно эффектвней в описанном в статье случае. И уж тем более на операциях вставки/удаления. Они используются только там, где операции чтения/изменения происходят значительно чаще операций вставки/удаления. И используют их только тогда, когда объем данных не помещается в оперативную память. О кеше там ни слова - деревья не бывают cache-friendly

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

Бгг. 11к нод - сранительно малый объем данных. Во-вторых проблемы с кешем при использовании "дерева" начинались с 3-го элемента и происходили от невозможности префетча не линейно расположенных данных. Ни о каком уменьшении обращений к памяти не шло - дерево в любом случае обходилось полностью. Речь шла о возможности предсказания обращения к памяти.

Вы о чем ? Речь идет не об уменьшении числа обращений к памяти, а о том, как сделать чтобы при этих обращениях было как можно меньше cache miss
И организация данных в линейные массивы по отдельным элементам очень удобна для этого

И для большинства простых ситуаций тот же std::map великолепно подойдет

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

Ну и в дополнение, разве можно сравнивать std::string и QString - последняя на порядок лучше и удобнее, чем это STL-ное *****

0

29

Steps3D написал(а):

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

C процессорным - нет. А вот значительно уменьшить колличество чтений они могут.

Steps3D написал(а):

А насчет вставки и удаления - большинство современных БД построены как раз на Б-деревьях

INSERT/DELETE опреции значительно медленнее SELECT/ALTER

Steps3D написал(а):

Речь идет не об уменьшении числа обращений к памяти, а о том, как сделать чтобы при этих обращениях было как можно меньше cache miss
И организация данных в линейные массивы по отдельным элементам очень удобна для этого

crsib написал(а):

линеаризацию памяти с агрессивным подходом к кешериванию

Вы, при этом, ссылаясь на статью говорилили о B деревьях. Я лишь поправил Вас в том, что деревья не причем. Ибо в противном случае некоторые посетители сего форума тут же ломанутся их писать, а потом на гд.ру будут всем компостировать мозг тем, что их гениальная реализации работает не так, как они хотели.

Steps3D написал(а):

Ну и в дополнение, разве можно сравнивать std::string и QString - последняя на порядок лучше и удобнее, чем это STL-ное *****

Речь шла о ассоциативных контенерах, разве нет? Мне, например, крайне редко нужен функционал из "разницы" между std::string и QString. Остро не хватает только возможности работы с форматными строками. И то, нужна эта функциональность кране редко.

0

30

C процессорным - нет. А вот значительно уменьшить колличество чтений они могут.

Посмотрите определение Б-дерева - оно очень хорошо дружит с кэшом за счет того, что в каждом узле от n до 2n записей идущих подряд (линейный массив)
Поскольку n  имеет порядок десятков, то вставка/удаление редко приводят к перебаланисровке и она дешевле (с точки зрения кэша)

Насчет цены операция в БД - так есть еще задача обеспечение целостности данных, которая и стоит очень дорого. А сама по себе вставка/удаление почти всегда - это просто пробежатся по массиву ключей и вставить/удалить ключ. Балансировка имеет место только кода количество ключей в узле выходит за [n,2n]

Речь шла о ассоциативных контенерах, разве нет? Мне, например, крайне редко нужен функционал из "разницы" между std::string и QString. Остро не хватает только возможности работы с форматными строками. И то, нужна эта функциональность кране редко.

С точки зрения STL - строки это тоже контейнеры
И мне например постоянно не хватает аналогов strlwr/strupr, которые какйо-то мудак решил не доавлять.
И писать вместо одного вызова метода большой transform мне почему-то неудобно :)))

Если честно, я просто не понимаю, как умному человеку может нравится такая куча говнокода, которым является STL и boost (No offense sugested)
IMHO это просто уродская куча макросов, крайне неудобная для отладки (как например из отладчика проверить есть ли в map нужная мне строка) и непригодная для работы с большим количеством данных.
На уровне "затычки для задницы" еще как-то тянет, но для серьезных вещей - никак.

0


Вы здесь » Компьютерная графика » Дзен » Найденные ошибки, опечатки, пожелания


создать свой форум бесплатно