Announcement

Collapse
No announcement yet.

So Epic....Lets talk about BSP

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    So Epic....Lets talk about BSP

    I'm a bit of a forum lurker - most questions i have for the forums have already been asked - so I'm usually content just reading. However, this is something I've been itching to start a discussion about. I haven't seen much constructive back and forth on the topic - threads on BSP tools tend toward frustrated venting. Theres some good discussion out there (for example) - but its few and far between. I apologize if theres a recent 50 page thread on this topic that I totally missed - lol you can dismiss whats below if thats the case. I'm also sorry if it incites dismissive TLDR. I try to compartmentalize my points, I apologize if I ramble.

    Since this is my first post, a bit of background before I pop off I guess. I've worked in the industry for 5 years - I've been a worldbuilder for about 2.5 years. I've been using Unreal Technology since....the Gears of War PC editor - so I guess....since ultra legacy UE3....or UE2.5...or whatever. EPICs sometimes clunky BSP system holds a dear place in my heart - as it was with Unreals BSP system that my level design fundamentals and methodology really began to gel. (at least in my eyes lol)

    Seeing Epics tech evolve to the marvelous spectacle that is UE4 has been truly amazing - however I feel BSP has been....somewhat neglected in Unreal Engine 4, and has arguably experienced a bit of a regression. Now, Id like to discuss this as constructively as possible, there were alot of fantastic new editor systems coming to life this past year - and its understandable that BSP has taken a bit of a back seat.

    So Im gonna talk about it a bit, discuss where Id like to see BSP become, and inquire what the community and the devs would like to see BSP become. I'm not looking to bemoan my frustrations or take snarky potshots at the dev teams in any way - I'm just looking to foster some dialogue between Epic Devs and the community on this topic. And give some constructive feedback on a tool that is very dear to me. And what better place to do it then a forum full of EPIC and community UT developers - who get down and dirty with BSP regularly .


    The Core Issue(s?)
    [PLEASE NOTE! I'm not looking for the UT Dev team to solve Geometry 2.0. Im not that presumptuous/rude. I am looking to pick their brains on the matter along with the community at large, conduct some realistic brainstorming, and perhaps drum up some advocacy on this topic]

    So first, this video sums up alot of my frustration quite nicely (minus some of this guys snarky bluntness, but the points this youtuber makes are still salient)
    [[**UPDATE: I WANT TO EMPHASIZE THAT THIS IS NOT MY VIDEO OR ME IN THE VIDEO. ]]
    Some people are assuming this video is me, and I would never take false credit for this guys well thought out youtube video. It capitulates the issue way more effectively than I ever could in the medium of forum posts..


    In short:
    This tool for rapid level prototyping isnt particularly conducive to rapid prototyping. Geometry Editing is not nearly as robust as most/all other editor tools included in UE4. While its very similar to the BSP system in UE3 - the UE4 BSP system has undergone many small regressions (ex: the loss of simple boolean unions, the inability to reliably control BSP pivots) and suffers from technical issues that make whiteboxing level geometry with BSP largely inefficient/frustrating when attempting rapid prototyping.





    Common Rebuttals and Workarounds for my BSP woes

    Im no stranger to the forum search tool - on this forum or the main UE4 forum. I'm not the first one to make such complaints. These are the most common rebuttals/workarounds to the issues that I've encountered:

    • "Try using a 3d application for level shells instead"
      • a workable solution, but far from optimal - and fairly overwhelming to those just starting to dabble in game dev

    • "Block out using modular meshes"
      • While this has been my preferred method as of late - it lacks the flexibility I used to enjoy with legacy-BSP. Especially without built-in features like vertex snapping, or the ability to reliably change your pivot
      • Also, I tend to like turning my BSP geometry into my collision shells in the latter stages of working on a level - collision shells that are highly malleable in engine. When I work using just modular meshes, my level collision tends to get sloppy real early.

    • [[The Grizzled Unreal Veteran Response]] - (a depressingly common attitude Ive seen lately):



    And other similar sentiments - all which somewhat sidestep the aforementioned core issue: this tool for rapid level prototyping isnt particularly conducive to rapid prototyping.

    Alternate workflows (using maya/modo, whiteboxing with modular mesh primitives) are well and good, but BSP can be a wonderful prototyping tool - especially for new initiates to the engine. And one of the things that sets Unreal Engine from engines like Unity are the great tools provided out of the box.



    So whats holding BSP/CSG/Geometry-Editor back? Why isn't it being iterated upon like other UE4 tools?

    (IMHO)
    • To begin with, Epic is naturally aware of this problem ("BSP Replacement" and "Geometry 2.0" have been on the wishlist / backlog since mid January). Which leads me to believe they've been quietly mulling over a BSP solution for a good amount of time. They also take the time to rectify the more egregious issues that crop up with our current BSP system - quite proactively.
    • Losing most of my core boolean operations makes things.....rougher than they need to be.
    • The scope of the engine is massive. It blows my mind. And Epic has to be reasonable in what they prioritize. No developer misses a game delivery because they have janky BSP tools - I respect the choices Epic has made in what to prioritize - but I'd also argue that the engine has come along far enough that its worth reevaluating more basic systems like BSP, and considering a dedicated usability pass / overhaul.
    • Asking any programmer I know: "why arent there quick and easy to implement BSP solutions?" has always resulted in a frown and a sigh. The consensus seems to be that implementing BSP systems is no light matter - BSP is inherently messy by its very nature.
    • Geometry modes not unusably borked - its just....clumsy to model with and unstable. As long as you save fastidiously....its serviceable - you can block out a level with BSP with some gumption and patience. It dances right on the line of "acceptably functional". BSP screwiness is simply not a "showstopper" that demands immediate attention. [Pure conjecture.... but with logical reasoning hopefully]



    How would the EPIC Developers like to see BSP evolve?

    THIS QUESTION ISNT RHETORICAL!!!!!
    Really - I wanna hear how you devs would like to see our Geometry Editor evolve. Like....what do your teams level designers fantasize about when it comes to improving our geometry editor?
    What are the limitations that concern your engineers for implementing a new geometry system?

    I don't see nearly as much back and forth discussion on this as there is with other in-editor tools.




    How would my fellow UT modders like to see BSP evolve?

    THIS QUESTION ISNT RHETORICAL EITHER!!!!!
    Im genuinely interested in what you guys/gals in the community think as well. What improvements would you like to see? Bevel? Chamfer? Better Extrusion?
    How would you improve our BSP system to better promote rapid prototyping?
    Am I just a windbag, pontificating for no good reason?





    How would I like to see BSP evolve?

    • My simplest wish? Get some classic legacy boolean operations online again - and better pivot controls. Deintersect? Yes please. Intersect/Merge? Oh god, yes.
    • At the very least Id like to see some healthy back and forth between the UT community and devs on whats possible for "Geometry 2.0". BSP is an important tool for the UT Mod community, its a good place for this kind of discussion to take place.
    • Full SUB-D modeling seems unrealistic...but better modeling controls would be great.


    Examples of cool/well-implemented solutions in other software packages

    (any comments regarding technical limitations preventing these sorts of things in UE4 are more than welcome)


    UNITY

    Unity never even bothered to foster BSP systems. Which has always been curious -
    however there are kick *** whiteboxing solutions in the unity store - most prominently pro-builder:


    FORM Z
    Specialist modeling package Form Z by Autodessys (not autodesk...) has a truly elegant BSP system.
    Far and away my favorite BSP tool that nobodies ever heard of. So satisfying and fast.
    And the toolset! I prefer this program over sketchup quite strongly. Especially the intuitive functionality displayed at 3:15 or so in this 1st video:



    The intuitiveness of reshaping, and offsetting is fantastic as well:





    And yeah....ill step down from my soapbox. Ive run my mouth enough for my 1st post.

    Greetings UT Forums - dont flame me too hard for being a blabbermouth. It wont happen often.
    Feel free to correct or criticize any faulty statements - im glad to redact anything incorrect/uninformed ive blathered out.



    Cheers,
    Boogerbreath


    P.S. EPIC devs (and PeopleCanFly) - Ive learned more from deconstructing your level designs (all the way back to the gears editor) then I have from all my other educational sources combined. Gears inspired me to pursue level design. Thank you so much. Looking forward to seeing where you take UT.




    BOOGERBREATH
    UT Modder, Gears Modder
    Folio: http://designabacination.prosite.com/

    Last edited by Boogerbreath; 07-04-2015, 02:01 AM.

    BOOGERBREATH
    UT Modder, Gears Modder
    Folio: http://designabacination.prosite.com/


    #2
    I agree. Rapid level blockouts aren't very rapid...

    Comment


      #3
      Absolutely, it's slow to the point where if I could build BSP in Source and then import it to UE4 then I surely would. As someone that's been using Quake / Source engine since 2002 obviously I have some bias, but watching even the most experienced Unreal engine level designers shell levels, they can't do it anywhere near as fast as can be done in Source.

      Comment


        #4
        Fully agree. It's difficult to create content in general in UE4 because of this. It really needs to prioritize a new geometry system. It's on the road map but, as far as I can tell, hasn't even been started. Would be nice to limit the amount of importing required to make a good looking game.

        Comment


          #5
          Would be cool to have some "edit in place" plugins that could allow you to modify 3dsmax, Maya, zbrush models within the engine. I bet it's possible 8). Would solve the creative issue of needing to design your own tool...and turn it into a technical problem of making all these plugins. Think of how nice it would be to tweak 3d geo in-place. Gets my jimmies rustled big time.

          Comment


            #6
            Great thread and video, thank you. I have to wonder if it would be possible for the community to implement such features in C++. Working quickly on the X, Y, Z 2d grid would get me finally mapping in the Engine instead of just modeling in Blender for sure. Also, I'm not sure how Quake 1 engine can just magically align textures along a curve properly like that. There must be some constraints set upon geo to accomplish that.
            Last edited by Quadj130; 07-03-2015, 12:35 PM.

            Comment


              #7
              Id love some more robust BSP tools. My previous levels have been made almost 99% out of bsp (for UT2004) and whilst I understand this is no longer the case BSP to me is still the simplest and most up front method of shelling a map for gameplay. In UE4 I found that it lacked a lot of the features that were present in previous versions (I'm going to leave UT3 out here as I spent no significant time mapping for it) but in UT2004 editor I could use the 2d shape editor. This is the big one for me. want to be able to essentially use the current pen tool and then extrapolate it around an axis to get a curve of the same shape. I want to be able to build simple angles without them resulting in bsp holes. I know ut2004 had bsp holes, but TBH they were hard to achieve, theyre simple to achieve in UE4. End of the day 'd love to see some effort put into the BSP in UE4, it would make prototyping maps so much quicker and easier. (and I already appreciate the auto build bsp to make the initial shell go 100x faster, would take hours in ut2004)

              Comment


                #8
                Originally posted by Tidal Blast
                In many game studios, designers and artists do NOT use BSP/brushes to build levels (including Hourences). They might do it if they need a floor to quickly test something, but they do not use it to build and/or blockout levels. Instead, they use 3D applications that are specialized in 3D modeling such as 3DS Max, Maya, Modo or Blender. It's faster, more flexible, allows to quickly add more detail where needed and if needed, it takes a second to update in UE4, etc. Big time saver. BSP are ideally a last resort, something more appropriate for beginners when they don't have any experience in a 3D app at all and just want to mess around in UE4. I'd rather see Epic invest in all the other aspects of the engine and let studios use specialized 3D modeling tools for 3D modeling tasks. Same thing if I want to texture, I'll use Substance Designer instead of the UE4 Material Editor.

                I agree on some things and disagree on others.
                Yes, using a 3d modeler is a common practice. However - there are plenty examples of engines that provide BSP solutions as well. Also its a workflow that Epic clearly utilizes, so BSP workflows have value within the industry. Look up videos of level prototyping for titanfall - what are they using? BSP. Hourences chooses not to use BSP in UE4 because in its current state - it doesnt facilitate rapid prototyping. But watch any of his older UE3 tutorial videos - and all his levels begin with simple BSP blockouts.

                "BSP is a last resort" isnt a sentiment I agree with. Give me the choice to prototype a level using in-engine tools vs using max/maya - ill always prefer the in-engine tools, especially if I have good Play-In-Editor functionality. BSP allows me to quickly build up my level shell - with the added advantage of Play-In-Editor - where im constantly spawning my character and interacting with the spaces I'm working on. I find when i block out using max - im guesstimating on just about everything - and toggling back and forth between the two apps constantly. My finalized levels have literally zero bsp in them - but my early stages of level iteration utilize BSP to great effect - and when its time to do a meshing pass and replace that BSP - I can turn all/some of that BSP geometry into a collision shell for my level that is highly tweakable.

                Also - you may notice that Epic reuses their BSP shells - converting that geometry into an FBX, tweaking and optimizing in max, and bringing it back into the engine
                See "/Game/RestrictedAssets/Environments/Liandri/Meshes/Optimizations/". All these assets are optimizations of early prototyping BSP.

                Ultimately, I just dont see the logic in disregarding the Geometry Editor altogether. If the tools already exist, why not refine its functionality?





                BOOGERBREATH
                UT Modder, Gears Modder
                Folio: http://designabacination.prosite.com/

                Last edited by Boogerbreath; 07-03-2015, 04:14 PM. Reason: me grammar no good

                BOOGERBREATH
                UT Modder, Gears Modder
                Folio: http://designabacination.prosite.com/

                Comment


                  #9
                  I know this is probably not going to be very helpful, but the reason the geometry editor seems vestigial is because it is. The new levels aren't meant to be built with geometry; there's no point to adding fancy brushes when the engine is built for the whole level to be made from meshes. At this point, I don't think BSP is going to get much more attention in the editor, I doubt there is any real interest from their licensees, and I doubt there is much interest internally.

                  BSP seems important here because we're all from the school of level design that came of age ten years ago, when BSP was vital. But that's not the only way to make a level anymore, and it's certainly not the fastest or most efficient way to make a level anymore. The last level I made, I blocked it out by applying transformations to the basic editor cube mesh and made the whole shell out of that; it took me less than a day to learn a new workflow and create a new shell. It just worked better, and I can see why Epic does not use BSP anymore. It seems silly for Epic to overhaul a feature putting time and money into it when it's there as a stopgap measure at best.

                  Comment


                    #10
                    Originally posted by Boogerbreath View Post
                    I agree on some things and disagree on others.
                    [...]
                    I agree with every single sentence of your entire post. This is simply how things are get done.

                    Levels are no longer made simply with BSP, but BSP is still an important prototyping tool, an ultimate solution for in-engine do-and-try rapid iterations.
                    And brushes don't count only as BSP, but also as multi-purpose volumes, with collision volumes being one of many.
                    Last edited by insomnaut; 07-03-2015, 04:04 PM.
                    @insomnaut aka charon / DM-Coma / ArmorWare

                    Comment


                      #11
                      It doesn't really matter, the argument is that they should still be easier to use and at least as powerful as they were in the past.

                      Or offer an equally useful alternative. Why can't we edit meshes in-place in the editor?

                      Comment


                        #12
                        Originally posted by aniviron View Post
                        I know this is probably not going to be very helpful, but the reason the geometry editor seems vestigial is because it is. The new levels aren't meant to be built with geometry; there's no point to adding fancy brushes when the engine is built for the whole level to be made from meshes. At this point, I don't think BSP is going to get much more attention in the editor, I doubt there is any real interest from their licensees, and I doubt there is much interest internally.

                        BSP seems important here because we're all from the school of level design that came of age ten years ago, when BSP was vital. But that's not the only way to make a level anymore, and it's certainly not the fastest or most efficient way to make a level anymore. The last level I made, I blocked it out by applying transformations to the basic editor cube mesh and made the whole shell out of that; it took me less than a day to learn a new workflow and create a new shell. It just worked better, and I can see why Epic does not use BSP anymore. It seems silly for Epic to overhaul a feature putting time and money into it when it's there as a stopgap measure at best.

                        I disagree with this. First of all, I dont think BSP is the only workflow to make a level, nor should it be.

                        However, I would argue the statement: "I can see why Epic does not use BSP anymore" is simply not true. Epic clearly uses BSP internally. Wanna see the BSP blockout for Outpost 23? Its beautiful and meticulously crafted.
                        Navigate to: "UnrealTournamentEditor\UnrealTournament\Content\RestrictedAssets\Maps\WIP\Outpost23_Shell"
                        If Epic didnt have internal interest and value in BSP workflows - that would be reflected in how they construct their levels. They use BSP to block out levels - they see value in the workflow.


                        Why are there BSP blockout competitions held in the UT community for a "stopgap" measure? Why are so many of their level previews BSP shells? If you've never acclimated to BSP - that's totally acceptable. I dont believe one blockout workflow is inherently superior to another - they both have pros and cons. However, if you're completely disregarding BSP workflows as a relic, I encourage you to take a closer look at how Epics UT devs are crafting their levels.
                        Last edited by Boogerbreath; 07-03-2015, 04:07 PM.

                        BOOGERBREATH
                        UT Modder, Gears Modder
                        Folio: http://designabacination.prosite.com/

                        Comment


                          #13
                          Rapid development --> im all for it !!! Being it BSP, lighting/illumination or other types of things that make out the basic parts of a map. I honestly can say for myself that it has been a de-motivator for me to see the tools being so cumbersome and clumsy. And i miss some good tutorials for especially the lighting/illumination system, especially indoor environments that gets light source from LED lamps or ancient torches.

                          I also believe many other gamers/hobby developers give up when theres not enough rapid development. Im very happy the money obstacle was removed some time ago and UE4 was made free. But to truely mainstream the level development in UT4 we need far better robust rapid tools.

                          Comment


                            #14
                            Originally posted by lo2dk View Post
                            Rapid development --> im all for it !!! Being it BSP, lighting/illumination or other types of things that make out the basic parts of a map. I honestly can say for myself that it has been a de-motivator for me to see the tools being so cumbersome and clumsy. And i miss some good tutorials for especially the lighting/illumination system, especially indoor environments that gets light source from LED lamps or ancient torches.

                            I also believe many other gamers/hobby developers give up when theres not enough rapid development. Im very happy the money obstacle was removed some time ago and UE4 was made free. But to truely mainstream the level development in UT4 we need far better robust rapid tools.
                            Originally posted by insomnaut View Post
                            I agree with every single sentence of your entire post. This is simply how things are get done.

                            Levels are no longer made simply with BSP, but BSP is still an important prototyping tool, an ultimate solution for in-engine do-and-try rapid iterations.
                            And brushes don't count only as BSP, but also as multi-purpose volumes, with collision volumes being one of many.

                            Exactly. Thank you. Glad to see some of the community is in agreement.

                            And it doesnt necessarily have to be a BSP solution. Probuilder in Unity (see vid in my first post) doesnt use CSG/BSP (i think) - instead, it uses some sort of voodoo I dont fully comprehend (auto-uv'ing meshes that you can freely create and manipulate in engine? witchcraft), yet somehow it has a similar functionality and feel to more conventional BSP tools.

                            There might be a more elegant answer to whiteboxing in editor, rather than BSP. I'm a bit thickwitted in such a technical topic, so I dont really go into it. Yet I am very open to, and interested in, insight from community members who have knowledge on such things as implementing BSP-like solutions. Like what is feasible within UE4? Something like probuilder? Something like Form Z?


                            Im really hoping some Epic devs weigh in on this when they get back from enjoying the 4th of July weekend. [HINT HINT Ms. Conley, if you're reading this]
                            Last edited by Boogerbreath; 07-03-2015, 05:06 PM.

                            BOOGERBREATH
                            UT Modder, Gears Modder
                            Folio: http://designabacination.prosite.com/

                            Comment


                              #15
                              Originally posted by Quadj130 View Post
                              Great thread and video, thank you. I have to wonder if it would be possible for the community to implement such features in C++. Working quickly on the X, Y, Z 2d grid would get me finally mapping in the Engine instead of just modeling in Blender for sure. Also, I'm not sure how Quake 1 engine can just magically align textures along a curve properly like that. There must be some constraints set upon geo to accomplish that.

                              You're preaching to the choir. If only I wasnt a total dullard when it comes to implementing such things.

                              BOOGERBREATH
                              UT Modder, Gears Modder
                              Folio: http://designabacination.prosite.com/

                              Comment

                              Working...
                              X