Page 22 of 25

Re: Automap (indoor & dungeon) implementation

Posted: Wed Jun 05, 2019 8:18 pm
by mikeprichard
Ah, right - didn't remember PH being quite that messy.

Re: Automap (indoor & dungeon) implementation

Posted: Wed Jun 05, 2019 11:59 pm
by BansheeXYZ
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.

Re: Automap (indoor & dungeon) implementation

Posted: Thu Jun 06, 2019 7:16 am
by Nystul
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

Re: Automap (indoor & dungeon) implementation

Posted: Thu Jun 06, 2019 8:11 am
by BansheeXYZ
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 447 times

Re: Automap (indoor & dungeon) implementation

Posted: Thu Jun 06, 2019 11:55 am
by TheLacus
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));

Re: Automap (indoor & dungeon) implementation

Posted: Thu Jun 06, 2019 12:27 pm
by Nystul
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?

Re: Automap (indoor & dungeon) implementation

Posted: Thu Jun 06, 2019 12:47 pm
by TheLacus
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 419 times

Re: Automap (indoor & dungeon) implementation

Posted: Thu Jun 06, 2019 1:34 pm
by Nystul
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)

Re: Automap (indoor & dungeon) implementation

Posted: Fri Jun 07, 2019 1:53 pm
by Nystul
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

Re: Automap (indoor & dungeon) implementation

Posted: Fri Jun 07, 2019 3:52 pm
by Nystul
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