Войти
ПрограммированиеФорумГрафика

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

Страницы: 1 2 3 4 5 6 Следующая »
#60
16:53, 7 янв. 2019

Mira
> я например использую ка краз буфер размещенный в GPU так как с ним можно
> напрямую в GAPI работать.
Подогнал бы примерчик.


#61
20:59, 7 янв. 2019

Mira
> создается с параметром USAGE_DEFAULT то-есть чисто GPU буфер не отображаемый в
> память. его можно только пересоздать но нельзя обновить содержимое
Это как? USAGE_DEFAULT буфера вполне себе обновляются черезе ID3D11DeviceContext::UpdateSubresource

#62
21:41, 7 янв. 2019

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

#63
9:04, 8 янв. 2019

Mira
> ну речь про копирование из системной памяти
Ну так ID3D11DeviceContext::UpdateSubresource именно это и делает. То есть DEFAULT ресурс вполне себе может быть обновлен. А вот как оно в юнити - я не знаю.

#64
9:55, 8 янв. 2019

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

#65
12:29, 8 янв. 2019

Mira
> проверял, он чето давал у меня просадку
Ну как... он достаточно неплох. Особенно если тебе нужно только часть одного большого буфера обновить - это будет лучший вариант. Например блендшейпы если на CPU, то лучше обновлять именно этим способом, а не динамик буфером.

#66
13:34, 8 янв. 2019

MrShoor
этот выделяет память, копирует туда твои данные, и отправляет ее в комманд буффер , чтоб когда у GPU "дойдут руки" скопировать уже в VM.
динамический вроде как постоянно держит эту память. при Map ее фиксирует, а так она в свободном плавании.

#67
1:20, 9 янв. 2019

Чисто для информации:

В Вектросити 80% времени занимают вызовы пары методов: Camera.ScreenToWorldPoint и Camera.WorldToScreenPoint. Для чего они нужны, не вникал.

ScreenToWorldPoint ничего не делает, вызывает свой аналог с другой сигнатурой, тот в свою очередь вызывает extern-метод (который InternalCall). Если такой тройной вызов заменить делегатом, который сразу запускает InternalCall, то всё работает быстрее (типа ~40мс вместо ~50мс). Как там дальше считается ― хз. Я вообще не уверен, что ScreenToWorldPoint писался с расчётом, чтобы его вызывали десятки тысяч раз за кадр. Может да, может нет, а может это интероп тормозит, если он там есть.

WorldToScreenPoint устроен аналогично.

Было бы интересно заменить вызовы этих методов явным кодом на C# и посмотреть, что будет.

#68
(Правка: 2:45) 1:29, 9 янв. 2019

alexzzzz
> Для чего они нужны, не вникал.
Проекция координат, из мировых в экранные и наоборот. Такие расчеты хорошо переносятся в шейдер.
alexzzzz
> Было бы интересно заменить вызовы этих методов явным кодом на C# и посмотреть,
> что будет.
Там умножение на матрицу проекции projectionMatrix и матрицу камеры worldToCameraMatrix (прямую и обратную) и масштабирование по разрешению экрана. Просто выведи результат оригинала для Camera.transform.forward + Camera.transform.position и там видно будет чем заменить.
Допустим если разрешение экрана 1191x614 (как у меня в отладчике показывает) то результат получается (595.5, 307.0, 1.0).

для Camera.WorldToScreenPoint можно такую формулу использовать

        Vector4 v = (Camera.main.projectionMatrix * Camera.main.worldToCameraMatrix) * new Vector4(tv.x, tv.y, tv.z, 1.0f);
        v.x = (v.x/v.z + 1.0f) * Camera.main.pixelWidth * 0.5f;
        v.y = (v.y/v.z + 1.0f) * Camera.main.pixelHeight * 0.5f;

для Camera.ScreenToWorldPoint получилось такое

        Vector4 tv.x = (v.x * (2.0f / Camera.main.pixelWidth) - 1.0f) * v.z;
        tv.y = (v.y * (2.0f / Camera.main.pixelHeight) - 1.0f) * v.z;
        tv.z = v.z;
        tv.w = v.z;
        tv = (Camera.main.projectionMatrix * Camera.main.worldToCameraMatrix).inverse * tv;

#69
2:44, 9 янв. 2019

