Не знаю как сделать с математической точностью, но на глаз я сделал так:
— в Edit mode сделать subdivide каждому ребру 1 раз (чтобы добавить vertex)
— выделить vertex на каждом ребре и slide его на точку пересечения (нажми два раза на g чтобы включился slide)
— после того как оба vertex-a рядом, выдели их оба и нажми alt-m для меню merge и выбери в центре
Разве? Прочитав пункт номер 1: Коллайдеры не должны двигаться, вращаться, включаться\выключаться и менять размер. я понял что если на обьекте висит коллайдер, то всё — двигать его уже нельзя :)
В документации написано, что если на обьекте есть коллайдер и его нужно двигать, то на нем обязан быть RigidBody — иначе будет серьезное падение в производительности.
Скорее всего это у вас и было — проверьте профайлером коллайдеры еще раз, но сначала на обьект повесьте RigidBody (Иначе получается глупо — зачем нужны коллайдеры, если обьекты нельзя двигать?)
«Обширный пост о неудачном выборе в пользу Python в отдельно взятом проекте»
Пост прочитал — на самом деле это пост о неумелом программисте.
Вкратце — его клиент в одном потоке читал данные с сокета и обрабатывал их. И так получалось, что приходили данные быстрее чем он их успевал считывать и обработать, в итоге сокет ломался.
На вопрос в комментах «почему не читать данные вторым потоком?» автор ответил что это сложно поддерживать.
Новость вкратце: Если докажут, что P=NP, то нынешние алгоритмы криптографии будет возможно сломать. А пока-что ломают через баги в имплементации.
А, секунду… Тоесть и не новость вовсе?
В книжке Thinking Fast and slow (by Daniel Kahenman), описана работа мозга примерно как вы представляете.
Автор описывает систему System2 (у вас это функция А()), и System1 ( функция B())
В книжке есть несколько достаточно интересных опытов и теория развита несколько дальше.
Если символ в первых таблицах — то 2 байта (16 бит), если не в первых — то минимум 2 ( и дальше 4-6-8+ в потенциале байт).
На деле не больше 4х (Помоему даже все китайско-японско-корейские входят помещаются в 4 байта).
Ответ 2+, «прыжками» в 2 байта (2/4/6...)
UTF8 добавляет 8бит для каждого символа (если ему не хватает предыдущих), UTF16 — прыжками по 16.
— в Edit mode сделать subdivide каждому ребру 1 раз (чтобы добавить vertex)
— выделить vertex на каждом ребре и slide его на точку пересечения (нажми два раза на g чтобы включился slide)
— после того как оба vertex-a рядом, выдели их оба и нажми alt-m для меню merge и выбери в центре
Скорее всего это у вас и было — проверьте профайлером коллайдеры еще раз, но сначала на обьект повесьте RigidBody (Иначе получается глупо — зачем нужны коллайдеры, если обьекты нельзя двигать?)
Пост прочитал — на самом деле это пост о неумелом программисте.
Вкратце — его клиент в одном потоке читал данные с сокета и обрабатывал их. И так получалось, что приходили данные быстрее чем он их успевал считывать и обработать, в итоге сокет ломался.
На вопрос в комментах «почему не читать данные вторым потоком?» автор ответил что это сложно поддерживать.
Предлагаю разрешить этот спор в пользу Python-а.
А, секунду… Тоесть и не новость вовсе?
Автор описывает систему System2 (у вас это функция А()), и System1 ( функция B())
В книжке есть несколько достаточно интересных опытов и теория развита несколько дальше.
Быстрее чем писать самому, но все равно очень эффективно
lib.ru/INOFANT/BRIN/spheres.txt_with-big-pictures.html
в оригинале написано, что «SELECT MAX(id)» обходит всю таблицу. («crawl»)
На деле не больше 4х (Помоему даже все китайско-японско-корейские входят помещаются в 4 байта).
Ответ 2+, «прыжками» в 2 байта (2/4/6...)
UTF8 добавляет 8бит для каждого символа (если ему не хватает предыдущих), UTF16 — прыжками по 16.
Выбрал 2-4, как наиболее подходящий.