We seem to have reached a crisis point in the NL2 community. A lot of parks are being released with some severe performance issues, despite a fairly modest amount of scenery. Below is a list of some important optimisation steps that many people are neglecting to follow when they create their projects. Follow them, and optimization your parks should become easy and intuitive.
1. Optimise right from the start
There’s an enduring myth in the Nolimits community, and many projects have met an unfortunate demise because of it. The idea that you can design your scenery in full, then return later and optimise it is wrong.
The idea that you can design your scenery in full, then return later and optimise it is wrong
This idea probably persists because in game development studios often do make multiple art passes before reaching the final asset. But in the game industry sequential art passes increase in complexity, (not decrease) and usually the previous pass is only used as a reference, and is normally discarded at the end of the process.
Working as a solo developer or collaborating as a small team, you’re not going to be able to make multiple art passes worthwhile, so instead make conscious decisions about optimisation as you’re making your assets because there’s every chance that that’s the last time you’ll touch that specific model. Optimise from the start and it’ll be easier to accommodate the rest of the rules below.
2. Use fewer 3D Trees
It feels a bit mean to say this, but NL2’s trees kind of suck. The typical way to render trees in videogames is to have several LODs of 3D tree, then finally replacing the mesh with a 2D billboard. Nolimits 2 doesn’t do this last step, so whereas a tree in a game like Crysis or Far Cry 3 might be 1500 polygons up close and 2 polygons when far away, an NL2 tree might be more like 1500 polygons up close and 300 when far away. In a large park, there might be hundreds of thousands of polygons being used just to render distant trees.
Fortunately, this is the quickest thing to remedy in most projects by swapping 3D with 2D trees, and the impact on visuals probably isn’t as drastic as you’d think. I recommend surrounding the important areas of your park (the coaster track and anywhere the player is expected to go in walk mode) and surround those areas with 2-3 rows of 3D trees, and then use matching 2D trees only beyond that.
3. Clip Aggressively
A large number of parks I’ve seen don’t have any distance clipping at all, so it’s no suprise when their performance isn’t great. To set the right clipping distance for your objects, firstly go to the NL2 display settings and set the LOD distance to normal. Object clipping distances are modified according to this setting, so we’ll decide the ‘optimal’ values at this setting, then people can trade-off performance and visual pop-in by changing their LOD distance setting.
Pop-in should just about visible when you’re looking for it, but it’s not distracting when you’re just playing the game
Choosing the right distances can be tricky, but I’d follow the example set by the AAA games you probably play; pop-in should just about visible when you’re looking for it, but it’s not distracting when you’re just playing the game. As an example, I’ve created an image album which shows the distances I chose for the Trash bin asset for Cypher III. Larger objects will often need to be LOD’ed/Clipped at further distances, as they have a higher polygon budget to match the fact they are more of a visual focus.
4. Set your supports’ LOD priority
This is a superb feature of the NL2 engine which I’ve seen hardly anybody use on custom supports. As with the clipping advice above, set your LOD distance setting to normal, then adjust your supports as you feel neccessary.
For support structures with a few large diameter pipes, you’ll mostly stick to high/highest priority, but complex structures like those found on Classic Arrow coasters and Intamin SLCs should have lower priorities set for diagonal/horizontal struts. Dark rides/tunnel sections can also have lower priorities, as they can only be seen up close.
5. Separate your scene into sub-objects
Version 2.5 of Nolimits 2 added an automatic occlusion system, which deals with a lot of the occluding that needed to be done manually in previous versions. You need to be aware of how it works in order to make the best use of it.
The Engine will skip the rendering of any objects that it thinks are occluded (hidden behind other objects). It must be noted however that this is only done on a per-object basis; the CPU overhead of per-polygon occlusion make it infeasible. This means that in your modelling software, you should split your scene into multiple objects.
Usually these splits are fairly logical, such as making the fences in your park seperate objects to, say, the terrain. For large, high-detail meshes such as a replacement terrain, it may make sense to split the model into several smaller objects which can then be individually occluded by the engine. Having individual meshes made of up to the magnitude of thousands of polygons is fine (a full scene in a video game might contain millions of polygons), but you probably don’t want to go much higher than that unless it’s something very high budget like a custom train model.
6. Use occluders, but sparingly
As mentioned, the automatic occluder will do a lot of the legwork for you now, but there are still some cases where you’ll want to create a manual occluder.
Don’t apply the occluder flag to materials on your complex meshes. Instead, create a separate mesh that sits behind the visible mesh, modelled as few, large quads as you can manage. Export the mesh with triangulation disabled in the exporter options. Occluders are great for dark rides, where distance-based clipping won’t optimise enough when you’re stood outside the building. You can also use occluders to lines of sight, which leads me to…
7. Think like a level designer
Whether you like it or not, you’re working with realtime graphics, so not only do you need to think like a park designer, but you’ll also benefit from thinking like a videogame level designer too. This is the most nebulous concept in this list, but I’ll try and give you an example.
You could, if you wished, build a large park around a central focal point, and have the individual parts of the park all link up via this central place. This would look pretty cool, but would have the downside that every part of the park would be visible from any place in the park, and as a result, you need to render everything in the park at once. Even if you’ve followed all of the above advice, you’re creating a worst case scenario. It may be time to a bit more pragmatic with you creative vision.
Generally, breaking up long lines of sight will make optimisation a lot easier. Your Main street styled buildings would look great, but they’d also be tall buildings that are great for hiding occluders in. Ignoring the tree problem mentioned previously, a park like Alton Towers would be the ideal layout for your NL2 parks. Small individual themed areas, with large distances between each area and little/no line of sight between each. Just know which battles to pick; which aspects of the park are crucial to your vision, and which could be done in a way that aides optimisation, rather than causes more issues.
With these simple steps you know have everyth— no wait I totally forgot the most important one:
Stop using Sketchup
Look, I get why people use it, and as a result this isn’t a declaration I make lightly, but Sketchup is unsuitable for modelling realtime graphics for several deal breaking reasons. This argument was originally going to be a separate blog post all of its own, but after each of several attempts at writing it it ended up long and ranting. Here’s the abridged version, so at least it’s short and ranting:
Sketchup lacks so many features I hesitate to categorise it as a modelling software. Not just visually-impacting features like UV mapping, but the complete absence of modelling paradigms like object/mesh separation that are required to optimise parks.
All of this could be forgiven if you could then export the rapidly created meshes and optimise them in another software, but unfortunately Sketchup’s exporter is garbage. The models you get out of it are unfixably wrong in almost every conceivable way; tonnes of parks are uploaded with double-sided faces so they’re rendering twice as many polygons as they need, all faces are separate so you can’t fix double sided faces or the lack of smoothing easily, every time two surface intersect, they’re both geometrically cut into each other, creating tonnes of needless polygons.
Sketchup’s exporter is garbage. The models you get out of it are unfixably wrong in almost every conceivable way
I actually wanted to first-hand experience to back these claims up, so I had a go at fixing Supercell by A113. The polygon soup that Sketchup provided was beyond hope of repair, so for most of the scenery I just had to choose which vertices to keep from the original mesh, and rebuild all of the triangles from scratch. The number of pointlessly created vertices from the Sketchup exporter was staggering. Producing meshes of identical visual quality, I managed to cut the polygon count on the scenery by 2/3’s, but if I excluded the complex emergency stair mesh and counted the polygons on everything else the savings were around 90%. That’s a staggering waste of your polygon budget. The original Supercell release had significant performance issues, but the optimised version I created maintained 60fps.
You will not be able to optimise your parks if you use Sketchup. It creates needlessly complex meshes which are not split into logical sub-objects, which are an anathema to clipping and occlusion. If you attempt a large project using Sketchup you will have created severe performance issues by the end, which are impossible to fix without rebuilding the scenery from scratch.