Oh, it’s not too hard–it’s just that both it and the other mechanic each have their “pros” and “cons”, both for development and as sections of a showcase.
For example, six degrees of freedom is more impressive, but the other mechanic is likely to be easier for more people to get into (being simpler to control, and less likely to incur motion sickness, I imagine).
So, I think that it’s worth discussion what we want to do with that section.
However, if you’re taking it on, and if you’re not planning on dealing with it soon, then the matter isn’t urgent. I mainly wanted to bring it up when I was thinking of sketching it out in the near future.
Nice!
The portal FOV does seem a little off to me at times: If I approach the portal, the view seems to extend away from me, suggesting that the FOV might be too wide; conversely, when I back away, the view seems to zoom in, suggesting that the FOV might be too narrow. This in turn creates a hitch when the player is transported.
However, I will say that it’s pretty cool thus far! It’s nice to see the view shift around as one changes position relative to the portal, and I kinda like that the portal is empty from “behind”: it emphasises the portal’s nature as an unusual connection to someplace else, perhaps.
There’s loads of visual optimization to do there; I wouldn’t say the portal mechanic is done yet. I’d want to add a much smoother inverse increment system for one, for the FOV control. And the portal at it’s current size could use a ramp to make it a little less awkward.
It is cool that the plane is one-sided, indeed! I’m happy with this as a sketch. It’s actually based on some old mirror code I wrote for a house environment once upon a time.
Looks cool! Actually I remember having done something similar a very long time ago – I’ll have to look it up.
Feel free to do so – I’ll be busy with Section 1 for quite a while yet, and I don’t even know how I could contribute to Section 2, to be honest.
And thanks for your contribution to Section 3, by the way! That certainly looks very interesting.
Does the hangar have to be located on a planet? It might be part of a space station too, or perhaps it could be more of a shuttle bay on a large mothership; the latter might look quite impressive and at the same time be more fun to model than a huge section of a planet. At any rate, we wouldn’t have to worry about breaking away from an atmosphere; we’d already be in space.
Today I finally added my code for Section 1 to the GitHub repo. The avoidance.py script shows a new way of dealing with obstacles and I feel it looks better than the previous implementation. Sadly though, when I apply it to the code in main.py, the bots can get stuck when they have to work in close proximity to one another. So for the moment I have disabled the collision-handling routines until I find something that works. Perhaps I could create a model in Blender that contains polys representing waypoints – or at the very least the target positions corresponding to each plate to be generated, such that the bots don’t have to stand/hover exactly below/above the plates. So yeah, we’re not quite there yet.
What does work well is the “assignment of jobs”, which is now a lot better implemented, I feel. Currently the “job schedule” is hard-coded. For this to work in the final version of the demo, a text file will have to be created that specifies after how many plates of the current hull section a new section of the hull can be started on (among other things). This will best be done by whoever applies the vertex colors to the plates in Blender, probably – it’s something I certainly wouldn’t mind doing.
When this text file is parsed, the resulting data structure should look something like what you can currently see in main.py:
Each dict in the self.job_schedule list specifies the total number of parts (part_count) to be generated in the current “job”, what kind of “worker” the job will be assigned to (worker_type; “bot” or “drone”), as well as any jobs that will follow (next_jobs) as soon as a certain number of parts in this job have been materialized. Each of the next_jobs is defined with their index in the self.job_schedule list, with delay indicating when it should start (equal to the number of parts already done in the current job).
When you run main.py, you should see the ground bots moving and rotating based on the vector-interpolation. The drones (quadcopters) don’t have any motion defined for them as of yet.
I believe the PandAI system uses splines from a modeling program to do this (not that we want to bust out PandAI).
Excellent! I like the ground bot traversals, it’s a nice improvement. We could add some “H-smoothing” to get the bot rotations smooth. The drone models are pretty nice – they could end up looking quite good with some detailed animations.
Actually, I’d be happy to be rid of the planet part – launching from, let’s say a spaceport hangar would be fine I think, or a mothership. This might allow some more time for an incursion with another ship on the way to the space station if we want. Or, we could use the extra demo time to make the space station section longer. I’ve updated the OP and repo notes to reflect this change.
We’ll end up scraping all my original models, I think, to fit this updated aesthetic change. At this point I’m open to changing the propulsion type, the size, and the layout of the starship in a new model. Suggestions are welcome. I would sort of like to see thrust coming off the starship, even if it’s “light energy thrust” or something scientifically loose like that. It should also make some cool noises, at least from the inside the ship while in transit.
Our team continues to work regularly on the P3D Space Tech Demo, and we’re excited about all the new features that will make their way into this new Panda3D game.
We’ve made significant progress on several items in the last two weeks, including updates to Modeling, Flight Mechanics, AI Scripting, Procedural Generation, Character Controllers, Skyboxes, Music, and Rendering.
To ensure that the Tech Demo is a success, and a surprise for new players, we’ll be keeping many details about the final game secret amongst the dev team. We may still post a screenshot here and there to give a taste of what’s to come.
We will present the final demo release to the Panda3D community only when we feel the game meets the high standards we’ve set for our team.
We appreciate the interest shown by the hundreds of views on this post, and we’ll continue to do our best to deliver a great experience at the end of the demo development cycle.
Hello again Panda3D enthusiasts! After a brief 140 days, our team would like to bring the Panda3D community a big update on the Collaborative Sci-Fantasy Tech Demo!
First of all, the tech demo lives on!
Over several months, our team has made 267 commits to the main branch of the tech demo. These updates have enabled many graphics and gameplay features that we’re quite excited to offer a glimpse of today.
Thusfar, we have written around 10,000 lines of Python, GLSL, and a tiny bit of Cg for the project, and we have collectively contributed over 40 wholly original 3D model assets. We have used a combination of modified Creative Commons textures and original procedural textures for our custom PBR pipeline.
Without further ado, check out some in-game screenshots of our current build:
Procedural generation of a user-selected spacecraft!
Our team has overcome quite a number of technical challenges to make these works possible, thoroughly enjoying ourselves along the way of course. I have written a project wiki which documents a number of these challenges (and successes): Home · P3D-Space-Tech-Demo/Panda3DSciFiTechDemo Wiki · GitHub
Recent feature updates which have not made their way into the wiki documentation just yet:
Asynchronous and staged model loading system for all current demo levels
Native .gltf armature actions for RPG and FPS style spacesuit animations
3D menu system with render to texture auto-FOV resizing functionality
Sophisticated pausing and resuming system for all gameplay Intervals, logic, physics, and particle effects
As to the current state of the demo, Section 3 is under heavy development, Sections 1 and 2 stand at about 90% completion, and Section 4 is merely a twinkle in the designer’s eye at the moment.
Our project is all-volunteer, so it proceeds at the speed of our team’s collective free time. We are still open to new potential group members – send me or @Epihaius a PM if you feel you might be up to the challenge!
This is going to be the mother-of-all panda3d demos. I’ve been watching the development of this multi-genre game and its seriously impressive. Great work
So for the moment I have disabled the collision-handling routines until I find something that works. Perhaps I could create a model in Blender that contains polys representing waypoints – or at the very least the target positions corresponding to each plate to be generated, such that the bots don’t have to stand/hover exactly below/above the plates. So yeah, we’re not quite there yet.
