The suitability of Panda to my project

Greetings all. :slight_smile:

I’m planning a project that I believe to be rather larger than most (perhaps any) of my previous game projects. As a result of the expected size of this project, and my desire (probably at least in part as a result of that size) to concentrate more on the game than on lower-level concerns, I came to the conclusion that it was time to move on to the use of an engine, for some projects, at least, and this one in particular, rather than my usual C+±and-OpenGL course.

Please note that by no means does this mean that I’m opposed to doing some programming, although I would prefer to either stick to C++ or use a scripting language (either of which seem to be available with Panda). :slight_smile:

Having done some searching and a little asking, I’ve come up with a short list of engines that I think might be suitable to my project, one of which is Panda. However, I don’t yet know just how well Panda might work for me, particularly in terms of the game environment that I intend on using and the system specifications of my computer.

The game, in (very) brief:
A first-person 3D adventure game (as was Sherlock Holmes: The Awakened) set in a forest Otherworld (although I believe that I have enough variation in environment, including some areas that are not tree-bound, for this to not become boring).

Points of concern:

  • I want to provide large, forest environments for the player to explore. While I don’t mind chunking them to some degree, I’m still looking at fairly large terrains with a fair bit of vegetation.
    [list][*]I will probably be wanting heightmapped terrain
  • I want various regions of the forest to be populated with specific types of tree, with the tree types being “blended” between region edges (that is, in parts of the forest that are not within a “region”). I currently intend on using tree density maps for this, as well, probably, as hand-placed trees in certain places, although I’m open to other methods.
    ]My system specifications:
  • Windows XP
  • P4 2.4GHz
  • 1GB RAM
  • FX5200 graphics card

