Ответ: Пишем 3D движок - замену Xors3D
 

Отлично. А там еще можно сделать вертикальную линию, которая отмечает ширину строки?

Ответ: Пишем 3D движок - замену Xors3D
 

ставь QtCreator не парься, там все для людей сделано.

Ответ: Пишем 3D движок - замену Xors3D
 

Смотрел сравнение - у qt нету статического анализатора и нету java.
Поэтому я выбрал eclipse.
А вообще мне больше всего нравится notepad++.

Но дело не в этом. Дело в том что dxsdk уже почти никак не работает в вин8 без студии - теперь все средства отладки находятся в ней, и если хочешь нормально работать с дх то нужно ставить студию.
Например сейчас в вин8 без студии в dxsdk (последняя версия в июне 2010 =)) я немогу даже отладочный режим включить.
Там можно несколько костылей сделать но это все бред вобщем - нужна студия.

Ответ: Пишем 3D движок - замену Xors3D
 

Новая студия, кстати, очень хороша.
А насчет вертикальных линий - из-под коробки не может, но есть же расширения разные. Вот простенькое специально для этого: http://visualstudiogallery.msdn.micr...5-630980e72c30.

Самое известное, пожалуй, visual assist и раньше только им и спасались. А в 13 студии даже снес специально, родной функционал не хуже и более гармонично вписан.

Ответ: Пишем 3D движок - замену Xors3D
 

Я работал с DX = QtCreator + компилятор MSVS + CMake - все отлично, лучше и понятнее чем в студии, лично для меня. Студия для меня это вообще непреодолимый монстр.
И кстати как ты в DX собираешься java использовать?
И что ты имеешь ввиду под статическим анализатором.
Текущая версия QtCreator умеет все, и даже более.

Ответ: Пишем 3D движок - замену Xors3D
 

И шейдеры можно профилировать и отлаживать в пошаговом режиме?
И разрабатывать под winphone?
И делать приложения совместимые с вин магазином?

Что значит что я имею ввиду под статическими анализаторами? Это такие анализаторы которые отлавливают ошибки, которые не может отловить компилятор и которые маловероятно можно отловить в рантайме в обычном режиме. Смотри например cppcheck. Я незнаю может в qt можно подключить внешний анализатор, тогда нет проблем.

java и dx никак не связаны, я просто с джава тоже работаю, например под андроид и как бы одно и тоже ide было бы удобно.

Ты сам то достаточно работал в других ide чтобы говорить что они хуже?

Ответ: Пишем 3D движок - замену Xors3D
 

Работал достаточно. Eclipse, NetBeans, Idea, Code::Blocks, MSVS, KDevelop, QtCreator всякие там Geany, Jedit... остановился на креаторе
Анализатор как минимум cpp check можно использовать, анализатор памяти valgrind
Про Windows Phone не скажу, но вроде в следующей версии появится поддержка.

И ранее было сказано, что неудобство связано со студией, а про девелоп под вин фон не было сказано, вот я и предложил.

Ответ: Пишем 3D движок - замену Xors3D
 

Но ведь в том то и дело что в мсвс всё удобно если ты разрабатываешь под windows и другие платформы мелкомягких.
Для других платформ - другие ide.
Одного универсального на все случаи жизни не бывает.

Ответ: Пишем 3D движок - замену Xors3D
 

да ну их, эти IDE. дело вкуса.
давайте лучше про вертекс лэйауты, интерлевед / не интерлевед данные и прочие интересные штуки беседовать.

вот вопрос:
как вы считаете, создание второго буфера для меша, состоящего лишь из позиций, может ускорить shadow pass? ведь локальность данных повысится?

Ответ: Пишем 3D движок - замену Xors3D
 

Всё зависит от того как устроен кеш на видеокартах.

Например когда я делал софтвеер рейкастинг была немного другая но схожая проблема - самым узким местом была скорость памяти.
Всё из за того что я сделал многопроходную обработку "шейдерами" (имеется ввиду функции выполняющие примерно то что делают пиксельные шейдеры).
Из за этого одна часть буфера изображения вытесняла из кеша другую часть.
Надо было же делать по другому: нужно было все операции которые требовались над пикселем сделать сразу, пока все данные находились в кеше, тем самым требовалось бы один раз прочитать исходный буфер из памяти и один раз записать результат в память. Теоретически факт того что у каждого ядра свой кеш 2 уровня это еще больше ускорило бы обработку данных.

