Vulkan presents a very specific problem compared to OpenGL or other frameworks. While it is more powerful, you get more low-level access, a lot of the responsibility lies with the application developer, and very little is managed by the driver / framework. WoW in general, even without it being run on top of a Vulkan Wrapper that intercepts / hooks DirectX11/12 API handles, struggles to utilize the majority of resources available to it. Even on my computer it barely uses 25-50% of my GPU memory, and prefers to store everything in slower DRAM instead.
[Responsibility. OpenGL does a lot in the background, from very simple things such as error checking, compiling high-level shaders, to avoiding deletion of resources that are still used by the GPU (which operates asynchronously) or managing internal resource allocation and hardware cache flushing. Another example is the handling of out of memory situation, where the OpenGL driver implicitly splits up workloads or moves allocations between dedicated/system memory. This code now moves from the driver into the application domain. Developers may also need to replace middleware that was OpenGL only with their own code. While Vulkan doesn’t have the "state-bleeding" issue that OpenGL has for middle-ware, resource management may be a new topic for developers.
Portability. Vulkan being so low-level means that getting the best out of different hardware architectures will very likely require dedicated code-paths.]
Transitioning from OpenGL to Vulkan -> https://developer.nvidia.com/transitioning-opengl-vulkan
Summary
Player models / entities, are more complex than map primitives and one-dimensional textures used to represent trees / fire / bushes / foliage, etc. Most player models / entities, are not very complex in comparison to newer FPS engines, which focus almost entirely on meshes / splines / B-splines, polygon counts exceeding 50 million per model. Game engines like that have a ton of vertical-integration with hardware APIs, workloads with a very specific target, whereas WoW is more focused on generic software / hardware rendering tasks that utilize a combination of integrated / discrete graphics card resources ( it almost resembles software 3D rendering. ) They don’t want it to lag on low-end / mid-range PCs, with the majority of players on WoW being casuals.
They updated the game engine in Cataclysm, but before that it didn’t even have things like bump mapping (back in vanilla WoW.) Even old FPS games from the late 90s had bump mapping. I wouldn’t expect too much from WoW. Player models in the old engine probably never exceeded more than 200-1200 polygons if you were lucky.
If you want to render a lot of things off-screen, utilizing z-buffer depth calculations to determine which objects to rasterize / draw to the screen, based on field of view / the camera layout, whether first-person or third-person ( projection, ) there are a lot of things to take into account, given they have multiple expansions, with the map primitives having an entirely different level of complexity, based on the expansion alone. WoW struggles with particle shaders, shadows / geometry shaders, lighting in general. If you disable almost all forms of that, the lag disappears, hilariously enough. It doesn’t scale very well, and it also relies almost entirely on DRAM to store game assets (EMIF / external memory interface, directly adjacent to the CPU, etc, DDR memory banks.) That’s one reason why it’s slow, but I’m sure with it being an MMO / MMORPG, they have a specific target market, which is mostly casual players with very generic hardware ( combination of integrated / discrete graphics, etc. ) If you tried to optimize for a million different hardware APIs, things you don’t see on blockbuster FPS games, because they deliberately set the system requirements for mid-range or high-end gaming PCs only, then of course they would suffer in some way ( they might optimize for a particular segment of their userbase which is in fact only a small proportion of people / players, and on top of that they might waste money doing so, vs putting the money into other things like developing game content, etc.) It’s hard to KNOW what their priorities are, so you can’t entirely predict why something occurs, for what reason, based on a design decision. You can take a guess, which is only a stab in the dark, and often involves giving boiler-plate responses. I have nothing to do with anything like this, other than just knowing very obvious things. If I had a lot of time I could dig deeper, and uncover the truth, but I’m sure even a simple educated guess is probably more than good enough ( I don’t worry about whether I’m wrong in that sense. ) My personal view, if I was one of those people who had THAT MUCH TIME on my hands, I would rather focus my time and effort on something that has a massive effect on MOST THINGS in general ( such as updating Kitware’s VTK to migrate from OpenGL to Vulkan. )
When WoW came out, if you tried to employ meshes / splines, even for simple models, the polygon count shot up to 3K-6K per model, which is probably the equivalent of a 20 player match in WSG in Vanilla ( under level 32, ) where most people had bad gear equipped. Even that probably lagged, because half of it I’m sure was software-rendered ( almost like the software-rendering mode in the Quake II engine. ) WoW I’m sure is quite a bit better now, but I actually have no idea why it lags, given I haven’t fully explored this engine, other than immediately realizing it hardly takes advantage of most hardware on even mid-range GPUs that are a couple years old, let-alone anything high-end. A lot of people do weird stuff like enable vsync with super high refresh rates, or crank the frame rate, not knowing they are just rendering a ton of stuff off-screen, that will never be displayed ( wasting GPU cycles, etc. ) There are tons of ways to get around performance limitations, but half of it is knowing the inefficiencies of the engine, and how half of it is just your motherboard / CPU / how much DRAM you have ( not entirely your GPU. ) Sure I could try to do something to get hundreds of frames per second. When there is no noticeable difference beyond 20-24, maybe even 30FPS, I could save 3/4 of the power, and only run my game at only 8W-30W load ( vs 150-300W draw, not counting the power wasted due to any minor inefficiency. It would still look barely any different. ) Everyone has different ideas, everyone has their own opinion, no one is really wrong when it comes to their interpretation of this. It’s just how well you can express one idea or another. Here are some more things to read that include a lot of basic terminology:
Valve Hammer / Worldcraft -> https://developer.valvesoftware.com/wiki/Category:Level_Design
Source SDK ( Modeling ) -> https://developer.valvesoftware.com/wiki/Category:Modeling
ZBrushCoreMini (Sculptris) -> https://zbrushcore.com/mini/download.php
Blender -> https://www.blender.org/download/
Softimage Mod Tool -> https://developer.valvesoftware.com/wiki/Softimage_Mod_Tool
Modeling Basics -> http://docs.pixologic.com/user-guide/3d-modeling/modeling-basics/
Z-buffer -> https://docs.blender.org/manual/en/latest/glossary/index.html#term-Z-buffer
Overscan -> https://docs.blender.org/manual/en/latest/glossary/index.html#term-Overscan
Render -> https://docs.blender.org/manual/en/latest/glossary/index.html#term-Render
Projection -> https://docs.blender.org/manual/en/latest/glossary/index.html#term-Projection
Procedural Texture -> https://docs.blender.org/manual/en/latest/glossary/index.html#term-Procedural-Texture
Bounding Box -> https://docs.blender.org/manual/en/latest/glossary/index.html#term-Bounding-Box
Depth of Field -> https://docs.blender.org/manual/en/latest/glossary/index.html#term-Depth-of-Field
Field of View -> https://docs.blender.org/manual/en/latest/glossary/index.html#term-Field-of-View
Mip-Mapping -> https://docs.blender.org/manual/en/latest/glossary/index.html#term-Mip-mapping
Particle System -> https://docs.blender.org/manual/en/latest/glossary/index.html#term-Particle-System
Pixel -> https://docs.blender.org/manual/en/latest/glossary/index.html#term-Pixel
Alpha Channel -> https://docs.blender.org/manual/en/latest/glossary/index.html#term-Alpha-Channel
Mask -> https://docs.blender.org/manual/en/latest/glossary/index.html#term-Mask
Triangle -> https://docs.blender.org/manual/en/latest/glossary/index.html#term-Triangle
Vertices -> https://docs.blender.org/manual/en/latest/glossary/index.html#term-Vertices
Micropolygons -> https://docs.blender.org/manual/en/latest/glossary/index.html#term-Micropolygons
Mesh -> https://docs.blender.org/manual/en/latest/glossary/index.html#term-Mesh
Vertex -> https://docs.blender.org/manual/en/latest/glossary/index.html#term-Vertex
Edge -> https://docs.blender.org/manual/en/latest/glossary/index.html#term-Edge
Face -> https://docs.blender.org/manual/en/latest/glossary/index.html#term-Face
Spline Types -> https://docs.blender.org/manual/en/latest/modeling/curves/structure.html#curve-spline-types
NURBS / B-Splines (Blender) -> https://docs.blender.org/manual/en/latest/glossary/index.html#term-Non-uniform-Rational-Basis-Spline
NURBS / B-Splines (3ds-Max)-> https://knowledge.autodesk.com/support/3ds-max/learn-explore/caas/CloudHelp/cloudhelp/2023/ENU/3DSMax-Reference/files/GUID-82A6AEA2-568C-4F19-9BC3-D5C362122EDA-htm.html