Capabilities of Panda?

Sorry David and ETC… I’ve got to ask some questions to help me decide whether to stay or revert to my previous 3d SDK.

The first questions that come to mind are:

  1. Does Panda currently support the ability for an object, such as a player character, to seemlessly enter and exit into a building?

  2. This question expands on my other post about everything being an egg. I was told yes. In that regard then, lets say I’ve created a building, some trees, rocks, the terrain etc… I’m wanting to put all these together now. From my previous 3d SDK experience I just enter the builtin editors and I can place the objects like the buildings, rocks, reform the terrain etc… How is this done in Panda? I’ve been through the tutorials on the Scene Editor, however, I was unable to determine if the editor would handle environments like I’m referring to.

I know Josh stated that the terrain needs to be generated flat and then you’ll need to manipulate the z-axis so I’m not really worried about that aspect, so that isn’t really my question.

ToonTown had its own editor I believe (a level editor) that took care of this, correct? Did ETC write the SceneEditor to slowly replace the level editor that ToonTown initially developed? Is that available somewhere?

My concerns are the capabilities or limits of what I can create. I’m willing to invest the time learning the Panda way if I know that most of these capabilities are already there, without becoming a C++ graphics programmer and implementing them myself. I know C++ and Python, its the graphics part I don’t understand :slight_smile:

Envision a first person shooter type of game. The character runs around in a town or space station, sometimes with a large outdoor area and can enter/exit buildings at will without delay, mount vehicles etc…

This is what I’m getting at.

I really didn’t want to create this thread because I know David and gang at ETC have a lot going on but I feel if these questions are asked now it may stop a lot of the future requests along the same lines or equip some of us non Disney VR and ETC people with the knowledge to reply to them.



Panda3d provides a scene which is populated by models. There is no special treatment given to different types of 3d geometry. The terrain is only ‘terrain’ because it looks like terrain, and only acts like terrain because you code your game to treat it appropriately. Similarly, a building on your terrain is just a large model, or a collection of models. There is no portal or transition dividing the inside from the outside. There is no special treatment of interior spaces versus exterior. The building is only a building because it looks like a building, and it will only act like a building if you code it that way.

For a first person shooter, if you want to transition from ‘outside’ to ‘inside’, all you are really doing is moving the camera from outside the ‘building’ to inside. Unless you code it such that something special happens when the avatar crosses a threshold then all that is happening is moving the camera.

I do not think Panda3d is very appropriate for an FPS, unless you are in the mood to code on the C++ side of the house to add some optimizations specific to the needs of an FPS. Panda3d does not match Torque in terms of FPS optimizations, if you want to do it all with Python. That is to say, in terms of capabilities Panda gives you the ability to do most anything - it just might not be fast or efficient unless you extend the engine. If I was doing an FPS, I would look at Panda3d, Ogre3d, Irrlicht, Cube/Sauerbraten and Torque.

One thing to keep in mind is how quickly you can make apps with Panda3d. Your models are likely to be usable with any of the engines I mentioned above. Panda offers an easy way to throw together tests of interaction and model usage. Panda also would be great for writing your own editors for game assets - even if your game is using a different engine.

Thanks Stampson.

I’m not really interested in just making a FPS (there’s been far too many of those already) as much as just using some of the features that most of the FPS games seem to have. Actually, I’ve been working on an action/adventure type game. This is actually to help my son who has interest and the art ability so I’m mainly doing this to encourage and direct him. My ultimate goal as a parent is to try and give him some skills he can use as an adult, hopefully working in the game industry since he really seems to enjoy the process.

I may have answered my own questions while typing the original questions. I am under the impression that BSP is what give engines like Torque the performance boost? Most all of the static content (bridges, buildings) are done in this way. The buidlings in Torque are not modeled in Maya or Max but done in apps that know how to make BSP type objects ( I guess its simple geometry right? ). You could technically create all your objects in Max or Maya but I believe it would give a good performance hit. In Torque, only the trees, player characters and a few other types of objects (if you needs lots of detail) are not created with BSP.

Python is easier for my son to learn to I wanted to stick with it.