У видеокарт нет таких проблем - там быстрая память, так что сложно однозначно сказать как будет - нужно делать эксперимент или искать доки на видеокарты.

Ответ: Пишем 3D движок - замену Xors3D
 

думаю что для толстых мешей однозначно да. потесть, чё.

Ответ: Пишем 3D движок - замену Xors3D
 

Как максимум это может быть удобней в чем-то для программиста, но ты начнешь терять время на переключение буферов в момент установки их в атрибуты, плюс проход по одному буферу ничего не стоит, по времени ровно столько же как обратьтся к &buffer[0] или &buffer[100500]. Внутри видеокарты это выглядит как смещение на величину stride.

Ответ: Пишем 3D движок - замену Xors3D
 

ну это если бы мы после обычного рендера каждого объекта, сразу бы рендерили его в тень до этого. а так ведь все равно это 2 разных пасса и переключений одно кол-во.

Ответ: Пишем 3D движок - замену Xors3D
 

Движок загнулся и обсуждение не по теме пошло уже :D

Ответ: Пишем 3D движок - замену Xors3D
 

Где и кто загнулся?????
На булке всегда обсуждения не по теме (и не только на булке).

И кстати почему "не по теме"? Разговор же как раз по теме.

Ответ: Пишем 3D движок - замену Xors3D
 

Всё по теме. А я наблюдаю за происходящим, при этом не спеша пишу движок...

Ответ: Пишем 3D движок - замену Xors3D
 

Народ, столкнулся с такой проблемкой - если использовать текстурный атлас, то для некоторых вершин нужно 2 текстурные координаты, что приводит к невозможности использовать индексный буфер. Кто как решал проблемку? Дублировать вертекс в таких позициях? Но тогда как выявлять такие вертексы в модели - не понимаю....

Ответ: Пишем 3D движок - замену Xors3D
 

Почему нету возможности использовать индексный буфер?

Ответ: Пишем 3D движок - замену Xors3D
 

Так как вертекс будет иметь одну и ту же текстурную координату. А надо для одного вертекса иметь две координаты. Если тупо слать вертексы в VB без индексного буфера - то все ок - все смежные вертексы засылаются отдельно и можно задать разные координаты текстуры. А вот как такое замутить с индексным буфером - непонятно.

Ответ: Пишем 3D движок - замену Xors3D
 

дублируй вертекс и меняй индексы

Ответ: Пишем 3D движок - замену Xors3D
 

если использовать текстурный атлас для уменьшения количества смен текстур - то ничего менять ненадо. просто твои uv координаты будут ужиматься до нужного куска.
но, в DX10 появились texture arrays которые данную задачу решают лучше, избегая болячек типа смешивания цветов на пограничных выборках или там проблемы с мипами.
а в кеплере и его амд-шнгом аналоге в gl-е появились bindless текстуры, которые еще круче.

если же тебе нужен мультитекстуринг, для лайтмап например, то вторые uv координаты нужны для каждой вершины. такчто и тут никаких проблем.

вообще, если в пределах одного меша у тебя для одной вершины нужны одни данные, а для другой другие - то это уже кривой подход.

опиши задачу яснее. ну и демок накидай в тему.

теперь понятно. дублируй такие вертексы.

Ответ: Пишем 3D движок - замену Xors3D
 

Решение очевидное, но вопрос как найти какой вертекс дублировать? Например есть сфера, на нее натянута текстура из текстурного атласа. На каких-то вертексах если использовать индексный буфер будет неправильный стык текстур, хотя без индексов все нормально отобразится. Не могу сообразить, как найти эти стыки, чтобы продублировать вертексы - вот в чем вопрос.


P.S. Предполагаю, что нужно как-то сравнивать текстурные координаты в каждой вершине при загрузке модели...

Ответ: Пишем 3D движок - замену Xors3D
 

рисуй без индексов.
если у тебя в индкесном буфере будут все индексы уникальными, то толку от него все равно нет.

сам виноват, что взял ГАПИ 10 летней давности.

Ответ: Пишем 3D движок - замену Xors3D
 

Ага, видимо проще забить на индексы, если в файле с моделью нет индексов изначально...

Ответ: Пишем 3D движок - замену Xors3D
 

я не понимаю твою проблему - какая разница атлас, не атлас?
была текстура отдельно, стала в атласе - если нет тайлинга, то только применить к ЮВ оффсет и скейл, чтобы загнать в нужное место.
с тайлингом из атласа сложнее.

Ответ: Пишем 3D движок - замену Xors3D
 

Как раз на тайловой текстуре в индексной геометрии я и споткнулся. Вопрос можно перефразировать так: конвертация неиндексированной геометрии в индексированную при использовании атласной тайловой текстуры.

P.S. Скорее всего проблему нужно решать на уровне модели, а не на уровне движка. Т.е. подводить модели под общие правила и формат...

Ответ: Пишем 3D движок - замену Xors3D
 

ага, тут либо в модели каждый тайл должен своими вертексами быть окружён, либо ты должен иметь оригинальные текскоорды + скейл и оффсет в пиксельном шейдере. тогда делаешь им fmod, чтобы повторялись попиксельно, затем трансформируешь. тогда со старой геометрией может проканать.

+ с атласом есть ещё свои заморочки с фильтрацией на краях. по нормальному, если тебе нужна не point фильтрация, тебе нужно края вокруг каждой текстуры в атласе сгенерить в несколько пикселей, как будто она тайлится вширь немного. для линейной хватает +2 пикселя, для анизотропной поболее, но вроде больше 4х не требовалось.

Ответ: Пишем 3D движок - замену Xors3D
 

угу, для первых двух мипов. а дальше?
хотя может на том расстоянии, где нужны мипы постарше уже будет без разницы.

был бы у тебя 10й директ - не было бы, такой проблемы.
чо вы ради 2.51% пользователей так заморачиваетесь (http://store.steampowered.com/hwsurvey/)

Ответ: Пишем 3D движок - замену Xors3D
 

кстати говоря, можно ещё 3д текстуру юзать как альтернативу текстурному массиву)
каждый слой - свой тайл как раз (если тайлы одного/похожего размера). меняешь Z у выборки - выбираешь нужный.
из-за дополнительной интерполяции может быть чутка медленее, чем атлас.

Ответ: Пишем 3D движок - замену Xors3D
 

уже немного пересмотрел свои взгляды... ХР поддержка закончилась... Пока перешел на DX9EX (который начиная с висты работает без потери девайса). Как разберусь полностью с шейдерами, шрифтами и GUI - перейду на DX11.

Сейчас очень много времени уходит на эксперименты и тесты.

P.S. Кстати, доступен для предзаказа Oculus Rift DevKit v2 :super:

Ответ: Пишем 3D движок - замену Xors3D
 

Зря. 11 директ поддерживает, конечно, не меньшинство компов; но все таки, если ты будешь использовать только 11, то очень и очень сильно потеряешь в потенциальной аудитории, как минимум в лице меня и обладателей калькуляторов староватых, даже возможно крутых и на сегодняшний день, видеокарт. Так что смотри.

upd. Посмотрел на линк с опросом. Судя по всему, опрашивали пиндостанских шкалатенков и барадатых дядек задров в срузис и подобные симуляторы обогревателя воздуха. У ~40 моих знакомых, карточка с поддержкой 11-го есть только у 3 человек.

Ответ: Пишем 3D движок - замену Xors3D
 

Не стоит забывать, что в DX11 есть feature levelы, т.е. можно написать дх11 код, юзая DX10/9 фича левел, и оно будет пахать на видяхах, поддерживающих лишь 10/9, лишь бы у них была винда не ХП.

Ответ: Пишем 3D движок - замену Xors3D
 

Работает, да. Но на моей AMD HD 4800 Bioshock Infinite, например, спокойно работает и на максах(1280 на 1024) с достаточно редкими просаживаниями FPS. Технически, по словам AMD, моя видяха может поддерживать 10 дайректэкс, но игры, которые его требуют, в том числе и биошок, частенько вылетают, попутно фризя ОС(благо семерка может аварийно перезапустить драйвера,а вот раньше и на ХР со старыми дровами и девятым директом игры и проч. слетали, унося винду в бсод), так что то ли у кодеров дровов руки из анала растут, то ли кодеры игры накосячили(что врятли).

