C++ Perfect progress 3d circle

Забаненный
Статус
Оффлайн
Регистрация
1 Фев 2022
Сообщения
32
Реакции[?]
26
Поинты[?]
6K
Обратите внимание, пользователь заблокирован на форуме. Не рекомендуется проводить сделки.
Во всех исходниках, которые постят люди я не находил вообще нормального рендера 3д круга на имгуе, так что нуждающиеся пусть получат.

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

Почему лучше использовать мой метод?
1. Основная реализация в других исходниках - костыль через render_line. Во первых он бьет по оптимизации, во вторых - когда кругов много, особенно если это саунд есп может произойти краш имгуя ругающийся на переполнение вертексами.
2. В слитых рендерах таких кругов есть куча багов,например если стоять в круге - он пропадает или обрезается и т.д.

C++:
void render::render_circle_3d_filled_border(const Vector vecPosition, const int32_t iPointCount, const float_t flRadius, Color a_color, float width)
{
    float_t flStep = (float_t)(3.14159265358979323846f) * 2.0f / (float_t)(iPointCount);
    std::vector<ImVec2> m_points;
    for (float a = 0; a < (3.14159265358979323846f * 2.0f); a += flStep)
    {
        Vector vecStart = Vector(flRadius * cosf(a) + vecPosition.x, flRadius * sinf(a) + vecPosition.y, vecPosition.z);
        Vector vecEnd = Vector(flRadius * cosf(a + flStep) + vecPosition.x, flRadius * sinf(a + flStep) + vecPosition.y, vecPosition.z);

        Vector vecStart2D, vecEnd2D;
        g_interfaces.m_debug_overlay->ScreenPosition(vecStart, vecStart2D);
        g_interfaces.m_debug_overlay->ScreenPosition(vecEnd, vecEnd2D);

        m_points.push_back(ImVec2(vecEnd2D.x, vecEnd2D.y));
    }

    draw_list->AddConvexPolyFilled(m_points.data(), m_points.size(), GetU32(Color(a_color.r() / 255.f, a_color.g() / 255.f, a_color.b() / 255.f, a_color.a() / 255.f *0.3f)));
    draw_list->AddPolyline(m_points.data(), m_points.size(), GetU32(a_color), true, width);
}

void render::render_circle_3d_filled_border_progress(const Vector vecPosition, const int32_t iPointCount, const float_t flRadius, Color a_color, float width, float progress)
{
    float_t flStep = (float_t)(3.14159265358979323846f) * 2.0f / (float_t)(iPointCount);
    std::vector<ImVec2> m_points;
    for (float a = 0; a < (3.14159265358979323846f * 2.0f); a += flStep)
    {
        Vector vecStart = Vector(flRadius * cosf(a) + vecPosition.x, flRadius * sinf(a) + vecPosition.y, vecPosition.z);
        Vector vecEnd = Vector(flRadius * cosf(a + flStep) + vecPosition.x, flRadius * sinf(a + flStep) + vecPosition.y, vecPosition.z);

        Vector vecStart2D, vecEnd2D;
        g_interfaces.m_debug_overlay->ScreenPosition(vecStart, vecStart2D);
        g_interfaces.m_debug_overlay->ScreenPosition(vecEnd, vecEnd2D);

        m_points.push_back(ImVec2(vecEnd2D.x, vecEnd2D.y));
    }

    draw_list->AddConvexPolyFilled(m_points.data(), m_points.size(), GetU32(Color(a_color.r() / 255.f, a_color.g() / 255.f, a_color.b() / 255.f, a_color.a() / 255.f * 0.3f)));
    draw_list->AddPolyline(m_points.data(), m_points.size()*progress, GetU32(a_color), progress==1.f, width);
}
Поясняю за количество точек: когда количество точек равно трем радиусам получается идеальный круг. Когда вызываете эти функции и передается количество точек стоит учитывать этот момент чтоб не получить обрубанную картошку вместо красивого круга
 
Участник
Статус
Оффлайн
Регистрация
15 Янв 2021
Сообщения
492
Реакции[?]
289
Поинты[?]
79K
костыль через render_line.
Ну а в твоём случае не костыль разве ? AddPolyLine отрисует линии по массиву точек, который ты собственно и заполнил в цикле. Я пока не смотрел само тело данной функции, но по идее она будет ещё раз пробегаться по массиву, чтобы отрендерить твои точки, что является небольшим минусом в твоей оптимизации ( два цикла, вместо одного ). Наверное потому и рендерили сразу в цикле саму обводку по линиям.
 
