So we have a new look for the brand new 1.10 (Yay!), but we still have the same old samples that look as if they were made 10 years ago (and they where). Maybe it’s time for something new?
Here’s my idea:
The samples should be a small tutorial, starting from simple things like importing ShowBase and loading models to more complex stuff like intervals, tasks, clicking on objects and player controls. Each step in the tutorial should introduce 3-4 new things and expand on what was made in the previous steps.
The style of the models should be simple, but not cartoon, so that it looks good without lights (FFP), looks better with lights and shadows and even work with PBR (probably with a different set of textures).
I can make some models, I can help plan out what should be in the tutorials, but I don’t think I’m the best person to actually write the code (my code style… well, let’s just say it’s not all that PEP8 compliant).
If I remember that the idea is not new, I saw how the new ralf was redone and everything was forgotten. I think that you should show by example how the new style of models should look. I can at least generate a few sounds, because recently I have been learning VST synthesizers.
I like this idea! (And the new site looks rather slick, by the way!)
I’m tempted to offer to help, but I’m not sure that I have the time to dedicate to a tutorial that was quite that extensive.
I might be able to contribute a small tutorial program–I was thinking of a simple top-down “endless enemies” score-shooter. It would demonstrate basic Panda usage (extending ShowBase, disabling the default camera controls, running the game, etc.); simple key-handling via “accept”; basic enemy- and player- classes, perhaps showing derivation from a shared base-class; simple collision via Panda’s built-in system; and some basic DirectGUI usage.
Regarding coding style, I’m not in a position to speak to whether my style is idiomatic; I have my own style.
I’m a beginner in panda3d and I can tell you anyway the difficult points that need a tutorial.
what technologies are used and avoid wasting time in old obsolete codes.
For example, use Bullet physic engine not ODE or native panda physic.
I can do it.
Create terrain with collision detection ! I lost 1 month to understand how to make ralf walks on a ShaderTerrainMesh !!!
I can do it.
Today I would like a tutorial that explains how to display trees and grass in a optimise code
There is currently no panda3d project that displays a grass field or a forest !
In 2019, however, it is something “basic”
I can not do it.
But, with lot of work i was able to create a mini game with
But I think an example to present to the community would be nice
I can do it.
The graphics game
If there hadn’t been the beautiful images of RenderPipeline I wouldn’t have used panda3d
Without RenderPipeline, panda3d is uglier than Quake2, it hardly attracts people
I’m not a graphic designer/texture, I can not do it.
A last tutorial with the all-combined tutorial :
A little technical demo like Crysis could be really nice, not game, a pretty landscape with snow mountains, a forest, an ocean…) run with RenderPipeline
An example that explains well : You have put a lot of renderer pipeline beautiful images on the official panda3d website, but nothing of a real game like YORG
Because Yorg is good game but it’s very ugly.
the pretty but useless mountain of RenderPipeline attracts more than an ugly but functional game
I’m datascientist and i not use AI library of panda3d, i use scikit learn and tensor flow for develop complex AI.
I don’t think it’s useful to do complex tutorials on artificial intelligence, because Python has many libraries better than what panda3d offers (like scikit learn and tensor flow)
The current basic tutorials are sufficient I think
I don’t think that Panda’s built-in physics system is obsolete, myself: I find that it’s perfectly fine for simple games. Further, it feels to me to be a bit simpler to use than Bullet–although that may be due to familiarity, in all fairness.
For more complex projects, Bullet is indeed quite effective.
Indeed, I currently have two projects underway: a large, complex game that uses Bullet, and a much simpler project that uses Panda’s built-in physics. In both cases I find that I’m happy with the results.
For simple games, and especially ones that don’t use a close third-person camera, I think that one could easily use a much simpler controller.
That said, if it “just works” out of the box, and isn’t too performance-intensive, then I can see this one being useful as a catch-all.
I’m inclined to disagree: I think that much comes down to the models and textures used. (Especially when a stylised aesthetic is used.) I fear that many of the examples on the Panda website are somewhat old, and thus may give the impression that they’re all that the engine can handle without RenderPipeline.
Setting up ShowBase, config variables, loading assets, setting position, rotation, scale, changing a color and a texture of a model, playing animations, parenting nodes to other nodes.
-how to import panda3d (from panda3d import core? from panda3d.import *? import panda3d.core as p3d?)
-how to use ShowBase ( ShowBase.__init__(self)? ShowBase.ShowBase()?)
-snake_case, CamelCase, properties?
Making a task that controls camera and player movement.
-what is the proper way? key map? input_state?
Loading and playing sounds and music. This is so late because I first would want to show a way to run a function after a key press, so that sounds can be played when a key is pressed.
A flyby cutscene using sequences, parallels, intervals.
Intro to Bullet collision detection, clicking on 3D objects
Make objects fall, collide, slide, etc. Control a kinematic object - making the player not run through walls.
I like that idea, but I feel that it might be a good idea to start with a smaller, simpler tutorial–something that produces a complete (if basic) game after only a few lessons. That way the reader has the encouragement of an early success, rather than only receiving that after a long, uncertain series of lessons.
Specifically, I’d likely omit steps 4 through 10, inclusive. (With regards to step 5, I’d just do much the same with Panda’s physics system, and leaving out clicking on 3D objects.)
That said, I would like to see something like your outline too, as a more advanced tutorial. To that end, my main critique is that I might separate out the “terrain” step into its own tutorial: plenty of games don’t require heightmapped terrains, so the specifics of that can be left for those who are making such games, I feel.
Hmm… I’d suggest inheriting from ShowBase, myself–but I’ll confess that I don’t really have a good argument one way or another.
To this, I’m inclined to suggest that we not worry about it, beyond a given tutorial being consistent throughout. A given programmer’s style doesn’t seem terribly important to me, beyond readability in a team environment.
And if different tutorials end up having different styles, then that might just reinforce the idea that different programmers have different styles, rather than there being a single “correct” style.
It does seem to me that there may be a concern that this would make the tutorials seem inconsistent overall; in this case, the tutorials could perhaps be given by-lines, or even just a line at the start indicating the chosen style.
… I’ll confess that I’m not sure of what you mean by “input_state”. Is this an approach that I’m not familiar with? ^^;
Here I would suggest starting with simple custom shaders–maybe a custom toon shader, or a rim-lighting shader–before getting into the more complex stuff. Thus I suggest making two steps of this.
That really depends on whether we do actually select a new GUI toolkit, to my mind.
Otherwise… For basic usage, DirectGUI… works. It’s clunky, but it does the job. For a beginner tutorial, I think that it would likely be fine. But if we do treat your tutorial as an advanced one, maybe it would be worth considering having this introduce the reader to the integration of some other GUI toolkit.
Honestly, I’d forgotten about this! Good point. ^^;
As to a simpler “beginner” tutorial, I’m inclined to stick with what I suggested above, which might look something like this:
Much as with your tutorial, this would involve setting up ShowBase; basic model-loading; parenting; positioning, rotation, and scaling; and Actors and animations (including the caveat about keeping a reference to them!).
“Accepting” key-events; likely a basic key-map setup
Setting up a simple class-hierarchy–likely something like this:
A (Showbase-derived) “Game” class, which holds an instance of a “Level” class.
A base “GameObject” class, from which is derived simple “Enemy” and “Player” classes
– The base class would handle health, damage, the object’s nodes, and movement
– The enemy class would have AI to seek and attack the player
– The player class would handle input
Perhaps a simple “Weapon” class with some derived specifics, to show how that might be used
Using Panda’s physics system to prevent the player from moving through walls, and to implement weapons-fire hitting things. Responses to collision events for weapons-fire. Perhaps a note that Bullet can be used for more-complex gameplay.
As you said: loading and playing sounds, and having them occur in response to things.
Score, health, and perhaps ammo/weapon UI elements. This is followed by a simple “main menu”, and a “game-over”/“score” dialogue box.
As you say, using setuptools
You may note that I leave out lighting, shaders, etc… In the interest of simplicity, I envisage this tutorial-game using a simple unlit art-style, with textures being used to distinguish objects.
If there’s a concern that this looks too simplistic, and thus may mislead readers as to Panda’s capabilities, we could perhaps add basic usage of the automatic shader-generator.
Finally, I’m not quite sure of where best to fit introduction to the camera. Perhaps in the first lesson, where we might set up a basic “top-down” camera. Later, if desired, it might be parented to the player-character.
By input_state I had in mind from direct.showbase.InputStateGlobal import inputState. You tell it to watch for some key events inputState.watch_with_modifiers('foobar', 'x') and later check if it happened if inputState.is_set('foobar'): do_foobar('bacon', 'spam')
I’d like to put in lights, shadows and some shader-foo because I’d like it to look if not ‘good’ then at least modern(-ish), and that’s also why I have my doubts about DirecrGui - it can be made to look good, but it takes many steps and a lot of spaghetti code.
I’m not sure about putting in AI in the tutorials - it would be nice, but PandAI ain’t nice. It could be AI implemented in Python and that could be a good way to introduce concurrency but I have this feeling some people will flee in terror at the first sign of async/await.
About the camera - I think it’s important to show a good replacement for the default camera driver because frankly the default camera driver is rubbish.
In general I agree - shorter and simpler is better.
Ah, I didn’t know about this mechanism! (Is it new, or have I just been unaware of it all these years? ^^; ) In that case, I’ll bow to those who know both systems well for an opinion on which to use in the tutorial.
That’s fair. In which case, I stick with my suggestion of using the built-in shader-generator for a “beginner” tutorial: it’s simple, it shows what Panda can do “out of the box”, and it can look decent, I think. Maybe have a single shadow-casting light and some models with normal-maps, perhaps even glow-maps or the like.
Again, largely fair, I think. However, I think that for a simple game, it could be made to look fine, at least: a single image-backdrop for the main menu; some buttons with images for each state and text overlaid; and a few labels for UI, score/game-over, and titles. It would be minimalist, but should be acceptable, I think. And I think that it wouldn’t be too complicated: the most complicated bit would be the state-images, but presuming that they’re provided, they should be easy to load via the “frameTexture” keyword argument.
That said, I am open to a new GUI system, should we settle on one.
Ah, there perhaps I worded myself poorly. I didn’t mean PandaAI, or even a third-party toolkit. I just meant basic logic: “Turn towards the player. If in weapon-range, shoot. If not, move forward.” Maybe some basic side-stepping to add a bit of challenge. Simple stuff.
I do agree! I didn’t mean to suggest that it be left out, I believe–just that I wasn’t sure of where to place it in the tutorial.
Thinking about camera-perspective, I’m tempted to suggest that a more-complex tutorial, such as your proposal, might take on a first-person camera: there are one or two tricks there that might be worth tutorialising, such as changing the near-plane to prevent the player from seeing through walls.
If I do put together a tutorial along the lines of what I outlined above, it might be worth having someone else look over it for any audio elements that I miss, but that might be a good idea to address. I have a tendency to forget about audio, I fear. ^^;
Well, @wezu has started in on a character, above, so I’m inclined to take that as a start in terms of direction. The character looks like it has a fairly cute style, so I suggest that new tutorial/sample assets have a cutesy style to them.
Otherwise… Do we really need to stick to a single theme? As long as the art is stylistically cohesive, I think that a variety of themes could be presented without them clashing.
I just think of all sorts of requisites to demonstrate examples, for example, a simple box (cube) or a music box. I don’t think they should stay that way. If we fit all three-dimensional objects to the same time and style, then if necessary we can combine them in one scene. Can think about the size of the measurement for the correct ratio of models.
I’m not yet sure about the style, what would fit an what would not, my character currently looks like this:
I think going for a modern-ish look (style wise) is the best way to go. So no far-future Sci-fi, no post-apocalyptic wasteland, no medieval fantasy. I’m kind of tempted to make the tutorial map a small, rural type school.
I see what you’re saying, I believe, I just disagree that a single setting-type is required: I see no inherent problem with wizards fighting robots in a wasteland, or modern adventurers exploring elven ruins, as long as they’re stylistically consistent.
So sticking to a single style would be important, but sticking to a single setting would not be, I argue.
What is your reasoning for that?
If I may, I have a suggestion that occurred to me last night: give her a domino mask, suggesting the black rings around a panda’s eyes. And perhaps black gloves, for the black paws of a panda.
(It would also look somewhat superhero-ish, which I think might be neat.)
Would using the “MakeHuman” software be useful as a baseline ? If a human model generated in that at, for example 1.8m tall was used as a reference, Then every-one would be on the same OpenSource page regarding size.
The reasoning behind a modernish setting is that we can still use ancient ruins and medieval castles (because they still exist in our times) and near-future sci-fi stuff as well (because in a near future things that are modern to us would still exist).
MakeHuman is fine, I usually use it for everything human-shaped, but I wanted to make a model that is clearly custom made for Panda3D not a generic, procedural human.
i agree,A custom model is better than a generic one(excellent model btw.) I just like things to a real world scale,and different 3d creation programs have different scales. Is your model 4 foot, 4 metres or 4 inches high ?
I’m just proposing that a makehuman mesh be used as a baseline for assets. To avoid things like a 100m high panda roaming about a 6 inch castle.
I still think that it’s not that difficult to mash-up settings, but if a single setting is desired, then I think that I’m inclined to agree with your reasoning for it to be such a setting as you describe–the “Uncharted” option, essentially.
(I might add that it also works with horror themes, for that matter–see Resident Evil and myriad “haunted house” games.)
Sorry for the double-post, but there’s a four-day gap between my previous post and this, the thread seems to have stalled for the moment, and I have a few more thoughts:
First, would anyone object to my starting in on my proposed tutorial, above? Are there any concerns before I start, presuming no objections?
(I currently intend to use stand-in models for the moment; they can always be swapped out for something else at a later date.)
Second it has occurred to me that there is one point on which Panda’s built-in physics system is arguably more convenient than Bullet: collision callbacks. While I believe that they’re possible in Bullet, I seem to recall that they can be awkward at times, or at least call for a few steps. Conversely, Panda’s system makes it very easy to just get notifications of objects colliding with, remaining within, or leaving other objects, I feel.
Finally, I’m tempted to take a shot at modelling a simple, small environment. Specifically, I have in mind a small, single-room “desert ruin”: a square room bounded by the low, uneven remains of walls; broad, square flagstones; and perhaps some piles of sand about the place. The style would be simple–I don’t intend to use photorealistic textures, although I do intend to include normal-maps. It would be intended to be used with my tutorial.
Any thoughts on this, and if it seems acceptable, are there any textures aside from colour and normals that would be desired?