Automap (indoor & dungeon) implementation

Discuss Daggerfall Unity and Daggerfall Tools for Unity.
User avatar
mikeprichard
Posts: 679
Joined: Sun Feb 19, 2017 6:49 pm

Re: Automap (indoor & dungeon) implementation

Post by mikeprichard » Wed Jun 05, 2019 8:18 pm

Ah, right - didn't remember PH being quite that messy.

BansheeXYZ
Posts: 469
Joined: Fri Oct 23, 2015 8:19 pm

Re: Automap (indoor & dungeon) implementation

Post by BansheeXYZ » Wed Jun 05, 2019 11:59 pm

Nystul wrote:
Wed Jun 05, 2019 6:16 pm
update: I tried out a quick shader hack to hide all walls by face normal test:
That's MUCH better, but as I expected, without replacing the textures with a color (shaded-per-dungeon-layer), and without outlines, there is still the problem of floors kind of blending in with those behind them, like the one on the righthand side. Outlines serve another purpose, which is to indicate a wall vs an unexplored path. This was another problem with dfall's overhead mode: once the walls disappeared you couldn't see unexplored paths anymore unless it was a doorway. So while showing walls isn't important, indicating them is. And of course, a black outline isn't going to be easily seen against those dark brown floor textures, so I imagine replacing floors with tan or bright purple or something would be interesting to see.

User avatar
Nystul
Posts: 1352
Joined: Mon Mar 23, 2015 8:31 am

Re: Automap (indoor & dungeon) implementation

Post by Nystul » Thu Jun 06, 2019 7:16 am

BansheeXYZ wrote:
Wed Jun 05, 2019 11:59 pm
Nystul wrote:
Wed Jun 05, 2019 6:16 pm
update: I tried out a quick shader hack to hide all walls by face normal test:
That's MUCH better, but as I expected, without replacing the textures with a color (shaded-per-dungeon-layer), and without outlines, there is still the problem of floors kind of blending in with those behind them, like the one on the righthand side. Outlines serve another purpose, which is to indicate a wall vs an unexplored path. This was another problem with dfall's overhead mode: once the walls disappeared you couldn't see unexplored paths anymore unless it was a doorway. So while showing walls isn't important, indicating them is. And of course, a black outline isn't going to be easily seen against those dark brown floor textures, so I imagine replacing floors with tan or bright purple or something would be interesting to see.
I also tried a hack to shade geometry just in a single color representing the main texture, but I am not too convinced. It actually looks better on the screenshot as it feels ingame :/ and even outlines won't solve this in my opinion but I would be happy if I am wrong and someone can pull off a better automap shader ;)

Image

update: a combination of wall hide above slice level, single color shading and transparency looks promising:

Image

or both single color shading and wall hide above slice level:

Image

BansheeXYZ
Posts: 469
Joined: Fri Oct 23, 2015 8:19 pm

Re: Automap (indoor & dungeon) implementation

Post by BansheeXYZ » Thu Jun 06, 2019 8:11 am

Well, you got it to the point that I could make a quick n dirty photoshop of what I had in mind, although there's no way for me to put lines down only where there are walls, so there is lots of wrong linework and coloring here. But yeah, each layer having its own shade gives a superior sense of depth. Instead of the mishmash of textures where a floor on level 7 is the same as a floor on lvl 3 and 1.
dfmp.png
dfmp.png (121.64 KiB) Viewed 412 times

User avatar
TheLacus
Posts: 879
Joined: Wed Sep 14, 2016 6:22 pm
Contact:

Re: Automap (indoor & dungeon) implementation

Post by TheLacus » Thu Jun 06, 2019 11:55 am

Nystul, the Handpainted model replacement mod causes a lot of errors to be thrown inside buildings:

Code: Select all

