Treeform's feature requests

This would probably never get done unless i did it myself. But this is my feature wish list:

Deferred shading pipline
requers the engine itself
requres editor for said shaders
Some thing like this: … shader.jpg
… the features that this should have could easily fill another post. I would write it up later.

Decals … 2722#42722
robust and fast system to place them around either statically or dynamically.

Imposters … _id=543409
Volumetric Billboards is currently the leading tech but its tightly coupled with forward or deferred shading that you do.

Quick Collisions
Very fast and temporary quick collision quarry for Ai stuff:
some thing like this:

# on button press
if collide(Sphere(tree.nodepath,radius=2),Ray(me.nodepath):
    print "me is looking at tree"

Obviously collision done every frame should be done like it is now but some times you just want to do a quick test when users presses the fire button. Always having a hit ray sticking out is inefficient and so is crating collision testers a new every time.

High precession math
(as a feature not default).
NodePaths that have operate in 64 bit doubles larger. Maybe (128 bit reals) ? Obviously graphics hardware cannot support that so after the computations are done turn them in 32 bit floats.
Example space ship (camera) is at 100000000000000000.00 and it sees a rock at 100000000000000002.33 all the GPU needs to know is that space ship is at 0 and rock is at 2.33 well inside float32 range while the maths are done in higher precession. It could be just a logical scene graph tied to standard panda3d scene graph that hides nodes out of float32 range.

Integer math.
A lot like High precession math but math primitives that use integers or fixnums for their computation. Such as Vec, Matrix, Quat etc…

Game swf integration
Play flash files as textures or as your UI screen. Art people love flash files because they can do so much cool stuff with them and they already know the flash editor.

Shader based particle system.
Particle system that uses sharers to do second to second computations.

Egg editor
Ability to move different nodes around, reparent, recolor and retexture. Maybe even create models from scratch. Not very complex just Notepad of 3d editors like Anim8or or Scetchup and to fix up or tweak models quickly or do some egg specific stuff. (maybe moot if we switch 100% to collada)

Ray tracing engine
Sort of like tinyGL but uses one of the open ray tracers to draw panda3d scenes in software. Possobly running its own “shader programs.”

Organize python api into how panda3d is organized internally or some thing a little better.


and python stuff just like C++ stuff

lol, i hope to see it anytime, so start to code treefrom :wink:

at my wishlist, a deep intergrated shader support from maya! why to create a wheel new, if there lots around??

maybe you are working with the wrong engine? if you do a bit of research you would find excatly what you want :wink:

do not copy old ways, create new ways!

At my wishlist:

  • FX pipeline, with support for CgFX shaders and an easier system for managing render passes and postprocessing filters.

  • Native collada support

Combining those two we could get support for ColladaFX too, and people will be able to use tools like RenderMonkey or FX Composer to create shaders.

The texture nodes thing that you showed is also on my wishlist - we could extend TextureStage to have more modes like that, and input/output connections to other stages.

About deferred rendering - if I get the FX pipeline stuff done, implementing that will be a lot easier!

Oh, and I forgot one:

  • Hardware geometry instancing

On Quick Collisions… You can emulate this by creating a temporary CollisionTraverser, adding your sphere/ray/etc to it, then traversing it. Something like:

tempTrav = CollisionTraverser("instaCollide")
tempQueue = CollisionQueueHandler()
tempTrav.addCollider(collisionRay, tempQueue)
if tempQueue.getNumEntries() > 0:
  processCollision (tempQueue.getEntry(0))

Maybe we could have a convenience function which does this in straight C++ code. The last game engine I used had functions like this – things like checkRay, checkSphere, etc. which would return a list of scenegraph objects that intersected the given ray/sphere/etc. Not designed for per-frame checks, but great if you wanted to do things like mouse-picking-on-click or to check for things like objects within an explosion blast radius.

I especially like the re-organized Python API. It would mean taking all of the Direct libraries and bringing them into line, though.

Personally, I don’t see much need for the Egg editor. I want my art assets to be authoritative, so if I re-generate an Egg from Blender, I don’t want to worry about running a fix-up process on the resulting dropped Egg. But, this is more of a work flow issue, I suppose.

I would like to see Pview expanded, though. It would be nice if it allowed you to do things like play multiple animations, display object scale meters, and had a hierarchy browser much like what is in directtools.

I’d also like to see the Particle system get some TLC, as I’ve already documented here. This obviously includes the Particle Editor Panel.

About the collisions: well, I guess we could just expose the CollisionSolid::test_intersection(entry) method to Python.

Agree with the most.

Quick collisions is pretty high on my priority list.

Sure agree on this one, even though I don’t need it for my own game. I guess an editor that

  • imports already prepared egg files and displays them in a hierarchy list
  • rotates, positions, scales those egg files in the scene
  • swaps UVs
  • place tags for lights, water, sound objects
  • exports an egg with relative paths only holding other egg objects

would already do a lot of good.

The other things you proposed are quite advanced. While they might be useful to some, many others just would never get there.

Another thing is particles or the particle editor panel, which afair does not run here on the Mac.

pview could display thing like scale, coordinate arrows and coordinate maxima.

the features Bradamante requests are already in that editor i’ve worked on. (get the svn version)

  • replace, modify egg textures & texturestages
  • add all kinds of nodes into a scene (particlesystem, models, lights, and more)
  • add shaders
  • height and texture paint-geomipterrain (seems to be broken with 1.7)
  • place lights, sounds

the project was to much to handle alone, so i stopped working on it after several months getting no significant feedback of ppl willing to help working on the core functionality.

A tiny bit more realtime debug info would be nice! As far as I can tell, all we can see is bounding volumes.

I could have used a normal display with an earlier debugging session*. :slight_smile:

I’m not sure if it would be best to implement such a thing as a part of NodePath (like show_bounds), or as a render attribute (DebugAttrib?)

(*I know you can display normals using the Egg interface, but not everything is rendered from triangles generated using that, so something a bit more generalized would be needed.)

I’d like to try that out, but I’ve never compiled something in my life and I don’t plan to do so.

It’s all Python code and nothing needs to be compiled, don’t worry.

Oh yeah, let me add this to the list while I am thinking about:

Simple DirectGUI editor, which reads/writes Python snippets (similar to how the ParticleEditor works). Ideally this should include helpers for things like building multiple geom effects for things like buttons.

I’ve just implemented this and checked it into CVS. As there hasn’t been much devblog activity in a while, I wrote another wall of text about the new panda3d.* structure:

This is cool rdb!

I cant comment on blog, it says “date is invalid”

Why didn’t anyone tell me that before?

Fixed now. I had to disable the anti-spam plugin. It worked, but apparently a bit too well. :slight_smile:

Checked in support yesterday.

Wow, hardware instancing seems to be pretty nice. Good job rdb.

I want to add a new feature requests:

Generate a texture from an python array of matrices or vectors that can be passed to the shader so we can do: hardware instancing, GPU skinning, and tons of other things that require this.

Make texture setRam image work for python strings or a long (which is a pointer) from python to interpolate with existing python drawing API’s like pygame, cairo, svg and countless others.

Better yet: we need support for passing arrays to shaders.

Certainly you can do that already. It’s not hard to construct a CPTAUchar from that. Furthermore, there is getRamImageAs that can automatically alter the format of the texture for compatibility with libraries like the ones you have mentioned.

you could use numpy for such stuff…