Войти
WarZesФорум

Система сцены для движка (комментарии) (3 стр)

Страницы: 1 2 3 4 5 Следующая »
#30
17:24, 16 янв. 2014

SunnyBunny
> например нужно создать вектор и заполнить его указателями на коллайдеры (ведь
> вряд ли физ-движок хранит контакты в удобном для нас виде)
Эм, посмотрите внимательно код, надеюсь вы знаете что такое передача по ссылке и чем оно отличается от передачи по значению. Ну а если нет (извиняюсь конечно:) ):

const std::vector<Collider*> &
Мы передаем не сам массив, а константную ссылку на массив.

Далее. Данный массив формируется только при реальном событии столкновения. Но опять же - он содержит указатели, а не сами объекты

SunnyBunny
> Я говорил о тех случаях, когда у объекта есть коллайдер, но на столкновения он
> никак реагировать не должен.
если будет в этом проблема (а это надо проверять на реальных примерах), то введу флаг отменяющий выполнение скрипта. Как в юнити Is Trigger (только он наоборот - выключает сам колайдер, но включает скрипт)

И к вопросу выше. Так и так, массив std::vector<Collider*> будет сформирован, независимо от того, должен ли объект реагировать или нет. Причина - движок ведь должен еще и сам обрабатывать события. Тот же камень. Конечно пользователю не нужно писать для него скрипт столкновения. Но вот движок должен недопустить чтобы через камень можно было проходить. То есть камень формирует std::vector<Collider*> и сообщает каждому элементу что ему сюда нельзя.

- Обрабатываем столкновения
---- берем первый Collider участвующий в столкновении
---- составляем ему массив Collider, с которыми он столкнулся (std::vector<Collider*>)
---- выполняем физические действия для данного Collider и Collider в массиве (непроходимость, катание, отталкивание и т.д.)
---- вызываем виртуальные методы Script::Contact у Collider, передавая константную ссылку на массив std::vector<Collider*>

#31
17:37, 16 янв. 2014

war_zes
Окей. Я понял.
У нас разные представления о том, как делаются производительные системы, о том для чего нужна компонентная система и вообще)
А разговор в стиле "надеюсь вы знаете что такое передача по ссылке" мне неинтресен.

#32
18:00, 16 янв. 2014

SunnyBunny
> мне неинтресен.
просто серьезно:
>>то входные аргументы для него все равно нужно сформировать.
Что я еще мог на это спросить? Вот и спросил

Но вообще не обижайтесь, если что не так - мне лично это дискуссия интересна, четче вижу как делать

SunnyBunny
> о том для чего нужна компонентная система
Я не делаю компонентую систему. В чистом виде она мне не нравится. И я тут погуглил на этом форуме, и понял что в чистом виде у нее есть несколько нерешаемых недостатков - например тот же transform, когда он нужен и физике и видеосистеме. или то что, в реальности не получается работать с абстрактными Component и приходится их кастовать к предкам:

MeshFilter filter = lod.GetComponent<MeshFilter>();

Поэтому я решил делать некую вариацию на основе компонентной системы. То есть с одной стороны объект состоит из компонент. С другой - нет абстрактного уровня. Все компоненты знают о себе

SunnyBunny
> как делаются производительные системы
Я тоже любитель оптимизировать каждую строчку. Но в определенный момент я понял что в серьезном 3D движке столько всего выполняется, что все мои оптимизации смешны. оптимизировать надо реально. И в этом мне помогает то, что у меня дешевый бюджетный ноутбук с i3, 3 гигами памяти и 512 мб видеопамяти от мобильного радиона. И ниче - мой движок летает

SunnyBunny
> производительные системы
Да и вообще. Я же выше написал. Метод Contact будет зваться по факту, когда реально будет нужен. И даже в этом месте можно оптимизировать - например не звать повторый Contact если прошло слишком мало времени (то есть объект не успел еще среагировать)
А то что формируется массив - он так и так будет формироваться - столкновение же произошло, и надо знать кто столкнулся. Так что и здесь лишней работы нет
И такая физика у меня прямо сейчас стоит с формированием массива столкнувшихся и вызовом callback функция реагирования. Производительность не упала. Так что заменив калбаки на виртуальные методы - я ничего не теряю

#33
2:04, 17 янв. 2014
Еще у них есть несколько указателей на свойства (Collider, MeshRender). они могут быть нулевыми - а значит у данного объекта их нет, то есть не все GO нуждаются в колайдере

В юнити сейчас две системы частиц, две системы анимаций, 3д и 2д коллайдеры. Получается, что старые системами уже не используют, а свойства так и остались. А вот на новые системы они свойства кажется не добавляли. Зато теперь есть collider и collider2D, что как-то странно.

Я уже сам не знаю компонентная система это хорошо или плохо. Смотрел в уроках по Cryengine или UDK, так там на меш и коллайдер создавали два объекта. А на тригер еще и третий создавали.  Мне это кажется еще хуже.

В любой момент времени может быть только одна сцена... Но их можно смешивать (то есть из двух сцен создать одну, вообщем тоже идея из юнити).

