Suggestion for other object culling modes . .

[charlesmlamb]

Describe the project you are working on

A 2.5D game, with barbarians . . .

Describe the problem or limitation you are having in your project

Ok, I've been thinking, Godot has I think frustrum culling, and, also support for rooms . .

Been thinking, could one make another culling mode, where something, in front of the camera, only gets rendered after a certain distance . . . Suppose I have a level, where there is a village, behind a mountain, and I have to go around a corner, before it can be seen . . . A very fast culling mode, would mean it'd only be rendered, at a certain distance . . So, when I go around a corner, on the mountain, that's only time, it has the required or, minimum distance . . . To do this, one would only need one value, the minimum distance, to render it . . . It could also be used for objects, in a house . . . Some rooms, one would just need to know the distance, to the boundary of a room, to know when to render what . . For many say rooms, it'd be enough to say, only render what is in the room, if distance is say 30 m, or 20 m . . It could be based on distance, to center of room, or a node, the parent node, or, using raycasts to detect the boundary . . It'd be sort-of simplified occlusion culling, require much less math, and for many perhaps use - cases, be enough . .

Another way to do it, was to have something like layers, with certain objects in . . . Take, a forest . . . One could put certain distant trees, one knows player can only see, after a certain distance, the other trees would get, in the way . . . Sort-of, layer culling, where one groups objects in layers, and when player is in certain distance, to such a group / layer, they get rendered . . It's almost the same as ' distance culling ', but one would work with groups, of nodes, and make layers, or 'backgrounds', with a certain distance, to the camera, or, some other node, perhaps the player . . .

The advantage is, it takes much less math, and, would be useful, in many cases . . . Many say houses, with many rooms, with a bit of testing, even at run-time, one could quickly find the minimum distance, where objects in a room, should get rendered . . More advanced, one could make a distance value, for moving to room from sort-of east, west, north, south . . Then, suppose a certain room has a parent node, say Room001, then all meshinstance nodes, maybe chairs, in the room would only be rendered, at a certain distance, maybe from east side, 10 m, from west side, 6 m, from south, 8 m . . . Unless player is close enough, there's no need to render stuff, even in front of the camera . . . For many use - cases, it'd work almost as well, as occlusion culling, and, be much more intuitive, for beginners . . .

Testing it, in wireframe view - mode, in the editor, would be enough to make sure it works . . Faster, mostly as useful as occlusion culling, it's sort-of a more beginner friendly version, if the mode could take rotation, of the parent node into effect, one could make almost anything, and, it'd be almost as good as occlusion culling, and, requirer fewer calculations . . . .

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Well, thought bit, about what other kinds, of frustrum, or occlusion culling might be useful . . There are many times, when distance to an object, or, distance to a parent node, maybe for a room, or area, would be enough, to get good results, esp. if one takes bit time, to maybe design levels, so it's easy . . . Combine that, with the static occluders, for occlusion culling, and it'd be almost, the same, for rooms, places designed, to use that . . Sort-of, ' cheap ' occlusion culling, or perhaps ' fast ' . . . Having both systems, would allow one to customize it, and, get best performance, anyway just got to thinking, of other ways, to make frustrum, or occlusion culling work . . . It'd be not as accurate, but, more beginner friendly . . . Right now occlusion culling it quite advanced, one could even make a value, not just for east, west, north, south, but, also north-east, north-west, sort-of set minimum distance, from eight angles, and I think it'd be just as fast . . . Maybe, one could make a new node, ' DistanceCulling3D ', that has special settings, and, all child nodes only renders, under special conditions . . . ? Thx . . .

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Well, like above, instead of raycasting all the time, for many level designs, this would be good enough, to give almost same results . . Having both systems, would allow beginners to get some performance, from the simple version, and hard - core, or more professional titles, the best result . . . As a beginner, I think the current occlusion culling mode, is too complex, it takes too much time . . . Having this mode, esp. with eight directions, to determine distance from, would give a similar effect, almost, the same, for levels designed, with this in mind . . . Hence, the need for a simple version, and also an advanced one, to get the best results . . . .

If this enhancement will not be used often, can it be worked around with a few lines of script?

