Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - JeGX

Pages: 1 2 [3] 4 5 ... 72
DirectX Raytracing (DXR) is a new feature in DirectX 12 that opens the door to a new class of real-time graphics techniques for games.

We were thrilled to join Microsoft onstage for the announcement, which we followed with a presentation of our own work in developing practical real-time applications for this exciting new tech.

Rendering accurate reflections in real-time is difficult. There are many challenges and limitations when using the existing methods.
For the past few months, we've been exploring ways of combining DirectX Raytracing with existing methods to solve some of these challenges.
While much of our presentation went deep into the math for our solution, I would like to show you some examples of our new technique in action.

Practical real-time raytracing for games
Raytracing is not a new technique, but until recently it has been too computationally demanding to use in real-time games.
With modern GPUs, it's now possible to use rasterization for most of the rendering and a smaller amount of raytracing to enhance shadows, reflections, and other effects that are difficult to achieve with traditional techniques.
Our DXR tech demo runs in real-time on current GPU hardware and, because it builds on existing methods, it was relatively easy to implement into our DirectX 12 game engine.
We are proud to be one of the first developers chosen to work with DirectX Raytracing, and we are excited about the opportunities for this new API.
I am happy to announce that we will be using DirectX Raytracing in a new 3DMark benchmark test that we hope to release towards the end of the year.

- DirectX Raytracing tech demo @ youtube

Fact Sheet and FAQ

What is DirectX Raytracing?
DirectX Raytracing is a new feature in DirectX 12 that bridges the gap between today’s rasterization techniques and the full 3D effects of tomorrow. It opens the door to a new class of real-time graphics techniques for games. Find out more from Microsoft’s DirectX Developer Blog. 

What did Futuremark present at GDC?
Futuremark and Microsoft presented a joint session at GDC called, "New Techniques for Accurate Real-Time Reflections.” It was the first in a series of advanced graphics tutorials for graphics engineers, technical leads, and advanced technical artists.
In our talk, we presented the first practical real-time applications for DirectX Raytracing. We showed and explained a new technique that combines DirectX Raytracing (DXR) with existing methods to improve the quality and accuracy of real-time reflections in games.

What are the advantages of this new technique for reflections?
Our reflection technique uses DXR to enhance commonly used reflection techniques and to solve cases that couldn’t be handled previously, such as reflections of dynamic objects outside the main camera view, reflections on non-planar surfaces, and producing perspective correct reflections for non-trivial-shaped spaces. 

What about performance?
Our demo runs in real-time on current GPU hardware. Raytracing is used selectively to enhance reflections that are difficult to achieve with traditional techniques. 

Which game engine are you using?
As with all our products, we use our own engine. Our DXR demo uses a modified version of the DirectX 12 engine we used for 3DMark Time Spy. 
Can your technique be implemented in other game engines?
Yes. Our technique builds on existing techniques which are well known to game developers. It would be relatively straightforward to implement in modern game engines.

Does your demo use NVIDIA RTX or AMD’s raytracing solution?
No. Our raytracing demo uses Microsoft’s DirectX Raytracing (DXR) API.

GeeXLab - english forum / GeeXLab released
« on: March 21, 2018, 12:07:38 PM »
GeeXLab has been released for Windows 64-bit only. I will update the documentation asap with new functions.


Version - 2018.03.21
+ added set_view_matrix_4x4() and set_projection_matrix_4x4() to gh_camera lib (lua / python).
+ added uniform_4x4f() to gh_gpu_program (lua / python).
+ added color_edit_4f_v2() and color_picker_4f_v2() to gh_imgui lib (lua / python).
+ added tree_node_leaf_v2() to gh_imgui lib (lua / python).
+ added set_cur_font_display_offset() and get_cur_font_display_offset() to gh_imgui lib (lua / python).
+ added project_3d_to_2d_v1() and project_3d_to_2d_v2() to gh_utils (lua / python).

Version - 2018.02.22
+ added joint_revolute_set_angular_limits() to gh_physx3 lib (lua)

GeeXLab - english forum / Re: horizontal scrollbar ImGui
« on: March 20, 2018, 07:09:30 PM »
I found the way to enable horizontal scrollbar. Just define a new constant window_horizontal_scrollbar with value 2048 and use it in window flags:

Code: [Select]
local pos_size_flag_always = 1
local window_no_save_settings = 256
local window_horizontal_scrollbar = 2048

local window_flags = window_no_save_settings | window_horizontal_scrollbar

local is_open = gh_imgui.window_begin("myWindow", 200, 400, 0, 0, window_flags, pos_size_flag_always, pos_size_flag_always)

By default, the vertical scrollbar is enabled and the horizontal scrollbar is disabled.

GeeXLab - english forum / Re: horizontal scrollbar ImGui
« on: March 20, 2018, 03:48:18 PM »
Yes it's weird indeed. Vertical and horizontal scrollbars are enabled. I will look at ImGui functions, maybe it's a bug in GeeXLab. I let you know.

The GeeXLab codes for shift and ctrl:


KC_LEFT_CTRL    = 29

Other codes are available here: libs/lua/keyboard_codes.lua

ASRock, a well-known motherboard maker, has published a teaser about its first graphics card. The following hashtags have been used in this tweet:

#ASRock #PhantomGaming #PG #Phantom #Gaming #FAST #MYSTERIOUS #UNPREDICTABLE

- Teaser @ youtube
- source

3D-Tech News Around The Web / Vulkan Subgroup Tutorial
« on: March 16, 2018, 01:14:18 PM »
Subgroups are an important new feature in Vulkan 1.1 because they enable highly-efficient sharing and manipulation of data between multiple tasks running in parallel on a GPU. In this tutorial, we will cover how to use the new subgroup functionality.

Modern heterogeneous hardware like GPUs gain performance by using parallel hardware and exposing a parallel programming model to target this hardware. When a user wants to run N parallel tasks for their algorithm, a GPU would divide this N-sized workload between the compute units of that GPU. Each compute unit of the GPU is then capable of running one or more of these parallel tasks concurrently. In Vulkan, we refer to the data that runs on a single compute unit of a GPU as the local workgroup, and an individual parallel task as an invocation.

Vulkan 1.0 already exposes a method to share data between the invocations in a local workgroup via shared memory, which is exposed only in compute shaders. Shared memory allows for invocations within the local workgroup to share some data via memory that is faster to access than reading and writing to buffer memory, providing a mechanism to share data in a performance sensitive context.

Vulkan 1.1 goes further and introduces a mechanism to share data between the invocations that run in parallel on a single compute unit. These concurrently running invocations are named the subgroup. This subgroup allows for the sharing of data between a much smaller set of invocations than the local workgroup could, but at a significantly higher performance.

While shared memory is only available in compute shaders, sharing data via subgroup operations is allowed in all shader stages via optionally supported stages as we'll explain below.


The Raspberry Pi team has updated the Raspbian operating system for the launch of the new Raspberry Pi 3 Model B+. This new version of Raspbian improves the support of different screen resolutions (large, medium and small screens) and brings a new option for supporting high resolution screens: the Pixel Doubling.

Enabling pixel doubling simply draws every pixel in the desktop as a 2×2 block of pixels on the screen, making everything exactly twice the size and resulting in a usable desktop on, for example, a MacBook Pro’s Retina display. We’ve included the option on the version of the desktop for the Pi as well, because we know that some people use their Pi with large-screen HDMI TVs.

As pixel doubling magnifies everything on the screen by a factor of two, it’s also a useful option for people with visual impairments.


3D-Tech News Around The Web / Unreal Engine 4.19 released
« on: March 15, 2018, 08:56:20 AM »
Unreal Engine 4.19 enables you to step inside the creative process - the tools become almost transparent so you can spend more time creating. Improvements to rendering, physics, Landscape terrain, and many more systems mean you can build worlds that run than ever before. The quality of life for the developers using our tools is always top of mind, so we continue to look at areas we can improve to put the power into the developers' hands.

Whether you are creating games, linear media, architectural visualizations, or product design tools, Unreal Engine 4.19 enables you to know exactly what the finished product will look like every step of the way. The new Live Link plugin seamlessly blends workflows between external content creation tools and Unreal Engine so you can see updates as you make changes to source content. And with the continued improvements to Sequencer, you can be the director with even more control of your scenes in real time.

When it comes to bringing the worlds in your imagination to life, the sky's the limit. Create breathtaking vistas in large, open worlds thanks to Landscape rendering optimizations. With the new Dynamic Resolution feature that adjusts the resolution as needed to achieve desired frame rates, those worlds will run smoother than ever before on PlayStation 4 and Xbox One.

