AM / Sapphire editing

[Gnome]

Is it possible to edit a large/high res AM in Sapphire?

I have the need for a high res AM and I'm running into trouble getting it to load up in sapphire without errors. Not sure if it's even possible but I thought I'd ask before I take the "workaround" approach.

Terrain info:
HF: 512x512 (imported)
HS: 10m (5.1km)

Editing the HF and all is just fine at the above settings, however I need an AM that is 5120px² (basically 1px=1m res is the goal). I've tried rescaling the HF to 5120²@1m, but get errors trying to paint in sapphire should it actually load and not crash out. I've also tried tiling it at different sizes with no joy. Works fine on HF of 2560²@1m. Perhaps a limitation?

I just noticed I apparently need to be saving the log file.. will do if needed. Hoping it's more of an operator error.

Exporting an AM and scaling it up would work if I could force an indexed palette or similar. Any help greatly appreciated. Using latest 2.9.

*edit*
some more useful info, actual errors while working on an AM:

CMapGroup::SaveGroupAs error
- cannot save mipmap

Sapphire::DrawScene (OpenGL - follows glInitCamera) error:
- GL_INVALID_VALUE

CL3DTio_BackupApp::InitEditRecord error:
- edit record is already initialised

The last 2 repeating until I surrender

[Aaron]

Hi Gnome,

I apologise for the inconvenience caused by this error.

I've tested L3DT just now using a 512x512 pixel heightmap and a 5120x5120 pixel attributes map, and I don't get any errors when editing the attributes map in Sapphire*. I tested this both with and without the attributes map split into a mosaic.

Can I ask you to send me the log file after you attempt to edit the AM in Sapphire ? You can get to it from the Windows Start menu by selecting the 'All programs->Bundysoft->L3DT [version]->L3DT logs' shortcut. That shorrtcut will open a folder containing a file called 'log.txt'. Please send that file to aaron@bundysoft.com.

Best regards,
Aaron.

* Note: I do see some texture streaking in the display of the attributes map in Sapphire, which may be due to the fact that the AM/HF ratio is not a power of two (10, in this case). I'll look into it.

[Gnome]

This error is just beating me to death. You get that email Aaron? Don't have a clue here. Checked everything openGL, reinstalled a couple times ... no joy.

[Aaron]

Hi Gnome,

Thank you, I did receive the log. I've had a look though it, but it doesn't provide many clues in this instance.

The OpenGL error only indicates that there was an OpenGL error before the start of a frame render, which might include setting up the texture units. I've added further OpenGL error checking in Sapphire for the next release so as to catch the error closer to the source.

I'll look into the 'InitEditRecord' error. My first impression is that this is a symptom of the failed frame rendering rather than a cause, but further investigation is required.

The crashes on exit in Win7 x64 are also now under investigation.

I'll let you know when I've got a fix ready for any or all of the above bugs. I apologise for this inconvenience, and thank you for your patience.

Best regards,
Aaron.

PS: Have you tried updating your graphics card drivers?

[Gnome]

Yep, bounced around with the the last few sets trying to find a magic setting.

I actually have 3 285's in this box with 3 monitors. I don't know how that might be an issue, but maybe?

I guess I can try installing on my amd/ati box and see if I have the issue there. Don't know if that violates any agreement, I'll have to read up on that.

Thanks for the reply Aaron, sorry to be a special case. I'm happy to hack, patch or whatever if you come up with a fix.


Kind Regards,
Gnome

PS: The crash on exit only seems to happen with other errors. No errors, no crash out. Don't know if I mentioned that clearly.

Cheers

[lmaceleighton]

So are you saying you are running an SLI system? Hmmm, I would wonder too if that was causing rendering errors too, although it always worked for my ATI Xfire with 2 4870's, of course Nvidia is a bit different as you know:O)

[Aaron]

Hi Gnome,

I guess I can try installing on my amd/ati box and see if I have the issue there. Don't know if that violates any agreement, I'll have to read up on that.

You can install L3DT on multiple systems; no license problem there. Please let me know how it goes.

Best regards,
Aaron.

[Gnome]

Ok.. now that I'm back to map related things. I did install on the AMD/ATI rig, also win7(64). Same issues.

Starting to wonder if all of this comes back to not utilizing a proper multiple in the horizontal scale. (?) Not having issues with 2x anything.

Regarding, SLi things. Yep I normally run in Tri-SLi, although I did test working down to a single gpu. Seems to be unrelated. I'll be more hands on again over the next couple weeks, so I'll hopefully find time to dig further.

An additional bonus question regarding workflow/files types. I utilize the .xyz plugin for export. On occasion though, I need to tweak things and the only process availble to me is by way of 16bit .png re-import into L3DT.

What if any concerns should I have about loss of accuracy in the HF or related? I assume none as the 16bit png should maintain the 0-65k range. Is that a safe assumption?

Best Regards,
Gnome

[Aaron]

Hi Gnome,

What if any concerns should I have about loss of accuracy in the HF or related? I assume none as the 16bit png should maintain the 0-65k range. Is that a safe assumption?

Correct. Passing the data through a 16-bit PNG won't cause any meaningful data loss, as the image greyscales span the full 64k range. The compression in L3DT's heightfield file format (HFZ) usually chomps the data down to the equivalent of about 14 bits of precision, and no-one has yet noticed (or reported) any problems. The only thing to be mindful of is the preservation of the minimum and maximum altitudes, but no-doubt you've thought of that already.

Starting to wonder if all of this comes back to not utilizing a proper multiple in the horizontal scale. (?) Not having issues with 2x anything.

Quite possibly. Using non-power-of-two attributes maps means non-power-of-two textures in OpenGL, which is the sort of thing that can be a bit flaky in new drivers [I did test L3DT and Sapphire at this map size, and I couldn't find a problem. Hence I'm still blaming drivers.] I'd suggest you try 8x or 16x and see if problems persist.

Best regards,
Aaron.

PS: So as to clarify my nomenclature, I should mention that L3DT will behave itself with non-power-of-two horizontal scales, which in the context of L3DT refers to the metres-per-pixel scale of a map. What does cause problems is the resolution ratio of maps, which is the ratio of the side-length of a map (e.g. the texture, light map, etc.) to the side-length of the heightfield (both measured in # pixels). Non-integer values are generally unsupported (so a 512^2 pixel heightfield with a 768^2 pixel texture is a no-no), and non-power-of-two values can be dangerous in certain algorithms (specifically in 3D rendering, but there may be others). These resolution ratios and are usually labelled as something like 'AM/HF res. ratio' in the appropriate wizards, and are accompanied by spin controls (up/down arrow buttons) that step the resolution up/down to the next power of two. </rant>