Quote Originally Posted by phibermon View Post
Yes sounds good to me - I was thinking about a small library that takes common features of both bullet and physx and implements each in tandem - to begin with just static geometry and rigid primatives then moving onto constrained joints for rag-doll and wheeled vehicle simulations - the flat pascal headers would be for this abstraction layer. Would save on having to keep pace with bullet API changes etc or at least that's one idea.
This sounds fine to me.

Random thoughts:


  • PAL (Physics Abstraction Layer) can be used to abstract physics libraries under a common API: http://www.adrianboeing.com/pal/index.html , https://en.wikipedia.org/wiki/Physics_Abstraction_Layer . That's not to say that I want to use PAL -- possibly making our own abstraction layer would allow us more flexibility (and possibly not cost too much time). I don't know PAL well enough to decide for sure.
  • I fear that such abstraction layer may hide some useful engine-specific features. E.g. I would like to eventually use Bullet soft bodies. PhysX also has soft bodies, but some engines don't -- e.g. ODE has only rigid bodies, as far as I know. This doesn't stop PAL from having soft bodies, of course (it can just not implement them for ODE backend; that's what it does, in fact, see https://sourceforge.net/p/pal/discus...read/c6a91d20/ ). But, still, an abstraction layer must choose some sensible common ground between it's backends, so I fear that some small features here and there could be missing.
  • But, this fear is unconfirmed. Possibly PAL rocks, and it's possible to abstract everything nicely without loosing anything important.
  • Also: at the beginning we want to just use rigid body like you write, which is supported by all physics engines.


So, summarizing my random thoughts above: Yes, I'm after doing an "abstraction layer" on our side, and extending it as much as necessary for our needs. We can probably learn by looking at PAL how it can be done nicely.

Quote Originally Posted by phibermon View Post
Yes indeed the main strengths of my system so far lie in JinkEd (the editor) and it's ability to co-operatively edit scenes across IP networks - arbitrary properties of any kind can be attached to each node so property sets for the castle scene graph would be quite painless to implement - allowing castle to be used for rendering.

I'll have a think and study castle in more detail and get in touch with you when I can - I've been unable to entice people to join me on my project so I think it's time to accept its weaknesses and play to castles strengths.
It would be great to join forces. Castle Game Engine lacks an integrated editor. I plan to fix it by "Visual designing of components", allowing for some visual editing (like GLScene or FireMonkey 3D).

But I don't plan to make a special, full-featured editor. Your editor would fill this role fantastically, and the fact that it allows collaboration online is a huge feature not seen in other game engines as far as I know. The only thing close to it that I seen is Verse -- https://en.wikipedia.org/wiki/Verse_protocol , https://web.archive.org/web/20110725...e.blender.org/ . It was integrated with Blender and it rocked (read: it actually worked. Unfortunately, the project is dead as far as I can see.

Please check Castle Game Engine, and if there's anything missing -- I can add it