Ответ: Пишем 3D движок - замену Xors3D
 

Ты подметил хорошо "на сегодняшний день".
Движки пишут не за 1/2 вечера, а годами. До того как у кого-то что-то будет дельное, пройдёт много времени.

"Надеяться" на коммерческий успех твоего движка, когда у тебя нету конкретного бизнес плана в индустрии игровых движков, сегодня является неимоверной наивностью.

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

Короче - юзай последнее и самое новое! Приятнее, красивее, интереснее, и перспективнее.
Иначе когда ты на древнем dx9 там что-то соберёшь уже будет DX13++ и ты вообще будешь считаться древним разрабом.
Да и почему не попробовать OpenGL после DX чтобы иметь больше опыта в обеих GAPI - это полезная практика для разработчиков - знать несколько альтернатив, и иметь возможность выбирать.

Ответ: Пишем 3D движок - замену Xors3D
 

Вообще надо делать двиг на OpenGL, за ним будущее. :)

Ответ: Пишем 3D движок - замену Xors3D
 

Тоже самое говорили 3 года назад, и 6 лет назад, и 10.

Ответ: Пишем 3D движок - замену Xors3D
 

Я уже говорил, почему выбран DX, а не OpenGL - это поддержка 3D Vision и OculusRift одновременно.

Ответ: Пишем 3D движок - замену Xors3D
 

ОГЛ может охватить практически весь рынок игровых и не только устройств, то бишь там, где просто есть графический ускоритель, причем давать производительность не меньше дирика(а в отдельных случаях даже больше) на самой винде, пример тому: Rage.
А против BugWay'я ничего не имею, раз уж решил на окулус идти:)
Тем более, если что-то и с двиглом и выйдет, написать второй рендер не составит никакого труда.

Ответ: Пишем 3D движок - замену Xors3D
 

Где то лежит пруф на, то, что Valve скомпилировала свои игры с использованием OpenGl и производительность повысилась на 13%. Причем исходный код они не меняли, а написали прослойку для OpenGl с использованием синтаксиса DX. Тоесть даже с прослойкой, работало шустрее

Ответ: Пишем 3D движок - замену Xors3D
 

Примерно на 14 странице данной темы была ссылка на презентацию, как повысить производительность OpenGL чуть ли не на 30%...

Ответ: Пишем 3D движок - замену Xors3D
 

Производительность opengl и d3d зависит в большей степени от программиста - всегда можно найти общее решение/стратегию для каждого gapi использующее его преимущества.
Rage для xbox пришлось делать на dx.
Любой хороший движок должен поддерживать оба gapi, иначе это не серьёзно, нужно же на обе консоли выходить.
И добавить еще рендер как раз не всегда легко - нужно заранее планировать архитектуру под два (или другое нужное кол-во) рендера.

Ответ: Пишем 3D движок - замену Xors3D
 

Любой хороший ИГРОВОЙ движок.
графика есть не только в играх.
я вот ни разу не пожалел о выборе гл-я.
с другой стороны мы софт отдельно от железа не распространяем.
для распространяемого софта лучше брать dx

Ответ: Пишем 3D движок - замену Xors3D
 

Дополнительная защита от пиратов? Чтобы на левом железе было проблемно запустить?

Ответ: Пишем 3D движок - замену Xors3D
 

Я ни о каком выборе не говорил, прогер должен знать оба гапи однозначно.
Игровой движок нужно по возможности, если нет на то видимых причин, делать под кол-во гапи, больше чем одного.
Если софт специализирован и ограничен одним гапи - ок, но это не отменяет знание второго, в следующий раз может пригодиться.

Ответ: Пишем 3D движок - замену Xors3D
 

нет. просто нет необходимости писать на директе, когда есть возможность влиять на целевое железо. не работает 3d vision? - ок, ставим квадры или линукс. проблемы с драйверами - ок, ставим те на которых проблем не было.

ну, знать гапи никогда не помешает. хоть, ИМХО, отличий dx11 от opengl меньше чем dx11 от dx9.

