search

func-godot / func_godot_docs

Documentation for the FuncGodot plugin.
MIT License
4 stars 4 forks source link

Document runtime map building #4

Open RisingThumb opened 2 months ago

RisingThumb commented 2 months ago

Similar to how we mention alternatives to worldspawn, we should be mentioning that maps can be built at runtime.

The class reference for FuncGodotMap is incomplete here and doesn't list the methods that can be used and called. For this verify_and_build() is the necessary method. If there's other methods that should be used by people often we should be documenting them too(though looking through the class, I don't see any that jump out)

Additionally since it's a common pitfall with runtime building, some mention about exporting the .map files should probably be made.

RhapsodyInGeek commented 2 months ago

I agree there should be a chapter of the manual that goes over runtime building. I hadn't included it when I made the manual mostly because I hadn't tested or even really experimented with the feature, and in wanting an accurate manual I didn't want to include "theoretical" features in it.

Now that sinewave has pretty much given us the proofs of concept it's definitely something worth figuring out the minimal path of least resistance that enables runtime building, and if an easy way doesn't exist then solving how we can make an easy way.

sinewavey commented 2 months ago

Worth considering that as maps get larger and larger, it's going to potentially be worse and worse.

An additional downside is currently the inability to bake lightmaps for these - see this issue in the Godot repo here: https://github.com/godotengine/godot-proposals/issues/8656

That said, it's still a realllllly useful tool for map makers, small games, or perhaps a totally new use of the format, like chunks that use data built in .map files - like prefabs. I have yet to explore the other ideas beyond some debugging tools.

Ultimately I think the feature should stay, but perhaps with some clarification about intent even and with these caveats in mind.

RhapsodyInGeek commented 2 months ago

I mean that's pretty much just an occupational hazard of runtime building and is the responsibility of the user. And the inability to bake Lightmap GI just means you'll want to figure out a Voxel GI or SSDFGI (?) solution. It's something definitely worth documenting but doesn't mean we can't find an easy path forward for runtime build support. The hard work is just us figuring it out so others don't have to.

The feature was always planned to be in there, we just didn't know if it worked or how to make it work. We were more focused on making sure the plugin could work at all. So there are no plans to inhibit or remove it; if anything I want to make it easier.

RisingThumb commented 2 months ago

An additional downside is currently the inability to bake lightmaps for these - see this issue in the Godot repo here: https://github.com/godotengine/godot-proposals/issues/8656

This currently applies to all things that can only be baked in-editor and have no node-related function exposing it. Also applies to particle baking emission points(https://github.com/godotengine/godot-proposals/issues/8106) and other things that could be baked. Similarly navmeshes also need to be baked(iirc?)- so this is just a wider topic that people should consider what they need to do post-build

sinewavey commented 2 months ago

I mean that's pretty much just an occupational hazard of runtime building and is the responsibility of the user. And the inability to bake Lightmap GI just means you'll want to figure out a Voxel GI or SSDFGI (?) solution. It's something definitely worth documenting but doesn't mean we can't find an easy path forward for runtime build support. The hard work is just us figuring it out so others don't have to.

100% agreed here: mention the potential concerns but that's about it. I think of Jolt's documentation and how it warna about a few options having particular caveats, like areas detecting static bodies.