[Unity3D] Делаю свой фреймворк для рисования линий. (4 стр)

Это вообще откуда результаты? Как работает LineRenderer и в чем отличие от генерации Mesh объекта? И "намного медленней" это в сравнении с "молниеносно" да? Ну типа 1мс или 2мс на кружок. Притом что генерация нужна 1 раз. При старте уровня, или при пеерходе в нужное окно и т.п. Если конечно игра не про редктирование радиусов кружков что в 0-посте, т.е. если у юзера нет UI с этими всеми настроками. А если про это - так это уже редактор мешей юзером, а не гейм-разработчиком.

кстати для прерывистой линии есть лайфхак, текстурировать "пустые сегменты" и переходы прозрачной текстурой. с ЛР не знаю катит такое и нет, и дружит ли он вообще с текстурами.
с обычным рисованием линии - 100% работает.

Пруфы в студию? Такие обороты "везде" да еще без пруфов, будто само-собой разумеещееся.. А еще WebGL юзает il2cpp для перевода из C#, а потом это cpp одинаков и для движковых-фукнций и для скриптов. Потом это cpp переводится в asm.js или webasm и там опять же одно. Наверное автор темы не вкурсе?
Кроме прочего, как мною по замерам определено для некоторых задач меш-генерации и трианглуляции (я тут пруфов тож не дам), производительность зависит от алгоритма и подхода, а вовсе не от [InternalCall] или написания сразу на cpp, вместо C#.

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

базара нет, что емкие расчеты на скрипте - это гавно по сравнению с CPP. если не использовать модные Burst и mathematics , но Burst пока не устоявшаяся технология и нужно 10 раз подумать прежде чем применять это в продукте. ну и они все равно не помогут избежать перезаливки геометрии.

А проблема в раскраске градиентами чтоли? Можно Uv2 \ Uv3 для любых целей юзать на каждой вершине, хоть на индекс stop внутри градиента, хоть на индекс градиента, можно еще юзать текстуру в которой закодированы все переходы градиента в rgba.

Mira

Под WebGL не умеет видеокарта зачастую на слабых системах.
, мы на ноутбуках тестили и не пашет.
Разбивка на под-меши - не сложно, "менеджер" за пру дней в самом сложном случае пилится.

Mira
> ну и они все равно не помогут избежать перезаливки геометрии.
а автору темы оно надо? Где у кого-либо была задача чтоб в рунтайме по каким-то правилам делать анимацию? Не один раз сгенерить меш? Морфинг или анимация, или даже создание кучи мешей - оно вообще решается другими штуками.

Alex_Hell
> А проблема в раскраске градиентами чтоли?
Автор боится что ему придется все это в меш запихивать самому, и еще не дай баже считать разницу между векторами на CPU или какие то более сложные расчеты (хотя нет в этом надобности).
Alex_Hell
> Морфинг или анимация
У него там анимация диаграмм для инфографики. Одним морфингом не обойдешься потому как количество вершин меняется.

Для всех кому нужны пруфы на то что InternalCall будет быстрее чем та же самая функция на c#

1) Вызовите 100 000 раз  какой нибудь Quaternion.Inverse
2) напишите функцию инверсии кватерниона скриптом
и вызовите ее 100 000 раз
3) сравните результат.

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

Polyflow3d
Ваш проект будет поддерживать штриховые линий?

DanielDem

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

Polyflow3d
> Для всех кому нужны пруфы на то что InternalCall будет быстрее чем та же самая
> функция на c#
ок, экспрессивный матан понятно зачем в обертке, но большая часть функций тупо завернуто в InternalCall потому, что нужно взаимодействие с ядром движка или слоем GAPI . которые из манаджед кода тупо не доступны. а не то что будет заметно быстрее.

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

так как через mesh.vertices тебе сначало придется заполнять свой массив, а потом движок уже будет (в лучшем случае) пересобирать весь VBO записывая туда кешированные UV, нормали и прочую лабуду включая новые вершины.  блокировать и обновлять в нем данные еще больнее (если не юзал markDynamic).

Mira
> пересобирать весь VBO записывая туда кешированные UV
Да я сейчас потестил с mesh.UploadMeshData(true); и он ругается если попробовать после позиции вершин попробовать дозалить нормали. Видимо все таки собирает в общий массив.

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

Было бы намного эффективнее если бы они приделали интерфейс к внутреннему общему буферу.

foxes
> mesh.UploadMeshData(true);
с параметром true VBO меши  создается с параметром USAGE_DEFAULT то-есть чисто GPU буфер не отображаемый в память. его можно только пересоздать но нельзя обновить содержимое, или прочитать из него.
это я проверял лично.

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

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