Book Image

Panda3D 1.6 Game Engine Beginner's Guide

Book Image

Panda3D 1.6 Game Engine Beginner's Guide

Overview of this book

Panda3D is a game engine, a framework for 3D rendering and game development for Python and C++ programs. It includes graphics, audio, I/O, collision detection, and other abilities relevant to the creation of 3D games. Also, Panda3D is Open Source and free for any purpose, including commercial ventures. This book will enable you to create finished, marketable computer games using Panda3D and other entirely open-source tools and then sell those games without paying a cent for licensing. Panda3D 1.6 Game Engine Beginner's Guide follows a logical progression from a zero start through the game development process all the way to a finished, packaged installer. Packed with examples and detailed tutorials in every section, it teaches the reader through first-hand experience. These tutorials are followed by explanations that describe what happened in the tutorial and why. You will start by setting up a workspace, and then move on to the basics of starting up Panda3D. From there, you will begin adding objects like a level and a character to the world inside Panda3D. Then the book will teach you to put the game's player in control by adding change over time and response to user input. Then you will learn how to make it possible for objects in the world to interact with each other by using collision detection and beautify your game with Panda3D's built-in filters, shaders, and texturing. Finally, you will add an interface, audio, and package it all up for the customer.
Table of Contents (22 chapters)
Panda3D 1.6 Game Engine
Credits
About the Author
About the Reviewers
www.PacktPub.com
Preface
Index

Chapter 6: The World in Action: Handling Collisions


Regarding basic collision detection

Question number

Answer

1

A collision solid is a shape used to define a mass for collision purposes.

2

CollisionNodes store many variables that determine collision behavior, including collision solids.

3

A CollisionTraverser is an object that does the actual work of checking to see if collisions happen.

4

The traverse method is passed as NodePath, and the NodePath matters because only that NodePath and its children will be checked for collisions; the rest of the scene graph won't.

Understanding handlers that generate events

Question number

Answer

1

They generate events based on collisions, according to the patterns that we define for them.

2

A collision entry object.

3

%fn and %in, which are replaced by the names of the From and Into CollisionNodes, respectively.

Understanding BitMasks

Question number

Answer

1

A BitMask is a series of 32 bits that can either be 0 or 1.

2

To limit the amount of possible collisions to the bare minimum to increase the overall performance of the game.

3

Using the setFromCollideMask and setIntoCollideMask methods.

4

A From mask limits what an object can cause a collision with; an Into mask limits what can collide with the masked object.

5

Yes, because bit 5 on both masks is set to 1.

Using Python tags

Question number

Answer

1

Using the setPythonTag() method.

2

Any Python object we want.

3

Using the getPythonTag() method.

4

A PythonTag will retain a reference to whatever is put in it, so we have to be careful to remove these references if we want that object to be removed from memory later.

Complex collision detection

Question number

Answer

1

With the sortEntries() method.

2

To get the CollisionNodes we use the getFromNodePath(), and getIntoNodePath() methods. To get the solids themselves, we use the getFrom() and getInto() methods.

3

Since we had two CollisionRays pointing down from the cycle, we checked to make sure that both of them collided with the track. if either of them didn't, then the cycle went off the track.

4

We used the getSurfacePoint() method of the collision entry object to which we passed render in order to make sure we got the point in the coordinate of the render system. We could pass in a different NodePath to get the point in a different coordinate system.

5

We checked the height of the points where our CollisionRays collided with the track and compared them to determine the slope our cycle was on, and changed our pitch to match it. We did this by placing a reference NodePath at one collision point and telling it to look at the other, which forced the reference NodePath to have the pitch our cycle should have.