Feature Requests.

We do support a CollisionParabola, used for trajectories. Is that what you are after?

That is just a single line. I’m hoping for a curved plane.

py-lepton particle engine integration


Above examples use Pygame or Pyglet (OpenGL) for rendering.

I had trouble with some dlls with the default windows installer version but got it working by getting and compiling the source myself.

I would love to see some additional attributes for the default ambient lights, namely:

  • Falloff (to create patches of ambient light in a scene)
  • Hemispheric options (provide two colours, final colour is interpolated based on the pixel’s normal)

I know I could write these myself, but it would be really nice to have out of the box!

Sorry, but these are not properties of ambient lights that we can configure. We’re limited to the set of lights and light settings that OpenGL and DirectX can provide. We could make a light type that only works with the shader generator, but it would probably be best to keep that as a separate light type.

I believe that the possibility of having armature manipulations via “controlJoint” blend with animations has previously been discussed and turned down, but I would like to make a suggestion, if I may.

I would like to suggest implementing such a blending by considering transformations made via “controlJoint” to be essentially a static “animation”; blending might then be achieved as with standard animations, with the blend weight being set by passing a constant to “setControlEffect” in place of the animation name.

(For my purpose which prompted me to consider this I think that I’ve found a workaround, if a slightly awkward one, but I do think that such blending has the potential to be useful.)

Perhaps that could then better be a separate mechanism, since you don’t want to take direct control over the joints per say, but instead create a custom one-frame animation that you constantly modify the low-level data of. I wouldn’t be surprised if the current system could be hacked into doing that.

A replacement for the whole Actor class is also on the list (though I wouldn’t have time to get to that any time soon), one that is implemented in C++ and does not inherit from NodePath.

That’s actually a rather interesting idea, and it looks as though it might work, with sufficient research into the inner machinery of the Actor class. Thank you. :slight_smile:

The replacement for the Actor class sounds interesting – is it intended to have any new functionality, or do anything different, or is it just a matter of moving it over to the faster language?

Actor currently inherits from NodePath, and it is bad design for anything to inherit from NodePath. It frequently raises issues for people when their animations stop working when their Actor object goes out of scope, or when CollisionEntry.getIntoNodePath() returns a non-Actor NodePath. The proper way would be to make it inherit from PandaNode and implement it in C++. This will have the added benefit of increased API coverage for C++ users as well, which is what we’re moving toward.

Remember that Actor is just a thin Python layer that binds all of the (C++) animation APIs together into a neat little interface. It does not do much by itself at all except reroute your calls, which is why this wouldn’t actually be much of a performance boost.

This question was discussed in the another topic, but just in case I raise it here.
It would be great if we can include shaders directly in the egg file and set it to the material or face. Relative message: Blender as a GLSL editor

Just wondering if autoshader can be tweaked for the next release:

  • Normal and specular maps don’t appear to be affected by parallax maps. Is it possible to fix this?
  • Is there any way to export parallax maps from Maya? I can’t see a way to do it in the manual so I’ve just been adding envtype { normal_height } by hand to my egg file!

Would love to have findAllMatches be able to return NodePaths tagging with a Python tag.

Real not-fixed function pipeline-like projected textures.
Everyone using other engines project blood and similar stuff on their characters. I can’t as they will show up on “both” sides of the character.

You can do that by adding a second TextureStage on top that that uses a projected depth texture with the filter type set to FTShadow. It’s very similar this way to shadow mapping, since that is essentially the same as projecting a purely white texture.

Keep in mind that there are more problems with this approach to blood splattering than just occlusion; if the model moves or animates, the texture won’t stay in place. An example of this problem can be seen in this video (warning, gory) which incidentally does use the depth texture approach.

Don’t know how.

BTW, can we have every module in direct.extensions not have pointless indentation? py2exe keeps complaining there is an unexpected indent.

The files in that directory are not intended to be imported by anything. They’re not valid Python modules. Can you instruct py2exe not to parse the Python files in direct/extensions?

Oh, I’ll do that then.

gamedev.stackexchange.com/questi … 8300#58300


I would like to request that there be an maya2egg 2014 feature added. I know it was only released in April, but it is the main version that we are using now. I apologize if this has already been requested, I searched as much as I could and found no information.


Sorry, but Autodesk does not seem to offer a 32-bits version of Maya 2014. Since we currently only offer 32-bits builds of Panda, we can’t provide maya2egg2014 for the moment. However, a future version of Panda3D may.

Feature request! The shader input p3d_NormalMatrix