Live data from Hacker News

Speeding up Unreal Editor launch by not spawning unused tooltips

larstofus.com

51–60 of 92 posts

Re: Speeding up Unreal Editor launch by not spawning unused tooltips

#51
post #13

This reminded me, I saw tooltips being a large chunk when I profiled my react app. I should go and check that. Similarly, adding a modal like this {isOpen && } instead of Seems to make the app smoother the more models we had. Rendering the UI (not downloading the code, this is still part of the bundle) only when you need it seems to be a low hanging fruit for optimizing performance.

That breaks the out transition.

Good. Transitions are meant to serve a purpose, showing what came from where. A modal doesn't need a transition, it should just disappear instantly. Like closing a window. The user is not helped by animating that something disappears when they close it, they already knew that.

Re: Speeding up Unreal Editor launch by not spawning unused tooltips

#52
post #24

From a purely technical perspective, UE is an absolute monster. It's not even remotely in the same league as Unity, Godot, etc. when it comes to iteration difficulty and tooling. I struggle with UE over others for any project that doesn't demand an HDRP equivalent and nanometric mesh resolution. Unity isn't exactly a walk in the park either but the iteration speed tends to be much higher if you aren't a AAA wizard wi…

I think UE is so good at graphics that there is no reason to use it for most of the developers. I don't understand why many indie developers chose to use it.

I'm working with a friend on a project and desperately trying to sway him away from Unreal. His reason for wanting to use it is because he can build the engine from source and modify it any way he wants (and he intends to attempt just that). He's also very much into pushing the engine's lighting to its limits.

We're a team with < 10 employees. He's paying very handsomely, so even if his Unreal foray is an absolute disaster, I'll have the savings to find something else.

Re: Speeding up Unreal Editor launch by not spawning unused tooltips

#53
post #24

From a purely technical perspective, UE is an absolute monster. It's not even remotely in the same league as Unity, Godot, etc. when it comes to iteration difficulty and tooling. I struggle with UE over others for any project that doesn't demand an HDRP equivalent and nanometric mesh resolution. Unity isn't exactly a walk in the park either but the iteration speed tends to be much higher if you aren't a AAA wizard wi…

Blueprints can be a great learning tool, if you double click a node it will open a VS window with the actual C++ code function.

Re: Speeding up Unreal Editor launch by not spawning unused tooltips

#54
post #23

Earlier quoted context omitted.

Being around back in days when LCDs replaced the CRTs and learning importance of native resolutions. I feel like recent games have been saved too much by frame-generation and all sort of weird resolution hacks... Mostly by Nvidia and AMD. I am kinda sad we have reached point where native resolution is not the standard for high mid tier/low high tier GPUs. Surely games should run natively at non-4k resolution on my 70…

You mean back in the day when 30 fps at 1024x768 was the norm? New monitors default to 60hz but folks looking to game are convinced by ads that the only reason they lost that last round was not because of the SBMM algorithm, but because the other player undoubtedly had a 240hz 4K monitor rendering the player coming around the corner a tick faster. Competitive gaming and Twitch are what pushed the current priorities,…

30 fps was not the norm, at least not with competitive games. Like Counter-Strike in 2000 on a CRT. Yes 1024x768 was common, but at 100 fps. Alternatively you would go to 800x600 to reach 120 fps.

It’s only when LCDs appeared that 60 Hz started being a thing on PCs and 60 fps followed as a consequence, because the display can’t show more anyway.

It’s true that competitive gaming has pushed the priority of performance, but this happened in the 90s already with Quake II. There’s nothing fake about it either. At the time a lot of playing happened at LANs not online. The person with the better PC got better results. Repeatedly reproduced by rotating people around on the available PCs.

Re: Speeding up Unreal Editor launch by not spawning unused tooltips

#55

Earlier quoted context omitted.

I think UE is so good at graphics that there is no reason to use it for most of the developers. I don't understand why many indie developers chose to use it.

I'm working with a friend on a project and desperately trying to sway him away from Unreal. His reason for wanting to use it is because he can build the engine from source and modify it any way he wants (and he intends to attempt just that). He's also very much into pushing the engine's lighting to its limits. We're a team with < 10 employees. He's paying very handsomely, so even if his Unreal foray is an absolute di…

Oh that's definitely something to play with if the $$ is good :D I wouldn't mind.

Re: Speeding up Unreal Editor launch by not spawning unused tooltips

#56
post #23

Earlier quoted context omitted.

Being around back in days when LCDs replaced the CRTs and learning importance of native resolutions. I feel like recent games have been saved too much by frame-generation and all sort of weird resolution hacks... Mostly by Nvidia and AMD. I am kinda sad we have reached point where native resolution is not the standard for high mid tier/low high tier GPUs. Surely games should run natively at non-4k resolution on my 70…

Native resolution was never good enough though. That's why antialiasing is a thing, to fake a higher than native resolution And now antialiasing is so good you can start from lower resolutions and still fake even higher quality

I don't agree with the framing of it as "faking" a higher than native resolution. The native resolution is what it is. The problem lies in how the view is sampled as it is rendered to the screen. What you ideally do when you have higher frequency content than the screen can represent is to oversample, filter and downsample the view, as in SSAA, or you approximate the effect or use it selectively when there is high frequency content, using some more clever methods.

It's really the same problem as in synthesizing audio. 44.1 kHz is adequate for most audio purposes, but if you are generating sounds with content past the nyquist frequency it's going to alias and fold back in undesirable ways, causing distortion in the audible content. So you multisample, filter to remove the high frequency content and downsample in order to antialias (which would be roughly equivalent to SSAA) or you build the audio from band limited impulses or steps.

