Posts Tagged ‘opengl’

October 2018 Development Update

Sunday, November 11th, 2018 by fireclaw

PyWeek

Two weeks ago, the semi-annual PyWeek challenge was held. In case you are not familiar with PyWeek, it’s a challenge to create a game within only seven days. The contestants are free to use any engine as long the game is written mostly in Python. Before the challenge begins, contestants vote on a theme in order to inspire and challenge the entrants’ creativity. The theme for the October challenge was “Flow”.

In this 26th PyWeek, two contestants have used Panda3D for their submissions. We’d like to highlight some of the challenges they faced and show how Panda3D helped them to finish their games in such a short time. They both used development builds of the upcoming Panda3D 1.10, which made for a great opportunity to test the new features, and the new deployment system in particular. Being able to quickly install Panda3D using pip has also been a very welcome feature for PyWeek, since installing Panda3D has been a stumbling block for PyWeek users in the past.

Chart of Flowrock

Chart of Flowrock

This entry was created by our community member wezu. It is an original take on the dungeon crawler game using only three keyboard buttons where possible moves are represented with a flowchart diagram at the bottom of the screen.
One feature from the Panda3D engine that helped wezu getting this game done was the intervals. These are functions to manipulate values—such as an object’s position and rotation—over a given period of time without the need to use tasks to manage those updates manually. Using intervals, he was able to quickly develop convincing walking animations with head bob and tilting when turning.

The game’s impressive graphical style was achieved thanks to a shader framework wezu developed, which is publicly available at GitHub. It has been made as a drop-in replacement for the built-in Cg-based ShaderGenerator, implementing various modern effects using GLSL 1.30. This proved to be a bit of a challenge in testing: while GLSL 1.30 shaders are typically usable on most platforms, OpenGL support has always been a bit behind on macOS, and has in fact even been deprecated by Apple as discussed in a previous blog post. This forced him to implement a special “potato mode” for low end and macOS systems that wouldn’t utilize these shaders. In this mode, the game would still be playable, just without those fancy graphics.
Working on an improved shader pipeline that avoids some of the driver-specific compatibility issues is high on the agenda for the Panda3D developers, which will help making shader-based game work reliably on multiple platforms without requiring extensive testing and tweaking the shaders for different drivers.

Chart of Flowrock won silver rating in the Production category and ranked sixth overall among the individual entries.

Let There Be Light

Let There Be Light

Our second entry that has been made for PyWeek was created by our main engine developer rdb. This game is a kind of strategic puzzle building game where you have to build an energy grid in order to supply cities with power and enable them to grow. The energy demand of the cities grows over time so you have to carefully plan your network so that your wires don’t overheat. For this game rdb decided to take a less heavily graphics-focused approach, instead going for a minimalistic art style with flat colors, low-poly models and simple lighting. The game employed numpy for calculating the currents through the nodes of the energy grid.

As the power lines were one of the most important elements of the game, some attention to detail was given with how they are rendered. The LineSegs class made it easy to draw nice catenaries between the pylons. Panda3D made the math rather easy to ensure that the wires connected up properly to the pylons regardless of their orientation: dummy points were added to the pylon models indicating the points where the wires should attach, so it was only necessary to use getRelativePoint() to determine the correct two points to draw the arc between.

As the player interacts with the game primarily using the mouse, extra attention was given to ensure a good user interface so that it is clear to the player what to do. Panda3D’s text nodes and billboard effects made it particularly easy to add labels in the 3D scene to clearly communicate where the user needs to click and what will happen when they click it, and intervals made it easy to give the important labels a nice animation to draw the eye. The free Font Awesome icon font was used to easily render crisp icons.

The sound and music had to be pushed off to the last few hours of the final day, but fortunately loading and playing spatialized sounds in Panda3D takes only a few lines of code. Having sound effects can really help with the user experience like this by giving direct feedback to the player’s actions. Smoothly adjusting the play rate of the music depending on the game speed was a nice touch appreciated by the reviewers, which took only a few minutes to implement using Panda3D.

Let There Be Light won gold ratings in the Fun and Production categories, Silver in the Innovation category and became the winner of PyWeek 26 among the individual entries.

Engine Developments

Despite the distraction of PyWeek, development of the engine has not remained idle. Plenty of bugfixes and stability improvements bring the engine ever closer towards the upcoming 1.10 release. We’ll give you a small selection of the many changes that have happened.

If you have ever tried loading models in a model format other than Panda3D’s own bam or egg formats, you may have already come across the Assimp loader, which has been in the Panda3D source for a while but was considered experimental. This uses the Assimp library, which supports most of the 3D formats in common use. This importer is now enabled by default and can be used in recent development builds.

On the graphical side were a few fixes and enhancements too. A big change was made in the rendering system to resolve some inconsistencies in how colors and material were being applied in the absence of lighting. It is normally the case that materials are not visible unless you have a light applied to the model, but in some cases (such as in the presence of a color scale), the material colors could show up anyway. It was also not always clear when vertex colors would show up or when they would be suppressed by the material. These behaviors have now been made consistent between the different rendering back-ends and the shader generator. If these changes are affecting your game, just let us know and we can help you resolve these problems.

As of 1.9.0, Panda3D has a GLSL preprocessor which among other things allows #include statements to include other files within the current shader. This is crucial for games that rely heavily on shaders, as functions often need to be shared between different shaders or just separated for better code organisation. It has recently seen some improvements, such as the ability to use it with procedurally generated shaders that are passed into Shader.make(), some optimizations to reduce the preprocessed size, and some parsing fixes.

There also have been some improvements on the Windows front. It is now possible to change the undecorated and fixed-size attributes of already-opened windows. There have also been some improvements in the build time when compiling with Eigen support on Windows.

The deploy-ng system has received a new feature: it can now use an optimized version of the Panda3D binaries, stripped of debug information and safety checks, when deploying a game. deploy-ng can make use of an optimized version of the Panda3D wheels that are available on our pip mirror under a special +opt tag. This allows deployed games to be smaller and faster while still providing the benefit of all the debug features and safety checks in the SDK.

July 2018 Development Update

Sunday, August 26th, 2018 by fireclaw

Despite the vacation period, the developers have not remained idle in July. Here is an update on some of the new developments.

Collision shapes

While the internal collision system provides many useful tests between various collision solids, the CollisionTube solid (representing a capsule shape) in particular was only really useful as an “into” collision shape. Many of you have requested for more tests to be added so that it can also be used as a “from” shape, since many see it as a good fit for use with character bodies. Earlier, we had already added tube-into-plane and tube-into-sphere tests. We have now also extended this to include tube-into-tube tests and tube-into-box tests. We have also added a line-into-box test to complete the suite of CollisionBox tests.

For those who are using Bullet physics instead of the internal collision system, we have also extended the ability to convert collision solids from the Panda3D representation to the Bullet representation to include CollisionTube and CollisionPlane as well. These solids can now be easily converted to a BulletCapsuleShape and BulletPlaneShape, respectively. This way you can add these shapes directly to your .egg models and load them into your application without needing custom code to convert them to Bullet shapes.

Depth buffer precision

As most Panda3D programmers will know, two important variables to define when configuring a camera in any game are the “near” and “far” distances. These determine the range of the depth buffer; objects at the near distance have a value in the depth buffer of 0.0, whereas objects at the far plane have a value of 1.0. As such, they also determine the drawing range: objects that fall outside this range cannot be rendered. This is fundamental to how perspective rendering works in graphics APIs.

As it happens, because of the way the projection matrix is defined, it is actually possible to set the “far” distance to infinity. Panda3D added support for this a while ago already. Because of the reciprocal relationship between the distance to the camera and the generated depth value, the near distance is far more critical to the depth precision than the far distance. If it is too low, then objects in the distance will start to flicker as the differences in depth values between different objects becomes 0; the video card can no longer tell the difference between their respective distances and gets confused about which surface to render in front of the other. This is usually known as “Z-fighting”.

This is a real problem in games that require a very large drawing distance, while still needing to render objects close to the camera. There are a few ways to deal with this.

One way people usually try to resolve this is by increasing the precision of the depth buffer. Instead of the default 24 bits of depth precision, we can request a floating-point depth buffer, which has 32 bits of depth precision. However, since 32-bit floating-point numbers still have a 24-bit mantissa, this does not actually improve the precision by that much. Furthermore, due to the exponential nature of floating-point numbers, most precision is actually concentrated near 0.0, whereas we actually need precision in the distance.

As it turns out, there is a really easy way to solve this: just invert the depth range! By setting the near distance to infinity, and the far distance to our desired near distance, we get an inverted depth range whereby a value of 1.0 is close to the camera and 0.0 is infinitely far away. This turns out to radically improve the precision of the depth buffer, as further explained by this NVIDIA article, since the exponential precision curve of the floating-point numbers now complements the inverse precision curve of the depth buffer. We also need to swap the depth comparison function so that objects that are behind other objects won’t appear in front of them instead.

There is one snag, though. While the technique above works quite well in DirectX and Vulkan, where the depth is defined to range from 0.0 to 1.0, OpenGL actually uses a depth range of -1.0 to 1.0. Since floating-point numbers are most precise near 0.0, this actually puts all our precision uselessly in the middle of the depth range:

This is not very helpful, since we want to improve depth precision in the distance. Fortunately, the OpenGL authors have remedied this in OpenGL 4.5 (and with the GL_ARB_clip_control extension for earlier versions), where it is possible to configure OpenGL to use a depth range of 0.0 to 1.0. This is accomplished by setting the gl-depth-zero-to-one configuration variable to `true`. There are plans to make this the default Panda3D convention in order to improve the precision of projection matrix calculation inside Panda3D as well.

All the functionality needed to accomplish this is now available in the development builds. If you wish to play with this technique, check out this forum thread to see what you need to do.

Double precision vertices in shaders

For those who need the greatest level of numerical precision in their simulations, it has been possible to compile Panda3D with double-precision support. This makes Panda3D perform all transformation calculations with 64-bit precision instead of the default 32-bit precision at a slight performance cost. However, by default, all the vertex information of the models are still uploaded as 32-bit single-precision numbers, since only recent video cards natively support operations on 64-bit precision numbers. By setting the vertices-float64 variable, the vertex information is uploaded to the GPU as double-precision.

This worked well for the fixed-function pipeline, but was not supported when using shaders, or when using an OpenGL 3.2+ core-only profile. This has now been remedied; it is possible to use double-precision vertex inputs in your shaders, and Panda3D will happily support this in the default shaders when vertices-float64 is set.

Interrogate additions

The system we use to provide Python bindings for Panda3D’s C++ codebase now has limited support for exposing C++11 enum classes to Python 2 as well by emulating support for Python 3 enums. This enables Panda3D developers (and any other users of Interrogate) to use C++11 enum classes in order to better wrap enumerations in the Panda3D API.

Multi-threading

We have continued to improve the thread safety of the engine in order to make it easier to use the multi-threaded rendering pipeline. Mutex lock have been added to the X11 window code, which enables certain window calls to be safely made from the App thread. Furthermore, a bug was fixed that caused a crash when taking a screenshot from a thread other than the draw thread.

June 2018 Development Update

Tuesday, July 31st, 2018 by fireclaw

Due to the vacation period, this post is somewhat delayed, but the wait is finally at an end. Here is the new update with a selection of the developments in June.

OpenGL on macOS

At the Apple WWDC in June of this year, Apple formally announced the deprecation of the OpenGL graphics API, in favor of an Apple-only graphics API called Metal. This move puzzled many as a lot of software is relying on OpenGL for macOS support, including Panda3D, and investing significant resources into developing a whole new rendering back-end to support just a relatively small segment of the market is hard to justify.

While it seems likely that—despite the deprecation notice—Apple will continue to include OpenGL support as a part of macOS, we will need to start looking at another approach for maintaining first-class support for high-end graphics on macOS. It would be nice if there were one next-gen graphics API that would be well-supported on all platforms going forward.

Enter MoltenVK. This is an implementation of the cross-platform Vulkan API for macOS and iOS, implemented as a wrapper layer on top of Apple’s Metal API. It has recently been open sourced by the Khronos group, in an effort to make Vulkan available on every operating system. Despite being a wrapper layer, it was still found by Valve to have increased performance benefits over plain OpenGL. This will let us focus our efforts on implementing Vulkan and thereby support all platforms.

Accordingly, we have increased the priority towards developing a Vulkan renderer, and it has made several strides forward in the past months. It is still not quite able to render more than the simplest of sample programs, however. We will keep you updated as developments unfold.

Mouselook smoothness improved

In order to implement camera movement using the mouse, many applications use move_pointer to reset the cursor to the center of the window every frame. However, when the frame rate gets low, the mouse movement can become choppy. This is usually only an issue occurring on Windows as other platforms support the M_relative mouse mode, which obviates the need to reset the mouse cursor. For all those who can’t or don’t use this mode, a significant improvement in smoothing this movement has now been worked out.
In previous versions, small movements that occurred between the last iteration of the event loop and the call to move_pointer could have been ignored, causing the mouselook to become choppy. This has been fixed by changing the get_pointer() method to always obtain the latest mouse cursor position from the operating system, resulting in more accurate mouse tracking. In the future, we will further improve on this by emulating relative mouse mode on Windows and perhaps even adding a new interface for handling mouselook.

Grayscale and grayscale-alpha support with FFmpeg

Panda3D’s implementation of FFmpeg now gained the ability to load videos that only contain grayscale colours more efficiently, greatly reducing the memory usage compared to the previous approach of converting all videos to full RGB. This is also extended to videos that have a grayscale channel as well as an alpha channel for transparency. Do note, however, that not all video formats support grayscale pixel formats.

Removing ‘using namespace std’ from Panda3D headers

C++ users, take note: besides the changes to add better C++11 support, we have also eliminated the bad practice of having using namespace std; in the public Panda3D headers. This prevents the entire std namespace from being pulled in and causing namespace clashes. If your codebase relied on being able to use standard types without an explicit std:: prefix, you may need to add using namespace std to your own headers. It would be even better to fully qualify your references to standard types and functions with an std:: prefix or—where appropriate—pull in specific types with individual using std::x; statements.

Bullet Vehicle chassis-to-wheel synchronisation

Using Bullet’s BulletVehicle class to simulate car physics had a problem with syncing the wheels to the chassis if the wheels were parented to the the vehicle’s RigidBodyNode. The wheel models would always be one frame ahead of the chassis model, resulting in visible artifacts as the wheels would appear to move away from the chassis. Especially if the vehicle accelerates to a significant speed, the wheels may appear to drift quite far from the vehicle. This bug was fixed thanks to a contributor.