нет, на данный момент директ никогда не может пригодиться если драйвера / железо выбираются под софт. единственное его неоспоримое преимущество - это качество драйверов у разных вендоров. Поэтому если софт должен работать на видеокартах разных вендоров - то лучше брать директ - меньше гемора. Если достаточно одной архитектуры одного вендора - то опенгл однозначно лучше. даже на винде.

Ответ: Пишем 3D движок - замену Xors3D
 

А есть вероятность что Power Basic работает на консолях?

Ответ: Пишем 3D движок - замену Xors3D
 

Если консоли работают на Windows - то да. :)

Ответ: Пишем 3D движок - замену Xors3D
 

Как дела?

Ответ: Пишем 3D движок - замену Xors3D
 

Вопрос риторический.

На это обречено 95% "движков", которые крутят кубики с бампом.

Ответ: Пишем 3D движок - замену Xors3D
 

Все движки имеют кубик с бампом, не все разрабы этим "хвастаются".

Ответ: Пишем 3D движок - замену Xors3D
 

Дела идут относительно неплохо. Огромная часть времени уходит на гугление. :( + Переписываю движок уже на 4 раз с нуля. Что радует - с каждой версией немного повышается производительность.

Из текущих проблем/задач:

1. AI - симуляция огромного числа NPC минимальными ресурсами (возможно утопия)
2. Рендер воксельного мира с использованием marching triangles.
3. Система плагинов.
4. Оптимизация GUI
5. Отладка новой версии Oculus Rift

Поймал себя на том, что движок стал походить на зачаток майнкрафт... :-D Кстати, работаю в этом направлении тоже. :)

Ответ: Пишем 3D движок - замену Xors3D
 

Ответ: Пишем 3D движок - замену Xors3D
 

Так ты 3D (рендер) движек пишешь, или игровой движок? Это немного разные вещи, и имхо слишком разные направления чтобы одному потянуть такой объем работы, в итоге будет всего по чуток со всех сторон - но сыро.

Если сфокусировался бы например только на Render движке, то его уже можно было бы использовать и народ бы либо сам писал свои AI и т.п. решения, либо даже контрибютил в твой двиг.

Ответ: Пишем 3D движок - замену Xors3D
 

Пишу-то по большей части рендер. Понятно, что звуковую, сетевую и физическую библиотеки внешние прикручивать надо будет. Понятно, что с физикой типа Physics мне не потягаться. Но уровень физики чуть лучше, чем в майнкрафт вполне могу реализовать. Про AI это я уже дальше думаю. Хочется что-то типа майнкрафта, только посолиднее. Кстати Нотч официально отказался поддерживать Oculus Rift из-за присоединения разработчиков к Facebook...

И да - я знаю что клонов майнкрафта сотни. Но хочется не клон - а нечто новое.

Xorex, давай в личке обсудим возможное сотрудничество.

P.S. На сайте гейм-института скидка 50%. Если кто-то интересуется книгами, лекциями другими материалами - рекомендую! Хоть и на английском, но всё понятно написано. (Не сочтите за рекламу)

Ответ: Пишем 3D движок - замену Xors3D
 

Модульность движка, и возможность подключить физику - порой бывает весьма сложной задачкой. Возьми тот же Bullet и физика у тебя уже будет на уровне.

AI - это совсем абстрактная и игровая сфера, не относится к рендер движку вообще.

Вообще движки разбивают на слои, более низкие такие как обертка над GAPI и работа с буферами, шейдерами, звуком, физикой, затем идут более абстрактные - граф сцены, материалы, AI, .. - это все фреймворк.

Так вот разделить на 2 слоя "обязательно" если ты не хочешь снова все переписывать в будущем.
Также писать под одну заточку (minecraft) не расценивай тогда двиг как рендер-двиг, расценивай его как minecraft-двиг, т.к. применение узко-заточенных движков в других сферах почти всегда будет не возможным, или просто не удобным.

Ответ: Пишем 3D движок - замену Xors3D
 

