-
-
Notifications
You must be signed in to change notification settings - Fork 21.3k
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
Web: Disable raycast module by default (no occlusion culling) #81716
Web: Disable raycast module by default (no occlusion culling) #81716
Conversation
The CPU lightmapper hasn't been reimplemented in 4.x yet, but we don't know if we'll keep Embree when it's ported anyway. (It also isn't available in exported projects, so it would only be usable in the web editor – and it would be slow due to WebAssembly overhead.)
Probably in these classes' descriptions:
And in these properties:
I can open a separate PR on godot-docs for https://docs.godotengine.org/en/latest/tutorials/3d/occlusion_culling.html. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I approve I approve I approve.
Most people exporting for web won't even know about the raycast module anyways, and this has been a compatibility issue with Webkit/iOS for a while now!
Pending the docs change, of course, but it looks like Calinou has already brought attention to that. It'd be good to put a notice in there for the person who comes by every so often who would need to know this.
811203d
to
35e6363
Compare
This means no CPU occlusion culling (and not compiling Embree), unless you compile custom export templates with `module_raycast_enabled=yes`. This reduces the memory footprint significantly, and binary size. Fixes godotengine#70621. Co-authored-by: Hugo Locurcio <hugo.locurcio@hugo.pro>
35e6363
to
8c40edf
Compare
Thanks @Calinou, added docs. I didn't put the note in Occluder3D and Viewport to avoid being too redundant, as both places refer to the other class or property for more details already. |
We use raycasts for importing meshes with LODs. We need to check that this change does not break mesh importing |
How feasible is importing meshes with LOD on web editor? |
It is technically feasible, but you probably don't want to work on a project with highly complex meshes in the web editor anyway. |
In my opinion, the limitation should be clarified in documentation. I don't know if there is a section about using the web editor, but clarifying that would be helpful. Other than that, I do think this change is for the better. |
I've tested importing a gltf scene into the godot web editor on this PR. Sample model: It imported successfully: (ignore the watermark, had to compress the video) cube-rotate_be9MIAJl.mp4Let me know if any more testing is required! |
Follow-up: The detail does in fact change on web with this PR! I say we move forward with this :) EDIT: Better quality images |
Thanks @ryanabx for confirming that compiling out RayCast won't break our LOD import logic! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like a good change. If there is demand, we can add a slim StaticRayCast fallback implementation for memory constrained systems.
Cherry-picked for 4.1.2. |
This means no CPU occlusion culling (and not compiling Embree), unless you compile custom export templates with
module_raycast_enabled=yes
.This reduces the memory footprint significantly, and binary size.
Fixes #70621.
@Calinou I'm not too familiar with the occlusion culling and lightmap documentation, could you tell me where to add some notes that this is not supported in default Web templates?