Replies: 9 comments
-
|
edit: apparently this is automated, oops is there really no way to just automate the culling? i'm not a fan of manually culling the map, it reminds me of the Source Engine, i just find the system to be so ass backwards, and to me this always felt like a problem which a computer should be smart enough to solve on its own for all i care, it could turn the whole level into giant squares, and use those to somehow do some fancy math, and give us some proper culling, like come on, there has to be a better solution i'm lazy and i would rather focus on making the level itself more fun, instead of wasting my time i feel like this is too much busy work in the end, honestly i would rather have the game run at a worse framerate, if it means that i avoid wasting my time with really tedious hand made optimizations edit: i thought you had to place the portals by hand, ignore what i said |
Beta Was this translation helpful? Give feedback.
-
|
anyway how well does this deal with windows \ transparent surfaces? what happens when you have stairs or more complex levels? can you set a giant volume, like a giant box, where anything in the giant box, gets culled? how do you tell the game what's a room? what if there was a tunnel, with holes on the top, how would the game know, to keep the stuff that's above, visible? is this solution only good for enclosed rooms? what if instead of culling a room, i want to cull a whole area? |
Beta Was this translation helpful? Give feedback.
-
Actually rooms and portals is quite adaptable, if you think outside the box. But it does admittedly work best with levels that are mostly static, that are designed to have some occlusion going on. Rooms and portals, and the closely related BSP / PVS approach (which is really just finer grained) were historically pretty much THE solution for occlusion culling in years gone past, a very high proportion of suitable older games will have used such a system - e.g. Doom, Duke Nukem, Quake, Unreal, Half life, NetImmerse / Gamebryo and games based on these engines.
Culling is actually a more difficult problem than it first appears. With more processing power and memory available there are some more variants that have become possible (although maybe not on e.g. mobile). But they all have their flaws, and often a need for some kind of manual work. It is a kind of pick your poison scenario.
Ultimately the computer does solve the problem of occlusion on it's own using the Z Buffer. Occlusion culling is really a search for a more efficient way of removing geometry than the traditional z buffer. I wrote a bit about this here:
This is actually one of the solutions possible, I believe Unity may have this method (I may experiment with this at a later point). It isn't perfect though because there can be small holes through which you can see geometry that could be missed by the method.
Sure, everyone would rather have as little manual work to do as possible. This is partly why many modern games are moving towards raster based approaches. We will hopefully be looking at raster based approaches in Godot 4.x. I can't do this easily in my module, because, it is a module and some things are easier to do tightly linked with the core.
To a large extent with rooms and portals you do have to place portals by hand. You can sometimes automate this to a certain extent. For instance in my demos I build a level from modular rooms so the portal placement is automatic. |
Beta Was this translation helpful? Give feedback.
-
It works fine with these. If e.g. a window is between one room and another, just place a portal over it. Other transparent surfaces can just be an object within a room and rendered as normal.
You can place portals in any orientation. You'd might start by placing a portal at the top of the stairs, at ceiling height, covering the hole between the lower and upper room. You might be able to google some images which will help show you techniques of portal placement. Artists would get quite skilled at it.
Just put a portal on the top of the room, and another room / area above it. The outside area can be separated into rooms too (room is just terminology, they are also sometime called cells, but are just convex areas really).
With LPortal yup you can do this, just make the giant box a room, or under a spatial named to be a room, and all the mesh instances within will be culled by the system. There's also now a single room mode where it may be able to accelerate levels that contain no portals (only to a limited extent, depending on the game, as it cannot do occlusion culling).
Just create a spatial with the name 'room_kitchen' and place everything you want in it as a child or grandchildren. It is explained in the docs:
You would place portals over the holes to see into the rooms above! 👍
Nope, it works for areas too. As I say room is just terminology, in a totally outdoor terrain you could even have a valley as a room, with mountains between, and portals to see into other surrounding valleys. Portals is often a good system to have in your arsenal, regardless of whether you are using raster methods as well, simply because it is super cheap at runtime. You can use it in combination with other methods too. |
Beta Was this translation helpful? Give feedback.
-
|
One other point regarding the manual effort of placing portals: In independent / beginner games the emphasis is often on making things as easy and effortless as possible (even if this is at the cost of performance). In professional games the balance can be very different. In professional games there will often be a team of background artists for different jobs within level building. There might be specialists for blocking out levels, specialists for making props, specialists for placing props and specialists for placing visibility tags (like portals) and gameplay elements. So for most beginners this kind of thing might be considered tedious, but for some people, it is literally their job. That is what pays their paycheck at the end of the month. A producer / investors will often be happier to hire artists specifically for manual visibility that is proven to work rather than take the risk on an automated solution that may or may not work. Essentially the question an amateur will ask is: If you are making e.g. a shooter game for mobile, having such a system makes the difference between something that is so slow as to be unplayable, and something that runs like a veritable sh*t off a shovel. And that will make you more money. At the moment Godot is mainly geared towards the amateur, but that's no reason why we shouldn't build the tools that might be desired by professionals / higher budget settings. Granted my module is rough around the edges 😉 but it is a step in that direction. And some of the experience will I'm sure help when we discuss the core implementations for Godot 4.x. |
Beta Was this translation helpful? Give feedback.
-
|
cool, thanks, i feel like i've learned something, and i guess i'll just need to go back to the Source Engine \ Hammer style workflow as far as the level design goes, so i'll probably add portals only once the level is more or less completed if there's no running away from the portals then, oh well, i'll use them once my framerate starts to chug, beats nothing at all i'm not sure how to handle a trackmania styled level yet though, where the player can straight up build their track however they want, with no regards for visibility or culling, it sounds like a nightmare to optimize with the portals alone even if the scenes had the portals pre-built into them, i think that would only work ok for very specific track pieces, tunnels are an obvious choice for me at least, so i could see myself slapping some portals already in the prefabs actually scenes ARE like prefabs in the Source Engine, huh wow these engines are actually not at all as different as i thought they would be, honestly everything is starting to make a whole lot more sense to me now, i might honestly rename "scenes" to something more obvious for myself, the word "scene" makes me think of a level, or of a stage i never thought of just, bundling the portals with some of the assets by default anyway i kinda wish the original godot repository could be as relaxed as this one, people are way too quick to shut each other down for some reason, and i struggle to take them seriously, but it also makes it a bit harder for me to get involved into anything long term i don't mind doing tedious things once in a while, but i feel like the time wasted on such manual work is generally not worth it, and it adds up quickly over time, and i feel like it's mentally more challenging than it should be, so i would much rather try to automate the problem away, even if it might take months worth of work, i feel like the long term benefits, on my own sanity, are too large to ignore hopefully there's some kind of middleground, but i'm willing to use the portal system if it's the only option we really have right now - i don't know, i can't really get my thoughts out properly meh, you'll figure it out, i'm just some random guy on the internet - i have no real game development knowledge, or any programming knowledge, or anything, i'm just winging it to be honest, and i'm just using my intuition mostly i can work with technical stuff, but deep down i honestly know nothing at all, most of my work is overly documented, out of fear of forgetting everything after six months, but my own documentation often saves my ass once in a while, even if i get a bit verbose so don't mind what i'm saying too much, i'm not even sure what to say to be honest, i kinda forgot my point halfway through, oops |
Beta Was this translation helpful? Give feedback.
-
|
tl:dr: in the long term, i think this would be nice to have, it can't hurt to add such a general tool as this one, sometimes you need a simple, cheap and fast solution, but if it could be partially automated somehow, that would be a huge time saver, and it would stop me from going insane 👌 and if a better system can outright replace it, we can just rip it out in the future, uh... hopefully i do want to focus on keeping the engine lightweight though, if i were to make a culling system, i would probably go for a more generalist type of system, which could deal with most cases, i like it when a system is balanced, or when it has some kind of middle ground, between sanity and performance so i'd definitely give up some control, and some performance, in exchange for some ease of use, and more automation personally i'm really afraid of bloating the engine, i've seen what happens when things go out of control, and i hope Godot can avoid that in the future, i really hope this won't end up like the unreal engine 4, god please no i'm the type of person who's usually more all in, so i would probably skip work on the portal system entirely, and see if i can figure out something more convenient in the long term, even if it takes longer to develop one system by itself, and i know that there's an increased risk with this strategy but, my approach really is all or nothing usually anyway yeah go for it, i'm not against this or anything, but i do wonder if the time spent on the portals, could be better spent, on a different solution - and if the portals ever get replaced anyway, why not skip a step, and just go directly for the golden egg i'm too ignorant on the topic, and maybe honestly, portals are the next best thing right now, i dunno, this is something i need to do more research over |
Beta Was this translation helpful? Give feedback.
-
|
I would say that one thing about the best solution for occlusion culling (and optimization in general) is that it depends very much on the nature of your game. What works well for one game may be different to another. One of the difficulties of making a generalist game engine like Godot is the balance between making features that everyone can use and those that are specific to a particular game type. One option that is being looked at for 4.x is to try and make the visual server quite customizable (from e.g. modules) so that the user can choose the visibility system that best fits the type of game they are making.
Don't feel you have to use portals for this kind of game, something else might be more appropriate for you. I've only watched some videos on youtube of trackmania, but I'm not sure the early versions are using any occlusion culling at all, just a max view distance (maybe with some fog). You can also sometimes just simply show / hide areas of your map more manually, as Bastiaan demonstrates here:
I am in total agreement, I also hate anything tedious 😄 .. hence why I usually make procedural levels out of modular blocks (like your tracks) with things like portals built in.
This is kind of where we are already with the lack of occlusion culling. It is easy to use, but won't give the fullest performance.
Oh yep I think that is the aim especially for Godot core. That's a lot of the reason why I started using it in preference to others. As much as possible the aim is usually to put functionality into optional modules. The PR reviews are usually quite strict about what gets into core. Another thing to make sure you are aware of, is that there is a lot of hype for occlusion culling, however as I wrote here: On powerful desktop PCs using complex shaders (like PBR, PCF shadows, filtering), be aware it may not speed things up as much as you are expecting. This is because although Godot currently draws everything, there is an initial cheap z-only pass with the renderer, such that only the frontmost faces are given the complex shading. If the cost of the main shader is much more expensive (e.g. 10x) than the z pass, then you can afford to draw a lot of occluded geometry before it starts to impact on the frame rate. Essentially, if you make your main shaders slow and inefficient enough (cough) things will be running so slowly anyway you won't notice the lack of occlusion culling. You will tend to see greater gains in simpler shading situations, and on mobile. Particularly on tile renderers there can also be benefit from simply cutting the poly count. You can also occlusion cull out skinned characters which can be a bottleneck. The other non obvious benefit, which can actually be rather significant, is that you can often turn off physics / AI etc in rooms that are not visible. |
Beta Was this translation helpful? Give feedback.
-
|
There is a proposal discussing this: godotengine/godot-proposals#2172 Portals and rooms are now implemeted in Godot 3.4 (in addition to occluder spheres). See https://docs.godotengine.org/en/3.4/tutorials/3d/portals/index.html for documentation. |
Beta Was this translation helpful? Give feedback.
-
Context
Occlusion culling is on the roadmap for Godot 4.0.
Problem
A lot of games would greatly benefit from occlusion culling.
Suggestion
Make a module to support this.
Solution
While some methods of occlusion culling are not easy to do without support within core, a portal rendering system is possible as a module. To that end I've been putting together a rudimentary solution:
https://www.youtube.com/watch?v=NmlWkkhGoJA
https://www.youtube.com/watch?v=Z1YOiJmj57k
It is still a work in progress, but the basic system is working, and I am now putting in better support for shadows. Latest source is available from:
https://github.com/lawnjelly/godot-lportal
While this is mostly to provide an optional module for Godot 3, it is possible some of the ideas will feed back into the eventual strategy for Godot 4.0 when it is done as part of core.
Being a module has had consequences for how I've designed it so far - it relies on conversion at runtime rather than a special importer.
Anyway rather than repeat myself here, I've written detailed instructions and tutorial:
https://github.com/lawnjelly/godot-lportal/blob/master/INSTRUCTIONS.md
https://github.com/lawnjelly/godot-lportal/blob/master/TUTORIAL.md
Feedback
What I'm interested in here is feedback and ideas, particularly on ease of use. And also how you would expect your ideal room / portal system to work?
Beta Was this translation helpful? Give feedback.
All reactions