I’m guessing maybe Panda isn’t really the proper tool for the job then.

Let me go a little farther with stamson’s explanation. The reason that most engines differentiate between terrain and “just another 3D model” is to make occlusion fast. Let me explain what that means.

Let’s say you’re in the master bedroom. You’re very close to the adjacent guest bedroom. But you can’t see anything in the guest bedroom, because there’s a wall between the master bedroom and the guest bedroom. The entire guest bedroom is “occluded.”

If the 3D engine isn’t smart about it, it has to render all the furniture in the guest bedroom, and every single bit of it turns out to be hidden by the Z-buffer. But if the engine is clever, it can just decide once and for all that the entire guest bedroom is behind the wall, and that there’s no reason to render any of it.

There are a couple ways to make this happen, but currently the most common method is a technique called “portals”. You divide up your scene into rooms (also known as “cells”,) which are connected by openings called “portals.” Given a terrain which is decomposed into cells and portals, an engine can do a little analysis and determine that the guest bedroom isn’t visible.

The problem with portals is that you have to give a portalized terrain to the engine. To “portalize” a terrain you have to either run a huge analysis program (called a “BSP compiler”) on your scene, which literally takes all day, or you can ask the artists to do it manually, which always confuses them (and it wastes their valuable time). Either way, it’s a big headache.

Another complicating factor is the fact that there are now better technologies than portals. In particular, “hierarchical Z culling” is more useful in outdoor scenes, and it doesn’t require that you provide portalized terrain. It does what portals do, without the annoyance factor. Panda doesn’t support hierarchical Z culling yet. (Most engines don’t.)

So the awkward question for us is, “should we encourage people to use portals, or not?” Portals are an obsolete technology which is a major inconvenience to use. On the other hand, we haven’t implemented hierarchical Z culling yet. So what do we do?

I should mention that what stamson said is all correct. In a properly designed engine moving the camera into a building is just moving the camera. I can imagine that in a badly-designed engine, moving the camera through a portal might require you to go out of your way to do something special. I would not use an engine like that. Portals are inconvenient enough as it is without having to treat “entering and exiting buildings” as a special event.

Wow, good information Josh! I appreciate the effort you’ve taken in your explanation. Torque definately uses portals. I wasn’t aware that was an outdated way of doing things though. I thought the UnrealEngine also used portals and it was supposed one of the most advanced out there.

One of the two main reasons I was excited about Panda was 1) Python and 2) all development on the art assets could be done in Maya. I use Python along with C in my day-job (UNIX) and I’ve purchased a license for Maya. In Torque as I stated in my other post, all buildings and such are done with rather unfriendly software (in my opinion) such as Quark, which was originally developed for the 3d Quake engine.

The good thing about all this is that Maya is the same between both programs, Torque and Panda. The main difference is that buidlings are created in Torque with tools such as Quark or CartographyShop and with Panda you can use Maya/Max.

More info on the Torque .DIF format:

“Why use DIF?” is a common question among beginning developers. It seem like it would be much more convenient to create buildings in a polygon editor like 3D Studio Max or Maya, and indeed it would be. There are some very real technical reasons that we use a BSP Brush editor like QuArK.

The BSP Brush style of object creation, while somewhat limiting in the creation phase, allows for an incredible number of optimizations on the code side of the engine. BSP Brushes are a very efficient way of determining object collision - one of the most CPU-intensive processes a real-time application performs. It also provides numerous shortcuts for culling of visibility through the use of “portals” so that rooms and terrain that the player can’t see don’t get sent to the graphics card for rendering. This is a lot harder to do, from a mathematical standpoint, than a non-programmer might imagine.

Does the panda3d engine handle occlusion? If I move the camera inside a box, does it occlude the rest of the scene and improve efficiency?

I guess I have been assuming that Panda simply culls the bits that are outside the view, and everything else is rendered unless its clipped.

