Relintai/godot-lportal
1
0
Fork 0
mirror of https://github.com/Relintai/godot-lportal.git synced 2024-11-11 10:52:09 +01:00
Code Issues Packages Projects Releases Wiki Activity

Update README.md

Browse Source
This commit is contained in:
lawnjelly 2019-10-14 15:43:12 +01:00 committed by GitHub
parent 8eb796919d
commit 7604a5ec04
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 7 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
README.md
View File

@ -13,16 +13,13 @@ https://www.youtube.com/watch?v=NmlWkkhGoJA
_Feel free to leave suggestions / feature requests on the issue tracker, especially regarding ease of use._
## Current status
The basic system is mostly working. I am now testing / polishing the interface and adding debugging. I will leave PVS and closable portals until after the first release.
I am currently diverted from the main work on LPortal, trying to get some kind of lightmapping working in Godot for a demo. It turns out the current lightmap workflow is quite broken. I've spent several days trying to work around bugs in the version of xatlas godot is using, but with no luck, so I'm now going to resort to exporting a mesh from godot, unwrapping in blender, then reimporting back into godot.
I am now working on shadows. Shadows can be cast by objects that are not 'in view', thus with the naive culling system, in some circumstances shadows will pop into and out of view.
This means a slightly more complex workflow, but it does potentially allow baking lightmaps in blender which should lead to a nicer result. The downside is that I won't have a bake for dynamic shadowing as objects move through the level.
There are three possibilities here:
1) Draw everything in the shadow pass (use Godot default octree). This gets rid of artefacts but would be slow and negate a lot of the benefits of visibility culling.
2) Draw everything roughly around the visible objects. The current version does this now, with the main pass only rendering objects in view, but the shadow pass draws everything within the rooms in view. This is better than naive version, but still can suffer 'popping' of shadows at doorways.
3) More intelligent system to try and work out which shadow casters are relevant to the view.
It may seem strange to be spending so long getting a demo working, but getting a usable workflow is imperative both for testing, and for tutorials.
Note that I've had to move from showing and hiding objects, to using Godot object and camera layers to differentiate between which objects to render from the camera and which for shadows, at least for now. This is a little hacky, and might interfere with your own code if you are using godot layers - layer 1 (default layer) is unset for all objects, and 19 and 20 are currently used by the system to toggle visibility internally.
The standard non-baked dynamic lighting workflow is mostly working (if not perfectly optimized), and that may be preferable for most people on desktop, but it is my intention to create a highly optimized system that will run very fast on mobiles as well, allowing fast action 1st person shooters etc.
## Roadmap
* Auto conversion of named room spatials and portal mesh instances to LRoom and LPortal DONE
@ -37,11 +34,12 @@ Note that I've had to move from showing and hiding objects, to using Godot objec
* Optional convex hull bound for rooms DONE
* Add debug graphical view of portal planes DONE
* Add debug graphical view of room bounds DONE
* Dealing with shadows from objects outside of view
* Dealing with shadows from objects outside of view PARTIALLY DONE
* Building baked lightmap workflow ONGOING
* Bug fixing / testing ONGOING
* Shadow caster optimization
* Closable portals
* PVS (primary and secondary)
* Investigate multiple passes (shadows, lights)
## Instructions
See [INSTRUCTIONS.md](INSTRUCTIONS.md) and [TUTORIAL.md](TUTORIAL.md)