Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gridmaps do not render when using Rooms and Portals System #60833

Open
GDelavy opened this issue May 6, 2022 · 6 comments
Open

Gridmaps do not render when using Rooms and Portals System #60833

GDelavy opened this issue May 6, 2022 · 6 comments

Comments

@GDelavy
Copy link

GDelavy commented May 6, 2022

Godot version

3.4.2 stable official (45eaa2d)

System information

Windows 10, GLES 3, Nvidia Geforce 1660 Ti (30.0.14.7168)

Issue description

  • Gridmaps aren't rendered when placed inside of a Room node after calling the RoomManager's room_convert() function, because they do not inherit from CullingInstance. They remain thus invisible.

Steps to reproduce

  • Download and launch the project below.
  • Launch the World scene and notice that the white surface (gridmap) doesn't render.

Minimal reproduction project

Gridmap Culling.zip

@lawnjelly
Copy link
Member

lawnjelly commented May 6, 2022

Yes, that's a known limitation, gridmaps aren't currently supported (unless you can e.g. bake them out to regular nodes). We should probably make a note of this in the docs.

It probably could be made to work to an extent, but it would be nicer to be able to have portals / rooms etc as part of the gridmap (rather than the gridmap in a room), and that would be quite complex to get working.

@GDelavy
Copy link
Author

GDelavy commented May 6, 2022

Thank you for the quick reply,

Is there any way to tell the Portal / Rooms system to ignore gridmaps? Even if I put the gridmap node outside of my room node, it doesn't render.

Alternatively, I've tried using the Occluder node to surround my gridmap, but the only OccluderShape available seems to be spheres. Is there a way for me to add cubes or planes or convex shapes instead?

I apologize for the many questions, but my entire project relies on gridmaps and I really don't know what I'm going to do if I don't find a workaround

@Calinou
Copy link
Member

Calinou commented May 6, 2022

Alternatively, I've tried using the Occluder node to surround my gridmap, but the only OccluderShape available seems to be spheres. Is there a way for me to add cubes or planes or convex shapes instead?

3.5beta4 has occluder polygons available, so you can use it to represent quads, boxes and the like.

I apologize for the many questions, but my entire project relies on gridmaps and I really don't know what I'm going to do if I don't find a workaround

Since you're using GLES3, remember that the depth prepass is already significantly reducing the rendering cost of overdraw. Opaque pixels are only shaded once thanks to the depth prepass. While occlusion culling will help speed up this depth prepass, it probably won't give you a massive performance boost as it can in GLES2 (assuming the level design lends itself well to occlusion culling).

Therefore, it's probably not the end of the world if you can't use occlusion culling – especially if your level doesn't offer much opportunity for occlusion culling. Level of detail is likely a more viable approach in this case, and it'll show significant benefits in GLES3 too.

@GDelavy
Copy link
Author

GDelavy commented May 6, 2022

Thank you so much for all the help, I really appreciate all the work you do!

I'm going to look into implementing Lod and also experiment with 3.5beta4 to see if occluders make a significant difference. Thank you again!

@GDelavy GDelavy closed this as completed May 6, 2022
@Calinou
Copy link
Member

Calinou commented May 6, 2022

Reopening, as this limitation should still be documented.

@Calinou Calinou reopened this May 6, 2022
@lawnjelly
Copy link
Member

lawnjelly commented May 7, 2022

To elaborate a little - the problem stems because the gridmap is rather special - it completely overrides the scene tree, and does everything itself internally. Whereas the room conversion code is based on, and assumes, a scene tree structure. So gridmap would probably need custom conversion code written to traverse it during the room conversion, and additionally it has no machinery for setting the portal mode. There would likely be other problems as a result of it not being part of the scene tree. This is not trivial, it may represent weeks of work, and would require testing etc.

A far more practical approach would be to simply bake the gridmap into normal scene tree nodes containing meshes and multimeshes. The result could then be processed as normal during room conversion. I don't know whether this functionality exists already, or perhaps someone enthusiastic could write this. But this is not really a "portals" problem, it could probably be written by anyone who is familiar or who wants to get familiar with gridmap.

It is also possible that the gridmap objects might show up by changing their portal mode to global in the gridmap c++ code where it creates the instances. They would not be occlusion culled though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants