Since this is my fist post here I thought I should introduce myself. I am an (almost ) 22yr old Architecture student from Romania. I am mainly a 3d artist (been at it since 'bout 2003 and worked as a modeling/texturing artist before I could afford the Arch. college), and in the past 3 yrs or so I’ve also started programing.
I’ve stumbled across Panda3d on DevMaster looking for a solution to quickly get me up and programing my projects. I previously worked on setting up my own framework and pipeline using render/physics/sound/etc libs on the net (at one time even tackled writing my own direct x renderer) but i ended spending way more time on writting tools and on the game engine than on working on the game projects themselves.
I’ve tryed to get a clear picture of the engine’s feature list from the features overview page and the manual (btw thanks gogg for pointing that one out ) but I’m still fuzzy on some features that I would need. I am going to list them, I am curious if they are supported/planned for the future/some one tackled them in personal projects.
-occlusion culling
-paging/streaming terrain/geometry
-coordinates accuracy for large worlds
-1.7’s instancing available for static props(not only animated)
-deferred shading
-decals
-asynchronous resource loading
-integrating bullet physics
-using the python wrapper for game scripts (aka loading python scripts in an c++ game)
What I do know is in panda from reading the manual:
-decals
-asynchronous resource loading
Paging terrain is not in the engine, but there is a blueprint in Launchpad for it. This is something I am also interested in and considering learning C++ by implementing it.
You may also wish to consider switching the c++/python relationship. Make your c++ code as python modules and then use python to glue the whole thing together.
1.7’s instancing works for static props. Furthermore, there should be no issues running Python scripts in a C++ engine, using Python’s C API, I think.
outdoor scenes profit very very little from occlusion culling.
indoor scenes on the other hand profit a lot where objects are mostly hidden behind walls.
as for frustum culling panda does that automatically.
precision is high enough even for big worlds, unless you try to blast our machine’s calculation precision which would require you to make something as crazy as simulating an entire planet which accuracies down to the cm scale. and even if, you can work aroudn most issues.
about physics, there is no bullet integration yet but ODE is integrated.
deferred shading is demonstrated in one of panda’s sample applications which come with your panda3d installation.
decals, well sure, old stuff it is, but still available.
asyncronous loading, all in as well.
paging well even if it’s not 100% out-of-the-box. it takes only a few lines of code to implement it. i once did a very basic implementation for paged loading of objects which was below 20 lines.
about the LOD system, panda has switching nodes which are intended to be used for LOD’ing, on the terrain side there is geomipterrian, which is an implementation of geomipmapping which is quite efficient.
oh and… in case you are curious about performance: no the samples are NOT made to demonstrate great performance but to show basic usage of panda. although most of them run pretty well some people get irritaded.
I am leaning towards Bullet because of cloth and integration with cuda(in the future opencl also). I did see a PhysX extension in the forums that could solve the problem though. I would need to find a way around the redist and linux dev on Archlinux(it has no rpm support, and last time i’ve checked the sdk came only packaged as that).
I was gonna run some of my own benchmarks. What’s python’s hit on performance? (Besides start up time)
Well, as for PhysX on Linux, you won’t get any of the things you want there. PhysX provides GPU acceleration only on Windows. There’s no support for cloth on Linux as well. So you either develop on Windows for Windows, or you might try writing a Bullet wrapper if you feel you can make it and really need that. I’m sure Panda in general would benefit.
Enough for most gameplay code. You don’t want to write any low level stuff in it (make it rendering, physics or even more advanced AI) but for most usage on the gameplay side it’s more than enough. And in most cases what you care more about with this side is the ease of development and prototyping and imho you just can’t get any better with that than Python.
This is not true anymore: Bullet is more robust (ODE sometimes suffers normalization asserts), Bullet it is better optimized for SIMD, Bullet is has some joint improvements over ODE, and better collision detection (ODE convex hull collision is broken), and we are working on GPU acceleration through OpenCL.
If there are important reasons to choose ODE over Bullet, we would like your feedback so we can improve future versions of Bullet.
Yeah, I agree. That statement is old and no longer applies.
Bullet integration would be great, but I’m afraid I won’t have time to implement that in the near feature.
) 22yr old Architecture student from Romania. I am mainly a 3d artist (been at it since 'bout 2003 and worked as a modeling/texturing artist before I could afford the Arch. college), and in the past 3 yrs or so I’ve also started programing.
