Телеграмм чат группы UnrealEngine4 страница 16719

ну они и существуют лишь в пределах этого метода, да

да, исключительно для функции трейса в теле тика. Больше нигде не нужны.
Тогда да, можно их константами.

21:28пожаловаться #1

n

а если думать про микрооптимизации (на самом деле не стоит с этим заморачиваться), то можно переписать вот так:

FVector Start = this->GetComponentLocation();
FVector End = Start - this->GetUpVector() * HoverDistance;

чтоб два раза не дёргать GetComponentLocation, но это уже мелочи

21:28пожаловаться #2

n

а, и this-> не обязательно писать, но это уже стилистика, ни на что не влияющая

21:29пожаловаться #3

IT

а если думать про микрооптимизации (на самом деле не стоит с этим заморачиваться), то можно переписать вот так:

FVector Start = this->GetComponentLocation();
FVector End = Start - this->GetUpVector() * HoverDistance;

чтоб два раза не дёргать GetComponentLocation, но это уже мелочи

спасибо) это уже кодстайл, который видимо должен с опытом прийти.

По сути, это мой первый код на плюсах :)

21:29пожаловаться #4

IT

не сталкивался, пока не появилась прямая необходимость:
физика, считающаяся по дельте, ведет себя очень неадекватно при падении фреймрейта

21:30пожаловаться #5

n

Ivan Takoi

спасибо) это уже кодстайл, который видимо должен с опытом прийти.

По сути, это мой первый код на плюсах :)

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

21:30пожаловаться #6

IT

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

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

21:30пожаловаться #7

n

Ivan Takoi

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

а в чём проблема? DeltaTime как раз и используется, чтоб не заморачиваться с длиной тика...

21:31пожаловаться #8

IT

а в чём проблема? DeltaTime как раз и используется, чтоб не заморачиваться с длиной тика...

Меня уже тыкнули в статью, как от этого избавиться, заюзав саб-степпинг, что бы делать пре-просчет физики, но для этого нужно:
1) Переписать код под плюсы (сделано)
2) Отвязаться от тика (в процессе)

21:32пожаловаться #9

IT

а в чём проблема? DeltaTime как раз и используется, чтоб не заморачиваться с длиной тика...

а проблема в том, что при хорошем фреймрейте, подвеска работает замечательно, а при падении, например, до 25-20 кадров, её начинает люто колошматить. Транспорт дрыгается, прыгает, улетает в космос.

21:33пожаловаться #10

n

ох, транспорт по физике это боль :D не работал с таким, но могу представить

21:34пожаловаться #11

IT

ох, транспорт по физике это боль :D не работал с таким, но могу представить

с другой стороны - интересная задачка, которая позволит хоть как-то вкатиться в плюсы, имея на то вполне конкретную цель)

21:35пожаловаться #12

IT

а то без цели начинал неоднократно и забрасывал.

https://twitter.com/Reedbeta/status/1312089273017888768

21:35пожаловаться #13

VA

Vladimir Alyamkin in Unreal Engine

Ivan Takoi

а проблема в том, что при хорошем фреймрейте, подвеска работает замечательно, а при падении, например, до 25-20 кадров, её начинает люто колошматить. Транспорт дрыгается, прыгает, улетает в космос.

Twitter

Nathan Reed

I don't know who needs to hear this, but: The correct way to make something like "speed *= friction" framerate-independent is to use an exponential function, like: "speed *= exp2(frictionRate * deltaTime)" where frictionRate = log2(friction)/originalFixedDeltaTime.

Даниил Козырев... in Unreal Engine

21:43пожаловаться #14

ДК

Можно вопрос? Это нормально что в Unreal Engine пропало E Actions в blueprints?