One more video with CAD Assistant – now showing Material Editor (introduced in CAD Assistant 1.4) for Metallic-Roughness PBR properties, as well as playing with lights for making a nice photo-realistic image using Path-Tracing renderer in CAD Assistant.
Fun with CAD Assistant – flight mode, walk mode, SpaceMouse.
RGB (red+green+blue) is the most commonly used color model, and computer graphics is not an exception. Mixture of red, green and blue (also called primaries for RGB) with different proportions allows defining any other color distinguishable by human eye, which is known to everybody from early school days.
Artists, however, usually aware of much more terms with and without RGB in name – sRGB, AdobeRGB, scRGB, DCI-P3, Rec. 2020, wide-gamut RGB. And developer of graphics application, including 3D Viewer, should be aware of them too.
Mutex is an essential tool for any multi-threaded application. But when it comes to small primitive types, and not structures, there are more options to consider.
Atomic operations, or simply atomics, are handy CPU or GPU instructions allowing to concurrently modify a value of primitive type without involving expensive tools like mutexes.
This small article is not intended to clarify usage of atomic operations, but to share a tricky experience of such operations in GPU program.
Open CASCADE 7.4.0 brings new handy class AIS_ViewController.
3D Viewer needs handling mouse input to bring interactivity to it. AIS_ViewController class takes responsibility for mapping user input events (mouse, keyboard, etc.) onto 3D viewer camera manipulations (rotation, panning, zooming) as well as highlighting objects in scene. Basically, it provides a more solid, cross-platform interface to V3d_View and AIS_InteractiveContext methods. AIS_ViewCube is another new class in OCCT 7.4.0 displaying an interactive cube for selecting 3D viewer camera direction.
As existing OCCT users might be curious what AIS_ViewController is, I have decided writing a small memo in Questions & Answers form.
sView user on Android device just sent me a link to online stereoscopic 3D video with yuv420p10 pixel format… and it is not an anime. The user complained about green screen in the player instead of a video. So far I haven’t seen much videos with more than 8-bit per channel in a wild, and appearance of such files in online services surprised me.
FFmpeg decodes such videos into pixel formats like AV_PIX_FMT_YUV420P10LE. This pixel format has 10-bit per-channel payload, but actually aligned into 16-bit per-channel planes. sView uploads such pixel formats into GL_ALPHA16 textures, which has been implemented a long time ago. After some investigation, I figured out that there is no OpenGL ES implementation supporting such texture format, and the only direct counterpart is GL_R16_EXT (normalized 16-bit red channel only format, same as GL_R16 on desktop), which is not yet in any core OpenGL ES specs, and requires extension GL_EXT_texture_norm16.
By the way, all this “deprecation thing” applied to useful texture formats like GL_APHA8, replaced by GL_R8 for no profit within OpenGL 3+ on desktop, always confused be. Applications supporting wide range of OpenGL drivers (including OpenGL 2.1) has to be messed up with different code per OpenGL version for exactly the same thing! As texture swizzling came later (and also messed-up API), fallback requires dummy GLSL code modifications fetching .r or .a of texture sample color.
Apparently, so far just two vendors support GL_EXT_texture_norm16 extension – Qualcomm Adreno and NVIDIA Tegra, which is quite predictable considering links to desktop graphics in their past. Testing on Adreno device has shown good playback performance of given video sample.
Unfortunately, devices with Mali graphics do not support this extension, leading to bad performance due to software conversion via SWScaler. Possible solution would be uploading planes into GL_R16UI textures (which is included into OpenGL ES 3.0 specs, but integer formats do not support texture filtering) and either implement texture filtering via GLSL program or convert it further into GL_R32F format (the latter one seems to be implemented by some internet browsers).
Mesh displayed in OCCT 3D Viewer might come from different sources – imported from external file (glTF, JT, STL, PLY, OBJ), computed for analytical BRep geometry by BRepMesh and ExpressMesh algorithms or generated directly by application code.
The mesh is usually displayed shaded, but this presentation is not suitable for analysis of mesh structure. In many cases, application developer needs other mesh presentations to locate issues (too many details, not enough details, local deviations, etc.) and make corrections based on analysis results (adjust mesh generation or export parameters).
In this case, mesh edges presentation becomes very helpful. Continue reading