Choosing Panda?

General Discussion
1

I evaluated Panda for our game 3 months ago. I found it to be a breath of fresh air in terms of instant installation, no fuss compilation, and being able to produce high quality appearing scenes. I also found that these forums were shockingly helpful. All these pluses weren’t enough at the time to stop us from opting to make the mistake of the converting over to Ogre. I’ve now wasted three months more after a year building under Irrlicht.

The deciding factor was that I was unable to produce quality shadows with Panda3D. Even the samples were inadequate, and as I demoed our models, it was clear they were not acceptable (at least on the mac, I didn’t try on windows). I also had some concern because of the python centric documentation since we are working with C++ exclusively. But the shadows sent me off on a wild goose chase to try and use Ogre. I think we are about to give up on that or would like to. I’d like to reconsider Panda3D as it had already easily won before aside from shadows, and after working with Ogre, it’s even more the winner for what middleware should be, a black box that your programming uses.

We have at least another year of work to make our game beta quality. Will panda3D have a shadow capability of the quality of Ogre and Irrlicht in the near future? With Irrlicht the quality shadows came at a price of horrible performance (which is what stopped us there), with Ogre, it’s great shadows and nothing else without a tremendous amount of pain using undocumented and outdated information which doesn’t ever seem to get corrected nor is adequately explained in their forums.

What is on the horizon for panda3D in shadows? Will they be there in a year?

2

I too am new to Panda, however, being able to use shadows at all was a deciding factor for me! Before I was considering Unity 3D, however, I didn’t want to pay a lot of money to “maybe” produce a game. Panda won me over for this reason and one of the very first tests that I did involved the use of a lot of shadows (I was working on a Lovecraft inspired game). I have to confess I was pretty impressed with the overall look and performance.

I baked an AO map in my 3D application to be the base of my diffuse texture so that I had a nice looking soft shadow for elements of the scene that were static. I had a light inside of a light bulb model at the top of the scene that would randomly flicker, dim and get brighter. Then finally I had some light coming in through a window as well as a door.

Overall, it looked quite good.

Perhaps you can show some screenshots of what your complaints with the shadow system in Panda is? Maybe highlight the difference in quality that you get between Ogre and Panda? I would be interested in seeing some examples of varying quality. I’m sure other forum members can give you a lot of techniques as well for tweaking what you can and convincingly faking what you have to!

-ZM

3

I hadn’t considered that the issues with dynamic shadows could be fixed. The threads I read had suggested that what I was observing was normal. I don’t have an Irrlicht or Ogre screen shot of the same, but they are what you’d expect from stencil shadows, well defined and matching the shape of the casting object. The shadows in the bed of the truck show the problem. The light is coming from above through the stakes (the uprights that would normally hold a canvas cover). They are fragmented with numerous drop outs. They don’t seem to match the surfaces they hit. The shadows on the ground below the model are the same, fragments. On my mac, this was about the same thing I saw in the python based shadow demo. Perhaps this is not what people expect on Linux or Windows?

sb.png749×431
[/img]

This was generated with a spot light (spot->set_shadow_caster) though I’d tried it with other lighting. It has been 3 months so I don’t remember all that I tried, but it was everything I could find in forum posts here.

Perhaps the existing dynamic shadows are better than what I’m seeing? Believe me, if so, I’ll start a new conversion project tomorrow :wink:.

Concerning static shadows, the modeler has not begun on that for any of the levels yet, so I am currently not even able to judge that.

4

Not being a developer for Panda, nor having worked with Panda for any real amount of time, I can’t really say what’s happening in respect to shadows.

I think the main reason for your shadow fragments is that you’re using a rather low resolution shadow map, from too far away. Simple fixes would be to either move the light closer, or increase the shadow map resolution (which then impacts on FPS).

Alternatively, there are one or two things on the forums that might help you further (another option would be to write some shadow shaders yourself, which I assume would fall under the category of ‘too much effort/work’).

PSSM: [PSSM Shadows)
[Parallel-Split Shadow Maps (PSSM): Shadows for large scenes)
PCSS: [PCSS soft shadows)

I haven’t tested any of these myself. For my simple projects I’m mostly skirted around the shadow issue so far.