я тоже так думал, когда писал двиг, но я знал тогда только DX9 и делал всё на нём.
потом столкнулся с задачей перевести всё на DX10, и выяснилось, что движок был к такому не готов, и многая логика работы и архитектура даже между DXами отличается, что уж там говорить о GL :-)
Пришлось вставлять очень много нелепых костылей.
Короче, пока ты не знаешь все GAPI (не писал на каждом что-то завершённое), не имеет смысла заморачиваться со слоями - только много (очень) времени просрёшь на эти никчёмные абстрагирования на "будущее".
Забей на слои, абстракции вообще, просто херачь, будет продуктивнее)

Ответ: Пишем 3D движок - замену Xors3D
 

Да у меня аналогично произошло.
Слои, не всегда выход. Точнее модульность можно обеспечить не обязательно слоями, а например где то на уровне сборки компонентов, где каждый работает напрямую с целевым гапи - меньше оверхеда, проще код. Цена универсализации может быть непомерно высокой.

Ответ: Пишем 3D движок - замену Xors3D
 

Если для начала - конечно нужен опыт, херачь.
Я не говорю об убер-абстракциях как в том же Ogre. Речь идет тупо о расслоении работы с матрицами и буферами и текстурами, и графа сцены. Если чтобы заменить то как производится работа с математикой - это переписать 90% всего двига, то это уже перебор.

Или если у тебя индексные буфера "знают" о существовании графа сцены (это нужно постараться), и делая изменения в графе сцен, у тебя все нахер - так далеко не "попишешь"..

Композиция кода должна быть нормальной, не убер-абстрактной, но и не кросс-зависимой по каждому "пуку".

Ответ: Пишем 3D движок - замену Xors3D
 

Банальный пример:
В DX10-11 есть InputLayout, то же что и VertexDeclaration в DX9, НО если в дх9 он создавался из нескольких руками заданных структур с параметрами, то в 10-11 тебе нужно иметь скомпилированный VS для его создания. Фишка в том, что в 9 на дроуколах много оверхеда была из-за адаптирования вертексдекларации к входной структуре каждого шейдера, а в 10-11 решили оставить это на препроцесс, убрав каждокадровый оверхед.
Вот только у меня в движке декларация ничего не знала о шейдерах, я её вообще считал частью меша (ну типа описывает как парсить VB), а шейдеры существовали где-то в параллельном мире. Пришлось делать костыли.

Второй пример - рендер стейты. В DX9 можно когда попало какие ставить, в 10-11 ты должен заранее создавать блоки стейтов и переключать их целиком. У меня в движке слишком рандомно менялись стейты by design, пришлось вставлять ещё костыль, который в рантайме чекал все стейты, искал в мапе похожие блоки, если не находил - создавал новые.

Ответ: Пишем 3D движок - замену Xors3D
 

Mr_F_, вот знание разных GAPI теперь тебе дает возможность рассмотреть суть абстракций, и если вдруг будет необходимость поддержки более нового GAPI, то переход будет не на столь болезненный.

А теперь прикинь у тебя все написано одной кашей, от друг дружки завязано. Вот та же тема со стейтами, что все встанет как полагается для DX10? Нифига, будут те же костыли и все будет не меньше ломаться. По крайней мере у тебя "добавления" зависимостей, а в одной каше это будет перелопачивание зависимостей с неприятными последствиями.

Опыт естественно нужен при работе с разными GAPI, но писать один спаггети-код - это прямой путь к провалу.

Ответ: Пишем 3D движок - замену Xors3D
 

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

Ответ: Пишем 3D движок - замену Xors3D
 

Так как первый - один из вариантов, но для опыта лучше двигаться ко второму, а опыта нету. Следственно стоит херачить быстро на одном гапи с мелкими абстракциями (для опыта), и затем их "поломать" и понять где напортачил при переходе на другой GAPI. По сути то через что ты прошел, тем самым будет отличный опыт.

Ответ: Пишем 3D движок - замену Xors3D
 

Ну может быть, тут в принципе чувак для себя пилит, а вот у меня был определённый заказ со сроками, и я тогда мог сделать много чего быстрее, если бы не заморачивался :D

Ответ: Пишем 3D движок - замену Xors3D
 

Но опыт то нужно тоже получать, а не тупо пилить - абы здать. Следственно ты все правильно имхо сделал.
Кодинг и вся жизнь разработчиков никогда не бывает гладкой, никогда. И те кто умеют "страдать" как полагается :) те и опыта набираются збсь.