Implement wonky walls like in DK2

[ufdada]

It's just a visual thing, but this would definitely make it look closer to the original.

This was actually achieved with Incremental Delaunay Triangulation.

Readings:

• https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCYQFjAAahUKEwjf2KahpITJAhVGEiwKHWZYBqU&url=http%3A%2F%2Fwww.karlchenofhell.org%2Fcppswp%2Flischinski.pdf&usg=AFQjCNERvoyhQYMwgtVXdNJYlZukkk8Kiw&sig2=E83lExb014YunXw9nbgkpg
• http://www.ti.inf.ethz.ch/ew/courses/CG13/lecture/Chapter%207.pdf
• https://www.mi.fu-berlin.de/en/math/groups/discgeom/dates/2nd_ERC_Workshop/slides/inc3-talk.pdf

[tonihele]

Terrain has wibble & lean values. Both vertical & horizontal which probably contribute on how much wonkyness is applied. Stone doesn't have much, but regular dirt is all over the place.

[belgianguy]

I used to think that this article was referenced somewhere on this repository, but I can't find it, @(tonihele) also commented on it. As did Robin Green (Ex-Bullfrog). Knowing when to split or flip.

https://simonschreibt.de/gat/dungeon-keeper-2-walls/

Also interesting: http://www.cs.uu.nl/docs/vakken/gis/terrain.pdf, points 5.1 and 5.2 detail how one could model terrain using Delaunay and keep on injecting vertices and flipping of illegal edges until a set of error-margins are satisfied.

Here I thought maybe one could see the "top" of the undug ground as 1 in height and the "floor" where the creatures run on and where you build on as height 0.

I would assume that assigning an "error" margin of 0.1 to the vertices that should be lowered (thus go from 1 (top) to 0(bottom)) and as long as the error margin is not satisfied, repeat the process with the worst offender and make sure the triangulation stays Delaunay.

I also think maybe by using a little random offset to these error-margins x and z values., the wibble and lean might be used to randomize the shapes.

Delaunay Triangulation Where To Start:
http://gamedev.stackexchange.com/questions/61424/delaunay-triangulation-where-to-start

Fast Delaunay in Java: https://www.duo.uio.no/bitstream/handle/10852/43535/delaunay_alg_performance.pdf?sequence=1

[tonihele]

Here is also a little something. Shader based wonkyness:
https://keeperklan.com/threads/7062-Warped-walls-recreation?p=55292#post55292

[Trass3r]

I also think they just used some simple vertex manipulations to create the effect.
That still seems tricky to do in OpenKeeper though seeing how complicated the terrain rendering is. It's all done in many small chunks according to RenderDoc.

[tonihele]

Physics-wise I'm also routing for non shader based solution...

[rainlizard]

Physics-wise I'm also routing for non shader based solution...

Not sure what you mean by physics, but just a reminder that they used perfect cube collision boxes. (collisions do not match the warping effect)

Unless your desire is to be even more accurate and better than DK2.

[tonihele]

Good catch. Didn't actually know that, but it makes sense. DK 2 doesn't really have physics in a sense. Everything is quite simple, such as shadows. But we were planning a bit to have Bullet physics. It will also make things maybe easier to implement even. If it totally breaks up the game, then not. But worth trying.

[Trass3r]

Played around a bit with this warping effect:
https://playground.babylonjs.com/#QMFPPE#250

[ArchDemons]

I think we should use Perlin noise (or another pseudorandom generator) because in the same vertices of adjacent block must have equal coordinatase. In editor tiles have attributes something like the value of entropy of pseudorandom generator

[Trass3r]

That's easy. The problem is the vertex displacement will affect the normals and tangents.

[RobertZenz]

I just got reminded that I did implement something similar for a bloxel game engine written with jME. Though, I did it when creating the mesh, it might be getter to dispklace the grid in the shader.

[Trass3r]

PoC with a slight offset: https://github.com/Trass3r/OpenKeeper/commits/wobblywalls

[tonihele]

Already makes a huge difference, doesn't look so dull

[Trass3r]

Yeah indeed.
But it would better if you could extend the default materials/shaders somehow instead of all this copy paste, and you need a way to only assign the shader to map geometry and the selector wireframe (or a material parameter). For some reason it even affects the water and torches even though it shouldn't.

[tonihele]

The default shaders in jME are just that, they are very generic and support all features we don't really use. I would imagine that in the future we would just have bunch of custom light weight shaders for everything to provide that cool Dungeon Keeper 2 feeling. Hopefully with a modern twist of course.

[Trass3r]

Yeah I just thought the same, sooner or later you'll have fully custom shaders anyway.
Also need a custom pixel shader later to reconstruct the normals and tangents after vertex displacement:
https://playground.babylonjs.com/#QMFPPE#250
https://playground.babylonjs.com/#QMFPPE#373

[Trass3r]

Updated thoughts on a shader-based solution vs computing the map mesh on the CPU:

• can use instanced cubes to reduce the amount of geometry data which is good esp. since the sides need to be subdivided once at least
• but you'll render quite some faces that are invisible
• requires a special shader with knowledge about the world setup baked in
• requires uploading the map as a texture to drive the distortion directions
• lots of vertex work every frame, even though the geometry is relatively static
• effort gets multiplied by Z pre pass or shadow rendering
• similarly, pixel shader work to reconstruct the normals etc
• the distorted vertices only exist on the GPU, so shadows work but not stuff computed on the CPU like collisions maybe