Anyway, hope that helps.

5

if you need stencil-shadow quality, you should use stencils to start with, instead of panda’s buffer-based shadows.

as far as i know, panda does support stencil operations. so i guess it is a matter of writing the stencil-volume generation code.

if i remember correctly then it was treeform who once played around with stencil shadows, long time ago.

6

Thanks for all the responses. I gave up too soon perhaps.

Dramatically bumping up the buffer sizes on the shadow caster brings the buffer shadows inline with the quality of non-stencil shadows in Ogre, in fact they look better. I’ve just briefly looked at the results but they may be good enough. It was as simple as spot->set_shadow_caster(true,4096,4096);.

Thanks on the note about Treeforms work from 2007. I will see to understanding it and seeing what it offers. Using stencil shadows under Irrlicht was the wall we hit along with a couple of other performance issues.

On the “too much work”, yes, we drew the line for practicality. Two people can’t develop all scenario, music, art, and glue for bullet physics and graphics, and code the middleware too. Serious shader work takes a full time person. From two hours building a Panda3d demo, the graphic quality is better than what I’d achieved with Irrlicht spending the months adapting various shaders, i.e., it’s better out of the box and that equates to time. This trend was forming with Ogre. I may be naive, but it appears that Panda3D has most necessary shader code set up and hidden appropriately, much as one would expect with a commercial middleware product (which unfortunately none exist cross platform or we would have gone that way at any cost). It’s a matter of how many years one has before releasing. As an example, If you compare the level of work in doing normal maps under Panda3D and Ogre, it makes the shader and material work under Ogre “too much work” and we are trying to cut corners for very important reasons. Admittedly, I’ve not tried a normal map on Panda3D, but the appearance is that everything is there, you don’t have to write it yourself.

Thanks again for correcting my misconception of Panda3D shadows. We will begin again on the Panda3D eval and probably conversion. I should have asked this question three months ago.

7

I’d love to see stencil shadows implemented in Panda. Either that, or soft/PSSM shadows, at least there is some code posted by users for those.

To be honest “proper” shadows is one of the very few things that I feel Panda is lacking, even though it’s still the engine of my choice. You could argue that people should write it themselves, but then you are arguing that people should write their own shaders, which most don’t have the time or knowledge for. Builtin shader effects (like normal mapping) can very often be a decision maker when choosing an engine, like here.
Does anyone agree?

8

I do.

If Panda didn’t have the autoshader I still would be looking for an engine.

It would be great if Panda had more eye-candy out of the box (more shadows options, terrain and water shader, deferred shading, more post-process effects).

9

I think I implied my agreement already.

The eye candy issue isn’t so important if you find that very basic quality rendering requires stealing shaders and extensive setup outside of your programs. Those occupy too much time. In assessing what I like about what we’d done in Irrlicht, I concluded that it was what we’d implemented in the shaders. It turned out the same is true in Ogre, only there, it was becoming very time consuming to make them work as well as they had in Irrlicht. I came back to my panda demo scene last night, hastily put together, and it was like coming home. It already had the specular and smoothing that my shaders were providing for Irrlicht, and hadn’t even equalled yet with Ogre.

Middleware should implement the basic fundamentals of it’s purpose and expand out from there, and do that in a way that is documented and thus reachable by it’s intended audience (which isn’t more middleware developers). I’m thinking that Panda3D seems to hit those fundamentals the best. If we have to code the expansion areas, that is way better than coding the basics. Now we have no close up water scenes (yet), our terrains are just meshes, our “fundamentals” are shadows, normal mapping, being able to layer textures, and have nice looking light reactions. Panda3D seems to do all this without much fuss. For me that equates to getting back to programming our scenarios and away from dealing with details that should be handled by the engine. At least I’m hoping :wink:.

One basic; shadows, comes out this way for us. Here is the after picture taken at approximately the same angle after increasing the buffer size. I consider these acceptable shadows and enough so, that I wouldn’t want to risk the performance hit for stencils. I do have some light “leaking” through on the shadow on the level, but it’s not something that will be noticeable. I’d provide more detail but the physics isn’t in this yet, and the truck is just stationary at it’s spawn position, the wheels and resting place on the level happen in the physics call, this was just a demo to look at our stuff in Panda3D.

