ZXDEMOS.RU

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

Молодец, че)Отредактировано dr.Titus (2016-12-19 08:09:10)

В нашей парадоксальной вселенной, как раз говнокод быстро написаный и работающий - идеал, а идеальнокод, так и не написаный - грех.
У меня правда не поехало сходу. Чёрный квадрат наблюдаю. Буду ковыряться, почему так.

Reobne писал(а):
У меня правда не поехало сходу.

В хроме и эксплорере работает, за риндекс браузер и подобные не ручаюсь, говнокод он такой.

Reobne писал(а):
У меня правда не поехало сходу. Чёрный квадрат наблюдаю.

Так надо выбрать модель из списка и нажать кнопочку нарисовать.

А вообще неплохо было бы задавать на входе 3 угла поворота по осям, а матрицу поворота высчитывать в коде, путем перемножения трех матриц (поворот вокруг X, вокруг Y и вокруг Z).

deathsoft писал(а):
А вообще неплохо было бы задавать на входе 3 угла поворота по осям,

Нет смысла, единственной целью данной хрени было проверить отрисовку не на z80. Косяки подтвердились. Дальнейшее развитие бесполезно, разве что по приколу, итак работы еще не початый край.

В консоле джавы он писал, что ошибка тИпа: setLineDash - не функция.
Обновил файерфокс вместе с джавой и всё пошло.

"Show normalez" не работает?
И немножко разжуй, как действует "Scale". Если меняю его, то точки не двигаются, но расчёт видимостей граней меняется.
------
Изучил код. Строки 280-282 говорят, что Scale влияет только на расчёт видимостей плоскостей.
------
280-281 даже можно было-бы вынести из цикла?
282 выглядит математически верно, если скалярное произведение получать "матумножением" вектора на транспонированный вектор.
Осталось вычислять плоскости правильно, на основании координат узлов.Отредактировано Reobne (2016-12-20 13:27:02)

Reobne писал(а):
Изучил код. Строки 280-282 говорят, что Scale влияет только на расчёт видимостей плоскостей.
------
280-281 даже можно было-бы вынести из цикла?

Все так, по выносу это последствия отладки, конечно можно, изначально там была манипуляция со скалярами как в коде через индексы. Это я stat.v умножаю, а в коде model.normals.v делили. Именно к матричному виду я привел уже после.

Reobne писал(а):
282 выглядит математически верно, если скалярное произведение получать "матумножением" вектора на транспонированный вектор.

Не понял. По факту нужен только знак z, небольшой изврат с умножением на скаляр это потому что транспонирование и умножение матрицы на скаляр я сделал позже, можно конечно для каноничности переделать, но и так все правильно по результату.

Благодаря рендеру наметились оптимизации по коду, от нормалей отказываться нельзя (по точкам для большинства случаев будет медленнее), а вот оптимизировать их и сам алгоритм можно вполне. Формат хранения будет однозначно другой. Так же надо исключить отрисовки кораблей которые вне экрана, сейчас они определяются только z координатой, думаю можно сузить угол. По факту в 90% случаев реально рисуются 1-2 моделей из 7 максимально возможных, а считаются 3-4, тормоза из за этого приличные. Но сначала пересчет нормалей.
По scale. Нормали к плоскостям не единичной длины, они как я уже писал используются для определения точки удаления самой плоскости и масштаб нужен чтобы для близких точек не приходилось жертвовать точностью. Грубо говоря сам вектор может быть длины 128, а его удаление от центра модели делится на константу и получается 16 ( для scale=3). По моему очень элегантное решение, единственное надо заменить деление на глобальное умножение, ускорит неплохо этот момент.

krt17 писал(а):
оптимизировать их и сам алгоритм можно вполне. Формат хранения будет однозначно другой

посмотри может Кладов уже это сделал за тебя

GoodBoy писал(а):
посмотри может Кладов уже это сделал за тебя

Может и сделал, но нормали пересчитывать не стал, да и кладовская элита мне интересна в последнюю очередь, наверное потому что у меня такой не было.

Нашел я причину глючности нормалей, тупо одну из компонент вектора умножили дважды на масштаб . Наверное в ручную делали, не везде конечно, но местами промазали.Отредактировано krt17 (2016-12-21 20:26:37)

krt17 писал(а):
Нашел я причину глючности нормалей, тупо одну из компонент вектора умножили дважды на масштаб . Наверное в ручную делали, не везде конечно, но местами промазали.

Круто, значит и пофиксить легко, просто заново пересчитать и заменить в игре.

Молоток! )

Заново пересчитывать и заменять он не будет) Он же свой движок придумывает, оптимальнее и быстрее)

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

