The engine is really holding its own now - performance is excellent and feature set is fat and juicy - really impressed! keep up the good work
The engine is really holding its own now - performance is excellent and feature set is fat and juicy - really impressed! keep up the good work
When the moon hits your eye like a big pizza pie - that's an extinction level impact event.
Thank you! We have great plans for 2017 to add more features: see https://castle-engine.sourceforge.io...d_features.php
Some exciting features planned! I too am looking to make use of bullet and I've got some ideas for an abstraction of their C++ API - if you fancy it one of the days perhaps we can brainstorm a design for our mutual use?
Also if it's ok with you I'd like to support Castle scene files in my editor - your engine is more complete and advanced than my own and I thought it would be wise to compliment your work rather than reinvent the wheel
When the moon hits your eye like a big pizza pie - that's an extinction level impact event.
Yes, by all means. We could actually create a project (on GitHub or SourceForge or such) with Pascal bindings for Bullet, and use it in both our projects -- that would be very cool!
My (rough) estimate of next Castle Game Engine releases:
- 6.2 release: Easy iOS recompilation
- 6.4 release: Delphi compatibility
- 6.6 release: Physics or Visual designing of our components (like GLScene) (depending on people feedback, what do they need most)
So, I may sit to physics quite soon, in <2 months. I'll make a note for myself to ping you when I have anything to start. Or, if you start anything earlier, I'll gladly join!
Great! By all means, please do, the engine is open-source and free to use (on terms of LGPL, just like FPC/Lazarus units). By "my editor" do you mean your Jink Engine? Because that looks extremely impressive, and I would be proud if my engine would be the renderer underneath.
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.
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.
Last edited by phibermon; 24-02-2017 at 09:21 PM.
When the moon hits your eye like a big pizza pie - that's an extinction level impact event.
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.
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
Agreed - I assumed something like PAL already existed and perhaps we'll find it suitable after assessment but at the very least it'll prove a useful aid when it comes to our own design.
In developing my editor it has proven to be as much work as the engine itself - I'll focus on supporting castle scene files to begin with which will allow for rapid prototyping in castle then we'll examine options.
Again fantastic work on the engine! highly recommended for anybody reading.
When the moon hits your eye like a big pizza pie - that's an extinction level impact event.
Bookmarks