Material doesn't have a texture property '_BumpMap'
UnityEngine.Material:GetTexture(String)
DaggerfallWorkshop.Game.Automap:updateMaterialsOfMeshRenderer(MeshRenderer, Boolean) (at Assets/Scripts/Game/Automap.cs:888)
DaggerfallWorkshop.Game.Automap:injectMeshAndMaterialProperties(Boolean) (at Assets/Scripts/Game/Automap.cs:934)
DaggerfallWorkshop.Game.Automap:createIndoorGeometryForAutomap(StaticDoor) (at Assets/Scripts/Game/Automap.cs:1168)
DaggerfallWorkshop.Game.Automap:InitWhenInInteriorOrDungeon(Nullable`1, Boolean) (at Assets/Scripts/Game/Automap.cs:1679)
DaggerfallWorkshop.Game.Automap:OnTransitionToInterior(TransitionEventArgs) (at Assets/Scripts/Game/Automap.cs:1701)
DaggerfallWorkshop.Game.PlayerEnterExit:RaiseOnTransitionInteriorEvent(StaticDoor, DaggerfallInterior) (at Assets/Scripts/Game/PlayerEnterExit.cs:1352)
DaggerfallWorkshop.Game.PlayerEnterExit:TransitionInterior(Transform, StaticDoor, Boolean, Boolean) (at Assets/Scripts/Game/PlayerEnterExit.cs:745)
DaggerfallWorkshop.Game.PlayerEnterExit:StartBuildingInterior(DFLocation, StaticDoor, Boolean) (at Assets/Scripts/Game/PlayerEnterExit.cs:960)
DaggerfallWorkshop.Game.<Respawner>c__Iterator0:MoveNext() (at Assets/Scripts/Game/PlayerEnterExit.cs:498)
I believe this happens because the mod doesn't use the standard shader. You may want to check a property with Material.HasProperty before accessing it; also note there is a class named Uniforms inside DaggerfallWorkshop namespace which holds ids for shader properties, which is a faster way to access them than string names.

Code: Select all

if (material.HasProperty(Uniforms.MainTex))
    newMaterial.SetTexture(Uniforms.MainTex, material.GetTexture(Uniforms.MainTex));
If you are interested in creating mods for Daggerfall Unity you can find the documentation here.

User avatar
Nystul
Posts: 1352
Joined: Mon Mar 23, 2015 8:31 am

Re: Automap (indoor & dungeon) implementation

Post by Nystul » Thu Jun 06, 2019 12:27 pm

This raises the question why does a mod "patch" materials/shaders of geometry that are created on purpose just for the automap.
This geometry should not be changed by a mod imo - why does it happen?

User avatar
TheLacus
Posts: 879
Joined: Wed Sep 14, 2016 6:22 pm
Contact:

Re: Automap (indoor & dungeon) implementation

Post by TheLacus » Thu Jun 06, 2019 12:47 pm

Nystul wrote:
Thu Jun 06, 2019 12:27 pm
This raises the question why does a mod "patch" materials/shaders of geometry that are created on purpose just for the automap.
This geometry should not be changed by a mod imo - why does it happen?
I don't think the mod changes the automap directly. I'm not sure how the automap works, but I believe it recreates objects from the real scene, which can include custom models. I think this is a good thing, but it should check that a texture is defined before accessing it. :)

2019.06.06-14.40.png
2019.06.06-14.40.png (1.29 MiB) Viewed 384 times
If you are interested in creating mods for Daggerfall Unity you can find the documentation here.

User avatar
Nystul
Posts: 1352
Joined: Mon Mar 23, 2015 8:31 am

Re: Automap (indoor & dungeon) implementation

Post by Nystul » Thu Jun 06, 2019 1:34 pm

it uses DaggerfallInterior.DoLayoutAutomap function to create its geometry which then calls AddModels() which then creates all the geometry with corresponding functions, e.g. MeshReader.GetModelData
but I understand now what the problem is - the Material can be changed by the mod override mechanism -
I think your suggestion how to change the code should work - will fix this - thank you

btw, your screenshot showing the exit marker in the wrong position will also be fixed with next pull request (coming soon)

User avatar
Nystul
Posts: 1352
Joined: Mon Mar 23, 2015 8:31 am

Re: Automap (indoor & dungeon) implementation

Post by Nystul » Fri Jun 07, 2019 1:53 pm

mikeprichard wrote:
Wed Jun 05, 2019 5:45 pm
Nystul wrote:
Fri May 31, 2019 8:36 pm
BansheeXYZ wrote:
Fri May 31, 2019 2:14 pm


I know that. It resets every time I open the map anyway, so I'd be constantly doing that before rotating the map.
I could implement an ini setting that when enabled would remember the last setting if that helps - or that the map will open with the slice level being maxed out (also if corresponding ini setting is enabled)
I also second (third) these improvements. I'd even suggest remembering the last map display setting as the default instead of needing to fiddle with the .ini to achieve it.
3D view will be default view in the future

regarding automap remembering slice level:
this is a bit tricky, as we have to decide between two possible implementations:
  • absolut slice level being remembered (which will result in problems when player will move upwards after using automap and then opening it again - geometry will be sliced at the lower level from before making the player marker float in the air and the geometry sliced below) - making a manual adjustment of slice level necessary in such case
  • relative offset of slice level to player marker being remembered - not suffering from the above issue but as a consequence absolute slice level will change when player moves up/down
I would implement second variant (via ini setting) if that's ok

Furthermore there will be an ini setting for always maxing out slice level (so no geometry is transparent ever)

both options are a temporary workaround until we have a better map rendering that would make those things obsolete

User avatar
Nystul
Posts: 1352
Joined: Mon Mar 23, 2015 8:31 am

Re: Automap (indoor & dungeon) implementation

Post by Nystul » Fri Jun 07, 2019 3:52 pm

some progress with custom notes (visualized as markers that can hold custom notes (will eventually show on mouse over in status bar on the bottom of the gui frame))

they can just be used as markers (used to indicate a path here) or when annotated with text as notes

markers will be added with left mouse double-click

Image

Post Reply