In my design, I’m going with a third-person camera view of the avatar, with a view angle relative to the ground that is slightly limited in range, so that there is a built-in limit on horizon distance. Eggs representing segments of terrain (prebuilt models) and models on the terrain will be ‘paged’ in as needed to display the area around the avatar. Models will fall off the scene at the ‘back’ as the avatar moves one direction, and be loaded (hopefully beyond view) in the ‘front’.

I am planning to handle interior spaces by having a transition, such that the avatar approaches a ‘door’ and then a scene is built representing the interior. The interior will be a separate space. Since my game is not an FPS, this is mostly a cosmetic issue - it would be nice to see out the window, but that is just one of the constraints placed on the designer of the levels in my game.

I’m approaching the use of Panda3d for my project by looking at what I can (hopefully) do with the capabilities that are already there. Good things happen to game design when designers are limited. It’s like a director working with a handheld, black and white camera - he can make just as good a movie in that format. It won’t be the next Lord of the Rings in terms of visual effects, but it could be oscar-worthy.

Good information Stampson!

I’m wanting 3rd person view as well. I downloaded ToonTown to help give me an idea of what may be capable with Panda. What I gleaned from playing ToonTown is that if I’m going to develop with Panda things need to be on a smaller scale. That is why I thought they implemented the doors and such like they did. By not actually entering a building seemlessly like we do in real life, they are just redrawing an entire new scene and then displaying it. Not really a transition in my opinion.

I’m not sure the vision of the game we are creating will look good from that point-of-view.

So terrain has to be pre-built meshes and need to paged? That might put a spanner in my works…

Interesting topic folks. Keep at it!

Does the panda3d engine handle occlusion? If I move the camera inside a box, does it occlude the rest of the scene and improve efficiency?

Only if you’ve portalized the scene and the inside of the box is a cell. But this doesn’t happen automatically, and there’s no manual page on how to do it manually. If you really want to learn how, though, it is possible.

  • Josh

stodge: there are lots of ways to do terrain. Many games simply create the terrain in 3D studio Max. A lot of games use heightfields. There are so many ways to do this, I can’t list them all. Put it this way: tell me what you want to do, and I’ll tell you how to make it happen.

I was hoping to have an API or a node type that would let me create terrainfrom a heightmap. I’m not a modeller so being able to do this would make life very easy for me.

I don’t like comparing apples and oranges (how I hate that overused phrase!) but I need something that rivals Torque’s terrain quality (or near as dammit). The terrain needs to be around 2 miles * 2 miles (sorry for any Canucks reading this).

I just have an idea in my head for a game that I want to prototype. Because I love Python, it’s easier to develop than having to deal with C++, I can try to use Twisted Matrix, Boa Constructor and wxPython and other fun stuff, I thought it would be cool to see if I could prototype my idea with Panda.

If I have to use meshes, then no big deal - I can probably find a script for Blender that will create meshes from heightmaps and I can export it from there. I could probably just stick them side by side to create larger terrains and maybe page as appropriate if required.

There are other obstacles before I can proceed (Python 2.3, moving Panda into site-packages etc.) but it’s an interesting challenge!

Just to clarify the obstacles - this isn’t high priority or important, so hopefully noone is running around trying to find solutions to my questions! :smiley:

I need a little more information: what kind of resolution do you need in your heightfield?

This is an important question. Let’s say you’re making a game on the scale of “a bug’s life.” In that case, your grid cells need to be very small - maybe 1/8 inch x 1/8 inch. On the other hand, if you’re making a flight simulator, then the grid cells can be quite large - maybe 32 feet x 32 feet.

The feasibility of doing a 2 mile terrain depends a lot on the size of your grid cells.

Hmm, I’m afraid I’m not knowledgable enough about heightmap resolutions to answer that. But if it would help, I could PM you a brief description of the game prototype, which might help answer your question.

Thanks again!

I don’t want you to think I’m asking a technical question. I’m only asking how big the objects in your game are going to be.

Let’s say, hypothetically, that you’re making a game which is a flight sim. In that case, you’re going to be moving very rapidly over the ground. You’re also going to be pretty far away from the ground. Under these circumstances, if there were (say) a daisy on the ground, you wouldn’t even be able to see it. You’re moving too fast, and you’re too far away. On the other hand, let’s say you’re making a game based on “A Bug’s Life.” (have you seen the movie?) In that case, that same daisy would fill your entire screen.

