conflicts with the imported type

[iqubik]

Столкнулся с проблемой, точнее ограничение движка на операции с объектами в которых больше 65000 triangles.
Сцена:
Плэйн с нойзом сделанный в максе (12800 триугольников) - успех
Чайник с 40 сегментами на гранях (102080 триугольников) - отказ (Meshes may not have more than 65000 triangles at the moment: Teapot03)
Не зависит от формата импорто-экспорта(collada,3ds,max).
------
Решаемо? Искусственно?

[Neodrop]

Я лично загружал объекты с куда бОльшим количеством полигонов. Не пойму, что там у вас стряслось...

[gnoblin]

Есть такая "проблема", действительно. Только что проверил.
Но она легко лечится разделением такого чайника на две части в максе (при сохранении одной сцены): выбираем половину поликов чайника и тыркаем detach.
Так что это совсем не проблема даже).

[Neodrop]

Точно ставил больше. Но в Маке (OpenGL)... Если не забуду, проверю как - нить.

[iqubik]

Есть такая "проблема", действительно. Только что проверил.
Но она легко лечится разделением такого чайника на две части в максе (при сохранении одной сцены): выбираем половину поликов чайника и тыркаем detach.
Так что это совсем не проблема даже).

Древние времена, постройка какой нибудь мега статуи шла в Афинах.
А ставить статую надо было в Риме....

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

К слову у quest3d таких ограничений нет.

А если серьёзно. То я побаиваюсь начинать работать с юнити именно из-за этого ограничения.
Интересный факт obj(максовский при эскпорте сразу говорит что у объектов более 65к поликов).

[Neodrop]

В любом движке есть это ограничение. Оно - в основе DirectX .
Просто каждый двиг (который его обходит) обходит его по своему. К примеру - дорогой и пафосный Virtools вообще до сих пор не смог его преодолеть.
Ещё раз повторю : вам подробно, с примером, объяснили, что проблемы в этом нет.
Если для вас она остаётся, что-ж, видать нам не по-пути.

[Const_47]

К слову у quest3d таких ограничений нет.

Нет если юзать .cgr экспортер, а вы PandaDX попробуйте

[iqubik]

Позиция ясна. Я так понимаю что юнити пока не собирается преодолевать это ограничение?

Слабые места в юнити которые бросаются в глаза:
1. 65к ограничение на импорт объекта
Решение: детачить в редакторах и компоновать в юнити.
2. В случае просмотра демки из под браузера при ошибке в игре браузер полностью улетает в небытие.
Пример: Простая сцена, плэйн нойзовый и чайники высокополигональные. Колижены назначены по геометрии объектов (то есть родные и оч сложные). При попытке врезаться камерой в такой коллижн плагин юнити для firefox умирает и захватывает с собой сам firefox. Захватывает жестко, даже без краш репорта.
Решение: назначать свои колижены и тестить (хорошенько тестить) проект перед публикацией.

----
Ваши мысли:?

[Neodrop]

Вылет броузера это не минус Юнити. Это черта абсолютно всех 3D плееров, работающих в броузерах.

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

[Const_47]

&icubic
Никакой физ двиг будет корректно работать, считая тучу поликов для коллизии.

Позиция ясна. Я так понимаю что юнити пока не собирается преодолевать это ограничение?

Может стоит пересмотреть свои взгляды на сборку сцен? А нужно ли Юнитеху вообще это преодолевать, никогда не сталкивался в нужде с таким количеством поли в одном меше.

[Serge]

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

[Serge]

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