New release: 1.5.3

Hey guys,

Finally, at last, 1.5.3 is finally there, as some of you already noticed.
Here are the brand new features:

  • License changed to BSD
  • Fixes x-file parser for real, this time.
  • Fixes serious bug in shader generator
  • Adds MSVCR71 and MSVCP71 back to the distro (for python)
  • Fixed a bug in GeoMipTerrain
  • Adds support for .egg.pz to packpanda --bam
  • Turns on libpandaode support
  • Mayapandatool fixed
  • Added support for 3dsmax 2009
  • Max exporter overhauled
  • Improved support for 64-bits, gcc 4.3 and OSX
  • New DirectRadioButton for DirectGUI
  • …and much more!

Also, there are now 64-bits binaries available on the download page. Most of the thirdparty packages are in now. For 1.6.0 we’re also planning to have OSX binaries available.

To the ones who have been downloading my pre-release of 1.5.3: remove it, its horribly outdated. Download the new one instead.

Wait no longer, and continue to the download page!
panda3d.org/download.php?version=1.5.3
Any bug reports are welcome.

pro-rsoft

PS. Josh indeed no longer works at CMU. Until they find a replacement, treeform and me are maintaining the releases.

Thank you, gentlemen: David, pro-rsoft, treeform, ynjh_jo and all others!
From the depth of my heart I appreciate your efforts to develop this wonderful engine and to bring it to us.

Thank you indeed! :slight_smile:

Is there by any chance available a full list of the changes made? I’m particularly interested in changes to GeoMipTerrain - I want to work with that but have been having trouble in getting the desired performance on my computer, and recall reading that you’re planning on making changes to the level-of-detail specification system for 1.6.0, leaving me unsure of whether I should try this version or keep the project on hold until 1.6.0…

A full list of changes can be retrieved using the “cvs diff” command, but really, you don’t wanna do that. (Wayyyy too much changes)
About geoMipTerrain, I didn’t change that much (except better bruteforce rendering), but if you’re having bad performance that’s most likely because the chosen terrain settings are not correctly finetuned. (If you email me your code I’d be happy to finetune them). The new near/far LOD system I’ll put in 1.6.0 will only make it easier to find the correct terrain settings.

Cool :wink: !Everybody has been waiting for the new release.
And we already talk about version 1.60!

1.6.0 will be grand!

Pro and me have been experimenting with launchpad.net to track bugs and feature suggestions here launchpad.net/panda3d .

Have fun with 1.5.3

Heh, true, but thank you. :slight_smile:

I thought as much, from what I’d read, but thought it worth asking - although I’m tempted nevertheless.

Thank you - I appreciate that very much. :slight_smile:

I’m not sure to what degree it would help me at this point, however, as I’m not yet sure of my final desired heightmap size or view distance.

If I may ask, how do you come up with good values? It might help me to learn a good technique or set of techniques for doing so.

I may yet take you up on that offer, however.

For that matter, what is the default relationship between heightmap size and final terrain size (is it one pixel to one Panda unit?), and what is the relationship between heightmap size and base z-scale (I find that a larger heightmap seems to produce a flatter terrain, despite the smaller map being simply the larger one scaled down, as I recall)?

That’s what I seem to recall reading, indeed, but I suspect that it might be of quite a bit of help.

thankyou guys for your great job

PS: I’m noticing in hp “Now under BSD License” - curiously I thought P3D was already under BSD, go figure why… :unamused:

@Thaumaturge, to tweak the terrain settings it’s essential to know how it works – but even then it’s more a matter of trial&error, and having done it often. I tried various times to come up with an easy algorithm, but failed, that’s why I changed the LOD system.
One pixel is indeed one panda unit: for the height, a white pixel means a height of 1 panda unit, a black pixel means Z=0 panda units. That’s small, so you always need to scale it up (using terrainRoot.setSz() or setScale()).

@astelix, Yeah, but 1.5.3 was the first release which officially had the new license text on top of the header files.

Aah, fair enough, and thanks - the new system looks promising to me.

Thank you too for the clarification on the scale - although I seem to find that, for a given z-scale, a larger heightmap produces flatter terrain, quite visibly so when comparing a 513x513 map to a 129x129 map (if I recall the sizes correctly), at least as of 1.5.2. It may be worth noting, however, that I’m using a parent node for my z-scaling, as a matter of convenience.