sb2.png710×398

10

I don’t know about Ogre or Irrlicht, maybe they don’t provide even half of what Panda offers out-of-the-box, but they are only 3d engines, of course they provide less. Users of these engines are expected to have enough time or knowledge to integrate other libraries for sounds, physics, etc.
I would compare Panda with an actual game engine like Unity. Unity has all these shadows out-of-the-box. If I had a project where I absolutely needed these effects, I would have to go with Unity because I wouldn’t have the knowledge nor the time implement it myself. And that’s what I think others do, so I believe adding just 1-2 more features would provide more users and therefore more contributors.

Anyway, sorry for going off-topic, I thought your questions were already answered.

11

My question was well answered already, and I was going off-topic too :wink:.

I don’t mean to bad mouth Irrlicht or Ogre. Irrlicht is as easy to use as it gets but you are going to program your own extensions to build a real game. People seem to be doing that, it’s not practical for our game. Ogre is feature rich, but the docs and forums don’t expose those features (sometimes it does, but then the docs will be outdated and still not work) and it can take weeks to do what was advertised as a feature. If you are serious about cross platform, it can take weeks just to install or upgrade. My point above is that what panda3D advertises, is documented (at least to python users, which can be converted with relatively little pain) and can be done in code that uses the engine rather than having to extend it, guess how to do it, or do too much work outside of the engine (e.g., shaders).

I was not thinking of panda3D as a game engine in this, most of those features are the type thing that granular control seems necessary for (AI state control, physics) making your game something innovative. We already have the bullet stuff worked out. It’s the 3D engine functions that are so attractive. Given that that is my perspective (though a little myopic), then having more eye-candy as expressed above, would be my wish. It’s not something I think we will need at the moment though. Good accessible basics are what we need to get out of the rut of redoing mechanics and on with building our scenarios.

Since I’m the one so far off my own topic, the “feature” I would like to see before eye-candy, is completion of the manual for C++. But, that is workable. I also note that there are features that are trivial in Ogre that are going to require reviving some of my Irrlicht do-it-yourself work, for example, skydome with weather. I can handle that sort of thing quickly though, while something like shadows, no way.

12

Since you’ve admitted this thread has gone completely off topic yourself, may I ask why C++? This is interesting to me especially given how focused on time efficiency you seem to be. Python is a much better language for writing gameplay, and for an advanced coder learning it is a matter of days. And Panda with Python is a very powerful combination (not to say that with C++ it isn’t, but it’s just quicker to get things done with Python).

13

My day job, my business, is all with interpreters (PERL and PHP), when I retired from my previous life, my career had devolved to Visual Basic and ASP toward the last (MS Mania in the corporate world), though C and assembly were my first loves. I recognize the value of scripting languages, but it does come at a price. Since I’ve never done any game coding in anything but C++ and Java, I have no idea what that price is, it’s totally guessing.

When we started to design this game (the design started about 3 years ago, it was a high school english project my son was working on), it was clear that it was going to stretch any platform it would run on. When you have your sights set on producing something with lots of AIs and lots of story, it seems likely that every CPU cycle is going to count (We found that quickly enough with Irrlicht, though admittedly, the CPU was being hogged by the stencil shadows, I could crank the number of AIs with shadows off). Even now we still fantasize being able to field 30 AIs (unrealistic I realize) and do it on 18 month old costco level junk hardware. :laughing:

I have to admit, there is some draw in seeing what people have done in Python. I could probably convert what we have as quickly as going from Irrlicht to Panda in C++ (the Ogre conversion isn’t worth using, I had to change to Quats, the Irrlicht version is all Eulers, more Panda friendly even with the change in handedness), especially since there is a lot of code ready to use out there. I’ve noticed that people don’t abstract their Python code for the sake of abstraction as is done with C++, and that renders a lot of code and good ideas non-reusable in the C++ world (due to obfuscation). But I’ve still held out that we may need the performance.