Likewise with the heightfield terrain. Let’s say you had a mound of earth that’s one foot across. In the flight sim, that would be too small to see. In “a bug’s life,” that same one-foot mound of earth could house the entire colony.

So I guess I could rephrase my question: in your game, what’s the smallest hill that’s worth rendering? In a bug’s life, I’d say a half-inch hill is a pretty big hill. In a flight sim, I’d say a fifty-foot hill is just barely big enough to be visible, from up in the sky.

For me, what I’m looking for is an immersion quality. Most of the stuff I’ve scene as examples with Panda doesn’t give the player a feel of depth in the world. Everything is either an enclosed room, or if its an open environment, you don’t see very far away. I realize most of the stuff I’ve seen is developed over a very short period and done for a specific reason so I’m not knocking it, its just all I have to use as examples.

If I’m entering a building, I don’t want the player to have to pause everytime they want to enter a new room in the structure they’ve entered. The game also has flying vehicles, ground based vehicles and some underwater areas. For me, the level of detail needs to change as the distance does.

Ah I see! I thought you were wanting some techno-shpeak information. :laughing:

Object scale would be 1 unit to 1m, so real world size. Hills would be say two or three storeys high at the very most. People would be typical human height - let’s say 6 feet tall. The camera would be floating would never be much higher than the highest hill.

Does that help?


Okay. So I’d say that your heightfield control points should be about ten feet apart. That’s close enough to create human-size hills, but not so close as to be pointlessly close. The terrain is two miles across: 10000 feet, roughly. That means your heightfield is 1000x1000, for a total of 1 million vertices. That’s too many to render all at once. You need some tricks to limit the total.

You might want some sort of limited visibility radius. Is there any particular visibility radius that seems good for you game? If it’s a game that has panoramic vistas, then it needs to be far. If you’re moving fast, then it needs to be far. If not, then it can be short. What do you say - can we limit visibility, or would you rather not?


I get the impression that you’d like to have some panoramic vistas in your game. Is that what you’re saying? If so, then that’s tricky, in any engine. You have a couple of options.

One is to allow the player to see into the distance, but he can’t travel very far into the distance. Lots of games do this: for example, Halo. In Halo, you can see the ring arching into the sky. Conceptually, that ring is part of “the terrain” (Halo is set on a world which is a big ring). But you can’t actually walk up the ring. Because you only ever see it from a distance, it can be modeled simply - just a few polygons - instead of modeling it like the rest of the terrain (individual hills and bumps).

On the other hand, if you want to be able to see a mountain in the distance, and then walk for a very long time and eventually arrive at that mountain, and then when you’re there, you can see individual little bumps on the side of the mountain, then you need a level-of-detail system.

There are several level-of-detail methods. ROAM is one of the older ones. Panda can’t do that very well. Geomipmapping is another approach. Geomipmapping is where you divide the terrain up into patches, and for each patch, you decide whether to render it at low, medium, or high detail. Panda can do geomipmapping without breaking a sweat. Geometry Clipmaps are another LOD algorithm. It’s a newish approach, and would be a little tricky to do without extending panda, but I think that extending panda would be very easy.

So what are you most interested in?

Visibility? Not sure what figure exactly I would want, but it’s turn based so it’s VERY slow paced. I wouldn’t need to worry about how fast polygons are getting pushed around. I guess the fastest requirement would be moving around the map and turning the mouse to rotate the view.

I haven’t decided what polygon count to aim for on most objects, but visible distance isn’t too important. I am thinking of trying to include minimal low polygon buildings, water and foliage.

Sorry if I’m dragging this off topic.

Ok, but on the other hand, if this is turn-based strategy, being able to get a “big picture” view might be pretty important. Maybe visibility radius is more important than you think.

You’ve got a tricky challenge. Big terrain, high visibility.

Tell you what. This is getting complicated. I’m going to write up how to do this, but not here. I’m going to put it in the manual. Give me a day or so.