Забаненный
Статус
Оффлайн
Регистрация
1 Фев 2022
Сообщения
32
Реакции[?]
26
Поинты[?]
6K
Обратите внимание, пользователь заблокирован на форуме. Не рекомендуется проводить сделки.
Ну а в твоём случае не костыль разве ? AddPolyLine отрисует линии по массиву точек, который ты собственно и заполнил в цикле. Я пока не смотрел само тело данной функции, но по идее она будет ещё раз пробегаться по массиву, чтобы отрендерить твои точки, что является небольшим минусом в твоей оптимизации. Наверное потому и рендерили сразу в цикле саму обводку по линиям.
Я когда писал этот пост - клонил к использованию polyline от самого имгуя, ибо своими линиями лишний раз его догружать приходится. По сути грузит только пересчет точек, ну это можно немного оптимизировать, но оно не так много жрет как рендер линий своими руками чтоб обращать на это внимание. Я конечно имгуй не писал, но сужу из своих наблюдений в профилировщике
 
Эксперт
Статус
Оффлайн
Регистрация
30 Дек 2019
Сообщения
1,970
Реакции[?]
958
Поинты[?]
19K
Во первых, если тут каким нибудь хуем число будет меньше 0, тебя ассертнет в дебагe, а в релизе крашнет нахуй
Во вторых, в сурсе сапфира я эту тему сделал ещё очень давно
он пропадает или обрезается и т.д.
Чтобы такого не было, нужно просто убрать continue, если w2s == 0
Fuck PI variable, all my homies use 3.1415926…
 
Последнее редактирование:
Забаненный
Статус
Оффлайн
Регистрация
1 Фев 2022
Сообщения
32
Реакции[?]
26
Поинты[?]
6K
Обратите внимание, пользователь заблокирован на форуме. Не рекомендуется проводить сделки.
Во первых, если тут каким нибудь хуем число будет меньше 0, тебя ассертнет в дебагe, а в релизе крашнет нахуй
Во вторых, в сурсе сапфира я эту тему сделал ещё очень давно

Чтобы такого не было, нужно просто убрать continue, если w2s == 0

Fuck PI variable, all my homies use 3.1415926…
ну в принципе да, спастив мой код добавить лишний чек или клемп достаточно проблематично. Про баг с исчезновением вряд-ли люди просто пастящие что-то слепо станут разбираться почему это, и я просто дал код таким чтоб его можно было взять и вставить. Да, можно вставить просто и без клемпа или чека о котором мы говорили, ибо если у человека вылезет прогресс в минус - скорее всего уже проблема не в рендере, а в том что челик считает неправильно. У меня ни одного краша не было из-за этого, потому что проценты считаю правильно. Для очень сообразительных могу выложить таймеры гранат человеческие, где проценты не уходят в минус. Вероятно, для вас реально проблема - посчитать нормально
 
Эксперт
Статус
Оффлайн
Регистрация
30 Дек 2019
Сообщения
1,970
Реакции[?]
958
Поинты[?]
19K
Вероятно, для вас реально проблема - посчитать нормально
Почему ты считаешь что это только для гранат быть может?
если у человека вылезет прогресс в минус - скорее всего уже проблема не в рендере, а в том что челик считает неправильно.
та не обязательно, банально в таймере для хаешки, если забыть сделать чек на детанацию, у тебя нахуй крашнет, если в таймере молика и смока поставить просто 7(для молика) и 14(для смока), тебя крашнет, ибо время горения в сиесджо того же Молотова, 7.03125.
Ограничить число поинтов по минимуму до нуля нужно даже если ты лауреат Нобелевской премии по математике, всегда есть шанс что у тебя где-то значение твоего процента будет отрицательным, а так как ты его в инт переводишь, одно даже при -0.01 может -1 дать
 
Пользователь
Статус
Оффлайн
Регистрация
26 Авг 2017
Сообщения
386
Реакции[?]
32
Поинты[?]
8K
Почему ты считаешь что это только для гранат быть может?

та не обязательно, банально в таймере для хаешки, если забыть сделать чек на детанацию, у тебя нахуй крашнет, если в таймере молика и смока поставить просто 7(для молика) и 14(для смока), тебя крашнет, ибо время горения в сиесджо того же Молотова, 7.03125.
Ограничить число поинтов по минимуму до нуля нужно даже если ты лауреат Нобелевской премии по математике, всегда есть шанс что у тебя где-то значение твоего процента будет отрицательным, а так как ты его в инт переводишь, одно даже при -0.01 может -1 дать
в "если" ты называешь обычные ошибки людей. если они их допустят даже при фиксе краша - все равно получится фигня, будет уродливо. Так или иначе, почему то для вас не очевидно, что при любом раскладе если считать неправильно - выйдет фигня, будь то краш или просто неправильная работа. Если считать корректно - краша не будет. То что человек не может по-человечески посчитать - исключительно его проблема
 
Сверху Снизу