Feature Requests.

[DangerOnTheRanger]

Is it possible to add to pdeploy the option to make a version of a Linux application which includes the needed libraries (i.e. not a deb file, but a compressed file with the necessary stuff - with some exceptions, like glibc)?

I was reading this post (but the entire thread is interesting, because it covers the Linux deployment), and this post answers to some doubts about the previous one; this is an article which covers the same subject, and the part 2 covers the specific part of executables.

The current pdeploy produces deb files, and this is the optimal solution when you can make assumptions about target systems. But, if you can't make assumptions (because you want to deploy to many different systems), you'll have some problems:

• http://www.gamedev.net/... section "The Problem"
• some distros could use different filesystem hierarchies, so you could have to provide different debs for different distros
• the user needs rights to install packages
• however you're missing non-deb distros

Previous points imply that with this kind of deployment you'll obtain:

• a simpler deployment (you've to maintain only one package (per-architecture))
• a more robust deployment (you provide the needed libraries and avoid bugs of specific versions of libraries installed by specific distros)
• a more complete deployment (at the moment you can target deb distros, but you would like to target even rpm distros, pacman distros, portage distros, ...)

I'm not against the current pdeploy method, I only think that this addition could improve very much the Linux support of pdeploy. Thank you!

Have you taken a look at PyInstaller?

[flavio]

Have you taken a look at PyInstaller?

Thank you for the hint. Currently I have a solution which uses pdeploy and it seems to work (I haven't done "massive" tests yet, though). If this won't work I will consider your hint, but generally I prefer a pdeploy-based solution, if possible.

[rdb]

A deb file is a GNU ar archive containing a data.tar.gz file, which contains the filesystem (usr/lib/game/ directories etc). You can simply extract that from the result and use that.

Or you can let pdeploy generate an archlinux package, which is really just a tarball with the filesystem and a package info file.

In any case, the binaries are compiled against such an old version of GLIBC that it should work on any recent Linux distribution (the binaries in the .deb will be the same as in the Arch package). You can just take out the binaries and redistribute them.

[flavio]

Or you can let pdeploy generate an archlinux package, which is really just a tarball with the filesystem and a package info file.

I'm using this currently, it is very useful, thank you!

[GrizzLyCRO]

1.I would like one function on nodepaths.

NodePath.alwaysLookAt(NodePath)

Basically, it would have same effect as calling .lookAt() every frame.

Usage would be something similar to setCompass(), so maybe name it setFocus or something similar?

2. make variables returned by globalClock.getFrameTime()
and globalClock.getDt() accessible as python attributes.
"x = globalClock.dt"

[wezu]

Somewhere on the forum there were some scripts to octree a mesh, but I can't find the one that worked for me (I'll have to test them all, I'm sure at least one worked)...

So my first request is to add a script like that to the sdk.

The second one is about gui.
I'd like a SIMPLE method to place gui elements in common locations like corners or center.
I know there are base a2d* nodes that I could parent the elements to, but I find them not very usefull (or I'm doing it wrong, there's nothing about them in the manual). So what I would like are nodes like 'top', 'bottom', 'center', 'left top', etc for every gui element. The idea is to use these to align one element to another, so if I align my buton panes 'bottom' node with the screens (render2d or aspect2d) 'bottom' node, then the butons will stick like glue to the bottom of the screen (not outside the screen) no matter what size the pane or the window is, or will be. If I'd align ones button 'rigth' to anothers 'left' and vice versa then the buttons will stay side by side even when one of the butons is moved, scaled or rotated.
I tried to make wrapers to d gui to work this way but failed ;(

[coppertop]

The second one is about gui.
I'd like a SIMPLE method to place gui elements in common locations like corners or center.

If you want a button to stick to the bottom left corner of the screen, then you can achieve that by setting the button frame to [0, <width>, 0, <height>] and reparenting to a2dBottomLeft.

If you want to stick another button to the first button's top right corner, you can do it like this:

Code: Select all

button2 = DirectButton(
frameSize = [0, <width2>, 0, <height2>]
pos = Vec3(button1["frameSize"][1], 0, button1["frameSize"][3])
)


I know it's not as convenient as having the corners exposed as nodes, and I would be all for that.

[preusser]

I agree that automatically (or manually) octreefying a collision mesh for Panda's collision system in code is a good idea. The Bullet physics engine does something like that already.

How about a sprite creation class? Right now I can make a single vertex and make it render like a sprite, but I helper class would make it cleaner.

[wezu]

I was thinking more of a stand alone commandline utility like egg-optchar that ships with panda... but sure if the loader can optimize (octreefie)a collision mesh at runtime then that's more the fine with me

[ThomasEgi]

while we are at standalone tools.
texture2txo please, for now i am working around it by creating an egg file for each texture and converting with egg2bam with -txo set.

[preusser]

This isn't a big deal, but I don't see why we have setPosHpr() and setPosHprScale() but no getPosHpr() and getPosHprScale().

[rdb]

We don't have a data type that can hold that information for us to easily provide that method.

[powerpup118]

Recast/Detour support http://code.google.com/p/recastnavigation/

Recast - automatically generates path-finding meshes from input meshes

Detour - offers basic steering behaviors for path-finding meshes

-------------------------
On an entirely different note, also:

panda-AI needs a real code cleanup, mostly blender exporter.. (it'd be possible to just use the egg-pipeline instead of .csv 3d-modeler exported files)

I'd love for a magic fairy who knows C++ to grant me all of these wishes I'm aware it may be unlikely though
~powerpup118

[rdb]

Xidram and I made a bare-bones Recast & Detour implementation a long time back. I think it's on panda3d_2_0_branch, in the directory panda/src/navigation.

[hobbit]

Just wondering, how good is pandaAI? I am wondering if I give it a try or if I should be write my own AI.

[Nemesis#13]

I'd like asynchronous loading of audio, video, images and fonts.


What would also be quite cool is the possibility to load and/or assign sound files to certain AudioManagers. As of now you can only load a sound through an audio manager and from there on the sound is bound to that AM.

[preusser]

How about a Metaball/Metaballs node?

[preusser]

Some people don't seem to be happy with panda's particle system.
How's this? http://spark.developpez.com/index.php?p ... es&lang=en

[wezu]

I'm not using panda particles because the particle panel is a bit...well cryptic. Also texured, transparent particles near the camera kill the framerate on my pc (a drop from 30-60 to 1-12fps).

If this Spark thing has a editor (with some docs) and can somehow make the particles render faster then I'm sure I could find some use for it.

[DangerOnTheRanger]

I'm not using panda particles because the particle panel is a bit...well cryptic. Also texured, transparent particles near the camera kill the framerate on my pc (a drop from 30-60 to 1-12fps).

If this Spark thing has a editor (with some docs) and can somehow make the particles render faster then I'm sure I could find some use for it.

I believe your observed frame rate drop is due to the way particles are rendered on the GPU - they have a high fill rate. Because of that, when your camera gets close to the particle emitter, your frame rate goes down. Long story short, it's your GPU's fault, not Panda's.

[preusser]

I think some particle systems allow you to disable depth testing on particles and use blending instead though.

[wezu]

It's true about my gpu. But I still played games on this pc where particles don't push fps from 60 to 5 with just one smoke emitter.

[Craig]

It's true about my gpu. But I still played games on this pc where particles don't push fps from 60 to 5 with just one smoke emitter.

Close particles are large in screen space, and have very little detail. Render the particles in another buffer at reduced scale, then enlarge and overlay. Also when possible, keep the particles as small as possible (including the transparent parts) and keep the particle count low. Sometimes more complex shaders on them can look as good with less particles, and render faster.

[rdb]

Some people don't seem to be happy with panda's particle system.
How's this? http://spark.developpez.com/index.php?p ... es&lang=en

Very intriguing. Certainly worth looking into.

[preusser]

Looks like C++ knowledge will be needed here to write the glue code for making the library use Panda's renderer, not as simple as just generating Python wrappers and making it work with Panda's task system, etc.
Also a particle config file writer/ reader would be a must I think.
So if any C++ coder is interested, let us know. I would probably be able to write a version of the particle panel for that library if this was done.

[liuhui]

It seems that the engine should load BHV or other format skeleton animating data, and could be integrated with kinetic devices. Do you think so?

[markjacksonguy]

It seems that the engine should load BHV or other format skeleton animating data, and could be integrated with kinetic devices. Do you think so?

That would be sweet! Especially since I already have a motion capture setup that uses BHV and Kinetic APIs.

[AnimateDream]

I have a what I hope is a very simple request. Could we make GeoMipTerrain.setBorderstitching() take an integer instead of a bool, and have the detail level at the edge of the tile match that integer.


There is a bug in its current behavior anyways. As it functions right now it does not use detail level 0 as stated in the docs. In fact judging by how few vertices are on the edge when i use border stitching, I bet that the detail level is equal to getMaxLevel().

[rdb]

You're right, it is max_level, and not 0.

I remember considering to make it an integer instead of a boolean, but I don't remember why I opted against it. I think that would have made it significantly more difficult to avoid seams in some special cases, or something of the sort.

[preusser]

Why not allow Intervals to run with a given delay time, not each frame? We have DoMethodLater, but nothing similar for Intervals, which are basically tasks too.

For intervals which take long time to finish, it seems pointless and waste of resources changing the value (say, color scale) by 0.0001 each frame instead of 0.006 each second.

Of course we can use tasks instead, but they are not as convenient as Intervals, that's why Intervals exist in the first place.