Important stuff.
by Aaron » Tue Oct 30, 2007 8:03 am
Hi Everyone,
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.
-
![User avatar](./download/file.php?avatar=2_1294969800.png)
Aaron
- Site Admin
-
- Posts: 3696
- Joined: Sun Nov 20, 2005 2:41 pm
- Location: Melbourne, Australia
-
by metalliandy » Thu Nov 01, 2007 12:34 am
Hey Aaron,
Im still having problems with Sapphire, It shows that i never use more than 60-70mb of Video card memory though my card has 768mb.
It stutters quite badly when flying around my maps.
Any ideas?
Great work so far mate ![Smile :)](./images/smilies/icon_smile.gif)
-
metalliandy
- Doyen
-
- Posts: 103
- Joined: Tue Mar 20, 2007 11:28 am
by Aaron » Thu Nov 01, 2007 11:08 am
Hi Metalliandy,
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.
Cheerio,
Aaron.
-
![User avatar](./download/file.php?avatar=2_1294969800.png)
Aaron
- Site Admin
-
- Posts: 3696
- Joined: Sun Nov 20, 2005 2:41 pm
- Location: Melbourne, Australia
-
by metalliandy » Sun Nov 04, 2007 10:01 am
Hey Aaron,
Sorry about the lengthy amount of time it has taken for me to reply.
I had replied previously but for some reason the post hasn't showed up :S.
Here goes again...lol
Here is a good average of the sort of map i am making, though in the future when the "pause/resume render" function is implemented the textures will be larger.
- Code: Select all
Terrain size: 1024 × 1024 Texture size: 8192 × 8192 Contents of map project
* Maps o Design map o Heightfield o Water map o Attributes map o Terrain normals o Light map o Texture map * Settings and flags o Operations o Design map settings o Heightfield settings o Attributes map settings o Light map settings o Texture map settings
Maps Design map Map size: 16 × 16 Horiz. scale: 6.40m Map file: testmap_DM.dmf File type: L3DT Design Map File Heightfield Map size: 1024 × 1024 Horiz. scale: 0.10m Map file: HF\testmap_HF.mmf File type: 2 × 2 mosaic of 5122 pixel Heightfield File v2 + gzips (.hfz)
Water map Map size: 1024 × 1024 Horiz. scale: 0.10m Map file: WM\testmap_WM.mmf File type: 2 × 2 mosaic of 5122 pixel L3DT Water Map Files (.wmf)
Attributes map Map size: 8192 × 8192 Horiz. scale: 0.01m Map file: AM\testmap_AM.mmf File type: 16 × 16 mosaic of 5122 pixel L3DT Attributes Map File + GZIPs (.amf.gz)
Terrain normals Map size: 8192 × 8192 Horiz. scale: 0.01m Map file: TN\testmap_TN.mmf File type: 16 × 16 mosaic of 5122 pixel PNG images (.png)
Light map Map size: 8192 × 8192 Horiz. scale: 0.01m Map file: LM\testmap_LM.mmf File type: 16 × 16 mosaic of 5122 pixel JPEG images (.jpg)
Texture map Map size: 8192 × 8192 Horiz. scale: 0.01m Map file: TX\testmap_TX.mmf File type: 16 × 16 mosaic of 5122 pixel JPEG images (.jpg)
Settings and flags
* Operations o GenDM o GenHF o FloodSea o FloodLakes o WaterTable o FloodAll o GenAM o GenTN o GenLM o GenTX * Design map settings o Algorithm = "PeakDM" o nx = 16 o ny = 16 o SeaLand = 74 o FlatSteep = 51 o FeatureScale = 88 o FracRough = 75 o PeakRough = 75 o Cliffs = 66 o Erosion = 8 o Lakes = 44 o Climate = "Temperate" * Heightfield settings o Algorithm = "InflateDM64" o HorizScale = 0.100000 o MosaicFlag = true o MosaicSize = 512 * Attributes map settings o Climate = "Temperate" * Light map settings o Sun(r,g,b) = { 255, 238, 206 } o Amb(r,g,b) = { 230, 245, 255 } o Azim = 0.000000 o Elev = 45.000000 o Brightness = 1.000000 o SunAmbRatio = 0.750000 o UseWM = true o ShadowFlag = true o BumpMapping = false o MosaicFlag = true o MosaicSize = 512 o LM_in_HF = 8 o AbsRGB(x,y,z) = { 10.000000, 20.000000, 50.000000 } o DoFresnel = true o DefaultTx = 1.000000 * Texture map settings o UseLM = true o UseTX = true o UseStrata = true o TX_in_HF = 8 o MosaicFlag = true o MosaicSize = 512 o MaxRadAA = 16
*post continued below*
-
metalliandy
- Doyen
-
- Posts: 103
- Joined: Tue Mar 20, 2007 11:28 am
by metalliandy » Sun Nov 04, 2007 10:13 am
Regarding Sapphire, i understand that it is not your top priority, and rightly so, as it is more than fit for the purpose for which it was made.
I always set the VRAM to 768 before rendering and only mentioned this because of you first post..lol...its not that much of a problem really, i just though that i would mention it
The texture splats and parallel multi-threading are great ideas and should improve work flow substantially.
I think the main problem with L3DT is the time it takes to calculate and render maps.
This is not a problem when creating small maps but when it comes to creating mega terrains, it can take days, which unfortunately is far to long for me to leave my computer on ![Sad :(](./images/smilies/icon_sad.gif) .
But that said L3DT is, and will remain, an indispensable part of my work flow...simply because it is the best at what it does. Plus the level of support you give is above and beyond:)
Do what you have to do mate, we all trust that you know what you are doing with L3DT and the changes you make or do not make are in the best interests of the program.
Keep up the good work ![Very Happy :D](./images/smilies/icon_biggrin.gif)
-
metalliandy
- Doyen
-
- Posts: 103
- Joined: Tue Mar 20, 2007 11:28 am
by Aaron » Thu Nov 08, 2007 9:33 am
Hi Metalliandy,
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.
Cheerio,
Aaron.
-
![User avatar](./download/file.php?avatar=2_1294969800.png)
Aaron
- Site Admin
-
- Posts: 3696
- Joined: Sun Nov 20, 2005 2:41 pm
- Location: Melbourne, Australia
-
by metalliandy » Thu Nov 08, 2007 8:40 pm
Hey Aaron,
All sounds very good, Im getting all excited..lol
Any ideas when the start/stop render will be roughly implemented...that's the one i need the most :S
I will try reducing the AA to X4 as you suggested and see what the textures come out like ![Smile :)](./images/smilies/icon_smile.gif)
-
metalliandy
- Doyen
-
- Posts: 103
- Joined: Tue Mar 20, 2007 11:28 am
by Aaron » Sat Nov 10, 2007 10:34 am
Hi Andy,
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.
Cheerio,
Aaron.
-
![User avatar](./download/file.php?avatar=2_1294969800.png)
Aaron
- Site Admin
-
- Posts: 3696
- Joined: Sun Nov 20, 2005 2:41 pm
- Location: Melbourne, Australia
-
by metalliandy » Sat Nov 10, 2007 2:04 pm
Hey Aaron,
I guess i will have to start leaving my computer on over night..lol
Thanks for the reply ![Smile :)](./images/smilies/icon_smile.gif)
-
metalliandy
- Doyen
-
- Posts: 103
- Joined: Tue Mar 20, 2007 11:28 am
Return to Announcements
Who is online
Users browsing this forum: No registered users and 178 guests
|