Automap (indoor & dungeon) implementation

[Nystul]

haha thanks!
would like to make doors appear in the automap.
this is bit of a problem since just creating doors with RDBLayout.AddActionDoors() creates a second copy (which is needed for the custom shader).
but door states of this copy do not match with doors inside "Dungeon" gameobject.

Same goes for action models.
It is connected to a bug where the player sometimes can go through invisible geometry.
I think this problem is coming from action models not matching with the state of the models in "Dungeon" gameobject (e.g. platform is activated and moving down but player is not going down on platform but stands on invisible 2nd platform - although this might be solved by specifying layers for hit tests for player).

update:
hmm vanilla daggerfall doesn't show the doors as well - so maybe I will skip that feature for now...
still have to solve the platform issue

[Interkarma]

It is connected to a bug where the player sometimes can go through invisible geometry.
I think this problem is coming from action models not matching with the state of the models in "Dungeon" gameobject (e.g. platform is activated and moving down but player is not going down on platform but stands on invisible 2nd platform - although this might be solved by specifying layers for hit tests for player).

I haven't seen that bug, or heard of it before now. The physical simulation is all handled by Unity (i.e. PhysX) and it's generally pretty solid. Any chance you could send me a save game somewhere I can reproduce?

[Nystul]

It is connected to a bug where the player sometimes can go through invisible geometry.
I think this problem is coming from action models not matching with the state of the models in "Dungeon" gameobject (e.g. platform is activated and moving down but player is not going down on platform but stands on invisible 2nd platform - although this might be solved by specifying layers for hit tests for player).

I haven't seen that bug, or heard of it before now. The physical simulation is all handled by Unity (i.e. PhysX) and it's generally pretty solid. Any chance you could send me a save game somewhere I can reproduce?

no the bug is not in your code or unity. It is caused by my additions. what i mean is this:
lets say there is a moving platform
It will be somewhere in gameobject "Dungeon" and there also its state (position) will be stored.
my automap geometry (in a gameobject say "Automap") is independent of the geometry in gameobject "Dungeon". So the platform is in there a second time.
if the player clicks the associated lever the platform (in "Dungeon") will move and its collider with it.
the platform in my automap gameobject is not affected and will stay together with its collider.
player is checked agains both colliders and so won't be moving with the platform

solition would be to only enable colliders of my geometry just before raycasting and disabling it afterwards. but I would have prefered not to have to traverse through the hierarchy of all objects inside gameobject Automap - nevermind will try to implement this

update: found an easy solution for the moment. I only activate the geometry gameobject before raycasting and deactivate it afterwards - not sure if this will work when we might have an automap window that can remain opened while moving around in the game, but this is not a core feature anyway

[Nystul]

Pull request is coming nearer as my todo list is getting shorter.

I would like to hear your opinion about 2 things:
(1) I would like to change the behavior of vanilla daggerfall's automap which is shifting rotation pivot axis besides moving the level geometry when clicking left/right/up/down buttons in the automap window.
I would like to change it so that the buttons only move the level geometry.

(2) vanilla daggerfall moves the level geometry when clicking left/right/up/down buttons, but a different approach would be to move the camera (which will be the same as moving the geometry in the opposite direction)...

What do you think? keep it as it is? change it? change (1) and keep (2) as it is?

[Interkarma]

Pull request is coming nearer as my todo list is getting shorter.

I would like to hear your opinion about 2 things:
(1) I would like to change the behavior of vanilla daggerfall's automap which is shifting rotation pivot axis besides moving the level geometry when clicking left/right/up/down buttons in the automap window.
I would like to change it so that the buttons only move the level geometry.

(2) vanilla daggerfall moves the level geometry when clicking left/right/up/down buttons, but a different approach would be to move the camera (which will be the same as moving the geometry in the opposite direction)...

What do you think? keep it as it is? change it? change (1) and keep (2) as it is?

I'm happy for you to make these changes as you think best. We can always tune up later based on feedback. I think the interior map is one of the most underused and disliked UI elements in Daggerfall, so any improvements are most likely going to be welcomed by everyone. After a few iterations, I can see this changing to be one of the more useful tools in the dungeon crawler's arsenal.

[LypyL]

Some thoughts after testing the latest version for a while:

1. Changing the color of already explored dungeons is a great idea! I think it would work better if as you traveled through already explored sections they changed back to normal color, so you can see your current path through the already explored dungeon.

2. The beacons seem to disappear from the map sporadically.

3. I had issues with the player controller being disabled at random. I'm not sure if it's even necessary to disable the player colliders? I commented out the relevant code in CheckForNewlyDiscoveredMeshes() and didn't notice any difference.

4. The raycasts are a little narrow. For example, you can look down a hallway and not have it show up on the map.

[Nystul]

1. Changing the color of already explored dungeons is a great idea! I think it would work better if as you traveled through already explored sections they changed back to normal color, so you can see your current path through the already explored dungeon.

hmm it should work like this - seems to be a bug then
update: this bug is an aftereffect of a nullpointer exception for the Debug.Log messages in function scanWithRaycastInDirectionAndUpdateMeshesAndMaterials() -> a nullpointerexception can happen in there - if it does the coroutine stops working - comment out the Debug.Log messages or check for null pointer of the variables they use -> will fix this in next push

2. The beacons seem to disappear from the map sporadically.

this is for sure coming from the coroutine which checks newly discovered geometry - see point 3 which is about the same issue. for the beacons it is easy to change this, since they don't have colliders anyway - so I will just remove the lines in the coroutine where they are disabled (was actually a left-over obviously) ... point3 is more problematic though...

3. I had issues with the player controller being disabled at random. I'm not sure if it's even necessary to disable the player colliders? I commented out the relevant code in CheckForNewlyDiscoveredMeshes() and didn't notice any difference.

I feared that this would happen... recent change... unfortunately the player colliders fuck up the raycasts for geometry discovery - hmm I fear we need a separate layer for default geometry different then other stuff like player, monsters, etc...

more details on the problem:
I do 2 passes when raycasting - one for geometry in "default" and one for "Automap" layer. I use this to detect doors (doors are not present in automap geometry - but I don't want geometry behind closed doors to be discovered - so i do the raycast for "default" layer, afterwards for automap layer and compare the two passes. If they match (in terms of ray distance) no doors and other obstacles from default layer were in the way -> so discovery is successful.
the raycast down to the ground hits the colliders from the playeradvanced gameobject, since they are in default. I hoped to circumvent this by disabling them just for the raycasting. Unfortunately the coroutine may take place at times that result in other problems - since it seems to be happening in parallel in a own thread. So we need to find a different way to prevent rays hit the player colliders - using a separate layer would do the trick, but I don't know the impacts to the core - so we may need Interkarmas help do you have an idea, lypyl?

update2:
I tried to move the playeradvanced gameobject temporarily into different layer than "Default" for the time of the raycasts and it works much better than disabling the gameobject

4. The raycasts are a little narrow. For example, you can look down a hallway and not have it show up on the map.

yeah definitely needs some finetuning then. didn't want to make it too easy to discover everything...


update3:
pushed the changes to git. Could you try it and report back please?

@interkarma: what would be your preferred way to get my pull-request? shall I make a pull-request into you work-in-progress branch. Or would a separate branch like the travel map branch be the way to go? if yes, will you have to create this branch - or is there a way to make a pull-request and "request" a new branch somehow?
I am just curious, but first I will wait for your feedback and bug reports before I initiate the pull request anyway

[Interkarma]

One of my goals for DFTFU and Daggerfall Unity is to require as little project setup as possible. I want it so developers can just import the .asset into Personal or Pro then open a scene and go. This obviously isn't possible in all cases (such as far terrain and enhanced sky, and creating good builds), but I do want it to be true of the core library and game scripts. This not only makes it easy for Unity newcomers, but few project settings means we don't need to distribute a project, which in turn avoids sticky problems between Unity Personal and Unity Pro. Basically, I want to avoid specialized project settings wherever possible.

If you find things getting to the point where you need deep changes to core and project settings just to support a UI screen, then it might be time to step back for a second and think about whether the approach can be improved on.

Raycasts are an easy place to start but they will hit items you don't want them to. One solution here is to use RaycastAll and ignore the objects you don't want to evaluate (I use this approach in PlayerActivate). The bigger problem is that rays are best at detecting convex objects like enemies or the outside of a building. They're not so great at detecting empty space like where you are inside that building, which is the problem you're trying to solve.

My approach would be to use an oct tree or similar. This obviates the need to use the physics system at all and turns the whole problem into a spatial search. You wouldn't necessarily need to write this from scratch either, as Unity has a working scene graph you can leverage to begin with. You just need to iterate over game objects and perform renderer.Bounds.Contains(playerPoint). You can then choose what level of the graph you want to pop out and consider that branch "discovered". A specialized graph and layout for interior maps would be far superior though and provide for specialized functionality.

The good news is we're all here to help each other and offer advice so we can get the job done. We'll just keep bouncing around ideas and iterating until it all comes together. And don't kill yourself doing this stuff. I will be ready when it's ready.

[Interkarma]

@interkarma: what would be your preferred way to get my pull-request? shall I make a pull-request into you work-in-progress branch. Or would a separate branch like the travel map branch be the way to go? if yes, will you have to create this branch - or is there a way to make a pull-request and "request" a new branch somehow?
I am just curious, but first I will wait for your feedback and bug reports before I initiate the pull request anyway

I'll make a matching branch for it and we can pull to that for now.

[LypyL]

The color seems to be updating properly now. Also didn't have any problems with beacons / marker disappearing.

I feared that this would happen... recent change... unfortunately the player colliders fuck up the raycasts for geometry discovery - hmm I fear we need a separate layer for default geometry different then other stuff like player, monsters, etc...

more details on the problem:
I do 2 passes when raycasting - one for geometry in "default" and one for "Automap" layer. I use this to detect doors (doors are not present in automap geometry - but I don't want geometry behind closed doors to be discovered - so i do the raycast for "default" layer, afterwards for automap layer and compare the two passes. If they match (in terms of ray distance) no doors and other obstacles from default layer were in the way -> so discovery is successful.
the raycast down to the ground hits the colliders from the playeradvanced gameobject, since they are in default. I hoped to circumvent this by disabling them just for the raycasting. Unfortunately the coroutine may take place at times that result in other problems - since it seems to be happening in parallel in a own thread. So we need to find a different way to prevent rays hit the player colliders - using a separate layer would do the trick, but I don't know the impacts to the core - so we may need Interkarmas help do you have an idea, lypyl?

update2:
I tried to move the playeradvanced gameobject temporarily into different layer than "Default" for the time of the raycasts and it works much better than disabling the gameobject

I think using layers would definitely be better than how it is currently. Keep in mind that the player needs to be hit by ray casts for other stuff like monster attacks etc.

Have you also considered checking a sphere around the player for close objects (maybe like the radius of an average sized hallway)? You could do raycasting for far away stuff where the player is looking, and check a sphere close by the player.

edit: Or just do what interkarma suggested