It wouldn't be a complete release without a mountain of workflow and usability improvements, and Unreal Engine 4.19 does not disappoint in this respect. Working with Material layers and parameters is easier and more intuitive. Features for debugging Blueprints are more powerful with the ability to step over, step into, and step out. You can now save content folders as favorites. Animation tools have been improved with pinnable commands, ability to have multiple viewports, and lots more.


Thanks for your work!
I added a new key.lua file in the libs/lua/ folder.  Will be shipped in the next update  ;)

3D-Tech News Around The Web / MagicaVoxel 0.99.1 released
« on: March 13, 2018, 04:03:32 PM »
MagicaVoxel is a free lightweight 8-bit voxel art editor and interactive path tracing renderer.


0.99.1 - 3/12/2018

    Renderer (hidden menu)
        Atmospheric Scattering Skydome : Rayleigh/Mie scattering
        Bladed Bokeu : for large depth of field
        Stretched Bloom Filter
        Grids : can change Spacing, Width, and Color
        Field of View (FOV) : change range to : 1-360
        Fix some bugs : e.g. Bloom dark points
        more options are saved into file, format is changed as well
        Align Objects in Editor
        New object is using last model size
        Fix importing files with unicode paths
        Add default export and snapshots folders in config



More advanced examples:


Vulkan Hardware Capability Viewer is an application to display hardware implementation details for GPUs supporting the Vulkan API by Khronos.

-   Full Vulkan 1.1 support including subgroup operations properties
-   Support for new extensions:

- Vulkan Hardware Capability Viewer 1.5 Download (win64)
- Other downloads

3D-Tech News Around The Web / volk: a meta-loader for Vulkan
« on: March 13, 2018, 03:40:15 PM »
volk is a meta-loader for Vulkan. It allows you to dynamically load entrypoints required to use Vulkan without linking to vulkan-1.dll or statically linking Vulkan loader. Additionally, volk enables loading Vulkan entrypoints directly from the driver which can increase performance by skipping loader dispatch overhead.

volk is written in C89 and supports Windows, Linux and Android.


Inno3D is about to released a graphics card for crypto-mining use only. The P102-100 Crypto Mining card is based on a Pascal P102 GPU and does not have output connectors.

Inno3D P102-100 Specifications:
– GPU: P102-100
– CUDA Cores: 3200
– Base Clock: 1582 MHz
– Memory Clock: 11 Gbps
– Physical Memory Size: 5 GB
– Memory Type: GDDR5X
– Memory Interface Width: 320-bit
– Memory Bandwidth: 400 GB/s
– Bus Support: PCIe Gen1 x4
– Card Size: 21.5 cm length, 12.5 cm height, dual slot
– Max TDP: 250 Watt
– Power Connectors: 2x 8-pin PCI-E


GeeXLab - english forum / Re: Luajit for Linux
« on: March 09, 2018, 01:13:25 PM »
I only tested GeeXLab + ImGui + LuaJIT on Windows and it works fine!

LuaJIT is currently supported by the Windows version of GeeXLab only. But I will try to add this support to Linux (and macOS) as soon as possible.

The RGB matrix HAT works fine with LED panels with the HUB75 interface. Are you sure you have a HUB75 panel ? Maybe you have a HUB12 panel (see here).

Change log for March 7, 2018 Vulkan 1.1.70 spec update:

  * Vulkan 1.1 initial release. Bump API patch number and header version
    number to 70 for this update. The patch number will be used for both
    Vulkan 1.1 and Vulkan 1.0 updates, and continues to increment
    continuously from the previous Vulkan 1.0.69 update.

    NOTE: We are not publishing an updated 1.0.70 specification, or 1.1
    reference pages, along with 1.1.70. There are still minor issues to work
    out with those build targets. However, we will soon generate all three
    types of documents as part of the regular spec update cycle.

    NOTE: The GitHub KhronosGroup/Vulkan-Docs repository now maintains the
    current specification in the `master` branch. The `1.0` branch is out of
    date and will not be maintained, since we will be generating both 1.1
    and 1.0 specifications from the `master` branch in the future.

Github Issues:

  * Clarify how mapped memory ranges are flushed in
    flink:vkFlushMappedMemoryRanges (public issue 127).
  * Specify that <<synchronization-pipeline-stages, Pipeline Stages>> are a
    list of tasks that each command performs, rather than necessarily being
    discrete pieces of hardware that one task flows through. Add a
    "`synchronization command`" pipeline type which all synchronization
    command execute (it's just TOP + BOTTOM), with an explanatory note
    (public issue 554).

Internal Issues:

  * Regenerate all images used in the spec in Inkscape with a consistent
    look-and-feel, and adjust image size attributes so they're all legible,
    and not too large with respect to the spec body text (internal issue
  * Document in the <<extensions,extensions>> appendix and in the style
    guide that `KHX` extensions are no longer supported or used in the
    Vulkan 1.1 timeframe (internal issue 714).
  * Remove the leftover equations_temp directory after PDF build completes
    (internal issue 925).
  * Update the <<credits, Credits (Informative)>> appendix to include
    contributors to Vulkan 1.1, and to list them according to the API
    version(s) they contributed to (internal issue 987).
  * Add a NOTE to the introduction explaining that interfaces defined by
    extensions which were promoted to Vulkan 1.1 are now expressed as
    aliases of the Vulkan 1.1 type (internal issue 991).
  * Instrument spec source conditionals so spec can be built with 1.1
    features, extensions promoted to 1.1, or both (internal issues 992,
  * Modify the XML schema and tools to support explicit aliasing of types,
    structures, and commands, and use this to express the promotion of 1.0
    extensions to 1.1 core features, by making the extension interfaces
    aliases of the core features they were promoted to. Mark up promoted
    interfaces to allow still generating 1.0 + extension specifications
    (internal issue 991).
  * Platform names, along with corresponding preprocessor symbols to enable
    extensions specific to those platforms, are now reserved in vk.xml using
    the <platform> tag. Update the registry schema and schema specification
    to match (internal issue 1011).
  * Updated the <<textures-texel-replacement, Texel Replacement>> section to
    clarify that reads from invalid texels for image resources result in
    undefined values (internal issue 1014).
  * Modify description of patch version so it continues to increment across
    minor version changes (internal issue 1033).
  * Clarify and unify language describing physical device-level core and
    extension functionality in the <<fundamentals-validusage-extensions,
    Valid Usage for Extensions>>, <<fundamentals-validusage-versions, Valid
    Usage for Newer Core Versions>>, <<initialization-functionpointers
    Command Function Pointers>>, <<initialization-phys-dev-extensions,
    Extending Physical Device From Device Extensions>>
    <<extended-functionality-instance-extensions-and-devices, Instance
    Extensions and Device Extensions>> sections and for
    flink:vkGetPhysicalDeviceImageFormatProperties2. This documents that
    instance-level functionality is tied to the loader, and independent of
    the ICD; physical device-level functionality is tied to the ICD, and
    associated with device extensions; physical devices are treated more
    uniformly between core and extensions; and instance and physical
    versions can be different (internal issue 1048).
  * Updated the <<commandbuffers-lifecycle, Command Buffer Lifecycle>>
    section to clarify the ability for pending command buffers to transition
    to the invalid state after submission, and add a command buffer
    lifecycle diagram (internal issue 1050).
  * Clarify that some flink:VkDescriptorUpdateTemplateCreateInfo parameters
    are ignored when push descriptors are not supported (internal issue
  * Specify that flink:vkCreateImage will return an error if the image is
    too large, in a NOTE in the slink:VkImageFormatProperties description
    (internal issue 1078).
  * Remove near-duplicate NOTEs about when to query function pointers
    dynamically in the <<initialization, Initialization>> chapter and
    replace by extending the NOTE in the <<fundamentals-abi, Application
    Binary Interface>> section (internal issue 1085).
  * Restore missing references to "`Sparse Resource Features`" in the
    flink:VkBufferCreateFlagBits description (internal issue 1086).
  * Tidy up definitions of descriptor types in the `GL_KHR_vulkan_glsl`
    specification, the <<descriptorsets, Resource Descriptors>> section and
    its subsections, and the <<interfaces-resources-descset, Descriptor Set
    Interface>> for consistency, reduction of duplicate information, and
    removal of GLSL correspondance/examples (internal issue 1090).
  * Correctly describe code:PrimitiveId as an Input for tessellation control
    and evaluation shaders, not an Output (internal issue 1109).
  * Relax the requirements on chroma offsets for nearest filtering in
    <<textures-implict-reconstruction, Implicit Reconstruction>> (internal
    issue 1116).

Other Issues:

  * Clarify the intended relationship between specification language and
    certain terms defined in the Khronos Intellectual Property Rights
    policy. Specific changes include:
  ** Rewrote IP/Copyright preamble and introduction to better agree with
     normative language both as laid out in the introduction, and the
     Khronos IPR policy.
  ** Added notion of fully informative sections, which are now tagged with
     "`(Informative)`" in their titles.
  ** Removed non-normative uses of the phrase "`not required`"
  ** Clarified the distinction between terms "`optional`" and "`not
     required:`" as they relate to the IPR Policy, and updated specification
     text to use terms consistent with the intent.
  ** Reduced additions to RFC 2119, and ensured the specification agreed
     with the leaner language.
  ** Removed the terms "`hardware`", "`software`", "`CPU`", and "`GPU`" from
     normative text.
  ** Moved several paragraphs that should not have been normative to
     informative notes.
  ** Clarified a number of definitions in the Glossary.
  ** Updated the document writing guide to match new terminology changes.
  * Explicitly state in the <<fundamentals-objectmodel-lifetime-acquire,
    application memory lifetime>> language that that for objects other than
    descriptor sets, a slink:VkDescriptorSetLayout object used in the
    creation of another object (such as slink:VkPipelineLayout or
    slink:VkDescriptorUpdateTemplateKHR) is only in use during the creation
    of that object and can be safely destroyed afterwards.
  * Updated the <<textures-scale-factor, Scale Factor Operation>> section to
    use the ratio of anisotropy, rather than the integer sample rate, to
    perform the LOD calculation. The spec still allows use of the sample
    rate as the value used to calculate the LOD, but no longer requires it.
  * Update `vulkan_ext.c` to include all platform-related definitions from
    the Vulkan platform headers, following the split of the headers into
    platform-specific and non-platform-specific files.
  * Fix bogus anchor name in the <<commandbuffers, Command Buffers>> chapter
    which accidentally duplicated an anchor in the pipelines chapter. There
    were no reference to this anchor, fortunately.
  * Add valid usage statement for slink:VkWriteDescriptorSet and
    slink:VkCopyDescriptorSet requiring that the slink:VkDescriptorSetLayout
    used to allocate the source and destination sets must not have been
    destroyed at the time flink:vkUpdateDescriptorSets is called.
  * Document mapping of subgroup barrier functions to SPIR-V, and clarify a
    place where subgroupBarrier sounds like it's execution-only in the
    standalone `GL_KHR_shader_subgroup` specification.
  * Use an HTML stylesheet derived from the Asciidoctor `colony` theme, with
    the default Arial font family replaced by the sans-serif Noto font
  * Numerous minor updates to README.adoc, build scripts, Makefiles, and
    registry and style guide specifications to support Vulkan 1.1 outputs,
    use them as defaults, and remove mention of `KHX` extensions, which are
    no longer supported.

New Extensions:

  * `VK_EXT_vertex_attrib_divisor`


Path tracing is a powerful, surprisingly simple, and woefully expensive rendering technique. In this tutorial, I’ll be walking you through the construction of the Caffeine demo, which implements realtime path tracing in WebGL.

- Caffeine path tracing tutorial
- Caffeine path tracing demo
- Caffeine path tracing source code

After a several year gap, I finally took another week-long programming retreat, where I could work in hermit mode, away from the normal press of work. My wife has been generously offering it to me the last few years, but I’m generally bad at taking vacations from work.

As a change of pace from my current Oculus work, I wanted to write some from-scratch-in-C++ neural network implementations, and I wanted to do it with a strictly base OpenBSD system. Someone remarked that is a pretty random pairing, but it worked out ok.

Despite not having actually used it, I have always been fond of the idea of OpenBSD — a relatively minimal and opinionated system with a cohesive vision and an emphasis on quality and craftsmanship. Linux is a lot of things, but cohesive isn’t one of them.

I’m not a Unix geek. I get around ok, but I am most comfortable developing in Visual Studio on Windows. I thought a week of full immersion work in the old school Unix style would be interesting, even if it meant working at a slower pace. It was sort of an adventure in retro computing — this was fvwm and vi. Not vim, actual BSD vi.


Complete story:

3D-Tech News Around The Web / Re: TechPowerUp GPU-Z 2.8.0 Released
« on: February 24, 2018, 11:50:56 AM »
Download Zone updated:  GPU-Z 2.8.0

Pages: 1 2 [3] 4 5 ... 72