Dx9

[Mikle]

cam(0) - координата позиции камеры по Х
cam(1) - координата позиции камеры по У
cam(2) - координата позиции камеры по Z
cam(3) - координата позиции цели взора по Х
cam(4) - координата позиции цели взора по Y
cam(5) - координата позиции цели взора по Z

Это я и так понял, хотя всё это как-то странно, но основная мысль была другая:
Такие базовые вещи, как позиция и направление камеры, не нужно ниоткуда "тягать"

Вперёд и вправо получается так:

Код: Выделить всё

Vec3Subtract CamDir, vAt, CamPos 'vAt - тот вектор, который задаётся в MatrixLookAtLH
Vec3Normalize CamDir, CamDir
Vec3Cross CamRight, vUp, CamDir 'vUp - тот вектор, который задаётся в MatrixLookAtLH
Vec3Normalize CamRight, CamRight
Vec3Cross CamUp, CamDir, CamRight 'CamUp - направление вверх камеры

[Sneaks]

Спасибо, заработало.
Там было 2 косяка с одним фовом во первых в радианах и во вторых не 90 градусов, а 45
Оставлю что у меня вышло тут, может кому пригодится.

Код: Выделить всё

Dim v As D3DVECTOR, CamPos As D3DVECTOR, ThingPos As D3DVECTOR, CamDir As D3DVECTOR
Dim CamUp As D3DVECTOR, CamRight As D3DVECTOR
Dim Width As Single, Height As Single
Dim vUp As D3DVECTOR, vAt As D3DVECTOR

ThingPos.x = 20
ThingPos.y = 10
ThingPos.z = 0

CamPos.x = cam(0)
CamPos.y = cam(1)
CamPos.z = cam(2)

vAt.x = cam(3)
vAt.y = cam(4)
vAt.z = cam(5)

vUp.x = 0
vUp.y = 1
vUp.z = 0

Vec3Subtract CamDir, vAt, CamPos
Vec3Normalize CamDir, CamDir
Vec3Cross CamRight, vUp, CamDir
Vec3Normalize CamRight, CamRight
Vec3Cross CamUp, CamDir, CamRight

Height = Me.ScaleHeight
Width = Me.ScaleWidth

FovY = 0.785398 '1.5708

Vec3Subtract v, ThingPos, CamPos
  Vec3Scale v, v, 1 / Vec3Dot(CamDir, v)
 
  TestX = (Width + Vec3Dot(CamRight, v) / Tan(FovY / 2) * Height) * 0.5
  TestY = (Height - Vec3Dot(CamUp, v) / Tan(FovY / 2) * Height) * 0.5
 
  Line (TestX, TestY)-(TestX + 20, TestY + 20), 200, BF


[Sneaks]

Доброго время суток,
я опять со своими теоретическими вопросами.
Раньше рисовал землю DrawIndexedPrimitive'ом, объекты DrawPrimitive или DrawPrimitiveUp'ом и горя не знал, решил перекинуть объекты на DrawIndexedPrimitiveUp и у меня возникли проблемы с нормалями если объект острой формы как к примеру куб, и возникли проблемы с текстурными координатами, на стыке виден шов. Раскинув скромным количеством своих мозгов пришел к точу что задача не решаема, т.к. по вертоксно мы вбиваем на одну точку несколько координат и нормалей для каждой стороны, а через индексы, то на каждую точку только одну нормаль и текстурную координату.
Теперь вопрос: на сколько сильно я заблуждаюсь, может я что то не учел.

[Mikle]

Всё, что можно нарисовать с помощью DrawPrimitiveUp, можно нарисовать и с помощью DrawIndexedPrimitiveUp.

[Sneaks]

Единственное решения которое я нахожу это дублировать вертексы. Ну тогда теряется смысл индексов.

[Mikle]

Смысл индексов в том, чтобы не дублировать полностью совпадающие вертексы, то есть в которых всё одинаково, ту часть вертексов, которые совпадают частично, можно дублировать, это не противоречит идее индексирования. У куба 8 вершин, но, если использовать нормали, то придётся использовать 24 вертекса с индексами, по три на вершину, но это всё-таки не 36 вертексов, которые пришлось бы задействовать при обычном TriangleList без индексов.

[Sneaks]

Доброго времени суток,
хоть это почти ни как не связанно с ДХ. Мучают меня мысли по поводу лайтмапа, что это, как считается и т.д. Не удержался сделал набросок по средствам SetDIBitsToDevice.
https://yadi.sk/d/kU4RR1u7QoO_wg
правая кнопка мыши передвигать 1 источник
Риалтаймом и не пахнет, размер всего 800 на 600 и 10 источников света, пока что даже без теней и считает это год(хотя по моей задумке, тени сократят объем вычислений что приведет к маленькому ускорению).
Но больше меня мучает "баг" или артефакт. По краям на стыке 2-х источников света кажется как будто гаснувший "поджирает" яркость у более яркого источника. смотрю картинки в инете глоу эффектов и неонов, там у них все красиво.
Ну собственно дискас, где я накосячил с расчетом и почему у меня руки не с того места, что все так тормозит.

[Mikle]

все так тормозит

На первый взгляд сразу видно: отсутствует Option Explicit, многочисленные счётчики в циклах нигде не объявлены, то есть имеют тип Variant, в таких местах:

Код: Выделить всё

For a = 0 To 2
ColorSL(a) = 0
Next


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

[Sneaks]

Ок спасибо, ща посмотрим.
А общий принцип? в правильном направлении мыслю?

Обновил фалы.

[Mikle]

в правильном направлении мыслю?

Вот как я могу на это ответить по исходнику, который возможно неправильный?
Могу только локальные ошибки определить, типа тут:

Код: Выделить всё

SetDIBitsToDevice Me.hDC, 0, 0, 799, 599, 0, 0, 0, 600, PicMas(0, 0), bi32BitInfo, 0

скорее всего "799, 599" - это ошибка, должно быть "800, 600".
Ты лучше опиши задумку на словах.

[Sneaks]

Если в общих чертах и на пальцах то хотел симулировать свет.
По моей логике - плавно гаснувший в зависимости от расстояния от источника. Т.е. у нас есть координаты источника света, в центре без потерь самый яркий, при удалении яркость уменьшается до конца радиуса по формуле (ярксоть * на силу "потери" от расстояния). В смешении двух или более источников на каждый пиксель складывается их цвета по 3 каналам, проверяется что б не вылезли за рамки и отдается уже конечный цвет пикселя.
Изначально хотел разбить по регионам действия источников, но решил что все равно в итоге надо будет хоть как то осветить весь кусок материала то смысла в этом нет и решил прогнать расчет тупо от начало (0,0) до конца(800,600).
Тени буду рисовать отдельно маской при помощи Polygon. По этой маске смотреть надо данный пиксель считать цвет, если он попадает в тень, то пропускаем.
Но до этого не дошел так как не нравится результат на данном этапе. И как угасание выглядит мне не нравится и этот баг с пожиранием цвета на краю. Может конечно и глаз замылился, да еще эти годовые расчеты на кадр. Вот и подумал может все не так и я не прав.

[Mikle]

Там же не понятно, это что, вид сверху на плоскость? А от чего тогда тени? А высота источника света над плоскостью как учитывается?

[alibek]

при удалении яркость уменьшается до конца радиуса по формуле (ярксоть * на силу "потери" от расстояния)

Если говорить за реальную физику, то мощность излучения падает пропорционально квадрату расстояния (без учета дополнительных потерь).
Поэтому приведенная формула странная, в ней зависимость линейная.

[Mikle]

Я так понял, речь про удаление на плоскости от места под источником света, там формула будет ещё сложнее - сумма квадратов высоты источника света и расстояния по плоскости до освещаемой точки на косинус угла между направлением на источник и вертикалью.

[Sneaks]

Так, источник находится идеально на 1 папугай от плоскости, т.е. сути прям в ней. Высота меня особо не пугает так как думаю её легко считать. На счёт квадрата расстояния спасибо, даже не думал что не линейно идёт И наверное самый главный секрет моей проблемы - не учел угол, естественно он будет меняться по удалению. Всем спасибо, завтра буду допиливать

[Mikle]

т.е. сути прям в ней

Если "прям в ней", то косинус при малейшем удалении станет нулём, освещения не будет вообще.

[Sneaks]

Да, если начать учитывать угол падения луча, то нужно отодвигать источник по высоте.
Сейчас добавил квадрат расстояния, и картинка начало выглядить как будто рисую сферы, освещенные идеально с верху. Но я думаю это более правильная форма чем была у меня. И фактический радиус освещенной местности сократился... не берусь сказать точно, но на взгляд раз в 5-10. По этому радиус приходится указывать чрезмерно большим, но думаю я с этим потом поковыряюсь.