I'll preface all that I am about to say by stating that Sapphire has not been seriously optimised for fast or smooth performance. In fact, it's quite de-optimised in some parts, because it's designed to handle huge, arbitrary terrain sizes (non square, non-power of two), and runtime terrain deformation. Hence it uses a '97-era ROAM terrain tessellation algorithm, which is rather expensive in terms of CPU cycles/frame, but is capable of odd sizes and per-frame mesh regeneration. Compare with, say, Atlas, which is much
faster and smoother, but can't handle odd map sizes, huge map sizes, or per-frame terrain deformation.
Another design requirement for Sapphire is that it must run on old hardware, so it doesn't use shaders, vertex buffer objects, or any of the fast goodies of modern 3D graphics. Furthermore, because it's a plugin, it has some data-access overheads that would be completely unacceptable in anything resembling a game engine. Sapphire has to ask L3DT for every bit of height and texture data via the plugin API, and that involves a lot of function calls (lots of checking at every level, etc). With those sorts of design constraints, it can never perform as fast as a game engine.
Phew, now on to answering your post:
It stutters quite badly when flying around my maps.
To get rid of the lag I will have to make a multithreaded texture loader. That's on the to-do list, but it's not a priority at the moment. I’ll explain why at the end of the post.
You can partially reduce the lag by using a smaller texture tile size. Generally, 512x512 pixels is the recommended texture tile size, except when using very high-res textures (16x or 32x res), for which you need to use 1024x1024 and 2048x2048 tiles, respectively (this is a constraint of the texture application code). What was your texture map size and tile size?
It shows that i never use more than 60-70mb of Video card memory though my card has 768mb.
There are two parts to my answer:
First, did you set the VRAM limit in the 'Extensions->Sapphire->Hardware settings
' menu option?
Secondly, you shouldn't expect Sapphire to use all (or even much) of your 768MB of VRAM. As I think I've said before, Sapphire presently loads only the texture tiles needed to render the current scene, which is usually under 100MB. You can increase the texture memory manually by decreasing
the LOD bias via the '[' key. However, it probably won't make a big difference to scene quality unless you have a really big monitor, and it will also increase
the lag (loading more high-res tiles more often). The situation will change somewhat when the multi-threaded texture loader is included. At that time, I'll be able to make Sapphire pre-fetch tiles in the background without adding lag (it will drop the frame rate, but smoothly, rather than lagging single frames).
Now, regarding priorities. For the next release, I don’t intend to spend much time on Sapphire at all. Basically, Sapphire is in my opinion ‘good enough’ for its intended purpose of editing heightfields, previewing textured terrain, replacing L3DTVi2, and demonstrating the plugin API. I think to spend more time on Sapphire right now would be to neglect more important problems. Thus, with L3DT release 2.6 I’ll be focussing on core-business issues like making climate development easier, making calculations run faster (more parallel multithreading), and giving users more/better options in heightfield generation (more algorithms, customisable algorithms, etc). If I do make changes to Sapphire in v2.6, they will probably be more tools for editing heightfields or painting texture splats, and possibly cleaning-up the dialogs used in some parts of the Sapphire UI. Performance improvements to Sapphire will probably
have to wait for L3DT 2.7. Anyway, I'll discuss the future directions more fully next week, when v2.5b is released.
Thanks for the feedback.