Polyflow3d
> Для всех кому нужны пруфы на то что InternalCall будет быстрее чем та же самая
> функция на c#
Ага, особенно учитывая предыдущее
Polyflow3d
> У меня такое чувство что я один на webGL ориентируюсь, все остальные только для dx12 разрабатывают

.. получается сначала автору нужно WebGL, а потом он сравниват C# с InternalCall  на с++
Я ничего не упустил?

выше уже был ответ

А еще WebGL юзает il2cpp для перевода из C#, а потом это cpp одинаков и для движковых-фукнций и для скриптов. Потом это cpp переводится в asm.js или webasm и там опять же одно. Наверное автор темы не вкурсе?

автор пусть сам сравнит и приложит пруфы, мне есть чем заняться

#70
2:46, 9 янв. 2019

Alex_Hell
> Я ничего не упустил?
Ты много чего еще подобного упустил. :)

#71
2:59, 9 янв. 2019

Polyflow3d
> О, еще один клоун-эксперт сообщил мне что:
кстати данными постами только автор себя клоуном выставляет :)

> 1) лайн рендер это меш, а мешь можно сгенерить. (ну это каждый эксперт тут сказал)
а что не mesh? но в 0-посте (и далее) автор заявил что не знает как LineRenderer рабоатет и поэтому меш генерить нельзя, ну типа медленно

> 2) что круг это не линия, а кривая
учитывая что тема называется "Делаю свой фреймворк для рисования линий" никакого фреймворка для рисования линий я не вижу, вижу интерполяцию кружков с разными параметрами.. ну кстати пунктиры и разные толщины это параметры линий - о них тоже речь шла, молодец автор что это хоть задумал делать, а показать кроме той демки под вебом есть что? демка не плохая если честно, но явно не тянет на фреймворк, и уж точно не ясно как ее юзать, и какой полный flow

> 4) линии нужно рисовать один раз при старте уровня, потом менять нельзя, иначе пользователь сам дурак.
не правда, я показал только то что рисовать можно (не не обязательно) для ускорения - в начале уровня.. если автору надо рендер каждый фрейм своих кружочков или полигонов (как в демо) так это тоже делается в момент изменения, и уж точно не каждый фрейм.. если этого UI как в демо - у юзера нету - знач нефиг обновлять постоянно.. в чем проблема то закешить? оно итак уже кешится.. автор занимается передергиванием, то оно в реале кешится, то заявляет в духе "1 раз хагрузить не камильфо, юзер дурак чтоли 1 раз роендерить"

> 5) и вообще зачем нужны кружечки, у тебя что, игра про кружечки?
ну и про что игра? игры тут нет.. фреймворк - не ясно для чего.. хоть бы список API был, и тезисно что планируется еще делать

> 6) Юнитеки дауны, вместо того что оптимизировать подходы и алгортмы, какими то не нужным InternalCall пользуются.
причем тут дауны или нет, вообще речь о WebGL
мы все ждем пруфов, что вот в C# эта генерация Mesh с заданными вершинами оч уж медленная в скрипте, а магически заюзанный LineRenderer с его InternalCall (если я не попутал) быстроый.. или что там быстрое то? автор сам генерит недо-билденный-меш когда списки вершин генерит для LineRenderer, на что ему уже было указано кроме меня - ранее - другим человеком
Ничего не забыл?

#72
(Правка: 3:10) 3:05, 9 янв. 2019

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

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

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

то что LineRenderer делает - очень очень не существенно для производительности,

всякие вызовы генерации меша по уже сгенеренным точкам - вообще меньше 1%
и уж юзать тут LineRenderer или уже Mesh - никакой разницы

#73
(Правка: 3:27) 3:24, 9 янв. 2019
lines | [Unity3D] Делаю свой фреймворк для рисования линий.

Справа оригинальный код Вектросити (~40мс), слева он же с заменой ScreenToWorldPoint и WorldToScreenPoint на C# аналоги, как их привел foxes (~20мс). Одна непрерывная линия из 15 тысяч контрольных точек.

#74
(Правка: 3:30) 3:28, 9 янв. 2019

alexzzzz
О круто! А ты всякую муть из цикла выносил на подобии:
(Camera.main.projectionMatrix * Camera.main.worldToCameraMatrix)
(Camera.main.projectionMatrix * Camera.main.worldToCameraMatrix).inverse
Это можно в отдельные матрицы запихать и еще от деления также избавиться.

Страницы: 1 2 3 4 5 6 Следующая »
ПрограммированиеФорумГрафика