(VIDEO) UE4's Geometry Mode is inadequate when compared with that of Quake 1

[JoeWintergreen]

I never do this, but I did a Me Talking Over Video video. This one is about the ways in which Unreal Engine level design has a lot of catching up to do when compared to Quake 1's (in one important respect, anyway) if it's planning on targeting smaller developers more now. More specifically it's about how editing CSG in Unreal (including 4) sucks, and why that is something that should be fixed instead of handwaved away as not being a big deal.

Otherwise: lovin' the engine, dudes, honestly it's really great don't hate me <3

To reiterate: I know that the conventional wisdom is "just don't use CSG in Unreal for anything more than whiteboxing, man!" My assertion is that

-UE4's CSG tools are inadequate even for that

-that the conventional wisdom only has validity in the first place because support for csg is bad, not because staticmesh-based level design is a superior technique.

I'm also aware that UE's CSG isn't efficient for performance for a few reasons (last I checked every face was a draw call) but again, I'm sure it's a thing that could be fixed if prioritised.

[Dishwasher]

Very well put video, I agree with you completely! Hopefully CSG tools, performance and workflow in UE4 will be improved.

[Hevedy]

I posted about this, time ago, in answerhub but the people started to put my down votes no idea why.
And how is faster that than the actual editor and the Call of Duty editor/Quake(Radiant) is faster than the Source engine (Hammer) editor but Hammer have more features.
For example in the UDK/UE4/Hammer need select the sides to move but in the Radiant is automatic, i'm going to make a video about this.

[darthviper107]

People don't care that much because few people use BSP

[JoeWintergreen]

Circular argument. People don't use BSP because the tools for it are bad.

[DotCam]

Circular argument. People don't use BSP because the tools for it are bad.

No, people don't use it much because it is a dated method of creating a level. Today it is only really used for blocking out parts of your level, then converted into a static mesh and modeled in a 3d creation tool.

The engine is optimized for static meshes, not editable BSP sections, and the performance difference is massive, with the main reason being they are still in an editable state, don't have UV's / Lightmaps etc, etc.

Their usefulness is very limited in modern game creation, it was a big deal back in quakes days as levels were basically just a bunch of hallways rooms and right angles everywhere, but this is no longer the case when it comes to level design.

[Errvald]

Hammer editor is game specific, most of the games are not made out of simple geometry ( like your example ).

I think BSP covers the need of placeholders well.

[JoeWintergreen]

No, people don't use it much because it is a dated method of creating a level. Today it is only really used for blocking out parts of your level, then converted into a static mesh and modeled in a 3d creation tool.

The engine is optimized for static meshes, not editable BSP sections, and the performance difference is massive, with the main reason being they are still in an editable state, don't have UV's / Lightmaps etc, etc.

Their usefulness is very limited in modern game creation, it was a big deal back in quakes days as levels were basically just a bunch of hallways rooms and right angles everywhere, but this is no longer the case when it comes to level design.

This is patently false, BSP's usefulness is enormous provided there are decent tools to work with it. Today in Unreal it's mostly used for blockouts, because Unreal has never had good BSP tools (even when it was more prominent in Unreal level design).

The performance difference is irrelevant to this discussion because it's a symptom of Unreal's deliberate lack of emphasis on it and solvable if Epic decide to solve it (and BSP does have UVs and lightmaps, but whatevs).

It's no more a dated method of creating a level than any other; these methods have just about been around for as long as each other.

If we're saying that CSG is outdated, we're also saying that level designers who are not 3D artists are outdated, which is dangerous because those skillsets do not tend to have significant overlap. Expecting an artist to create great levels is exactly like expecting programmers to generate great art.

Hammer editor is game specific, most of the games are not made out of simple geometry ( like your example ).

I think BSP covers the need of placeholders well.

Hammer isn't game-specific any more than UnrealEd is. It's engine-specific, sure... but what's your point?
Most Quake-derived games are primarily made out of (relatively) simple geometry (although BSP need not be boxy), with a few props scattered here and there.

Examples:

All Valve's games.

Look at the HL2: EP2 screenshot at the bottom of this post. The staticmeshes in this screenshot are the ceiling lights, fencing, speakers, obvious physics objects and pipes. That's a pretty sick tunnel with pretty sick lightmaps on it though! Could use more polys on the tunnel, but that's not a BSP limitation.

This Portal 2 screenshot. Even less staticmeshes here, but the game is so pretty! And it shipped like this! We've got some rubble on the floor, some (but not all!) of which is staticmesh and the rest is BSP. The cube dispenser. Bits of strut in the ceiling aren't BSP. The door's not. That's it!