А я бы сделал, чтобы сцена могла состоять из других сцен. Для удобства можно было бы графику в одной сцене создавать, а логику в другой. Отключать\включать одну сцену(меню). TimeScale настраивать для каждой сцены.
Кстати, где-то читал, что в каком-то движке, чтобы не загромождать иерархию, в сцене есть несколько типов объектов и каждый тип хранится в своем списке.
Также на сцене есть одна камера, потому что я не понимаю этой фичи в юнити с возможностью создать сцену без камеры (и получить черный экран) или создать несколько го с камерами.

Иногда надо создавать две камеры. Оружие в FPS рендерится второй камерой, чтобы не проваливалось в стены. На консолях раньше часто играли вдвоем на одном ТВ. В гонках зеркало заднего вида. И просто для зеркала или отражения в воде создаются дополнительные камеры. Можешь легко сделать управление повесив просто на него скрипт, который будет работать с камерой как с обычным объектом. И если новичок, то сразу видишь в сцене камеру и все ее настройки, а не ищешь их черт знает где.
#34
10:14, 17 янв. 2014

Ну и где система сцены ? :)

#35
14:57, 17 янв. 2014

innuendo, не мешай дискуссии.

#36
11:24, 19 янв. 2014

SunnyBunny
> Сколько всего методов планируется у Скрипта. Если посмотреть в юнити то там у
> MonoBehavior их около 60. Это же жесть))
О, я придумал, как решить эту проблему... С помощью наследования скриптов. У меня же пользовательский скрипт наследуется от базового Script. так вот, для каждой ситуации написать несколько других базовых. Например, хочет пользователь в скрипте работать с  мешами, он тогда пишет

class Foo : Script, MeshScript
{
};
Хочет с колайдерами, пишет:
class Foo : Script, ColliderScript
{
};
А хочет и с мешами и с колайдерами, то пишет:
class Foo : Script, MeshScript, ColliderScript
{
};

И ничего другого пользователь делать не будет. Все остальное доделает движок. Мне такое решение нравится:) А то и правда всяких полей может оказаться дофига и большая часть будет не нужной пользователю

#37
12:24, 19 янв. 2014

Както это все сферично-вакумно выглядит. По сути выходит пользователь получит охапку скрипт-интрерфейсов которые ему придется низкоуровненно программировать. Даже на уровне теории это уже выглядит отпугивающе. Вобчем все сведется к множественному наследованию, кастам-перекастам и прочим плюхам ООП. Я бы отбросил плюсы и разрабатывал на чистом Си, играя со структами внутри, а пользователю предоставил бы только мета-язык для выбора регистратора и обработки событий.

#38
12:41, 19 янв. 2014

Zloten
> По сути выходит пользователь получит охапку скрипт-интрерфейсов которые ему
> придется низкоуровненно программировать
нет, все точно также как на unity В юнити же никого это не отталкивает. Хотя там намного больше
>>множественному наследованию, кастам-перекастам и прочим плюхам ООП
И половину из этого я пытаюсь убрать от пользователя

Zloten
> Я бы отбросил плюсы и разрабатывал на чистом Си, играя со структами внутри, а
> пользователю предоставил бы только мета-язык для выбора регистратора и
> обработки событий.
Я не люблю функциональщину и все, на нее похожее. У меня ООП головного мозга с рождения:) ООП я понял раньше чем написал первый хеловорд

#39
13:47, 19 янв. 2014

Эх, посадить бы вас, оопистов, на Спектрумы на месяцок, а лучше на Корветы или Агаты :-) и штоб тока чистый асм, и ни сточки Сей, ррррр :-)

#40
20:33, 19 янв. 2014

Zloten
> Эх, посадить бы вас, оопистов, на Спектрумы на месяцок, а лучше на Корветы или
> Агаты :-) и штоб тока чистый асм, и ни сточки Сей, ррррр :-)

Есть опыт по написанию движков ? Именно движков под N нужны, а не заточка под конкретное ТЗ ?

#41
2:35, 20 янв. 2014

innuendo
Опыт есть, зарелизенных нет :) Пишу, как и большинство, больше для себя, для тренировки... годами :) Так сказать творческая отдушина :) Вот и здесь поэтому, в поисках компонентного грааля... ну или с целью беззастенчива спереть какую-либо ценную идейку :)

#42
4:21, 20 янв. 2014

Zloten
Вот кстати чел пишет на Си
http://www.hmrengine.com
И в отличие от других Си движков, этот хотя бы с шейдерами и неплохой картинкой

можешь по красть у него код, он опенсурсный.

#43
7:59, 20 янв. 2014

war_zes
> О, я придумал, как решить эту проблему... С помощью наследования скриптов. У меня же пользовательский скрипт наследуется от базового Script. так вот, для каждой ситуации написать несколько других базовых.
Отличная идея) Мне кажется, так намного лучше будет, чем один базовый скрипт.

#44
11:04, 20 янв. 2014

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

Страницы: 1 2 3 4 5 Следующая »
WarZesФорум

Тема в архиве.