ddiakopoulos / polymer Goto Github PK

Performance optimization to use stencil mask to early-reject fragments not visible through the HMD lenses

https://github.com/ValveSoftware/openvr/wiki/IVRSystem::GetHiddenAreaMesh

A polymer mesh will hold multiple sub-meshes and material instances. It should support multiple workflows:

• vector of: one-mesh + one-material now handled parent/child entity relationships
• one-mesh (single vertex buffer, multiple index buffers) + multi-material

Scene cameras and skyboxes should be serializable components. For now they are treated more implicitly.

Draw an imgui instance to an aux framebuffer, and then hook up a billboard and laser pointer so it can be interacted with and rendered in VR.

glsl => spir-v => api shader compiler (includes, defines, optimization, reflection)

Somewhat trivial feature that requires renderer modification. We need a better API to disable render passes (for instance, to only leave the skybox). Rendering the procedural skydome every frame is a huge performance hit.

Fixed by removing the check @

According to https://hero.handmade.network/forums/code-discussion/t/1013-opengl_arb_vs_ext it's mandatory for OpenGL 3.0+

Cleanup following #15

The scene editor needs an imgui implementation to describe the scene graph. It currently shows all scene entities as a flat list, but they should be grouped according to the transform graph.

Is there an easy way to add more camera trajectory position?
It seem to bug out when adding more than 4.
It is probably me doing something wrong, not understanding the code completely.

Ps.
Keep up the amazing work you are doing, you are brilliant! 😍

At present, Polymer's renderer is fairly rigid and not exactly hackable/adaptable.

Unity's scriptable render pipeline is worth an investigation alongside LabRender from @meshula

Also: Experiment with compute shader skinning as a job

• Object pool (arena?)
• Memory pool
• Component pool
• Alligned allocator

A generic memory pool is relatively simple and useful enough that Polymer should have one even though it's not presently required for any in-engine features.

While component pools and hash tables provide most of the heavy lifting for the ECS functionality, an object pool can still be useful (i.e. objects that wrap third-party functionality like physics).

Reference: https://github.com/mtrebi/memory-allocators

This is a precursor to #23

Scene light probes were recently moved from being a shader-oriented assets to scene-oriented assets, now we need to build a small pipeline to bake radiance and irradiance cubemaps.

Both samples crash with an access violation here https://github.com/ddiakopoulos/polymer/blob/master/lib-engine/gfx/gl/gl-api.hpp#L572

Hi! I've noticed I have push access to the repo.
Wouldn't it be better if we forked the repo and do PR so we can discuss modifications before pushing a change?

https://renderdoc.org/docs/window/event_browser.html

The gl_shader_asset object has facilities to compile variants based on included defines. A function needs to be written to analyze the currently used texture handles on a material and ensure its variant is compiled appropriately. Current materials simply define all potential shader defines, but this is actually a bug since not all materials will use all the define-available texture slots.

The scene graph is reconstructed every frame to task the renderer. We typically clear the payload and assemble a renderable object. A renderable should be refactored to a render_component which might be cached with a dirty flag.

Separately, materials need one last refactor before being fully usable. Material instances are serialized into separate *.json files containing the uniform values and texture sampling info. A material_component simply has the handle to a material instance. To recreate a typical metalness/roughness scene, we would need N different materials, each with a single value changed... this is not ideal. Instead, what we actually need is for the uniform values to be stored as part of a material_component per entity (kind of a prefab). I am imagining that texture samplers are what define the material (and are largely responsible for requiring new shader variants), while uniform properties can be overridden on a per entity/material_component basis.

Any other thoughts @meshula ?

Different buggy behavior for either

Here:

https://github.com/ddiakopoulos/polymer/blob/master/samples/gl-render/gl-render.cpp#L93

import_model returns an empty map. I think it finds the file because it logs: "0 shapes, 1 material"

Bullet3 is included and repo already has starter wrapping code. Previously it was integrated into samples on an ad-hoc basis, but it's ideal to have a rigid_body component type and wired into the the collision_system in lib-engine

Cereal has a lot of boilerplate for polymorphic relationships.

Polymer is presently uses OpenGL 4.5 features across the codebase. The eventual goal will be to replace all GL with a rendering abstraction capable of targeting multiple graphics backends. A reasonable target might be GL, DX12, and Vulkan. For macOS, it should be possible to use MoltenVK to bring Metal2 support with minimal effort.

glsl => spir-v => api shader compiler (includes, defines, optimization, reflection)

Inspiration
https://github.com/NVIDIAGameWorks/Falcor
https://github.com/sgorsten/workbench

A list of planned future samples

• sample-engine-events (child/parent, collisions)
• sample-engine-model-import (make it a model viewer app)
• sample-engine-animation-system (skinning system)
• sample-engine-picking (raycasting and object picking)
• sample-xr-painting (meshline renderer + tube geometry)
• sample-xr-archery (Valve style bow+arrow+balloon)
• sample-xr-physics (A couple interactive widgets)
• sample-xr-audio-saber (very simple clone of a well-known rhythm game)
• sample-xr-teleportation (pads, zones/collision, FoV tube)

This is relatively trivial just need to put some time into it.

Craft a few basic samples demonstrating features of lib-polymer and lib-engine.

• convert metallic/roughness/occlusion into 3 channel texture
• compute mips with better-than-box filter
• export as *.dds (dxt1/dxt5)

Current plan of attack is to use the Microsoft gLTF SDK.

https://github.com/Microsoft/glTF-SDK

Must be implemented after initial pass at ECS

A transform hierarchy followed by a robust collision system (entity-entity, entity-ray) will form the basis of all VR interactions.

Already implemented, but need to integrate at the renderer level

Results in an editor bug where, for instance, texture_handles, are assigned the last selectable value.

engine-openvr-scene has the beginnings of a teleportation-style locomotion system. A long time ago, Valve and others discovered that fading to black before the teleport event minimizes locomotion-induced sickness. This will need to be integrated into the renderer as configurable post pass.

A core promise of Polymer is a unified method of treating interactive VR objects. This concept only exists in various bits, pieces, and smaller prototypes. This system should be capable of bringing together the following features:

• a generic interactable base for grabbing and throwing (with direct physics integration)
• optional user input filtering (position, velocity) using the lib-polymer's one euro filter
• well-tested integration with the collision system for common event types (on grab, on grab parent, on release, on intersect, etc).
• haptics sequencing

There are three toolkits worth taking inspiration from:

1. SteamVR Interaction System
2. VRTK
3. NewtonVR