Если не будешь менять ничего, то хотя бы добавь 1-2 новые модели корабля) Интересно же было бы)

dr.Titus писал(а):
Если не будешь менять ничего, то хотя бы добавь 1-2 новые модели корабля) Интересно же было бы)

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

Свяжешься с вами, научишься ржаво скрипеть всякую гадость.
Дополнил говнокод своими ка, кодовыми извращениями. Чтобы плоскости высчитывались из координат узлов. Всё по тупому и не оптимально. Если узлов больше трёх, то коэффициенты наивно усредняются.
Чтобы считалка сработала, ставим галочку на "Calc planes"....
Стоп! А где на форуме кнопка добавить файл-то? Добавить картинку и видео вижу, а файл нельзя? Он много не займёт, всего 8 килобайт.
А пока пересчитанные координаты для кобры:
Код:0,0; 62,42.69278517869794; 31,19.852951024050345-18,-18.2516971737533; 55,55.35679582369133; 16,16.44658426645901618,18.2516971737533; 55,55.35679582369133; 16,16.446584266459016-16,-16.513312212884074; 52,53.71706289581203; 14,15.38119388150431516,16.513312212884074; 52,53.71706289581203; 14,15.381193881504315-14,-5.833758286588476; 47,51.337072921978574; 0,014,5.833758286588476; 47,51.337072921978574; 0,0-61,-60.92472068242524; 102,101.54120113737541; 0,-0.634632507108596261,60.92472068242524; 102,101.54120113737541; 0,-0.63463250710859620,0; 0,0; -80,-80-7,-6.3076757100813134; -42,-38.899226199373835; 9,7.8391967001182840,-3.1720657846433024e-18; -30,-26.33940666756184; 6,5.3041759846094697,6.3076757100813134; -42,-38.899226199373835; 9,7.839196700118284db #00,#2B,#14,#1Fdb #12,#37,#10,#9Fdb #12,#37,#10,#1Fdb #11,#36,#0F,#9Fdb #11,#36,#0F,#1Fdb #06,#33,#00,#9Fdb #06,#33,#00,#1Fdb #3D,#66,#01,#BFdb #3D,#66,#01,#3Fdb #00,#00,#50,#3Fdb #06,#27,#08,#DFdb #00,#1A,#05,#DFdb #06,#27,#08,#5F

Вначале идут расшифрованные параметры плоскостей, исходный рядом с пересчитанным. Ниже пересчитанные округлённые и зашифрованные.

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

Reobne писал(а):
А пока пересчитанные координаты для кобры:

Молодец конечно, но для меня бесполезно, мне надо матричные выкладки что бы я меньше отвлекался.

Шыншыл писал(а):
Мож кто вспомнит про энти трюки?

То что вы в школе через жопу делали это немного другое. Я думал над этим, там еще напутал скалярное и векторное, пока не знаю как лучше будет посмотрим. Читай все гоба, тут кода минимум, будешь 3д демы делать.

krt17 писал(а):
Читай все гоба, тут кода минимум, будешь 3д демы делать.

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

когда я маялся с 4squares, я перебрал массу дем и вышло, что поляки:
- рисуют фигурки по готовым наборам данных
- рисуют буффер и кидают на экран.

в опщем это не реалтайм выходит?

Шыншыл писал(а):
навскидку:

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

как и какого : надо смотреть на ходу. По идее есть известное быстрое умножение по таблицам квадратов, есть рисование линии не по координатам а с учетом экрана(такой способ реализован и мы делали году в 96м).

Че я делал в 96 я лучше не буду говорить ибо тогда я заселился в общагу. Да и по сути с 3д частью все закончено, как че рисуется понятно, че тормозит тоже. Ща рихтануть, добавить и дальше. Линии рисовать и умножать это лоу левел, собственно поэтому сюда это и попало, понятно и прикольно.

А на ходу смотреть я уже старый и голова занята весь день сраными цисками, не до прыти. Ты коли такой шустрый кладовскую разбери, народ интересуется а мне как то на нее параллельно.

ладно, я спросил ты ответил. Вернемся, когда будет время.

Пересилил себя пересчитать нормали. И столкнулся с такой батвой как векторное произведение, а именно с ... символом зла Леви-Чивиты. Оно то понятно что условиями перебора задается легко, но как то это не православно, а на форуме бог как никак. Вездесущий инет как то не дал прикольной формулы, да и я сам чет туплю. Охота сделать универсально для вектора размерности N, я так понимаю один фиг придется сделать пару ифов?

В жопу его, для N=2 можно сделать отдельную хрень, а для N>2 универсальная с условиями покатит.