Posts Tagged ‘MSVC’

May 2018 Development Update

Sunday, June 24th, 2018 by rdb

With the work on the new input system and the new deployment system coming to a close, it is high time we shift gears and focus our efforts on bundling all this into a shiny new release. So with an eye toward a final release of Panda3D 1.10, most of the work in May has centered around improving the engine’s stability and cleaning up the codebase.

As such, many bugs and regressions have been fixed that are too numerous to name. I’m particularly proud to declare the multithreaded render pipeline significantly more stable than it was in 1.9. We have also begun to make better use of compiler warnings and code-checking tools. This has led us find bugs in the code that we did not even know existed!

We announced two months ago that we were switching the minimum version of the Microsoft Visual C++ compiler from 2010 to 2015. No objections to this have come in, so this move has been fully implemented in the past month. This has cleared the way for us to make use of C++11 to the fullest extent, allowing us to write more robust code and spend less of our time writing compiler-specific code or maintaining our own threading library, which ultimately results in a better engine for you.

Thinking ahead

Behind the scenes, many design discussions have been taking place regarding our plans for the Panda3D release that will follow 1.10. In particular, I’d like to highlight a proposed new abstraction for describing multi-pass rendering that has begun to take shape.

Multi-pass rendering is a technique to render a scene in multiple ways before compositing it back together into a single rendered image. The current way to do this in Panda3D hinges on the idea of a “graphics buffer” being similar to a regular on-screen window, except of course that it does not appear on screen. At the time this feature was added, this matched the abstractions of the underlying graphics APIs quite well. However, it is overly cumbersome to set up for some of the most common use cases, such as adding a simple post-processing effect to the final rendered image. More recent additions like FilterManager and the RenderPipeline’s RenderTarget system have made this much easier, but these are high-level abstractions that simply wrap around the same underlying low-level C++ API, which still does not have an ideal level of control over the rendering pipeline.

That last point is particularly relevant in our efforts to provide the most optimal level of support for Oculus Rift and for the Vulkan rendering API. For reasons that go beyond the scope of this post, implementing these in the most optimal fashion will require Panda3D to have more complete knowledge of how all the graphics buffers in the application fit together to produce the final render result, which the current API makes difficult.

To remedy this, the proposed approach is to let the application simply describe all the rendering passes up-front in a high-level manner. You would graph out how the scene is rendered by connecting the inputs and outputs of all the filters and shaders that should affect it, similar to Blender’s compositing nodes. You would no longer need to worry about setting up all the low-level buffers, attachments, cameras and display regions. This would all be handled under the hood, enabling Panda3D to optimize the setup to make better use of hardware resources. We could even create a file format to allow storing such a “render blueprint” in a file, so something like loading and enabling a deferred rendering pipeline would be possible in only a few lines of code!

This is still in the early design stages, so we will talk about these things in more detail as we continue to iron out the design. If you have ideas of your own to contribute, please feel free to share them with us!

Helping out

In the meantime, we will continue to work towards a final release of 1.10. And this is the time when you can shine! If you wish to help, you are encouraged to check out a development build of Panda3D from the download page (or installed via our custom pip index) and try it with your projects. If you encounter an issue, please go to the issue tracker on GitHub and let us know!

March 2018 Development Update

Friday, April 20th, 2018 by fireclaw

Winter is over and it’s time for a spring-cleaning. Many issues have been fixed this month and we’ve also completely refreshed the forum system. Also, changes have been made towards cleaning up the codebase and removing obsolete code. Keep an eye open for the awesome things our developers have in store for later this year!

Forum

The forums got a complete overhaul and has been moved over to Discourse, a 100% free and open source discussion board with plenty of neat features and a modern look. It has become quite a popular system of late, so it may appear familiar to some. The new software is considerably better at preventing spam and the increased mobile usability, code highlighting support and better notifications are welcome features as well. However, due to the conversion to Markdown, some formatting in old forum posts may not have been converted correctly.
If you have any trouble or concerns using the new forum, let us know! We’ll do our best to make the transition as smooth as possible.

Adjacency Geometry

Silhoutte rendering using a geometry shader. Model by Christophe Seux.

Silhoutte rendering using a geometry shader (click to enlarge). Model by Christophe Seux.

Support has been added to the OpenGL renderer for adjacency information. This is primarily useful for geometry shaders that need to access information about vertices connected to the primitive that is being processed, which is useful when implementing effects such as silhouette rendering (as seen in the screenshot to the right). Panda3D can automatically generate adjacency information for existing meshes, but can also take precomputed adjacency information.

Logging in deploy-ng

A new addition to deploy-ng which could help with debugging deployed apps—especially on Windows—is the possibility to provide a path to a log file to which a packaged app will automatically write all of its output. As GUI applications on Windows can’t write to the console, this new way of logging can be used to easily reroute the output to a log file without having to write an extra logging mechanism in your application.
To enable this feature for your application, you simply have to set the log_filename variable in your setup.py script. For an example, take a look at the setup script in the asteroids example in the deploy-ng branch. By default the log file will be rewritten every time, but with a simple switch of the log_append variable, you can preserve the previous content.

Dropping support for MSVC 2010

Since we are continuing to take greater advantage of C++11 features in the Panda3D codebase, we can no longer support the Microsoft Visual C++ 2010 compiler. The 2015 version has been made the new default for building Panda3D from source on Windows systems, and we intend to cease supporting 2010 very soon. If this is causing issues for you or your team, please make your voice heard as soon as possible on the corresponding GitHub issue!

Dropping Mac OS X 10.6 “Snow Leopard” support

Furthermore, we also intend to stop supporting Mac OS X 10.6 “Snow Leopard” due to the limits it imposes on how much of the C++11 standard can be used in the Panda3D codebase. However, if your application is still targeting this version of macOS, please give your opinion on the corresponding GitHub issue.

Video4Linux

Panda3D now supports the grayscale pixel format on Linux which is used for example by some infrared (IR) cameras. Additionally, the reading of video frames from the camera is now done asynchronously, meaning that the framerate of the application is no longer locked to the framerate of the camera in Augmented Reality applications. The previous behaviour can be restored by enabling the v4l-blocking configuration variable.

Better Python 3 Support

Support for Python 3 has been enhanced by replacing usage of the C++ string type with vector_uchar where it is used to refer to binary data. Since all strings are seen as UTF-8 now, this avoids exceptions which were raised due to confusion about whether buffers contained UTF-8 strings or binary data. Convenience functions have been added for efficiently dealing with the new way of representing binary buffers.

Media decoding and playing

CFSworks, who regularly contributes to the project, has done some work on various parts of the audio system, among many other changes. Firstly, he implemented workarounds for some rare OpenAL implementation bugs which are particularly prevalent on the Apple implementation. He also helped to clean up use of deprecated APIs in the FFMpeg integration and implemented features available to newer versions of this library. We are very grateful to him for his continued contributions.