Postby Leodagan » Wed Aug 21, 2013 7:59 am
Sorry to dig up this old thread...
From my research getting elevation on open land terrain could be pretty easy...
Lot's of talks about interpolation, quad nearest point to obtain a triangle that can be interpolated !
Honestly from what I remember there are not so much 'usable' interpolation/filtering solutions, "nearest neighbour" is out of question as results would be hugly, bilinear filtering which is a simple weighted averaging algorithm and have predictable behaviour (you can write your own bilinear filtering implementation that should give the same results as everyone else's algorithm) and trilinear filtering (or bi-cubic) which use a ratio constant that needs to be tuned to change the blurriness of the final result (that could be a lot less predictable than a bilinear filtering)
Simply using an image editor to change image size from 256*256 to 65536*65536 should default to bilinear filtering, I did not test anything, but I think you could merge terrain.pcx and offset.pcx then size the image to zone size, or first increase the size of both images then merge (always with ratio from sector.dat)
I don't think a graphic rendering engine could be using heavier filtering than the one I listed... (these game softwares needs to be fast, and simple to maintain !)
For collision with NIFs object that could be a lot harder to detect, work could begin around a simple barrier (like there is in camelot hills), for trees it's just plain simple they are listed in nifs.csv with a radius for collision and should have a collision on all the Z axis or just enough to prevent jumping (doesn't matter on terrains as they aren't layered, and they can't be jumped above !)
And at last for NIFs, there should be strong 3D modeling algorithms, using waypoint, or nodes grid is just a way to prevent from using game assets (which I can understand, even a triangle arrays in a 3D space needs a lot of code and maths knowledge !)
there are 2 types of NIFs, standard NIF with a "collidee" Node that is just a wireframe mesh or triangle array to implement collisions, and Dungeon NIFs (dnifs) which have "collidee" Node and a "pickee" node, pickee node looks like a floor mesh in most of dungeon...
For ppl who noticed that pets were using waypoints, I think they use "pickee" mesh which are divided in small areas (a Darkness Falls stairway DNIF have about 8 pickee meshes) so the mob/pet path must be using the center of a pickee mesh or other simpler "waypoint" like algorithm to lower compute needs on long pathing (or maybe even a full 3D pathing algorithm but that doesn't fit with 10 years old servers at the game launch...) and maybe even using those full mesh for server-side LOS checking...
At last LoS checking could be the main algorithm used for collisions too and maybe "stupid-pathing" algorithm (check LOS : OK -> move there, check LOS : WRONG -> try something else; until LOS : OK)
LoS checking can only be done by casting "Rays" (like in ray tracing algorithms) this can sound heavy but for only one point in space, and only cast when needed, it could be only "hundreds" of rays by seconds which is easily handled by any processor (ray tracing can get really fast when you don't use reflections or shadows, reduce rendering to a tiny area, ignore textures blending, etc...)
This is also the method used by any "picking" algorithm (click in a 3D scene to select object/polygons), thus casting ray could be a great way to detect collision but maybe not enough to obtain a complete pathing algorithm (at least plenty enough to detect a tree and make a mob path move for some degrees to get around)
Picking algorithm/Pickee Mesh... (Maybe it's just a guess...)
We have to keep in mind that all this data will only be kept in "wireframe" view, and only colliding objects will matter to the server (colliding objects are identified in zones manifests...) it could indeed raise memory consumption dramatically but, today, memory is way cheaper than compute power !