Re: Speeding up Unreal Editor launch by not spawning unused tooltips

#57
post #23

Earlier quoted context omitted.

Being around back in days when LCDs replaced the CRTs and learning importance of native resolutions. I feel like recent games have been saved too much by frame-generation and all sort of weird resolution hacks... Mostly by Nvidia and AMD. I am kinda sad we have reached point where native resolution is not the standard for high mid tier/low high tier GPUs. Surely games should run natively at non-4k resolution on my 70…

You mean back in the day when 30 fps at 1024x768 was the norm? New monitors default to 60hz but folks looking to game are convinced by ads that the only reason they lost that last round was not because of the SBMM algorithm, but because the other player undoubtedly had a 240hz 4K monitor rendering the player coming around the corner a tick faster. Competitive gaming and Twitch are what pushed the current priorities,…

> You mean back in the day when 30 fps at 1024x768 was the norm?

I recall playing games at 100 FPS on my 100 Hz CRT. People seriously interested in multiplayer shooters at the time turned vsync off and aimed for even higher frame rates. It was with this in mind I was quick to upgrade to a 144 Hz display when they got cheap enough: I was taking back territory from when the relatively awful (but much more convenient) flat screens took over.

> because the other player undoubtedly had a 240hz 4K monitor rendering the player coming around the corner a tick faster.

I play 99% single player games and in most of those, response time differences at that scale seem inconsequential. The important difference to me is in motion clarity. It's much easier to track moving objects and anticipate where they will be when you get more frames of animation along their path. This makes fast-paced games much more fun to play, especially first person games where you're always rapidly shifting your view around.

Re: Speeding up Unreal Editor launch by not spawning unused tooltips

#58
post #24

From a purely technical perspective, UE is an absolute monster. It's not even remotely in the same league as Unity, Godot, etc. when it comes to iteration difficulty and tooling. I struggle with UE over others for any project that doesn't demand an HDRP equivalent and nanometric mesh resolution. Unity isn't exactly a walk in the park either but the iteration speed tends to be much higher if you aren't a AAA wizard wi…

And blueprints take forever to wire up in my experience compared to just writing the C++ directly.

I think UE requires the dev team to have a clear cut between the designers and programmers. Programmers code BP "components" and give them to designers to wire them up. The heavy lifting and complicated logic should live in C++ IMO. Otherwise it's going to be hell.

Re: Speeding up Unreal Editor launch by not spawning unused tooltips

#59
post #24

From a purely technical perspective, UE is an absolute monster. It's not even remotely in the same league as Unity, Godot, etc. when it comes to iteration difficulty and tooling. I struggle with UE over others for any project that doesn't demand an HDRP equivalent and nanometric mesh resolution. Unity isn't exactly a walk in the park either but the iteration speed tends to be much higher if you aren't a AAA wizard wi…

That's extremely unfortunate given that Unity is becoming financially hostile gouging enterprise customers, and apparently Godot is not quite mature enough to compete. Game engines are quickly becoming a problem

Re: Speeding up Unreal Editor launch by not spawning unused tooltips

#60

Earlier quoted context omitted.

I think UE is so good at graphics that there is no reason to use it for most of the developers. I don't understand why many indie developers chose to use it.

I'm working with a friend on a project and desperately trying to sway him away from Unreal. His reason for wanting to use it is because he can build the engine from source and modify it any way he wants (and he intends to attempt just that). He's also very much into pushing the engine's lighting to its limits. We're a team with < 10 employees. He's paying very handsomely, so even if his Unreal foray is an absolute di…

> He's also very much into pushing the engine's lighting to its limits.

With a bit of experience you can achieve global illumination results that are competitive with Pixar films by using static scene elements, URP, area lighting, baked GI and 5~10 minutes on a 5700XT. The resulting output will run at hundreds of FPS on most platform targets. If this means pegging vsync, it may also be representative of a power savings on those platforms.

Lights in video games certainly use real electricity, but the power spent on baked lights is amortized across every unique target that runs the game. The biggest advantage of baking is that you can use an unlimited # of lights. Emulation of a physical scene is possible. There are also types of lights that aren't even accessible at real-time (area/volumetric). These produce the most compelling visual results, avoiding problems that others create such as hotspots in reflection probes and hard shadowing.

Lightmap baking is quickly becoming a lost art because realtime lighting is so simple by comparison (at first!). It also handles a lot of edges cases automagically. The most important ones being things like dynamic scene elements and foliage. Approximately half of the editor overlays in Unity are dedicated to visualizing the various aspects of baked lighting. It is one of the more difficult things to polish but if you have the discipline to do so it will make your game highly competitive in the AAA arena.

The crazy thing to me about baked GI is that it used to be incredibly crippling on iteration time. Working at a studio back in 2014 I recall wild schemes to bake lights in AWS so we could iterate faster. Each scene would take hours to fully bake. Today, you can iterate global GI in a fixed viewport multiple times per second with a progressive GPU light mapper. Each scene can be fully baked in This tech doesn't have to be all-or-nothing either. Most well engineered AAA games utilize a mixture of baked & real time. The key is to make as many lights baked as possible, to the extent that you are kind of a constraining asshole about it, even though you can support 8+ dynamic lights per scene object. I look at real time lighting as a bandaid, not a solution.

If you want to attack this from a business perspective - Bleeding edge lighting tech is a nightmare if you want to ship to a large # of customers on a wide range of platforms.

Post reply on HN