Naturally, given these specifications, I don’t expect to employ the latest shader technology. :wink:[/*:m][/list:u]

A note:

  • I don’t require complex collision detection or physics for this project; although more complex physics might be nice, I’m happy with fairly basic collision detection (polygonal collision detection and response, and perhaps circle or cylinder support as well), as long as it works well. 2D collision detection could work, for that matter. Simplicity is preferred here.

So, what opinions have you? Do you think that Panda would be a good choice?

My thanks for any help given. :slight_smile:

well the main problem is drawing of frosted terrains. You will run into this problem in any engine not optimized for such things (ie Crysis.) Your biggest problems are going to be pixel over draw because leaves on the trees will be more or less transparent.

There was jungle demo some place … but much of the panda3d tech has improved since then. The terrain is taken care of with GeoMipMapper (also you might need some texture and shader foo to map it properly)

I would recommend reading … _ch07.html … ter01.html and other such tutorials.

Panda will be a great boost. After you get over the hurdle of drawing large quantities of trees the rest will be easy.

Thank you for your reply, and for those links - they look interesting. :slight_smile:

Hmm… Does Panda support imposters? That would, I believe, help quite a bit.

Bear in mind that I’m doing this with an FX5200, so shader support is, I think, limited to some degree (although not, I don’t think, non-existent). I’m not sure what limitations I might encounter - I haven’t embarked on shader experimentation yet - but I don’t want to count on using very recent shader elements.

By the way, I find it enjoyably appropriate that my question should first be answered by someone with such a username. :wink:

i second treeforms statements.
panda is quite capabale if it comes to outdoor environments. geomipterrain already can help you a lot. rendering a forest can be more tricky but nothing that hard.
things like a good LOD-system which draws small plants only on small distance aswell as reducing the level of detail of far away objects.
i hardly belive you can get forests like crysis where you can see an entire island covered with forest. but you can have some really neat,dense forests with some limits on viewing distance. maybe a few hundret meters viewing distance without breaking performance.
using density maps is as well possible as using random to add more variation.

most of what you’r looking for was already done in the jungle demo

the shaders you would want to use are about the most basic ones used to blend textures together. even gf3 and gf4ti series can handle them well if you dont overdo it. you hardly find grafic hardware not supporting those.

what do you mean with “does panda support imposters” … what would be an “imposter”?

That sounds encouraging, ThomasEgi - thank you. :slight_smile:

A view-distance limitation of a few hundred metres shouldn’t be a problem, I don’t believe - one element that I forgot to mention is that I’m pretty sure that I’ll be sticking to human-height views, with no aerial views of the forest. Such situations as looking out over a lake towards distant forest will probably be faked using textured quad-strips, or something similar.

An imposter is, essentially, a fake, 2D version of a 3D object. The idea, as I understand it, is essentially a level-of-detail measure, in which distant trees are replaced by textured quads (or something similar), the texture being a generated view of the model being represented, if I recall correctly. It sounds (to me, at least) as though it ought to produce visibly incorrect results, but I believe that it can actually work pretty well.

Again, as I recall, they’re useful in forest rendering (as well as having seen an OGRE forest demo that I believe employed their use); distant trees are replaced by imposters.

This article would seem to provide further information on the concept. :slight_smile:

Yeah i was going to mention a technique that loads geometry back to just images but i could not remember its name - “impostering” - is correct. Normally when you need a new view of the model you draw the model into an off screen buffer and then update that only when need too.

Fair enough - although I’d prefer an automated handling of it, I think.

Nevertheless, so far, so good. :slight_smile:

Well no one really needed impostering at this point. I also think it would not give you as great of a performince benefit as mashing low lods and stuff together like with the pyro system i been working on.

I think impostors could be useful. They could render a model on a transparent quad at a low resolution or frame rate even. This could produce pretty good results at a distance without the “popping” effect problem that mesh-based LODing has. I’m gonna add this to the feature request list. Maybe I’ll even implement this myself…

Just a small note: I have the FX5200 as well, and I’m using quite advanced shaders already – advanced enough to make my game look quite good. It’s a good card overall, but the only drawback is that its quite slow on pixel shaders.

about this impostering LOD. shouldnt this be quite easy to add?
we already have lod-switching conditions so it sohuld be possible to flag an lod-level as impostered, and if the level is to be shown. let panda create a texture-card of appropriate size, render the object in question twice in an offscreen using ortho-camera from the same angle as in the real scene (once in color, once white with black background for transparency channel.) and show it.
points for optimisation:
-flatten several imposter together in one geom to speed up batching.
-auto-regenerate imposters if the angle at which you are looking at them passed a threshold.(combining those with flatten and using a “cone” which represents the volume in which the camera can be without the need of updating the group of imposters also speed up things over creating individual ones). a system simmilar to geomipmapps autoflatten might be good,too.
-using many offscreen buffers might drop performance, so if many imposter images have to be created one might be able to arrange them side by side and render 4 , 16 or more objects in one call (which would also be beneficial cause they can share a single texture if you pack them together in one geom).using bounding volumes when arranging

The most simple form of impostors is know to Panda3D users as “billboards”. A quad with the whole tree on it. More complex would be to choose between, say, 12 different quads depending on the view angle. Panda3D allows to use point geometry for whole cells of billboards, so impostor LOD is quite easy to do. Have a look at the Ogre3D “Paging Geometry” AddOn Projects. Most of it is already there.


I wonder if some of this stuff is better implemented in the C++ engine instead of in the Python script. It sounds like this would take a lot of extra Python function calls per frame, which means these “optimizations” may actually make things slower.

Is there some way built into Panda to call a function only, say, 10 times a second instead of every frame?

I know jMonkey Engine has support for Impostors. It’s written in Java, but it’s BSD license so maybe we could swipe and port some of their code?

doLaterTask can handle the periodic updates.
if you organize it right i dont see a problem using python. it’s not like you have to loop through 5000 objects each frame.
question of implementation. whereas an easy to use c++ thingy is always something nice :slight_smile:

My impression (albeit not yet seriously researched) is that it is a pretty effective technique.

I’m not sure what you mean by “mashing low lods and stuff together”, treeform, but if you mean combination of meshes into a “supermesh”, then I would imagine that one could do the same with imposters.

I see that you have added it - thank you very much for doing so, and more yet if you take it on yourself! :slight_smile:

If you do take it on, the article that I linked to earlier in this thread might be of use to you, as might this thread on the OGRE forums. I see that there’s a link to a page on the project described in that thread in the first poster’s signature, although whether there is more information there than in the thread I don’t know. The forum linked to in the same signature looks as though it may well have useful information within it. :slight_smile:

I think that the source code for the project in the linked-to thread might be available, too. :wink:

I suspect that one might be able to get away, in some cases, at least, with completely pre-computed views (I think that I’ve seen such done for forest rendering, at least). With enough angles on, for example, a given tree, one should, I think, be able to do without the rendering phase for some objects.

Of course, this might not work well for all objects - it might actually be more efficient to perform the “low-frame-rate-rendering” technique on objects that change, or animate overmuch, for example.

Perhaps, if such a system is found to work, one could flag objects for representation by pre-generated imposter textures (and, of course, specify the texture map or atlas, and at least an offset in the latter case), and have the code fall through to render-based generation if the flag is not set?

Aah, I’m glad to hear it! :slight_smile:

I’ll admit, I spoke primarily from my experience in playing games - I find that games that use shaders tend to not play well on my machine unless I reduce the shader usage (usually to “low”, as I recall, albeit not necessarily “off”).