Comments 20
Другой способ: отображать заранее отрендеренный ландшафт как фон и спрайты в UI для обозначения предметов. Это конечно потребует написание кода, зато предполагаю будет меньше вычислений.
По моему, это все равно что забивать гвозди микроскопом… Рендер сцены, второй раз… Я теперь понимаю почему плохие игры на юнити тормозят.
Я не спец в Unity2D, но хотелось бы узнать, а как правильно это сделать с вашей т. зрения?
Хуже будет дальше, когда они начнут делать масштаб и пытаться зарендерить все кружочки попавшие в камеру и весь мир))), а еще попытаться сохранить масштаб кружочка персонажа, чтобы при увеличении карты он не стал размером с пиксель.
Рендерится один только слой. Я попробовал закинуть на сцену побольше роботов (30) и посмотреть изменение фпс… не увидел просадки. Точнее, просадка была, но не из-за миникарты, а из-за бОльшего количества образовавшихся теней от объектов, что неудивительно. После оключения теней разницы в фпс не вижу.
Быть может глупый вопрос, но разве дополнительный рендер сцены не влечет кратное повышение ресурсоемкости? Да еще эти фокусы с шариками. Похоже на большой колхоз «на коленке» с инструментами, не предназначенными для таких задач в принципе.
Рендерится только слой с шариками и фон, так что ответ на Ваш вопрос скорее «нет», чем «да». Однако на «колхоз» действительно похоже. Не оптимально, не производительно, но зато быстро. Так что как вариант — имеет право на жизнь.
Ответил выше про рендер. А какой инструмент вас смутил? Render Texture? Читаем мануал юнити: Render Textures are special types of Textures that are created and updated at runtime.
За такие методы рисования миникарты стоит выделять отдельный котёл. Как сделать грамотно: текстура фона(ортографический рендер или рисованная карта), поверх неё текстуры обозначающие персонажей, дальше понадобится немного кода, который будет мировые координаты персонажей приводить к экранным координатам относительно фона.
А описанный в статье метод, даёт лишние дроуколлы, которые могут понадобиться для чего-то более красивого.
А описанный в статье метод, даёт лишние дроуколлы, которые могут понадобиться для чего-то более красивого.
На этапе прототипирования, когда геймдиз срочно просит миникарту, может пригодиться.
Ух, помню еще на Blitz3D делал такую «мини-карту» и просто надеялся, что оно не будет тормозить.
Прошло столько времени, уже и движек другой, а колхозные методы остались. Приятно :)
Конечно, данный способ не применим в продакшене, но, как и сказали выше, когда срочно требуется составить план мира, как временный вариант — самое то, даже без кружочков.
Прошло столько времени, уже и движек другой, а колхозные методы остались. Приятно :)
Конечно, данный способ не применим в продакшене, но, как и сказали выше, когда срочно требуется составить план мира, как временный вариант — самое то, даже без кружочков.
Данный метод несмотря на свою простоту имеет явные недостатки.
1. Низкая производительность.
2. Для добавления новых меток надо создавать новые сферы (лишний хлам в префабах).
3. Добавление новых типов меток и их фильтров для различных игроков сильно затруднено.
4. Для смены внешнего вида метки необходимо создавать меш!
5. Лишние объекты на каждой сцене => лишняя сложность => сложнее разработка и поддержка.
6. Сложно тестировать => больше возможных багов (с учетом 3).
По моему мнению нужно сразу избегать подобных решений.
Как вариант делаем Mono скрипт MiniMap с возможностью добавления и удаления Mono объектов типа MapMarker.
MiniMap отслеживает координаты MapMarker`s и основываясь на внутренней логике возвращает относительные координаты объектов.
За прорисовку карты отвечает третий скрипт который не входит в систему мини карты (GUI отделено от логики).
Более подробного описания сделать сложно. Точный вид классов сильно зависит от задачи решаемых разработчиком.
1. Низкая производительность.
2. Для добавления новых меток надо создавать новые сферы (лишний хлам в префабах).
3. Добавление новых типов меток и их фильтров для различных игроков сильно затруднено.
4. Для смены внешнего вида метки необходимо создавать меш!
5. Лишние объекты на каждой сцене => лишняя сложность => сложнее разработка и поддержка.
6. Сложно тестировать => больше возможных багов (с учетом 3).
По моему мнению нужно сразу избегать подобных решений.
Как вариант делаем Mono скрипт MiniMap с возможностью добавления и удаления Mono объектов типа MapMarker.
MiniMap отслеживает координаты MapMarker`s и основываясь на внутренней логике возвращает относительные координаты объектов.
За прорисовку карты отвечает третий скрипт который не входит в систему мини карты (GUI отделено от логики).
Более подробного описания сделать сложно. Точный вид классов сильно зависит от задачи решаемых разработчиком.
Вопрос не по теме, но: можно ли сделать так, чтобы один и тот же объект для разных камер имел разный цвет? Как-то через шейдеры? Основное условие — не создавать 2 объекта, а использовать один объект.
Вот такой скрипт сделает то, что вам нужно:
Только вешать его надо на камеру, на которой надо подменить материал. Ещё есть вариант сделать с Camera.SetReplacementShader, но там всё немного сложнее и вряд ли решит именно вашу задачу. И ещё учтите, что этот код изменит материал у всех объектов, на которых висит тот же материал, что и на целевом объекте, если вам это не нужно, то замените sharedMaterial на material.
using UnityEngine;
using System.Collections;
public class PrerenderChangeMaterial : MonoBehaviour {
public Material replacementMat;
public GameObject target;
protected Material tempMaterial;
protected MeshRenderer targetRenderer;
void Awake()
{
targetRenderer = target.GetComponent<MeshRenderer>();
}
void OnPreRender()
{
tempMaterial = targetRenderer.sharedMaterial;
targetRenderer.sharedMaterial = replacementMat;
}
void OnPostRender()
{
targetRenderer.sharedMaterial = tempMaterial;
}
}
Только вешать его надо на камеру, на которой надо подменить материал. Ещё есть вариант сделать с Camera.SetReplacementShader, но там всё немного сложнее и вряд ли решит именно вашу задачу. И ещё учтите, что этот код изменит материал у всех объектов, на которых висит тот же материал, что и на целевом объекте, если вам это не нужно, то замените sharedMaterial на material.
Извиняюсь, двусмысленно написал. Я хотел сказать, что если изменить свойства sharedMaterial, то это отразится на всех объектах с тем же материалом. В приведённом коде всё будет работать нормально, т.е. материал сменится только у целевого объекта.
Спасибо, попробую Ваш подход. Выглядит именно так, как мне нужно.
Sign up to leave a comment.
Создание миникарты на Unity