Як визначити порядок жеребкування у флеш-грі із ізометричним видом?

Це для флеш-гри з ізометричним видом. Мені потрібно знати, як сортувати об’єкт, щоб не було необхідності перевірки z-буфера при малюванні. Це може здатися простим, але є ще одне обмеження, сцена може містити 10 000+ об'єктів, тому алгоритм потрібно запускати менше ніж O (n ^ 2). Усі об’єкти - прямокутні коробки, а в сцені рухаються 3-4 об’єкти. Який найкращий спосіб зробити це?

ОНОВЛЕННЯ

у кожній плитці є лише об’єкт (я маю на увазі, що об’єкти не можуть укладатися один на одного). і ми отримуємо доступ до обох карток Об'єктів і Об'єктів мають своє положення.

ОНОВЛЕННЯ2

дивіться ці цифри:

спочатку слід намалювати перший спочатку синій предмет, потім зелений, а потім червоний. тоді як у другому ви повинні намалювати їх у зворотному порядку. вам потрібно намалювати спочатку червоний, а потім зелений та нарешті синій об’єкт. як ви бачите, різниці в положенні синіх та червоних об'єктів немає, вони мають різну відстань від камери тощо. але через їх відносне положення до зеленого поля потрібно змінити їх порядок малювання між двома зображеннями. ось що робить цю проблему безладом.

бічне зауваження: оскільки всі об’єкти мають прямокутну призму, математично можна довести, що існує принаймні один порядок малювання для задоволення проблемних потреб.

Це насправді дуже просто, якщо ваші предмети відповідають вашим ізометричним плиткам. Погляньте на це зображення:

Спочатку слід намалювати об’єкт у червоному положенні, потім об'єкти у синьому, потім зеленому, потім жовтому, потім пурпуровому тощо, ... Потрібно бути досить очевидним, як це реалізувати, якщо на вашій дошці є об'єкти замість об’єктів маючи позицію як атрибут. Якщо це не ваш випадок, вам слід зберігати окрему структуру даних, оновлюючи її щоразу, коли об’єкт рухається (що також має бути досить простим.)

У цьому з’явилася нова проблема: ви можете легко побачити, наскільки її складність дорівнює O (N), де N - розмір вашої дошки ( N=W*H). Для подолання цієї проблеми просто створіть нову лінійну структуру даних, де кожен індекс у вашій структурі відповідає заданій глибині, оновлюючи її щоразу, коли об’єкт змінює глибину.

Випадок, коли об’єкт не відповідає одній плитці, трохи складніше, тому я опублікую його, якщо вам це потрібно, як тільки ви оновите своє запитання.

Я не маю спеціальних знань з цього приводу, але ось думка.

Почніть з позначення кожної комірки як "не намальована". (Або, що еквівалентно, використовуйте масив, щоб зобразити розташування найближчої "намальованої" речі на кожній "ближній лінії" комірок, або набір тощо). Потім для кожної комірки (я б, мабуть, пройшов їх через порядок, описаний якD): перевірте, чи ця клітина намальована; якщо він не був намальований і містить об'єкт, перевірте, чи була намальована кожна комірка, яка була б затемнена цим об'єктом, і якщо не намалювати її рекурсивно; намалюйте об'єкт, що міститься в цій комірці, якщо необхідно і позначте цю клітинку та будь-які комірки, зайняті її об'єктом, як "намальовані".

Я припускаю, що ви можете швидко зіставити клітинку з об'єктом всередині неї, якщо такий є. Я вважаю, що це час O (n), хоча це може призвести до створення великого стека (який, можливо, ви захочете перетворити на зв'язаний список, якщо ви переживаєте, що не вистачить місця у стеку).

Якщо вам справді потрібен список, ви можете додати його до списку замість малювання. Я підозрюю, що починати з в основному відсортованого списку не допомагає.

Я б застосував алгоритм художника з відстані такси з відстані від камери, віддаленої від камери, спочатку намалював ті, хто найближчий до камери, а потім перемістився назовні.

Редагувати: це не працює, якщо ви не можете намалювати вміст кожної комірки окремо.

Що змушує вас вважати, що "математично можна довести, що існує принаймні один розіграш для задоволення проблемних потреб"? Ось тривіальний контрприклад, де ви не можете покластися на z-сортувальні об’єкти: