This is the last call for users to report bugs in the release candidate of L3DT v2.5b. The fourth and final release candidate is now available for download, in both Standard and Professional versions. If no-one reports a critcal bug, we will proceed with the release of L3DT 2.5b some time during the week starting the 5th of November (depending on when I finish updating the docs).

This release has been extensively tested over the past five-or-so months by the beta testers and myself, and I'm quite confident that it is ready for 'stable release' status. However, we can't test all possible uses of the program, particularly when dealing with other 3rd party applications. Thus, before release I'd like to make one last check with you to make sure that I haven't broken any part of your work-flow. If you'd like to download and install the release candidate, the things to look out for are:

Do all your favourite file formats work properly?

Does the 3D renderer/editor (Sapphire) work as expected?

Have I broken compatability with any 3rd party applications that you use with L3DT?

Can the new version load your old L3DT projects? (as far back as L3DT 2.4 should be supported).

Are there any new or changed buttons/menu options/settings whose purpose is not obvious, or don't seem to do what you think they should?

As I said, I'm satisfied that this release is ready to go, but I'd welcome any reports that indicate otherwise.

Finally, I'd like to offer my thanks to everyone who sent in a bug report or requested a change during the development of this release. I couldn't do it without you!

Best regards,
Aaron.

PS/FYI: The build version of this release candidate is 2.5.2.16, and the release date is 30th of October.

PPS: L3DT Professional still has to be run under administrator mode in Windows Vista. This will be fixed in L3DT release 2.6.

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.

metalliandy wrote:I think the main problem with L3DT is the time it takes to calculate and render maps.

Quality takes time

But seriously; I will be looking at more performance improvements for v2.6 and v2.7. In addition to the multithreading already mentioned, there are quite a few other tricks and optimisations I'd like to try out. In particular, there are some big changes to the climate/texturing system coming up in v2.6, one side-effect of which will be the possibility to pre-calculate and reuse some of the texture blending that is currently done each time the texture is generated.

By the way, do you find that 16x anti-aliasing gives you noticeably better results than, say, 4x? Anti-aliasing is really only there to:

Conceal blockiness when you make a very high-res texture from a very low-res attributes map (not the case here; you've used 8x in both cases), and;

Smooth the transitions between certain land types (i.e. sand->grass). This is useful up to a point, but it just looks silly when you smooth the edges too far.

I would probably use a maximum anti-aliasing radius of 4x when dealing with both 8x attributes and texture maps, but your mileage may vary. In any case, the high anti-aliasing value will be one of the main reasons your textures are taking a long time to generate, and it may not bring much benefit.

metalliandy wrote:Any ideas when the start/stop render will be roughly implemented...that's the one i need the most.

Sorry, I'm not really sure yet. The good news is that a lot of the functionality required for stop/resume will also be needed for other useful things like 'calculate selected area', and network cluster rendering. However, there are some rather tricky parts specific to 'stop/resume' that could require a lot of work. When 'calculate selected area' is complete, I will be in a better position to guess when 'stop/resume' might be ready.