Practically, you got me here, I don’t have any benchmarks to say what the performance edge is, other than hearsay. It does stand that I can’t do anything about what goes on in an interpreter, and that is a limitation I’ve lived with in work which may not matter in this venue. I also have the concern that threading may be an issue with Python (currently unfounded but likely).

I appreciate the comment because perhaps I should be thinking along these lines. I’m about to effectively start over again anyway, you got me thinking hard. Sure would be easier to read the manual :wink:.

Sorry for the length, it’s the way I talk.

14

since panda is c++ under the hood, and only controlled with python. chances are that 99,5% of your code will run fast enough in python without any optimisation.
from the remaining 0.5% you usualy get 99 out of 100 cases where you use panda in a way you should not use it, or you are not using an existing optimisation.
from the remaining percentage there often is optimisation potential within your algorithm.
then there often are external libraries that might do the trick (numpy saved me quite a lot).
and if everything fails (it never did for me since since, dunno 4 or 5 years), you can still rewrite a slow algorithm in c++ and simply call it from python.

from my personal experience, being able to code c++ is a nice bonus, but absolutely not necessary with panda, unless you want to extend the engine itself or when pushing your hardware’s limit. having said that, most of my applications even run on a now 11 year old laptop with 850Mhz, 256MB ram , savage3d gpu and 16meg texture memory. And they are all python coded.

prototyping speed clearly wins over the speed gain in c++. at least for me.

15

Sold! :wink:

Seriously, development time is pretty crucial too. Plus, I’ve been eyeing some Python snippets here on the forums…

I’ll convert my panda demo over tonight, give Python a try, though frankly, I think I made it by converting from Python pieces in the examples in the first place.

I do have another question then. We are using bullet physics 2.79 (though 2.78 was adequate) for the raycast vehicle controller, ghostobject/character controllers for player character and all the AIs, and the debugdrawer. Collision is currently handled in a standard bullet Tick callback. Is all this pretty seamless with the bullet version that Panda Python uses? A quick look at the manual suggests that everything is there, but what version do you get when you use the Panda version from Python. I presume I can’t keep my own copy any longer if used from Python.

16

It’s a pretty solid implimentation.

Check out the samples.zip here in the developers first post here: https://discourse.panda3d.org/viewtopic.php?t=10231&start=0

Hope this helps,
~powerpup118

17

Thanks for the link. It does look very clean. Unfortunately it also points out that the OSX version isn’t ready, and will only be available on 1.8 (now I know why there is no libpandabullet in my lib). It also requires significant changes to how I’m doing collision (iterating through the manifold in the tick callback, I don’t use groupings on collision masks). That is a major change, but workable and could be for the better. But it does accommodate something I’ve spent a lot of time on with the other engines, tri-meshes can be added without manually pulling the mesh data from the 3D engine. In Ogre, that took quite a bit of time for the levels.

With bullet driving all the positioning, I’m not sure I could accomplish much in python until 1.8 comes out. In C++, panda and bullet can be kept discrete. This was a strength in not using IrrBullet, as conversion to Ogre was seamless from a physics standpoint. I’ll go check when 1.8 will be available, that would be a deciding factor, and of course, if OSX is still considered experimental when it does, that might suggest staying with C++ anyway.

Regardless, this thought exercise is very valuable. Thank you.

P.S., I would never have gotten this much out of a forum post on the other two engines. That says a lot about this community.

18

While 1.8 is not officially out, 1.8 builds are available on the download page. I’ve personally never had an issue with the nightly builds, but individual mileage may vary. My suggestion, get a build and as long as it works for your needs continue using that build until 1.8 official comes out. If you do eventually run into an engine bug then update to the latest nightly build.

19

Off-topic in a off-topic, what do you think about labeling some daily builds (which are considered solid enough or have completed the implementation of a specific feature) with tags like “alpha x”, “beta y”, “release candidate z”?

20

Technically, you could. You would just need bindings for it. Whether it makes sense or not is a question you have to answer yourself by evaluating the pros and cons. I don’t use Bullet (I built my stuff around ODE when Bullet wasn’t yet supported by Panda), but I know the implementation is relatively solid. Then again, it all depends on how much you’ll have to change and how you feel about writing bindings for your Bullet code.

I keep saying that the community should be listed as Panda’s feature.