|
|
@@ -1,183 +0,0 @@
|
|
|
------------------------- RELEASE 1.0.0 ---------------------------------
|
|
|
-
|
|
|
- * We now have working exporters for Max5, Max6, Max7, Maya5, Maya6
|
|
|
-
|
|
|
- * The Max exporter is dramatically improved:
|
|
|
-
|
|
|
- - it now includes support for character studio.
|
|
|
- - the polygon winding bug has been fixed.
|
|
|
-
|
|
|
- * Panda no longer requires any registry keys or environment
|
|
|
- variables. This means it is now possible to:
|
|
|
-
|
|
|
- - run panda directly from a compact disc
|
|
|
- - install multiple copies of panda on a single machine
|
|
|
- - install panda by copying the tree from another computer
|
|
|
-
|
|
|
- Note that the installer does add the panda 'bin' directory to
|
|
|
- your PATH, and it does store an uninstall key in the registry,
|
|
|
- but neither of these is needed for panda to function.
|
|
|
-
|
|
|
- * The 'makepanda' build system is now capable of building
|
|
|
- prepackaged games for Windows. These prepackaged games are simply
|
|
|
- copies of panda with the game code included, some of the
|
|
|
- unnecessary stuff stripped out, and some changes to the start
|
|
|
- menu. See "Airblade - Installer" on the panda downloads page
|
|
|
- for an example.
|
|
|
-
|
|
|
- * All of the sample programs have been tested. The ones that didn't
|
|
|
- work have been removed, the ones that do work have been (lightly)
|
|
|
- documented.
|
|
|
-
|
|
|
- * This is the first release to include not just a binary installer
|
|
|
- for windows, but:
|
|
|
-
|
|
|
- - a binary installer (RPM) for Fedora 2
|
|
|
- - a binary installer (RPM) for Fedora 3
|
|
|
- - a binary installer (RPM) for Redhat 9
|
|
|
- - a binary installer for windows, as always
|
|
|
- - a source tar-ball for linux
|
|
|
- - a source zip-file for windows
|
|
|
-
|
|
|
------------------------- RELEASE 2004-12-13 ---------------------------------
|
|
|
-
|
|
|
- * Basic server-client networking support is back in Panda3D. There is a
|
|
|
- networking sample in the samples directory. This uses the Panda3d
|
|
|
- distributed object system.The README file will explain how to run this.
|
|
|
- Documentation of this if forthcoming.
|
|
|
-
|
|
|
- * Panda3d now reduces the number of environment variables such that only 2
|
|
|
- are needed now - PRC_PATH and PLAYER.
|
|
|
-
|
|
|
- * GraphicsChannel and GraphicsLayer class have been removed from the
|
|
|
- panda/src/display directory. Most Panda applications won't need to be
|
|
|
- changed, since most applications simply use ShowBase.py (which has been
|
|
|
- adjustedappropriately) to open a window and do the initial setup. For
|
|
|
- those rare applications where you need to create your own DisplayRegions,
|
|
|
- the makeDisplayRegion() interface has been moved from GraphicsLayer to
|
|
|
- GraphicsWindow (actually, to GraphicsOutput, which is the base class of
|
|
|
- GraphicsWindow). You can modify your application to call
|
|
|
- base.win.makeDisplayRegion() accordingly. If you have something like
|
|
|
- displayRegion.getLayer(), replace it with displayRegion.getWindow()
|
|
|
- instead.
|
|
|
-
|
|
|
- * Effective with the current version of Panda, the way that HPR angles are
|
|
|
- calculated will be changing. The change will make a difference to existing
|
|
|
- code or databases that store a hard-coded rotation as a HPR, but only when
|
|
|
- R is involved, or both H and P are involved together. That is to say more
|
|
|
- precisely, HPR angles with (R != 0 || (H != 0 && P != 0)) now represent a
|
|
|
- different rotation than they used to. If you find some legacy code that no
|
|
|
- longer works correctly (e.g. it introduces crazy rotations), try putting
|
|
|
- the following in your Config.prc file:
|
|
|
-
|
|
|
- temp-hpr-fix 0
|
|
|
-
|
|
|
- To turn off the correct behavior and return to the old, broken behavior.
|
|
|
- Note that a longer-term solution will be to represent the HPR angles
|
|
|
- correctly in all legacy code. The function oldToNewHpr() is provided to
|
|
|
- aid this transition.
|
|
|
-
|
|
|
- * PandaNode definition has been changed to support setting an
|
|
|
- into_collide_mask for any arbitrary node, in particular for any GeomNode.
|
|
|
- It used to be that only CollisionNodes had an into_collide_mask. This
|
|
|
- change obviates the need for CollisionNode::set_collide_geom(), which is
|
|
|
- now a deprecated interface and will be removed at some point in the future.
|
|
|
-
|
|
|
- Details:
|
|
|
- There's now a NodePath::set_collide_mask() and
|
|
|
- NodePath::get_collide_mask(), which operate on all CollisionNodes and
|
|
|
- GeomNodes at and below the current node. By default, set_collide_mask()
|
|
|
- will replace the entire collide mask, but you may also specify (via a
|
|
|
- second parameter) the subset of bits that are to be changed; other bits
|
|
|
- will be left alone. You can also specify a particular type of node to
|
|
|
- modify via a third parameter, e.g. you can adjust the masks for GeomNodes
|
|
|
- or CollisionNodes only.
|
|
|
-
|
|
|
- The NodePath set_collide_mask() interface changes the into_collide_mask.
|
|
|
- Those familiar with the collision system will recall that a CollisionNode
|
|
|
- (but only a CollisionNode) also has a from_collide_mask. The
|
|
|
- from_collide_mask of the active mover is compared with the into_collide_mask
|
|
|
- of each object in the world; a collision is only possible if there are some
|
|
|
- bits in common.
|
|
|
-
|
|
|
- It used to be that only other CollisionNodes had an into_collide_mask. A
|
|
|
- mover would only test for collisions with CollisionNodes that matched its
|
|
|
- collide_mask. If you wanted to make your mover detect collisions with
|
|
|
- visible geometry which had no into_collide_mask, you had to call
|
|
|
- set_collide_geom(1). This allowed the mover to detect collisions with *all*
|
|
|
- visible geometry; it was either an all-or-none thing.
|
|
|
-
|
|
|
- Now that GeomNodes also have an into_collide_mask, there's no longer a need
|
|
|
- for set_collide_geom(). A mover will detect collisions with any
|
|
|
- CollisionNodes or GeomNodes that match its collide_mask. This means, for
|
|
|
- the purposes of collision detection, you can use CollisionNodes and
|
|
|
- GeomNodes pretty much interchangeably; simply set the appropriate bits on
|
|
|
- the objects you want to collide with, regardless of whether they are
|
|
|
- invisible collision solids or visible geometry.
|
|
|
-
|
|
|
- (This should not be taken as a license to avoid using CollisionNodes
|
|
|
- altogether. The intersection computation with visible geometry is still
|
|
|
- less efficient than the same computation with collision solids. And visible
|
|
|
- geometry tends to be many times more complex than is strictly necessary for
|
|
|
- collisions.)
|
|
|
-
|
|
|
- There's one more detail: every GeomNode, by default, has one bit set on in
|
|
|
- its collide_mask, unless it is explicitly turned off. This bit is
|
|
|
- GeomNode::get_default_collide_mask(). This bit is provided for the
|
|
|
- convenience of programmers who still want the old behavior of
|
|
|
- set_collide_geom(): it allows you to easily create a CollisionNode that
|
|
|
- will collide with all visible geometry in the world.
|
|
|
-
|
|
|
- Along the same lines, there's also CollisionNode::get_default_collide_mask(),
|
|
|
- which is 0x000fffff. This is the default mask that is created for a new
|
|
|
- CollisionNode (and it does not include the bit reserved for GeomNodes,
|
|
|
- above). Previously, a new CollisionNode would have all bits on by default.
|
|
|
-
|
|
|
-
|
|
|
-
|
|
|
------------------------- RELEASE 2004-11-11 -----------------------------------
|
|
|
-
|
|
|
- * Multiple mice can now be used with Panda3D. showbase has a list called
|
|
|
- pointerWatcherNodes. The first mouse on this list is the system mouse. The
|
|
|
- getMouseX() and getMouseY() will return coordinates relative to the
|
|
|
- application window. The rest of the mice on the list will give raw mouse
|
|
|
- positions and will change when they are moved on the screen.
|
|
|
-
|
|
|
- In addition there are new events for mouse buttons. Each mouse will be have
|
|
|
- a corresponding event. mouse1 will send mousedev1-mouse1, mousedev1-mouse2
|
|
|
- and mousedev1-mouse3 events. mouse2 and any other mouse attached
|
|
|
- will send similar events mousedev2-mouse1 etc.
|
|
|
-
|
|
|
- The old mouse buttons work too. mouse1, mouse2, mouse3 events will be
|
|
|
- triggered if that button is pressed on any mouse
|
|
|
-
|
|
|
------------------------- RELEASE 2004-10-13 -----------------------------------
|
|
|
-
|
|
|
-General
|
|
|
-
|
|
|
- * Release notes: Each release will now have an entry associated with
|
|
|
- it in this document. This will be updated in reverse-chronological order.
|
|
|
-
|
|
|
-Panda3D
|
|
|
- * Distributed with this release is a working version of the SceneEditor
|
|
|
- created in Spring 2004 at the ETC. Documentation will be forthcoming on the
|
|
|
- website. This can be found in <InstallPath>/SceneEditor
|
|
|
-
|
|
|
- * The latest version of FMOD is distributed with this release. The latest
|
|
|
- version is 3.73.
|
|
|
-
|
|
|
- * AudioSound object now allows more types of sound. These include wma and
|
|
|
- ogg vorbis formats. This is valid when using the fmod sound system. Midi,
|
|
|
- Mod, s3m, it, xm and such sequencer type file formats are not supported.
|
|
|
- Exception - Midi files can be played. This is not fully implemented.
|
|
|
-
|
|
|
- * A bug in SoundInterval is fixed. SoundInterval looping would incorrectly
|
|
|
- add a minimum of 1.5 seconds to the sound. This has been fixed. Sound
|
|
|
- looping problems in general should be fixed. Midi's still don't support
|
|
|
- looping through the AudioSound object. They should loop through
|
|
|
- SoundIntervals though.
|
|
|
-
|
|
|
- * Cg support has been added to Panda3D. Documentation for this is
|
|
|
- forthcoming.
|
|
|
-
|
|
|
-
|
rdb