Извините, ничего не найдено.

Reizel · 26.10.2011, 13:50

Сообщение от Crayzi

Full Tex Size Quad - это мат оО??

impersonalis · 26.10.2011, 16:29

dsd · 02.11.2011, 01:42

xCreateTextureFromData ( void * pixelsData,
int width,
int height,
int flags = 9,
int frames = 1
)
" void * pixelsData," вот это что и как его создать?

Handle tex3d=xCreateTexture(64,64,1024,64); Таким образом получится 3д текстура. И фреймы будут подразумевать третье измерение, а доступ к слоям xTextureBuffer(tex3d, layervar); Так?

Mr_F_ · 02.11.2011, 01:44

вот это что и как его создать?

создаёт текстуру из указателя на пиксели (типа как при открытии RAW в фотошопе)

dsd · 02.11.2011, 01:49

Сообщение от Mr_F_

создаёт текстуру из указателя на пиксели (типа как при открытии RAW в фотошопе)

Элегантный посыл нахер. Это значит что своими ручками я в памяти не смогу организовать подобное из цыфирек? Мне интересен сам процесс генерации подобных данных.

Mr_F_ · 02.11.2011, 01:55

насколько я помню, просто линейно расположенные RGBA (по байту на канал) готовишь

dsd · 12.11.2011, 19:59

Сделал я в пайнте вот такую текстуру только больше, И возникла у меня следующая проблема у текстур граничащих с краем наблюдается вот такой эффект:

Пропадающий при вот этих настройках:

texture main;
sampler mainSampler = sampler_state{
Texture = <main>;
AddressU = CLAMP;
AddressV = CLAMP;
AddressW = CLAMP;
MinFilter = NONE;
MagFilter = ANISOTROPIC;
MipFilter = ANISOTROPIC;
MaxAnisotropy=5;

Но появляется "шевеление" текстуры, это как-то лечится магическим флагом или надо просто не использовать какую-то часть по контуру?

Mr_F_ · 12.11.2011, 20:37

типичная проблема атласов.
как это можно решать:
1) хранишь не кратные степени двойки тайлы, вокруг каждого ободок в 4 пикселя в виде "продолжения" этого тайла. в шейдере уменьшаешь текскоорды, чтобы взять только нужный квадрат, остальные 4 юзаются для фильтрации.
2) вместо обычной tex2d юзаешь
float2 TexCoords = текстурные координаты, какие были бы если б ты ими 1 тайл тайлили.
float2 dx = ddx(TexCoords);
float2 dy = ddy(TexCoords);
float4 tex = tex2Dgrad(mytex,TexCoords,dx,dy);

зачем это нужно - когда видюха семплит текстуру, она выбирает правильный мип, если у тебя там резкий перепад текстурных координат (например у одного пикселя 0, у следующего 1), то выбирается лоуресный мип (потому что типа если маленькое расстояние между пикселями на триангле, значит текстура сплющена там, значит ей не нужен хайрес там - думает видюха), и выходит что если ты тайлишь атлас каким-нибудь fmodoм, на стыках тайлов швы.
tex2Dgrad позволяет делать выборку с заранее посчитанными данными, по которым выберется мип.
но он помедленнее будет обычного tex2D.
на самом деле ваще не рекомендую нифига юзать такие атласы на терейн, хотя как знаешь.

dsd · 14.11.2011, 01:40

Чет я никак не вкурю что последние два значения делают.

tex2Dgrad(s, t, ddx, ddy) - делает градиентную выборку точки из 2D текстуры s по координатам t Недоступно в шейдерной модели 1.х

На глаз получается, что их надо указывать в долях от 1, и это будет как шаг из текстуры? То есть чем ближе к камере тем ближе число к 0, а чем дальше тем ближе к 1? Кстати у меня оно работает быстрей обычного tex2D() в четверо почему то.

HolyDel · 14.11.2011, 02:22

на самом деле ваще не рекомендую нифига юзать такие атласы на терейн, хотя как знаешь.

что порекомендуешь вместо атласов, Ф?

.Squid · 14.11.2011, 02:25

Последние два значения задают скорость изменения текстурных координат, которая нужна для определения оптимального мип-уровня и которая вычисляется сама для tex2D из заданных текстурных координат.
Собственно, Мр_Ф это и написал.
Помнится мне, что ты используешь динамический бранчинг. Так вот, если в нем есть tex2D, то бранчинг не работает и вычисляет все варианты, что вполне может снижать производительсноть. А не работает он потому, что:
1) ГПУ работает с блоками 2х2 пикселя;
2) для tex2D вот эти вот частные производные, которые передаются последними параметрами в tex2Dgrad, вычисляются автоматически из этого блока 2х2 пикселя;
3) пиксели из одного блока 2х2 могут быть обработаны разными ветками, и в этом случае вычисленные производные окажутся невалидными;
4) поэтому компилер шойдеров исключает такой случай и выбрасывает tex2D за пределы бранчинга.
Соотвественно, если, у тебя было 4 ветки и в каждой свой tex2D, то на самом деле они всегда все вызывались.
tex2Dgrad не требует автоматически вычисленных производных, поэтому может работать в бранчинге. Только производные надо вычислять за пределами бранчинга.

Сообщение от HolyDel

что порекомендуешь вместо атласов, Ф?

У тебя же ОГЛ какой там по счету? Там нет аналога текстурных массивов из ДХ11? Мне кажется, что они удобнее всего в данной ситуации.

HolyDel · 14.11.2011, 02:36

мне интересно что порекомендует Ф для DX9 железа. Насколько я знаю они пишут движок/ игрушку под девятый. Возможно есть какая-нибудь интересная идея. И еще у текстурных массивов должны быть размеры одинаковые для каждого элемента. это логично, но не всегда удобно.

Mr_F_ · 14.11.2011, 05:33

мне интересно что порекомендует Ф для DX9 железа. Насколько я знаю они пишут движок/ игрушку под девятый. Возможно есть какая-нибудь интересная идея.

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

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

dsd · 18.11.2011, 20:38

Как имея позицию камеры, ее поворот и соотношение сторон камеры собрать для нее в шейдере мировую и проекционную матрицы? Мне нужно иметь в шейдере как бы две камеры.
Или хотя бы дайте ссылку, где все кратко написано, но есть расшифровка где, чо. А то я только про операции над матрицами найти могу инфу. Но, блин, мне транспонирование и умножение матриц не помогают XD. Причем раньше попадалось, то что нужно, а щас никак. Такое ощущение, что гугол издевается надо мной.

Справился

xGetViewProjMatrix ( Camera * camera )

dsd · 18.11.2011, 23:59

В вершинном переводим вершины в координаты на экране.
output.position = mul(input.position, matrixWorldViewProj);

Допустим VPOS мне не подходит.

Так я получу координаты на поверхности экрана:
u=output.position.x/output.position.w
v=output.position.y/output.position.w ?
В каких пределах они будут изменяться если соотношение сторон 1:1?
от -1,-1 к 1,1 или от 0,0 к 1,1. Или это вообще не так делается?