PMG http://forum.pmg.org.ru/ |
|
Непроизвольный FAQ http://forum.pmg.org.ru/viewtopic.php?f=2&t=6648 |
Страница 2 из 2 |
Автор: | Ernesto [ 20 мар 2008 10:22 ] |
Заголовок сообщения: | Re: Вопрос по альфа-каналу |
Вот блин, а ведь действительно... Черт побери... Спасибо, дружище! Есть всетаки еще здесь возможность получить ответ... Сегодня попробую! А, кстати, я тени сделал! )) На первом этапе рендеринга из точки зрения источника сета, все объекты проходят через шейдеры, выводящие цвет точки в зависимости от удаления от источника. Кроме того сохраняю в тип источника саму матрицу, чтобы на втором, конечном, этапе корректно переводить координаты... Вобщем понятно. |
Автор: | Ernesto [ 22 мар 2008 00:00 ] |
Заголовок сообщения: | Re: Вопрос по альфа-каналу |
Вот еще вопрос на банальном книжном примере такого кода Position = mul( inPosition, matViewProjection ); Если и входной inPosition и выходной Position описаны в одном регистре, например POSITION0, не будет-ли это означать что после данной строки они будут иметь одно значение? Если, скажем, после этого мне нужен изначальный inPosition, то получу-ли я его, обратившись к переменной inPosition? |
Автор: | NetLib [ 22 мар 2008 12:38 ] |
Заголовок сообщения: | Re: Вопрос по альфа-каналу |
Ernesto писал(а): Если и входной inPosition и выходной Position описаны в одном регистре, например POSITION0, не будет-ли это означать что после данной строки они будут иметь одно значение? В шейдерной архитектуре, насколько я помню, входные и выходные регистры разделены, то есть это будут два различных регистра. |
Автор: | Ernesto [ 23 мар 2008 05:18 ] |
Заголовок сообщения: | Re: Вопрос по альфа-каналу |
Не хочу упускать такую замечательную возможность поговорить со знающим Посему вопросы: 1) С увеличением количества функций, полностью перенесенных на шейдеры, возникает ситуация, в которой крайне необходимо каждому шейдеру передавать массу флоатов, имеющих одни и те-же значения. Например, общее фоновое освещение, какие-либо опорные точки... Да много таких. В итоге из 25-35-и шейдеров все имеют штук по 30 одинаковых входных переменных. Есть соблазн покидать все шейдерные функции в один текстовый файл. Но в приложении один фиг доступ к переменным получается посредством указания конкретной функции.... И на 25-35 шейдеров приходится описывать по 30 одинаковых величин... Я понимаю, что довольно смутно описал проблему, но опытный человек, я уверен, поймет о чем я. Как это принято решать? 2) Почему при создании буферов (вертексных, индексных) последовательность действий - CreateBuffer, Lock, CopyMemory, Unlock. А в обратной ситуации - когда требуется из буфера извлеч конкретные значения, вы делаем Lock, Unlock, а CopyMemory хоть головой об стенку расшибись - не пашет, и все покорно юзают поэлементное копирование (вы представляете каково делфисту разбирать эти ваши " **void++::==*++=& " ?!?!?) 3) Каким таким боком всем удается создать текстуру, отрендерить на неё сцену а потом попиксельно еще перекинуть в массив? Я два часа головой бился об клаву, пока не прочел в манах, что чтоб на текстуру можно было рендерить она должна быть создана именно D3DPOOL_DEFAULT, в то время как другая страница хелпа четко говорит, что D3DPOOL_DEFAULT -текстуру нельзя залочить, и, соответственно, получить валидную ссылку. Я не напрягаясь за минуту нашел в нете с десяток подобных примеров, полностью противоречащих документации. И они у вас работают? Может мне просто надо найти документацию такую-же как у вас? И все заработает? )) 4) Вертексный: void vs_main( float4 inPosition : POSITION0, out float4 Position : POSITION0, out float Distance : TEXCOORD4 ) Position = mul( inPosition, matViewProjection ); Distance = Position.z; В пиксельном вывожу точки с цветом, зависящим от Distance. Вижу - нормально перспективно спроецированные плоскости, а цвет, полученный из Distance показывает полное отсутствие перспективы: |
Автор: | NetLib [ 26 мар 2008 12:47 ] |
Заголовок сообщения: | Re: Вопрос по альфа-каналу |
Ernesto писал(а): С увеличением количества функций, полностью перенесенных на шейдеры, возникает ситуация, в которой крайне необходимо каждому шейдеру передавать массу флоатов, имеющих одни и те-же значения... Как это принято решать? Мне кажется, что у вас путаница с эффектами и шейдерами. Эффект состоит из нескольких проходов, в каждом из которых есть свой вершинный и пиксельный шейдер. Сами шейдеры не слишком сложные (ведь есть ограничение на максимальную длину шейдера и оно не такое уж большое). А вот эффекты по 8 - 10 проходов, каждый со своим шейдером не такая уж и редкость. По поводу сохранения значений между вызовами сказать достаточно сложно - вы можете отметить, что оно вам нужно, но решать будет компилятор. Ernesto писал(а): Почему при создании буферов (вертексных, индексных) последовательность действий - CreateBuffer, Lock, CopyMemory, Unlock. А в обратной ситуации... А у меня пашет. Напишите, пожалуйста поподробнее. Кстати, если вам приходится что-то вытаскивать из видеопамяти, надо подумать о переработке архитектуры - это сильно тормозит работу. Попробуйте хранить копию буфера в системной памяти и хоть обкопируйтесь. Ernesto писал(а): вы представляете каково делфисту разбирать эти ваши " **void++::==*++=& " ?!?!? Нет. И не хочу. Ernesto писал(а): Каким таким боком всем удается создать текстуру, отрендерить на неё сцену а потом попиксельно еще перекинуть в массив? Вы всегда визуализируете в текстуру. Вам просто надо сказать, что визуализировать надо не во вторичный буфер, а в созданную вами цель визуализации. Ernesto писал(а): Может мне просто надо найти документацию такую-же как у вас? И все заработает? )) А чего ее искать? http://www.netlib.narod.ru |
Автор: | Ernesto [ 26 мар 2008 23:26 ] |
Заголовок сообщения: | Re: Непроизвольный FAQ |
Вот блин... Невнятен я всетаки когда нервничаю... По большинству пунктов - согласен. Требуется пересмотр принципов именно в указанную вами сторону. А вертексы я их *.х гружу действительно единожды, лишь при его подгрузке. Но что касается рендеринга в текстуру - я ведь сказал - та, в которую можно рендерить не совпадает по параметрам с той, которую можно лочить. А про шейдеры - уточню: У меня отдельные шейдеры для рендеринга: - ландшавта - солнца - моделек всяких - воды ... т.д. Каждый хочет от меня кучу своих личных значений. Но их объединяет и тот факт, что они ждут от меня координаты, цвет, яркость солнца, собственные значения смещений.... Т.е. совершенно одинаковых и даже одноименных. Шейдеры получаются: ############################ 1-й в отдельном файле (для ландшавта): Переменные функция ############################ 2-й в отдельном файле (для моделек): Переменные (в основном те-же что и первый) функция ############################ 3-й в отдельном файле (для еще чего-нить): Переменные (опять-таки все те-же) функция ############################ ..... так нельзя-ли сделать типа: ############################ Переменные (общие для всех в перемешку с собственными переменными отдельных функций) функция 1-го шейдера (для ленда) функция 2-го шейдера (для моделей) функция 3-го шейдера (для еще какой-нить штуки) ############################ Вот.... Бывает так? Кстати сейчас просмотрю подкинутую литературку (спасиб кстати). может там уже есть все ответы. |
Автор: | NetLib [ 27 мар 2008 12:47 ] |
Заголовок сообщения: | Re: Непроизвольный FAQ |
Ernesto писал(а): ############################ Переменные (общие для всех в перемешку с собственными переменными отдельных функций) функция 1-го шейдера (для ленда) функция 2-го шейдера (для моделей) функция 3-го шейдера (для еще какой-нить штуки) ############################ Вот.... Бывает так? Так это и есть эффект. У нас есть несколько проходов: Проход 1 - рисуем ландшафт (свои шейдеры). Проход 2 - рисуем модели (свои шейдеры). Проход 3 - делаем какой-нибудь спецэффект (например, размытие) - опять же свои шейдеры. При этом общие переменные у всех проходов объявляются только один раз глобально. Поглядите главу 19 у Луны или книгу сент-лаурента по шейдерам. |
Автор: | Ernesto [ 29 мар 2008 23:22 ] |
Заголовок сообщения: | Re: Непроизвольный FAQ |
Не-а. Не о проходах я говорил. Ну да ладно. та проблема решена кардинально. В данный момент решаю тему множества источников света. Передавал в вертексный шейдер массив источников света с кучей доп. параметров. В том числе и, собственно, количество активных источников. Все работало, но, как всем понятно, расчитывать освещение в вертексном шейдере - не есть гуд. Перекинул все параметры в пиксельный. И только размахнулся... Я понимаю, что инты, получаемые пиксельным шейдером в параметрах, автоматом считаются флоатами. Это очевидно ввиду свойств используемых трансферных регистров - текскоорд, позишн... етк... В общем ни у кого не возникало подозрений, что и величины, передаваемые не от ветрексного, а непосредственно из приложения, один фиг считаются интерполированными и посему флоатами? Короче стоят рядом две строки: float3 LightColor[50]; int LCount; ... И при этом LightColor прекрасно обрабатывается, а LCount при любой попытке к нему обратится вообще приводит к некомпилляции шейдера. Я теперь делаю так: LCount = LCount + 1.3; for( int i=0; i<50; i++ ) { if(i<LCount) { ...обращение к i-му источнику.... } } Но неужели это нормально?!?! (Я прогаю давно, даже преклонно. Попрошу не оскорблять меня предложениями проверить арфографию. NetLib-а не касается. Ему все можно ) Поправочка: Мой список параметров, получаемых пиксельным шейдером от приложения: sampler2D Texture1 : register(s0); sampler2D Texture2 : register(s1); sampler2D Texture3 : register(s2); sampler3D Texture4 : register(s3); float Bump; float3 GlobalAmbient; float3 Diffuse; float3 Ambient; float3 Specular; float3 Emissive; float Power; float4 TexPos[4]; float2 LightRange[50]; float3 LightA[50]; float3 LightColor[50]; float3 LightPose[50]; float3 LightVec[50]; int LCount; int Tip; Позволяет обратиться к любым LightColor и прочим, в количестве не более двух - хоть к сороковому, хоть к тридцатому, но не более двух разных индексов! Остальных это правило так же касается. Так, например, корректно работает LightColor[45]+LightColor[18], так же корректно скомпилиться LightColor[1]+LightColor[18], но категорически не проканает фраза типа LightColor[1]+LightColor[18]+LightColor[45]. Это утверждение валидно для любых комбинаций индексов массивов. Попытаюсь упредить ответ и задам встречный вопрос - ка кдолжен выглядеть код прохода по 50-и элементам массива в пиксельном шейдере? (на примере, если не трудно) |
Автор: | NetLib [ 01 апр 2008 11:24 ] |
Заголовок сообщения: | Re: Непроизвольный FAQ |
Цитата: В общем ни у кого не возникало подозрений, что и величины, передаваемые не от ветрексного, а непосредственно из приложения, один фиг считаются интерполированными и посему флоатами? Это сильно зависит от аппаратуры - согласно стандарту все завязано на нее и самым безопасным вариантом будет считать, что все числа float, а все остальное - программная эмуляция. То есть вам гарантируется только наличие float. Кстати, достаточно часто как int реализованы только счетчики циклов и для них выделены отдельные регистры. Цитата: LCount при любой попытке к нему обратится вообще приводит к некомпилляции шейдера Здесь, пожалуйста чуть подробнее- попытка обратиться где? в шейдере или из программы? Цитата: Попытаюсь упредить ответ и задам встречный вопрос - ка кдолжен выглядеть код прохода по 50-и элементам массива в пиксельном шейдере? Цикл for с добавлением по одному элементу (ну и, если надо, то еще и if, чтобы отбрасывать ненужные). Это опять же особенность архитектуры. for ( i = ; ...; i++) TotalColor += Color[i] |
Страница 2 из 2 | Часовой пояс: UTC + 3 часа [ Летнее время ] |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |