Indeed, you can disable the shadow caster in the flashlight loop to remove the ridiculous performance penalty.
I think this can be improved over time. I like the gun, it doesnât look bad. The rest can be replaced and corrected. And sooner or later there will be a good example.
Updates:
- Changed âbeepâ DirectObject to self.accept()
- Removed redundant calls to camLens
- Added basic time normalization to NPC handler movement increment applications with globalClock
- Corrected the walking animation playing the wrong animation segment
- Shadow casting is disabled on the flashlight by default because of the performance penalty
1 Like
I have uploaded the initial case changes. There are a few examples that were not easy to switch over.
Update, these are not actually outstanding issues, they are non-issues, but Iâm keeping it here for clarity:
Oustanding issues switching from camelCase:
lerp_pos_hpr_interval is not defined
mouse_watcher_node is not defined
lerp_func is not defined
global_clock is not defined
cam_lens is not defined
bullet_character_controller_node is not defined
Partial list of changes to snake_case:
set_mouse_mode()
set_fov()
set_near_far()
set_focal_length()
set_pos()
attach_new_node()
set_light()
BulletWorld().set_gravity()
load_model()
reparent_to()
find_all_matches()
get_path()
add_geom()
add_shape()
set_mass()
set_friction()
set_scale()
set_collide_mask()
attach_rigid_body()
set_attrib()
set_x()
set_y()
set_z()
set_h()
set_p()
set_r()
set_text()
set_pixels_per_unit()
set_page_size()
load_font()
set_font()
set_small_caps()
set_align()
set_text_color()
set_color()
set_lens()
set_attenuation()
set_light()
set_light_off()
attach_character()
get_anim_control()
set_play_rate()
set_ccd_motion_threshold()
set_ccd_swept_sphere_radius()
get_pos()
get_hpr()
get_parent()
has_mouse()
get_mouse()
get_relative_point()
ray_test_closest()
get_node()
get_pointer()
get_x()
get_y()
get_z()
get_x_size()
get_y_size()
get_p()
globalClock.get_dt()
show_wireframe()
show_constraints()
show_bounding_boxes()
show_normals()
set_debug_node()
is_hidden()
do_physics()
set_deactivation_enabled()
The entire program has had a minor update. Now there are randomly colored collision cubes which surround the NPC and are capable of interacting with the NPC and player.
The playerâs gun no longer immediately clips through walls as I have enlarged the character controller cylinder shape to envelop the gun model position (in lieu of an actual depth test).
1 Like
Some of these are class names (e.g. LerpFunc), while the others are instance variables (of ShowBase), which do not have alternative snake_case names, so itâs fine 
. Thanks for the updates!
2 Likes
Minor update:
- Added Backface Culling to the handgun model
- minor syntactic updates
Update:
- Fixed player characterâs walking animation not playing
- minor performance improvement
1 Like
Update:
- Reduced hitch time when objects are cleaned up during success condition
- Eliminated most cases of the NPC clipping through the floor during success condition
- Added cursor-hidden #t to load_prc_file_data
1 Like
Minor update:
- Changed LerpFunc input to t = t * 3 from t = t * 1 which appears to prevent most if not all cases of the handgun interval animation not playing upon success condition
Additional minor update:
- Added the animation sequence to just after the NPC cleanup routine to cover the additional cases where the animation was not playing on cleanup. Iâd like to keep the option for an interval animation open as it allows for some randomization and fine control of the animations.
1 Like
Update:
- Switched gun animation to an Armature Action instead of Interval lists. The handgun is now an Actor. I could not figure out how to get 100% animation coverage under all conditions (especially on cold start) with the Interval format so I gave up on that.
- Triangulated the handgun mesh faces for rigging purposes.
Additional Notes:
- I think Intervals are great, but for some reason theyâre one of the first things to fail under cold start conditions. To solve all possible cases of cold start hitching, I think youâd need to load all the possibilities beforehand and hope that they remain in memory, and I do not have a clean solution for that. Armature Actions do seem to be more reliable, however, on startup.
1 Like
Looks cool. 
If this is meant to be a sample, I do wonder if the code might become more manageable to someone studying it if it were broken up into logical parts. As-is youâre not using any OOP concepts, for example (other than the fact that you have a class inheriting ShowBase, which is actually unnecessary in your case as you might as well just put everything at module scope as-is). Perhaps that is fine for such a relatively simple sample, though like this it will quickly become unmanageable to scale up to a more complex game while keeping the code readable and maintainable.
I suppose it really depends on what you want to achieve with this sampleâif all you want to do is show the mechanics of how to implement a physics-based FPS, then this is probably the most compact way to do so.
1 Like
Thanks for the reply! I didnât spend any time to make this a maintainable sample, but Iâm not against it. This was written mostly to prove a point, that Panda supports first person shooters âout of the boxâ.
I was also trying to follow the âclassic Panda3D sample programâ format, which maybe we should be clearer to everybody is not the only way to instantiate the engine or work with it.
So hereâs my general concept of what a maintainable version would look like:
- the flashlight gets a class
- Bullet collision generator gets a class
- the first person camera/handgun setup routine gets a class
- Iâm not sure what else
- the ray testing parts could be made part of a class but itâs already so compact I sort of wonder what the point of that would be
- the NPC controller is intentionally bad, I wouldnât want that to be held to a standard
I have been âmaintainingâ a few of these code objects for several years. If there are specific suggestions about how to structure this to meet more standardized guidelines, I will certainly consider it.
This is, arguably, another reason to update the samples!
My rule of thumb for âshould something be a classâ (where âsomethingâ is some entity with its own lifetime and logic) is to ask a question like âDoes this entity manage state that has a unique lifetime?â
Or, perhaps more simply, âcan I imagine there being more than one of this entity?â. This usually leads me to separate out eg. a class for the World/Level from the main engine/game class, since the World may be torn down and recreated, or replaced with a different level that has different world logic. Or, the World logic and state and doesnât even need to come into the picture until the user has navigated through menus and only then needs to be instantiated. And there might be multiple NPCs that all manage their own state and logic, and putting them in a class makes it easy to handle their lifetime and destruction cleanly.
I would not personally use classes to encapsulate, say, a one-time process (which could go into a function just fine), since it doesnât have to manage the lifetime of some state.
2 Likes
I appreciate very much the theoretical approach of your logic. Are you a mathematician by chance?
Unfortunately, I cannot distinguish easily between such world states and my own concepts, which are usually unbounded in some sense. The collision generator I have created could be used an infinite number of times in itâs current, âfunctionalâ declaration. I have no personal need for it to exist in a class.
I am not a mathematician, but I do appreciate elegance in all things, including code architecture design. To me, readable code is ideally an easily-followable narrative of verbs being called on nouns.
I agree that a collision generator does not need to be in a class, since it is not a long-lived entity, but a one-time process. A function is the best fit for that.
Update:
- Radically improved shadow casting performance (I would appreciate a few testers)
- Shadow casting is enabled by default
- Removed simplepbr.init() requirement (gltf patch loader is still required)
- Antialiasing and setup is now being handled in the main loop
- The âActor shaderâ is now a scene shader being applied to the whole scene
- Added a sky color
- Minor shader syntax improvements
- Doubled the number of physics cubes
- Changed near value of the flashlight lens to 0.5 from 0.05 to avoid shadow weirdness with the player character mesh
1 Like
This looks like a neat update!
On my machine, with the window maximised, Iâm seeing a frame-rate of about 60 with the light off, and a frame-rate of about 45 with it on.
(I havenât been able to try the game at other sizes, as it grabs the cursor so completely that I canât seem to extricate the cursor to do anything else, resizing of the window included.)
My system specs:
Dell Inspiron 15 3000 Series
CPU: Core i7 2.4GHz (4-core)
Memory: 8GB
Graphics: GeForce 840M, 2GB
1 Like
Thanks for the report, it is appreciated.
I am curious what would happen if you set the shadow caster of the flashlight to (True, 128, 128) on your system at line 252.
And I do have cursor-hidden #t set in the config. This is mostly to avoid how unsightly it is to see a relative mouse twitch around the target dot.
1 Like