Well, it can, one can make it manually, but having a node, where one just types the numbers, then test it in wireframe mode, would be much faster . . To really customize it, one could make a custom angle, say 148 degrees, to one side, only render the node, and, all child nodes, at distance 12 m . . So, one could add a few angles, to make it ALMOST the same, as occlusion culling . . . And, disable certain angles, say west, north, if it wasn't necessary . . . Sort-of, simple, fast occlusion culling, it doesn't have to be a special node, maybe if all nodes, not sure, had this setting, and, some way of inheriting from a parent node, or so . . .

Is there a reason why this should be core and not an add-on in the asset library?

Well, it'd be a simple way, of occluding, also faster, math-wise, thx . . . . ! . .

[charlesmlamb]

Example . .

For a room like this, it'd only be one direction, then IF player is inside room, render stuff . .

One could also set a time, for how often one wants to check for distance, say every 0.5 secs, then, sort-of scatter the calculations, over several nodes, even say 100 . . . Since, it isn't necessary to check every frame . . .

Add a special gizmo, for setting center of room, and, how many directions are ' active ', and it'd almost be occlusion culling, but much faster, so on . . . .

Idea is to make the simplest version, also, one that is more beginner - friendly, thx . . . . ! <3

[Zireael07]

Doesn't the rooms and portals system solve this problem?

[charlesmlamb]

It does, but I think it is based on constantly raycasting the screen, to a big distance . . This would lower the calculations, for almost all rooms . . One COULD make an even higher node, for a group of rooms, say west side, of a big house . . . Only check for individual rooms, if one is on west side . .

It's mostly, bec. sometimes one wants a quick solution, right now one has to set up rooms, also doors, it takes a lot, of time . .

It could also support, stuff like ground floor, level 1, level 2, in a house . . . Only render certain stuff, if has right vertical distance . . . Having super-nodes, that avoids calculations for say individual rooms, would be fast . . .

The idea is, to make a very simple system, that gives good results . . . Then, just add nodes, to control say rendering, perhaps sound, and, it just works . . . Also, effects . . . If one tries a value, of say 8 m, from from one direction, and it doesn't work, just make it 9 m, or 10 m, until there's no sort-of clipping, etc . . .

It's much more intuitive, and, also faster, occlusion culling is the best, but it takes a ton, of time, esp. for a level, with many rooms . . . Maybe it isn't good enough yet, but, in theory it'd be simplified occlusion culling, much easier, for beginners . . . Once it works, never have to tweak it again, etc . . .

It could be a setting, under all 3D nodes, or, one could make some new nodes, to sort-of better organize it . . . Thx . . . . A special gizmo, for some DistanceCulling3D nodes, would make it, even easier . . .

[charlesmlamb]

For this room, it'd be a simple, distance, and angle, from center, of room . .

Having super - nodes, that calculate for other areas, or having vertical check, for several floors, say, is player at height + / - 0.5 m, from an entire floor, would also work . . . It would require a setting, to not just use camera, as occluder, but, some node, say the player . . .

One could add a setting, to check each room, say for 60 rooms, check one distance, or room, every second . . . It'd also be even faster, with group nodes . . No need to bake a new occlusion map, or coordinates . . . Add a new room, place it right way, the main goal was to make something simpler, bec. the new system, for occlusion culling, takes a ton of time . . It's also almost logical, esp. with a gizmo, that's easy to set up, not sure I have the best idea, maybe someone can think of the last details . . . There are a few situations, where it won't work, but, I don't think it'll impact performance that much, something like rooms, one can see at a great distance, spherical rooms, it'd take bit time . . . Easy, fast, and Godot I think tries to be very user-friendly, this is sort-of as simple, as it gets . . Have some new nodes, with special settings, then just make them parent node, of rooms, or areas . . . Having the ability, to make a square room, but also a round room, ie. a sphere gizmo, would make it the same, as occlusion culling, faster, and, easier to manage, sort-of, add a new room, tweak settings, and it works the same, not sure . . . Thx . . . Or, a cylinder, or, perhaps cone, I think it's the same, maybe, from every angle . . .

[mrjustaguy]

Yeah I don't really see the benefits of this over what already exists..

[charlesmlamb]

Well, for me, most beginners . . It'd be a quick way, no need to bake rooms, or, even set up portals . .

It'd also be 99 % as good, if set up correct, and be faster . . Anyway, not going to use occlusion culling, bec. it's too advanced . .

Also, mrjustaguy, if you could stop posting, on what I write . . You're mostly negative, and, seem to be the same, for other posts . .

