Unity3d - ограничения (43 стр)

Я думал динамик бранчинг использует хардварный инстансинг, а оказалось нет, там на ЦПУ магия. Ну чтож, рад, что они наконецто до инстансинга добрались, лучше поздно чем никогда. :)

Ещё до текстурных массивов добрались. Тоже всё тянули.

И передачу массивов в шейдеры переделали по-человечески, а не как раньше for (int i=0;i<length;i++) material.SetFloat("name"+i, ...);

alexzzzz
Cryengine 5 на пятки наступает. Вот и зашевелились))
Хотя я думаю найдется еще куча фич, до которых они и через 2 года не доберутся.

The general idea behind our implementation of instancing is that we pack per-instance data (including world matrices) into big uniform arrays, and in the shaders we use the system value SV_InstanceID to index into these arrays.

Ну вот, нормально решение, а не рудимент-атавизм PER_INSTANCE :)

Эх хотелось бы консервативную растеризацию в Unity.

К вопросу об ограничениях, не слышал ли кто-нибудь об успешных попытках прикрутить к Unity сторонний профайлер кода? Существующий для кода очень неудобен.

Когда мне надо что-то запрофилировать, я
1) выношу этот кусок кода в отдельный консольный проект в Visual Studio,
2) придумываю заглушки или способы обхода вызовов Unity API, которые в .net-проекте не работают,
3) разглядываю это проект в ANTS Performance Profiler, в котором можно увидеть статистику по выполнению любой строки кода,
4) вношу нужные исправления,
5) перекидываю исправленный код обратно в проект Unity.

Один из вариантов решения - изначально писать всё что можно в отдельную универсальную dll, но меня интересует, можно ли прикрутить человеческий профайлер в саму Unity или её Моно.

WISHMASTER35
> Cryengine 5 на пятки наступает. Вот и зашевелились))

Мне кажется появление в нашем измерении CryEngine 5 Unity не заметит, как не заметило появление Unreal 4. Ну т.е. толпы народа как носились между движками с криками «Ура! Графон!!! Ура! C#/C++/Lua/Python/Blueprint!!!», так и продолжат носиться. Но от них всё равно никакой пользы.

alexzzzz
Не соглашусь. Многие мои знакомые профессиональные разработчики отказались от юнити, и некоторые из
них используют UE4. Не все правда.
Юнити был пионером, и потому у него есть аудитория, которую уже довольно тяжело переучить. Но из-за того, что
сам движок довольно таки говнян по многим параметрам, ну и нестабильность и производительность с каждой версией
падает - всё это рано или поздно закончится тем, что ни один серьезный разработчик не будет рассматривать юнити
как платформу для своей игры.
Даже сейчас, например, Ragnar Tornquist в своём твиттере открыто ругал юнити 5 за баги и краши.

От себя добавлю, что я больше полутора лет работал с юнити (как раз начал со времени первого поста в этом топике), а
сейчас работаю с UE4 - и анрыл, по моему мнению, намного удобнее и стабильнее.

Mephisto std
> производительность с каждой версией
> падает
можно поподробнее/пруфы? не наезжаю, а реально интересно, ибо перебираюсь (вовремя, блин) с 4 на 5, и такой прогноз меня напрягает. что стало медленее? физика точно стала быстрее, это по всем тестам видно (ибо физикс новый). всё остальное по профайлеру вроде тоже не замедлилось.

Mephisto std
> Даже сейчас, например, Ragnar Tornquist в своём твиттере открыто ругал юнити 5
> за баги и краши.

Тем не менее, не жалеет.

David Hubner ‏@hubnerd  · Jan 4 
@ragso Question: In hindsight if you were just starting development on Dreamfall Chapters would you still be thinking of using Unity?

Ragnar Tørnquist ‏@ragso 
@hubnerd We would. Despite the problems it has served us well.

Вчера потыкал CE5 - монструозный двиг, который за пару часов упал раз 10, это я даже до скриптинга не добрался. Понравилось, что заточено под реал тайм и можно посмотреть отработку логики на ходу, не понравилось все остальное, в том числе явная заточка под FPS, да и туторов внятных гораздо меньше чем на юньку, так что думаю у многих "юнитеков" его появление разве что любопытство вызовет, по крайней мере я не стал задерживаться.

В Texture2D наконец-то появился нормальный способ загружать\выгружать данные: LoadRawTextureData и GetRawTextureData. Хотя ComputeBuffer.GetData более нормальный. Но не догадлив они так сделать и для текстуры.
В Texture3D и RenderTexture конечно же забыли или забили это сделать.
Так же появился метод Graphics.CopyTexture, которым можно гонять данные между Texture3D\RenderTexture и Texture2D.
Глядишь лет через 10-20 Unity обзаведется нормальным API.
А вообще лучше бы RenderTexture использовался бы только как RenderTarget ибо создавалась она именно для этого, а для ComputeShader сделали бы, чтобы обычные текстуры можно было бы сделать Read\Write\UAV.

Надо же - "появился способ". Интересно а как я его еще в 2014 году использовал? Ну, конечно он не был документирован, но вообще то очень давно работал.
Вот еще обсуждение: http://unity3d.ru/distribution/viewtopic.php?f=18&t=21955

seaman
И много еще таких недокументированных функций?

А пес его знает. Попадаются иногда...