Sure, most of Portal is literally white boxes, but what are we saying, here? We only want people to use Unreal if their game happens to be easier developed without BSP? That would have been ruling out Portal. Portal.


CS:GO! Look at all this sweet BSP. Don't be fooled by the sticky-outy bricks on the corners, those walls are BSP. They just add sticky-outy brick meshes to the corners when they're done iterating and hardly anybody ever knows the difference.




Thirty Flights of Loving!

Thirty Flights is literally on the Quake 2 engine. Luckily, the Quake 2 engine has better tools for non-artists to create and iterate upon level geometry than Unreal does. Again, I'll preempt any "Unreal is for games with good graphics hurr hurr" by reminding you that Unreal is specifically, calculatedly trying to move into the indie game space, and for the business-oriented minds among you, Thirty Flights was profitable.



Double Action Boogaloo! Sure, it's a bit blocky even by Source standards, but the important thing to remember is it's an awesome game that the team wouldn't have been able to create as well on Unreal because Unreal has bad geo tools.





If it seems like I'm going overboard here, here's the tl;dr: all of the above games are clearly excellent and clearly successful and clearly made by super smart people, and Unreal would have been a bad choice for them because its geometry tools are poorly implemented and don't allow rapid and carefree iteration cycles. People don't choose Quake-derived engines because they're stupid, they choose them because there are extremely solid foundations with which Unreal has never been able to compete.

Bam.

[JoeWintergreen]

To clarify: When I'm saying BSP I'm talking about CSG, or just whatever superficially-similar-to-BSP in-editor tools for generating geo. Not fussed that it actually be BSP.

[DotCam]

This is patently false, BSP's usefulness is enormous provided there are decent tools to work with it. Today in Unreal it's mostly used for blockouts, because Unreal has never had good BSP tools (even when it was more prominent in Unreal level design).

The performance difference is irrelevant to this discussion because it's a symptom of Unreal's deliberate lack of emphasis on it and solvable if Epic decide to solve it (and BSP does have UVs and lightmaps, but whatevs).

It's no more a dated method of creating a level than any other; these methods have just about been around for as long as each other.

Look, I'm not going to sit here and get into a back and forth over what method works the best for you, but I will say Epic made a design choice based on getting the best performance possible from meshes, and decided on Static Meshes. BSP's have way too many limitations, and the performance issues are real, even if it was optimized, static meshes will always be faster because BSP's are in an editable state. There is no getting around that fact, being editable adds significant overhead.

There are plugins coming to the marketplace soon (such as pro-builder) and Epic is working on Geometry 2.0 for a future release if you feel the need to work this way. But they will not replace static meshes.

[JoeWintergreen]

I never suggested that BSP should replace staticmeshes, I suggested that Unreal needs good, rather than bad, geometry tools. There are absolutely going to be ways to get around any overhead associated with BSPs being editable; you could bake them into a static form for the packaged game or whatever. The workflow is the important thing.

[DotCam]

I never suggested that BSP should replace staticmeshes, I suggested that Unreal needs good, rather than bad, geometry tools. There are absolutely going to be ways to get around any overhead associated with BSPs being editable; you could bake them into a static form for the packaged game or whatever. The workflow is the important thing.

Well Epic will be implementing Geomerty 2.0 sometime next year (as per trello), but the Pro-Builder guy's are your best bet for a near term solution.

Here is the Pro-Builder I mentioned, see if you can get a response back from him, seems to be in active development, it's already available for Unity as well (with a video showing how it works).
https://forums.unrealengine.com/show...-4-Marketplace

[Errvald]

Bam.

Again all those examples are flat, boxy meshes.

I'd like UE to replace ZBRUSH too but that ain't going to happen

[JoeWintergreen]

Errvald: Are you saying they're boxy meshes and not BSP (in which case you're mistaken), or just that you don't like the propensity of BSP to usually come out flat and boxy? In which case I'd reiterate: it doesn't matter if you reckon Half-Life 2 or Portal 2 or CS:GO or The Stanley Parable or Thirty Flights look boxy, because they were obviously good enough. Which means Unreal shouldn't be ignoring the methods used in their creation when, again: solved problem since '96 or earlier.

If Epic want to seriously move in on the indie game/small team space, this is a pretty simple reshuffling of priorities to solve a problem Unreal's had since The Beginning which has continually stopped people converting from other engines

[Errvald]

If Epic want to seriously move in on the indie game/small team space, this is a pretty simple reshuffling of priorities to solve a problem Unreal's had since The Beginning which has continually stopped people converting from other engines

Last time I checked none of the major Game Engines had incorporated their own '3ds max' in their editor.

BSPs are enough for placeholders, I have the feeling you guys are confusing game engines with game mods...