In the end, I think this is better, bec. it's simpler, and, works for most cases . . . Also, faster, etc . . .

[mrjustaguy]

Well setting things to which distance you want to not render things already exists. see godotengine/godot#53778

However from what you've written here, most of what you want to do really isn't simpler compared to other methods available, both in terms of creation and quite possibly run time speed..

[charlesmlamb]

Sigh, how can doing a bunch of raycasts, to infinite distance, every frame, be faster than, a few if statements . .

I'd like this, bec. it's easier to understand for beginners, it's also more intuitive . .

One last thing, mrjustaguy, I would like you not to respond to what I write, I've seen you on some other proposals, and it's always negative, or, just rude . . .

Sigh, Godot is sort-of known, for it's user - friendly, and sometimes fast to learn features . . I think this is better, for what I currently understand Godot, to be about . . I don't see how this would be slower, instead of running a bunch of raycasts, not sure if it's 10 raycasts per frame, or 100, for occlusion culling . . . Then, this becomes cheaper fast, it's also easy to test, in wireframe mode . . Combined with frustrum culling, I think this might be as fast as occlusion culling, and make more sense . . . .

[charlesmlamb]

I'm asking bec. it's simpler, more user - friendly, also faster to set up . . .

Those are also consideration, for any feature . . .

I think, it'd be 80 %, maybe 90 % as good, as occlusion culling, when it comes to removing objects, and, even if it is a bit slower, more users will use it, bec. it's faster, and easier to make . . .

I also think it'd be easy to code, not bloat stuff, in terms of code, if it was made some special nodes, then, almost any - body could use it, get good results, and, that's why it's a good idea, well in theory . . .

Idea, maybe a simple dot product, or, cross product could calculate, when to occlude . .

If on one side, render town, then, if one that side, at certain distance to house, render what is inside . .

For isometric games, one only needs frustrum culling, guess it's be for first-person shooter, or, TPS . . .

I'm prob. not gonna use occlusion culling, bec. it takes too long to set up, also, a pain . . . I think this system, maybe better fits Godot, bec. it's user - friendly, takes a few days to learn, then, it works . . .

[charlesmlamb]

Last, the point here is, to sort - of think, are there other ways of culling, this is my idea, but, can one make a simpler system, that's really fast, in above image, one could also render some of houses, at one angle, the rest, at another angle . . And, one could sort-of scatter the if statements, over several frames, so it's only one if statement, or, a cross - product, every tenth frame, or etc . . . If one knows say movement speed of character, and only need to check every second, one can have a ton of these, at almost no cost . . .

[mrjustaguy]

Distance also doesn't cause something to be visible or not, I have no ideas where you get that idea from.
If I'm standing 10m away from a person, that doesn't mean that I cant see the person. I could also not see anything past a few mm away from me when I've got a blindfold on that's occluding everything.. see where I'm going?

Also explain this bit please

even if it is a bit slower, more users will use it, bec. it's faster, and easier to make . . .

On another note, how does a dot/cross product matter for checking the distance from something? I think I've lost you completely at this point.

In general try to be more concise about your proposals, as they're very hard to read.. Your flow of thinking is extremely difficult to follow as you're always adding unnecessary details or are just jumping from subtopic to subtopic or just plain going off topic and generally the structure isn't great.. You should try to answer the Proposal questions with as few words as possible while giving the most useful information possible.
I mean Here is you:

• So, i think it'd be cool if, eh you know in rooms when distance is 10m, we could make super fast, maybe behind a mountain . . . bla bla bla bla bla bla - (insert this type of writing for a good couple of paragraphs, you get the idea)

