Every level, every environment begun with a BSP blockout - the use of simple geometry to create the layout, the framework onto which final environment was built on. But that only means BSP has served its function. To use BSP brushes correctly it's important to understand what they are, their benefits, limitations and their purpose in UE4 production pipeline. To create the initial layout of the environment, don't jump right into inserting Static Meshes, texturing or lighting. You need to build the framework and test your idea in editor.
Purpose of BSP is to blockout the initial geometry of a level or environment for testing; to establish scale , layout, flow and spatial relationship of architecture - for this use BSP brushes. BSP brushes are simple, primitive geometric shapes available to use right inside the UE4 editor. BSPs bug out very quickly when you use non boxy shapes.
Even when you use only boxes, rotating them to create something like a ramp still has a high chance of bugging it out. Sometimes it is visual, sometimes it affects the collision, it is simply not feasible to depend on BSPs for anything other than simple, occasional corners, floor, or walls.
Besides that, they are extremely slow, for large levels, it feels as if it is an order of magnitude slower. Static meshes are way, way faster, but they are not instanced. Each Static Mesh takes a separate draw call to draw, even if they are exact copies of the same model. They don't waste memory however. You can use instancing via a 3d modelling application, instances created inside a 3d modeler will be instanced inside UDK as well, however they will all be inside the same mesh, and would take more memory than just copying a single mesh inside an editor.
UT3 afaik is mostly modular meshes with no special instancing, just copying same meshes all over the map to save memory at the performance cost. Dungeon Defenders use instancing extensively for variety of different sections of maps, I assume the main purpose is to have better performance at the cost of using more memory.
You will typically get much better rendering performance by simply creating the mesh properly in an external app and importing it.
There is also no ability to do smoothing groups with CSG. Vertices can only be shared if the position, texture coordinate, and normal are the same which almost never is the case with converted meshes. It's exciting stuff for people who haven't programmed or scripted before, and it's a creative goldmine for people starved to get their design goals onto a screen. Get a basic empty shell with some triggers and dynamic lights and have them go to town with switches, gates, toggles, actor factories, attaching objects, etc That said, learning basic decent visual meshing is what gets people jobs.
It's sad but true that visual candy will trump scripting experience in 9 out of 10 hiring situations for LDs. Get people hooked early on giving the player feedback with every event. Everyone needs to know how to trigger a basic screen shake, spawn particle effects, and play sounds. If they take an hour to make some building fall and form cover or something, for God's sake take another 5 minutes to add those 3 things and make that event an authentic "experience", even if they're placeholder.
Mocked up a boss fight? If he's not making any sound there's about zero chance you'll get anyone excited about it. Outputting "big fireball goes here" to a log just doesn't do it for people, haha, go figure. Somewhat off topic, but every university student piece I've ever seen treats player feedback as an optional last minute polish item, but in reality this is core stuff that puts the smile on the player's face. I wish instructors would get the importance of feedback burned into their heads early.
If they need to drop a few far left field design bulletpoints to get the basic player interactions feeling solid and fun, well, that's a far greater service to them than simply indulging their design whims with no parameters and allowing them to wander aimlessly through an overly ambitious design.
I'm sure that flies in the face of many people's perceptions that a student should take the opportunity with no real business or production constraints to "stretch the envelope" Prefabs for us are a collection of instances, each prefab will tack changes so that when you update a prefab it won't blow over any changes you've made to an individual prefab.
So you can have a prefab door with a build in dynamic red light over it, place it all over, change one prefab light to be green, later you tweak the shade of red used on all the doors and update the main prefab, all the red lights will update to the new shade, but since you've altered the one prefab instance to show a green light that one will stay green even while all the others are updated. So basically they're instances but they remember anything you've changed about one particular instance so that when new changes are propogated down you don't lose individual changes.
From Daniel Vogel : Texture atlassing is only a win for meshes with small textures that are littered all over the level. For regular meshes we still go with a single texture or well, set of textures if you look at normal, diffuse, Stuff like debris on the ground, signs and all the little stuff is a good candidate for atlassing as it needs to be always streamed in anyways given how its used in a level. This is very important. It sounds obvious enough but a lot of projects I've worked on in the past didn't do this and suffered from it imo.
And usually it's the gameplay. It's just far too common to hit a roadblock waiting on code or assets to come online and burn a week "rearranging the furniture" instead of solving a gameplay problem or polishing script early on.
Kismet and Matinee in UE3 makes this easier because you can schedule near final scripting VERY early on in a project and designers can make or at least prototype just about anything without ever bothering a programmer.
Conclusion Obviously, there is a lot more ground to cover on your way to creating a world class level and we will get to that in more advanced articles to come. This, however, should give you the basics of what you need to start playing with the editor and seeing what you can make.
If you are looking for the Unreal Engine 4 documentation, please visit the Unreal Engine 4 Documentation site. Search public documentation:. Contact the UDN Staff. Don't show me this again. Terms and Conditions Privacy Notice. Some tips Once you've got people capable of basic bsp construction and level basics, I'd reccomend getting people turned onto the scripting side quickly. Texture atlassing is only a win for meshes with small textures that are littered all over the level.
Make sure you shell out your map thoroughly in BSP first. Also, the really annoying thing is that doing a CSG operation only leaves you with the result, meaning you always need to store a backup of the shape you want to carve if you need repeat it somewhere. This also means that you have to be pretty confident about what you're doing, because the next time you'll want to modify a cut-out, it might not be so easy.
Because the resulting mesh topology after a CSG operation is bad. Very bad. It's even worse than what Sketchup produces. Let's have a look at my arches:. Also, we can see that my arches were cutting too deep into the ceiling, and you just have to look at the edges to see it's going to be quicker to start over than trying to fix the problem.
Which, in a whitebox phase, is kind of a problem. Another issue with this is performance. CSG operations are expensive. By the time I added the 6th arch because I can't do all of them at once , the operation was already taking significantly longer to complete. And in the above picture, selecting a face was a real struggle and I've got a decent computer. So obviously, we could get around most of those problems by adopting a modular approach and using building blocks, but in that case, I consider we're past the whiteboxing phase in most cases.
0コメント