If this doesn't happen every time that's a separate issue, in this thread we're looking for videocards completely incapable of displaying the new terrain so I can get my hands on one of them and fix the issue.

Well that didn't help either. Ok this is at the point where we'll need to hunt down a system that can reproduce this issue. There's not much more we can do until then. We're on it don't worry.

We put out a new client with a lot more logging going on, please do another dump now, same as before with d3d debug.

Allright, the new client should be up, please let me know if this has fixed the game for you, Lahha.

Annihilator: no, this issue is a missing videocard feature kinda thing, those errors you referred to indicate missing artwork (they are mainly a way for the graphics artists to track down content bugs, not all of them are actual errors)

Looks like the texture format used by the new terrain engine isn't supported by your card, I'm looking into a workaround.

Allright, that's good. Here's what I need you to do:
Run C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Utilities\bin\x86\dxcpl.exe, this is the dx sdk config tool. I'll need you to put the sdk into debug mode for this.

To do that you'll need to go to the direct3d 9 tab and set two things: the debug output level should be the second to last (setting it all the way up will just fill the log with unneeded data so don't do that), and set the debug/retail d3d9 runtime option to "use debug version of direct3d 9".

Once you're done with this create a clean log just like you did and drop it to pastebin.

Also don't forget to undo the changes (set the sdk back to retail) once you've created the log or you'll experience diminished performance with d3d apps.

Check something for me please: turn off shadows completely, turn off AA completely, go into fullscreen 1024*768 mode, restart the client and see if that does anything to fix the issue. (This should reduce video memory requirements a bit and if this works we'll need to have a look at the vidmem usage of the client)

The plan is to release the gfx update along with the PBS expansion - at this point it's less work to finish everything than to revert the changes It's mostly content that's missing, the new lighting setup is still in the works, but the code is basically finished. I've since moved on to implement the player oriented terraforming toolset.
The avatars will get some love as well, but only after we're done with PBS. They will need a lot of experimenting with different rendering techniques and some new content as well, but right now with the looming expansion they're not too high on the todo list as you might imagine.

Unfortunately implementing better animation blending is one of the things that would require a major rewrite of the 3d engine. As you can imagine the animation system was one of the first things to be implemented about 5 years ago and just about everything in the 3d engine relies on it. This old architecture only supports blending between two animations at once and the current setup is the most we can make of that. As with everything else when working with such a small team we need to prioritize - the rewrite of the 3d engine that would be required to implement a proper animation blending pipeline with partially procedural animations would require about 4-6 months of work. We can bring the whole visual quality of the game to a whole new level with that amount of work, which is what we chose to do for now.

You're talking about several different things here
One is the client's performance requirement while not active (when you're doing other stuff) which we already regulate, but from what I've seen in other games we could go as far as dropping the framerate to 10-15 fps in this case - this can be implemented as a client option if needed.

Then there's the terrain vs terminal performance discrepancy vs having multiple cores in your machine. The way the graphics pipeline works is by first doing stuff on the cpu to prepare the scene to be rendered by the gpu. While the cpu is working optimally the gpu is drawing the previous frame, but if the cpu side is taking too long the gpu just idles waiting for things to do. In the case of the terminal the cpu has very little to do except drawing the interface, so the gpu becomes the bottleneck. On the terrain however we need to process many thousands of items in the scene graph (animating the whole scene etc) which takes a lot of time.
On most systems we've tested if we calculate everything we need on the cpu side just "fail" to send it over to the gpu, we get a framerate increase of about 5-10%. If we remove the cpu side work from the engine as well, we get 500-1000% increases. This means that the drawing part on the gpu (the fancy new terrain shaders for example) doesn't really matter in the performance because the gpu is waiting on the cpu anyways. The systems that don't behave like this are those that have gpus on the lower end of the scale coupled with relatively high performance cpus - mobile devices mostly, like laptops and such.
Also, due to the nature of scene graph traversal and the architecture of our engine the 3D engine's cpu part can only use a single core in your pc.

The new terrain engine actually removes most of the associated load on the cpu side while moving around and thereby makes things a lot more even. My aim is that the performance of the game is actually increased from these changes.

The current user interface engine is pretty strict when it comes to resizing, so that's a definite no. As for rendering the 3d at different resolutions to keep the fillrate constant - that has it's own separate set of issues starting with not being able to use antialiasing on rendertargets all the way to fillrate not actually being a bottleneck on most pcs for Perpetuum.
On most systems the cpu is our bottleneck and I'm working hard on relieving some of the workload from there.
There's a very quick way to see if your system has a fillrate issue or not - if you only change the resolution of the game and the framerate changes drastically you're most likely fillrate bound. Mobile hardware is the only place where we have confirmed this, but that's... well... mobile hardware