Sigel

[HolyDel]

ну да. за экран выходит. но и в блице тоже выходит за экран. т.е. в том примере если бы даже объект не было видно (например он справа за экраном) кусок текста все равно бы торчал.

но это работает только до тех пор, пока объект ПЕРЕД камерой - когда он ЗА камерой - результат не определен.
у меня скорее всего будет два варианта определения видимости объекта (аналог EntityInView)
1 - на основе фрустум куллинга (плоскости отсечения тоже считаются)
2 - на основе попиксельного запроса (т.е будет рисоваться объект, и считаться сколько пикселей прошли Z-тест, если больше 0 - объект видим).
естественно 1 намного быстрее 2.

[impersonalis]

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

HolyDel, дык в блице функция возвращения видим/нет, отдельна ведь (EntityInView).
Хотя там ведь вроде если не в камере, тогда будут по нулям возвращаться?
А у тебя как понял будет за экран выходить? Если да - то это очень удобно!

В блитце также есть аппликата проекции, представляющая из себя булево состояние, описанное ХолиДелом.
Насколько я помню, EntityInView определяет видимость объекта в камере, т.е. в некоем конусе видимости, доступном камере (бокового зрения у неё нет). ProjectedZ() же свидетельствует о позиции объекта по локальной оси аппликат относительно камеры в разбросе 1;0.
Т.е. для двигающихся линией ботов каждый имеет истинную аппликату для каждого, но ложную сущность_во_взгляде.

/|\ /|\
/ \ / \

[HolyDel]

аналог EntityInView сделал.
пример:

if(megaboss->InView())
  terribly++;
else
  terribly = max(0,terribly-1);

[-=Jack=-]

ммм... а InView чего? Кто его видит? У меня, к приимеру, это идёт как Entity::InView(Camera cam) и проверяет, видит ли эту ентитю указанная камера.

[HolyDel]

-=Jack=-, и то правда. я просто пока с многокамерами не возился. а так да, по идее надо задавать камеру.

[HolyDel]

добавил 4 новых типа блендинга.

const int BM_DETAIL = 5;
const int BM_MAX = 6;
const int BM_MIN = 7;
const int BM_DECAL = 8;

BM_DETAIL аналог блицового 5-ого режима блендинга. т.е. двойное умножение. годится в первую очередь для detail карт, потому и константа так называется.

BM_MAX, BM_MIN я думаю из названия понятно. выбирается соотвесвенно максимальное и минимальное значение компоненты пикселя. того, который рисуем и того, на котором рисуем. аналог lighter color и darker color из фотошопа.

BM_DECAL - нужен для записи в текстуру с альфой. цвет пишется как с обычной полупрозрачностью. а альфа складывается.

[moka]

DETAIL переименуй на OVERLAY, так более интуитивно понятно. Сужу по разным графическим редакторам и т.д. OVERLAY подрузумевается под перемножением.

FFP развиваешь? Я бы делал ставку на более непривязанные фичи чем к FFP, всёравно нынче FFP не используется практически вообще..

[HolyDel]

ок. пусть будет BM_OVERLAY
это не только для FFP.

[HolyDel]

сделал дополнительный набор текстурных координат.
создать набор можно так:

somesurface->AddTexCoordsLayer(index);
index может быть от 1 до 31. для максимальной производительности они должны идти по порядку.
т.е не так, что есть 2, 7 и 26 слой тк. а лучше 1,2,3. (хотя можно и 2,7 и 26).

	sfloor->MakeQuad(34.0f,8.0f);

	sfloor->Lock();

	sfloor->AddTexCoordsLayer(1);
	sfloor->VertexUV(1,0,0,0);
	sfloor->VertexUV(1,1,1,0);
	sfloor->VertexUV(1,2,0,1);
	sfloor->VertexUV(1,3,1,1);

	sfloor->UnLock();

в данном случае 34 -это размер квада. а 8 - множитель тк. т.е на этом кваде тексткура первого юнита будет повторяться 8 раз.

дальше добавляется второй текстурный юнит и задаются UV координаты для всех вершин.

[moka]

Как понял функция VertexUV(Layer%,Vertex%,U#,V#)? А где W позабыл? Часто в шейдерах юзается в виде индексов (я юзал для инстансинга). Плюс для 3D текстур нужен будет.

[HolyDel]

эээ. нету его. пока. спасибо за замечание.
скорее всего тогда будет не
sfloor->AddTexCoordsLayer(1);
а
sfloor->AddTexCoordsLayer(1,n);
где n число от 1 до 4 - число компонент на одну тк. для 3д тк - нужно указать 3.

второй параметр задает кол-во компонент у тк.

[HolyDel]

добавил возможность работы с 2д фигурами.

в аттаче пример.

в примере space - менять режим отрисовки.
динамический или статический.
в фигуре 128 трисов. 128*3 вершин.
за кадр рендерятся 100 таких фигур.

[-=Jack=-]

фпс - 200/600
А как понять 2д фигуры? Рисование мешей в экранных координатах?

[HolyDel]

Рисование мешей в экранных координатах?

бинго! и без z координаты.

[moka]

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

эээ. нету его. пока. спасибо за замечание.
скорее всего тогда будет не
sfloor->AddTexCoordsLayer(1);
а
sfloor->AddTexCoordsLayer(1,n);
где n число от 1 до 4 - число компонент на одну тк. для 3д тк - нужно указать 3.

второй параметр задает кол-во компонент у тк.

Как понимаю это в целях экономии видео памяти?
А много будет экономии, к примеру хранить не float4 а float2 в модели с 2к вершин, это по 8 бит на значение (так?) - это 2000(float2 vars) = 24000bits(2000*2*8 ) = 31Kb - Правильно? Просто я хз по этому вопросу (образование нуна)..
Тоесть если в памяти примерно 4 миллиона вершин, по дефолту (float2 на uv), то это почти 60мб, чисто на UV! Ух.. Я уже не говорю о цвете вершин, их нормалей, позиций. Тоесть приблезительно на 1 миллион вершин, тратится инфы: float4 (position) + float3 (normal) + float4 (rgba color) + float2 (UV) = 13 float's; 13f*1000v*8b=100mb! Весьма не мало.

Вот интерестно, я в шейдерах заметил правило и использование W компонента расстояния, но так и не понимал какую инфу он несёт (что он содержит), и можно ли от него избавиться.
Цвет вершин, юзается, но редко (хотя тут раз на раз не приходится, зависит от стиля кодера графических техник). Вроди как щас уже можно отрубать?
UV - уже опционально, и слои, и колличество компонентов.

Вроди ничего не забыл..