I think this is perfectly doable, especially for the /main/ sample application code! (Other imports, like of engine modules… won’t ever go away, but I’m assuming those are OK since all samples have those to function today).
Awesome! Right now I’m looking into similar, just poking at Ralph’s code trying to smooth out the collision bugs and fix the camera control. Currently still colliding with anything paralyzes Ralph completely, unable to move. So looking at how to best smooth some of that collision/response logic out better. I’ll post as I go for sure! Happy to collaborate!
Agreed here. I’d also love to help flesh this out better in some docs/tutorials/samples . I do have some experience writing Blender plugins so if need be, happy to automate that workflow.
Back when Blender Game Engine was a thing I did mess with that as well. I’d like to see if we can integrate Panda more tightly, possibly even a Panda preview button from Blender… just ideas for later (once some sample code is running here)
I just wanted to say this thing is REALLY cool. I would totally love for this to work like jsfiddle where we could collaborate on some Panda code, share the links with each other here. And work on Panda code together.
Is the code for this easily hackable? Can one pull it, add some hacks and redeploy?
There were not many games completed with it, as I remember.
Blender and Panda3D do seem to be pretty mixed at this point. One as a framework for logic and the other as a modeling and skeletal animation interface.
As for the preview in panda, I remember @moguri doing something similar in his plugin. However, this is slow, you need to pass the context to panda, call the frame, take back the buffer output. This is clearly not something to think about, it is a passed stage.
I think the existing is OK, with just working physics. But I don’t have any experience yet with ‘Panda’ physics, so not sure yet if it’s faster to swap the terrain out with something better (happy to whip it up in Blender) or, gen it procedurally, or other (there is a terrain engine, I’ve noticed! has collision been implemented there yet?)
The collision is the grid data. In the role of this is the usual geometry, which is usually easier than for rendering geometry.
And yes, collisions are not physics. A math intersection of geometry.
One thing the built-in collision system does is straightforward character welding, which is not necessarily the case with the current state of the Bullet methods.
Here’s an example of a more sophisticated Ralph variant:
Need to add to the examples
That’s fair–and a good argument for overhauling what we currently have, I believe.
Oh, of course! I’m not suggesting that I want the entire engine replicated in one file! XD;
Would you like some help there (whether advice or reference-code), or would you prefer to work on it yourself?
Let me note that we do have a few Blender exporters around–for two, we have “blend2bam” and “YABEE”, albeit that the latter only supports versions of Blender before 2.8, I believe.
That said, a better one, or an improvement to one that we have, could well be excellent!
Right, there’s no need to reinvent the wheel. I do think there is an elegance of the Blender plugin system ingesting a .zip file and having all of our modeling and animation needs met at the Blender export stage, without running a command line program for instance.
That was the nice thing about YABEE, indeed! It’s a pity that Blender changes combined with YABEE’s developer (I gather) dropping away from it resulted in it being incompatible with newer versions of Blender.
For sure! Happy to have help! Send anything at all you think might be useful, I’m starting from scratch here, understanding what the options are for fixing collision in Ralph. Reverse engineering the collision calls I see now in the current crop of samples.
I’m trying really hard to keep Roaming Ralph in one file, @Thaumaturge but I’m struggling… please promise not to be angry if I cave in to my weaknesses and organize this thing… =)
Not a problem!
The main thing that I’d suggest would be to rework Ralph’s collision to work something like this:
- Have a ray-and-CollisionHandlerQueue setup for the ground-height, similar to what’s there bit using Bitmasks to filter collisions rather than a name-check
- Remove the code that resets Ralph’s position on hitting an obstacle.
- Use a sphere-and-CollisionHandlerPusher setup for obstacle-collisions
With the position-reset removed and a pusher to more-smoothly prevent intersections, Ralph should no longer just stop dead when hitting an obstacle. Instead, Ralph should be able to “slide along” walls and the like.
You can see an example of the use of a CollisionHandlerPusher here:
Hah, to be honest, I’m curious as to how you might separate it out without the modules being of very limited utility–there’s barely anything in Roaming Ralph! XD;
Sounds great, thanks for the tips. I’ll give this a go!
I caved, very quickly. I’ll write a shell script to recombine the code into a single file though. Promise =)
Strange, added a single line of code after some refactoring, and the ‘stuck’ bug no longer happens. Ralph will stop when he hits things but can walk away now.
# Normally, we would have to call traverse() to check for collisions. # However, the class ShowBase that we inherit from has a task to do # this for us, if we assign a CollisionTraverser to self.cTrav. #self.cTrav.traverse(render) self.physics.update(render) # (this in turn calls cTrav.traverse())
Code is here: