Recommendations for mapping?

[Yue]

I am creating a level with the brushes, however I am encountering certain drawbacks, such as the camera turning in another direction, walls and entities suddenly appearing. It is as if they were not there, and with the turning of the camera the process is visualized when they begin to be drawn on the stage.

Any recommendation to implement a correct level mapping?

Thank you.

[reepblue]

This is the occlusion culling working and the renderer not keeping up. I've fought with this for my years and figured out that disabling vsync by default and capping the framerate above 100fps reduces the effect a lot. This will keep the app at a consistent rate while reducing the culling effects  I use 120hz as my target framerate.

context:Sync(false, 120)

 

[Josh]

This happens on slower graphics cards. I wouldn't worry about it, I see the same thing in any game that uses hardware occlusion culling. I definitely would not change your game style.

[Yue]

I should add something, this does not happen in the editor as such. It only happens when I run the game in development mode. Possibly it is because I am running the editor and the game instance as such.

So possibly the problem is solved when I launch the game standalone without the editor.

I am using a GTX 1050ti

[Josh]

The editor does not use occlusion culling because it is an event-driven application.

[Yue]

I remain concerned. It turns out that in the Leadwerks example in the first person shooter game, this does not happen. In my level, with brushes only, the flaw is more than obvious, so I think I'm missing something.

[Yue]

[Josh]

That's because my FPS example doesn't use a skybox and the camera clear mode is set to only clear the depth buffer.

[Yue]

15 minutes ago, Josh said:

That's because my FPS example doesn't use a skybox and the camera clear mode is set to only clear the depth buffer.

Hey, the question is: How do I do the buffering, what is the command, I am looking at the fps player file but I don't see anything. I only found this.

 

[Josh]

Actually, I am not sure I did anything with the clear mode, but a bright skybox will definitely be more visible than just a black background in an already dark level.

[Yue]

This is a mystery, it continues to work correctly even if I put a skybox. I don't know what is going on.

 

[Yue]

42 minutes ago, Josh said:

Actually, I am not sure I did anything with the clear mode, but a bright skybox will definitely be more visible than just a black background in an already dark level.

I have managed to reproduce the error at the example level, this is a lot of perseverance to solve something. The error is evidently with the skybox that is implemented in the level. However it strikes me the intention that it is only reproduced in this one place. That is to say the rest of the map does not present this error.

So what I see in this and is that the corridors should not be so closed, it's just what I can think of at the moment.

Translated with www.DeepL.com/Translator (free version)

 

[reepblue]

The brush culling is less noticeable with a black clear buffer (This is set up as the default) with the frame rate above 90. Your CSG gets collapsed into multiple models, but in most cases half of your one room will be it's own slice. There hasn't been any clarification how the engine determines how to cut up the CSG.

Another option is to model your indoor level into sections so you can control how your indoor levels cull. This is a big pain since the main reason I switched to Leadwerks was due to it's editor and the obj export doesn't export the uvs. I haven't found any blender plugins that mimics the texturing features like in Leadwerks. 

I would not worry about it until your art pass in which you would be in a better place to mesh your level off the CSG if it really bothers you that much. My game however needs the collapsed CSG for the mechanics to work.

[Yue]

I think I am going the way of many in the aspect of creating a map with Leadwerks. 

One thing I have noticed is that if I use very small chunks for walls, like a lego, in the graphical aspect the Occlusion culling system is much more evident

when I rotate the camera. So possibly the solution is to create with bigger joke elements for a corridor and avoid small parts.

 

 

[reepblue]

4 hours ago, ЖYueЖ said:

One thing I have noticed is that if I use very small chunks for walls, like a lego, in the graphical aspect the Occlusion culling system is much more evident

Right. This is why I suggest making entire rooms models if you can. The entire room will not get culled because you'll be always looking at it.

[Josh]

I think you are paying way too much attention to a detail that does not matter. I see this effect happening in AAA games, and like I said, it's due to your old graphics card and the average user isn't going to have the same problem.

[reepblue]

Tbh, I fund the culling of lights to be more annoying especially if you are using point lights to light entire rooms.

[Yue]

17 hours ago, Josh said:

I think you are paying way too much attention to a detail that does not matter. I see this effect happening in AAA games, and like I said, it's due to your old graphics card and the average user isn't going to have the same problem.

Well, Josh you are right, in the absence of knowledge I tend to get obsessed with some things.  But I'm reassured that you mention that. So on any user's computer with a more powerful computer that won't be so obvious. But what does have me thinking is that in the leadwerks example that doesn't happen, so I'm starting from optimizing this. But you are absolutely right. 

[reepblue]

I recall you being on a 1050ti and I also use that card for my development machine and I think it only has 2GB if VRAM. 

Yeah, a better card means it can do more things at once, but if your game is capped at 60hz, other engine is only going to go that fast. Due to how the renderer is set up, things will cull based on the speed of the app. Again, I would just set vsync off by default and put a higher frame rate as the second parameter in your sync call so the game will not fluctuate in speed too much. If you do 120fps and the game goes to 90fps; you'll barely notice it compared to 300 to 90. 

[Josh]

It's not only the framerate, but the time the GPU takes to return data to the CPU. The CPU does not wait for the GPU to complete the task, but how long it takes for that data to become available is independent from framerate and I would guess is highly variable across hardware.

[Yue]

Well, I found the solution to my nightmare. I just have to disable occlusion culling in the camera. And that solved it

Culling false

 

Culling True

 

Culling False

 

 

 

 

[reepblue]

While it does fix this dreaded issue, I'm noticing a performance penalty in debug mode. I have it as a console variable and I'll continue to experiment with it. I didn't really care about the brushes as much as I did with the point lights.

I think setting this to false on the camera is just omitting all OC functionality which is causing the application to run slower.

[Yue]

I would have to deal with this in some other way. For example manage the performance with the drawing spacing of the brushes and meshes, as well as the lights.  And play with a level in the form of corridors in different directions, because equally what you put behind the camera is not rendered. 

That is to say, the optimization would have to be done manually. 

[reepblue]

With C++ I tried disabling occlusion culling for the collapse brushes and it didn't do anything. For lights I'm thinking adding Draw hook functions for every point light that has a radius greater than 5. It'll check if the camera's position is in it's AABB and temporarily disable OC mode if the point intersects and re-enable it if the camera is out of it's bounds. I'll have to see if it's worth it. 

You're playing with fire when it comes to this stuff this is why Josh recommends you just leave everything as default.

[Yue]

 

It seems that this option does not work for brushes. For mesh entities, if it works properly next to the lights.