Here is what you wanted (if I understood correctly everything to this point and haven't lost anything while reading):

• I want to not render objects that are a given distance away from the camera to improve performance.

[charlesmlamb]

Dude, are you brain-dead . .

In the case of the mountain, for a FPS, one would only be able to see the village on one side, of the line . . On the other side, bec. the mountains would obscure the village, there's no need to render it, even if one looked at it, 'through' the mountains . . . That's what occlusion culling does, if I understand it . . .

Then, if one the right side, of the line, only then are the houses rendered . .

How is this not dirt-simple to understand, here's the last . .

You are insulting, demeaning, generally seem to be here to wreck good proposals, and, frankly scum-bag . .

Please stop responding to my posts, you're deliberately insulting me, or, being mean, or rude . . .

I may make dumb proposals, bec. I don't understand engines, or, what really makes sense . . But, I try to help, dumb as it may seem, what I have seen, whenever you post something, is insults, or rudeness . . I have reported you to gitHub, after seeing you do the same for other people's ideas, I don't mind feed-back, but, this is sadly trolling . . Please, stop writing on my proposals, you're not helping the engine, the other devs, or, even me . .

Then, when you lose the argument, you start blaming it on me, sure, I'm a noob, and, don't always know what I'm doing, ask stuff, that doesn't make sense . . . Read this, stop posting on my suggestions . . .

My idea still stands, this may not be as good as occlusion culling, or efficient . . But, it is user - friendly, and, if a person knows the node - based structure, this will be very easy, to learn, prob. take 2 - 3 days, then one can occlude many things, very easily . . . That's the advantage, that it's user - friendly, and will prob. lead to 80 - 90 % improvements, compared to occlusion culling . .

I can say I'm not gonna use occlusion culling, bec. it's a waste of time, and, takes too long to learn . . . It's too complex, takes too much time, in the current version . . .

I'm asking for this, bec. it's much simpler, and, easy, to get to work, etc . . It may not be as fast, but it can be optimized in many ways . . . Scatter the if statements, over 60 fps, then it's one if statement, every frame, so on . . .

I hope, you'll think about it, if you made this system, I'd use it, I also think most beginners would prefer it, over the occlusion culling system, that's a pain to make work, and, never really feels ' right ', based on gizmo estimates, how big should a portal be, guess-work . . . In this case, it's just some numbers, that does what you need, set an angle, and direction, to room . . Booom, just makes sense . .

In the end, occlusion culling also relies on math, every frame . . How can this not be cheaper, since this is the simplest math, you can possibly do, etc . . .

[mrjustaguy]

You are insulting, demeaning, generally seem to be here to wreck good proposals, and, frankly scum-bag . .

Please stop responding to my posts, you're deliberately insulting me, or, being mean, or rude . . .

My Intent is not to be insulting, my intent is to try to find holes in a Proposal before someone tries to implement it, as those holes can make the whole thing collapse and waste dev time needlessly or end up being bloat as it can already be done just fine as is.
If you're not fine with other people probing your proposals and adding their 2 cents, maybe this isn't the best place for you as this is what everyone does to everyone else here, that's kind of the point - To determine issues with the Proposal if there are any, and offer up potential corrections if possible and in general to just see if it's a feature that is of interest in the community for all of which the proposal also needs to be much clearer, which most of yours haven't been thus far, with like 1 exception.

[Zireael07]

@charlesmlamb You said @mrjustaguy is 'insulting' but then proceeded to call him 'brain-dead' in the last post. Sorry to say, but I find 'brain-dead' insulting even if it wasn't directed at me.

[charlesmlamb]

"with like 1 exception."

Blocked . .

This suggestion is so simple, I sadly feel it's being misinterpreted, just because . . .

I realize I make 'dumb' suggestions, and don't really know how to make an engine, or, what's even possible . . .

This is not the place to argue, it only gets in the way of suggestions being listened, and I feel this serves mrjustaguy . . .

What a clever way, to say ' f you ', blocked . .

[Zireael07]

@charlesmlamb: The way you presented this proposal (as well as many others) is, unfortunately, NOT simple.

[charlesmlamb]

Ok, thanks . . .

I don't really see the problem, but been lucky that many devs, have told me, when it was not good, or, not possible . . .

My opinion, occlusion culling is if word bit ' dirty ', it's too complex to solve the problem . . I think this idea is perhaps, better for Godot, and yes, I like the engine, and support it, where I possibly can . . .

Also, have almost started a video - game company, or, for 3D animation, and plan to use the engine, for many years . . .

The goal was, to ask devs, if there was a simpler way to get good object culling, not sure this is best, another idea, have each mesh, or object have a setting, to only render at a certain distance, sort-of a sphere . . Sort-of hoping, someone may have some better ideas, thanks . . . .

[charlesmlamb]

My bad, I checked Godot 4 early alpha, it has a setting called visibility range, that does this already . . . It takes a sphere distance, here . . . .

This will work for many use - cases, it'd be if one could set a box, instead, and, have it affect child - nodes, since many rooms are square . . Also, if the calculations could be set, to affect nodes, below, it'd be an easy to use system, etc . . .

Ok, it doesn't affect child nodes, guess what I'm asking is, that visibilty range has a new setting, affect child - nodes . . .

If one could set a box, and there was a gizmo, it'd be easy to see, sort-of how it works . . . It'd be almost as good, as occlusion culling, esp. if one could space the calculations, over say a second . . . I'd use that, almost 100 %, bec. occlusion culling takes too much time, to make work, etc . . .

Maybe, a setting, ' Inherit visibility ', or, not sure . . . Or, maybe ' toggle visibility of child nodes ' . . .

[charlesmlamb]

Ok, maybe call it ProximityOcclusion, or ContactOcclusion ?? Or, not sure ClosenessOcclusion, etc . . .

Make a special node, that makes nodes under it, in the tree, not visible . . .

I see it is complex, etc . . . Maybe someone could think about it, maybe not a gizmo, just some settings . .

Well, I'd use that over occlusion culling, bec. it's just faster, easier to set up, well, I see it is complex, maybe someone can make a nice version, that fits Godot, thx . . . !

ps. One could make a gizmo, that was not transparent, sort-of, maybe opaque . . .

Example, maybe if it was less transparent . .

Need, some pros to make it nice, see, what's possible, thx . . .

Maybe, if it was dark grey, and one could set one side, if on sort-of one side, don't render objects, but, if one other side, render, so if one clicked a toggle, maybe one side of the cube changed color, and, it checked that . . Almost same, as occlusion culling, take no time to set up, last, easy to change after it was done, not sure . . .

[lawnjelly]

Distance culling

Although I'm not sure your suggestion is super clear, you allude to culling by distance a few times, which can be useful in some cases, it's kind of similar to LOD, it's fairly easy to do in gdscript if you wanted to. Funnily enough I discussed this recently when looking at Wrought Flesh, putting a distance cutoff on VisibilityNotifiers / Enablers (this can prevent animation / processing as well as just rendering), as this is one of the bottlenecks in an open world. Just not got around to that yet.

Occlusion

Occlusion in general is one of those things that is much more difficult to do correctly than you would imagine. It has been actively researched for 50 years, and still there is no "solved" solution that works best in all scenarios. If there was one, we would all be using it.

Rooms & Portals

To dispel a misconception - rooms & portals isn't expensive at runtime. It's ludicrously cheap. In fact in PVS-only mode it is practically free (it is basically a lookup table). This is why it was the go to technique in the 90s / 2000s, because CPUs weren't capable of too many calculations. Quake, Unreal and many other games used these techniques. In fact GPUs in many cases weren't powerful enough to render high frame rate scenes without occlusion culling.

I'm fully aware that for many users building rooms can be daunting / time consuming for quick games, and this can be frustrating. They are primarily intended for higher end games, and procedural or kit bashing approaches.

Geometric Occluders

On the other hand I'm also working on some simpler geometric systems to give users plenty of tools until they move to Godot 4.

OccluderSpheres have been available since 3.4:
https://docs.godotengine.org/en/3.4/tutorials/3d/occluders.html

I'm currently working on Occluder polys, and generalized occluder meshes hopefully for 3.5:
https://twitter.com/lawnjelly/status/1485644075583877124

These aren't as powerful as rooms & portals (especially they only disable rendering, but cannot disable processing, and have no gameplay notifications), but are better than nothing at all, and they can work well in some situations where rooms & portals do not (they can also be used in combination with rooms).

Auto PVS

Additionally depending on time (way after 3.5), after geometric occluders is done I may also be able to have an experimental look at a very rough PVS system which uses ray casting to build a static database. The tricky bit of this is partitioning the world sensibly into cells (zones) automatically, and with stochastic ray casting there is always the chance to "miss" an object that should be visible. But it is possible something like a navmesh can be reused to create cells. And of course it takes time to do the pre-calculation, and the data has to be stored in a compact format. And this only works for static parts of levels.

Your scheme

If you want to round out your scheme you could maybe try it out in gdscript. It may not work fast, but such proof of concepts is how new features first appear.

[charlesmlamb]

Ok, I can easily code it, the problem is it's tedious for a big world, repeat code, also, can't code a gizmo, or, I'd have to make some box, I think I got it, that scales with the settings . . . I think there's some ' live preview ', of code . .

[Calinou]

Closing due to lack of support (see reactions on OP and general lack of activity here).