is totally messed up. I should validate against the gltf test models found here.

Just an oversight, we need to support mipmaps when uploading both cubemaps and regular textures.

An important part of having a smooth experience is not only to have a high frame rate but also to have low frame rate time variance. Having frame time variance results in microstutters.

Currently, in release on vk in gpu mode, puts frame time stddev at around 0.8ms or so on my desktop. On my laptop, I hit 3ms stddev in cpu mode and 4-8ms stddev in gpu mode. Ideally, stddev for frame times should be below 0.02ms. We obviously have a lot of work to do.

My friend listed a set of things that often cause microstutters, things to be mindful of:

Shader recompilation. Memory allocation. Any sort of mutex lock or unlock even when not contended. IO in the render thread. String formatting.

Materials should contain a 3x3 matrix to transform UV coordinates so textures can be scaled, rotated, or transformed.

When I introduced CPU mode, I removed the ability to have per-face materials. This vastly limits the ability for games dealing with tons of low-poly, static, non-atlassed objects to optimize. Both bve and animats are dealing with exactly this.

I think the solution is to allow multiple materials per mesh, but specify that only the first one will be used in CPU mode. This allows the user to decide if they want to support CPU mode at all, and if they do, to disable mesh combining, or so forth.

Currently, we don't resize at all and will just explode when more than 256 textures are added.

We currently have basically zero documentation. This makes learning rend3 very difficult. This should be fixed.

It would be useful to have people able to bring their own wgpu device, swapchain, etc.

As a related issue, I should allow users to provide the frame that I consider to be my "swapchain" so that they can have me render to a texture or render to it after I render to it.

There are platforms (like web) where it can't be compiled for, and can cause trash build times. It should be only available if absolutely needed.

We need this so that you can use something like tracy to monitor cpu usage.

We need this for gltf, but should also be a builtin function for usability reasons.

We should use https://github.com/GPUOpen-Effects/FidelityFX-SPD once subgroup ops are supported in wgpu. This requires figuring out how to deal with FildelityFX stuff. In the meantime traditional mipmap generation is okay.

Upgrading to shaderc 0.7 causes heap corruption in spirv-cross on at least commit 4da6f64530a15e85da91b1df99553e0ac7eff517. The differences between 0.6 and 0.7 should be investigated and brought to the right place.

scene-viewer is a very idiosyncratic example as it's used for testing that rend3 is working correctly. We should make a very simple example that highlights how the API is to be used if you just want to render crap.

Consider the following situation:

The user is showing a loading screen through external integration. They are loading things. However, due to the asynchronous nature of the renderer, these will only happen in the next render, potentially gigabytes of resources later. There should be a way of keeping the events pumping.

Should be supported by rend3 now so just needs to be tied together.

The renderlist is powerful as it is, but as we add more rendering techniques, it needs to become a bit lower level to facilitate use of compute shaders, as well as dealing with all the variety needed in a real life renderer.

This is required for most enhancements going forward, so is top priority. This issue is mainly to organize my thoughts, but commentary is appreciated :)

The rewrite will contain major changes:

• Add an initialization phase where persistent data can be stored.
• Add support for custom buffers which can be initialized with data.
• Add support for initializing custom textures with data.
• Custom data should use opaque handles as identifiers, not clunky strings.
• Custom data needs to be constructed/destroyed explicitly, though the renderlist can help make this easier by allowing create_or_reuse and marking other resources as transient.
• Turn the concept of a renderlist into a trait:

  trait RenderList {
    fn init(&mut self, recorder: &mut RenderListCreationRecorder);
    fn render(&mut self, recorder: &mut RenderListFrameRecorder);
  }

  This will allow RenderLists to hold arbitrary state.
• Each target will be recorded separately. When recording a pass, the parameters are:
  • The object filter (see #56) to determine which objects to start with.
  • If cpu-side frustum culling should be applied.
  • If cpu-side sorting should be applied.
  • The target (shadows, or a non-shadow texture view)
• The function doing the recording will be a FnMut function which is provided:
  • The count of objects that match the filter.
  • Current renderer details like wave size and rendering mode.
• Unlike the current design the user triggers draws that are aware of mode:
  • draw_cpu which looks similar to today's RenderOp.
  • draw_gpu which explicitly takes an indirect and count buffer as well as count.
• There are added compute passes for compute shaders.
  • dispatch which takes an explicit size.
  • dispatch_indirect which takes an indirect buffer.
• Passes can be named, the renderer will return statistics corresponding with those names.
• MSAA support needs to be included (see #34)

Each object should be able to use multiple meshes, the one used determined based on on-screen-size or distance. This will allow the renderer to render only as much detail as is needed.

The API will look something like:

pub enum LodDistance {
	OnScreenArea(f32),
    Distance(f32),
}

pub struct LodLevel {
    pub distance: LodDistance,
    pub mesh: MeshHandle,
}

#[derive(Debug, Clone)]
pub struct Object {
    pub mesh: ArrayVec<[LodLevel; 6]>,
    pub material: MaterialHandle,
    pub transform: AffineTransform,
}

(Enhancement request)

People will want to click on things. Here's what I'd like to have as support for that, for the Animats viewer for Second Life.

An API for submitting a point in screen space, and getting back information about the first object rendered to that pixel.

Arguments

• Point in screen space, or a vector in world space.
• Max depth to check.

Returns:

• MeshHandle of mesh hit
• Index of triplet in triangle array for the triangle behind that pixel.

Additionally,

• The 3 vertices of the triangle (so we can get tangents)
• The 3 UV values of the triangle (so we can calculate the coords in texture space, which is useful for control panels and such.)

It doesn't have to be an immediate return. If we have to wait a frame time for the result, and get it back as a future or callback or queue entry, that's fine. Keeping the overhead of this down is more important. It would be nice if mouse-over didn't cause screen stuttering.

Here's the documentation of what Second Life needs on a click or mouseover.

(Can a shader be written to do this without changing the textures? That would be a clean implementation.)

I'm intermittently getting this crash. This is probably due to passing a previously deleted handle into Rend3 and is probably a problem in my code. The trouble is, this error occurs long after the bad call. The API just puts requests on the queue, and they are processed later during the draw cycle. So I can't tell which call caused the trouble.

The code at registry.rs:52 is

self.mapping.get_index_of(&handle).unwrap()

and the "unwrap" is failing.

Something that panics with a message that includes the value of "handle" would be helpful. Thanks.

Non-useful backtrace:

thread '' panicked at 'called Option::unwrap() on a None value', /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/rend3-0.0.5/src/registry.rs:52:44
stack backtrace:
0: rust_begin_unwind
at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/panicking.rs:493:5
1: core::panicking::panic_fmt
at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/core/src/panicking.rs:92:14
2: core::panicking::panic
at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/core/src/panicking.rs:50:5
3: wgpu_conveyor::AutomatedBuffer::write_to_buffer
4: rend3::renderer::material::MaterialManager::ready
5: rend3::renderer::render::render_loop::{{closure}}
6: <tracing_futures::Instrumented as core::future::future::Future>::poll
7: <core::future::from_generator::GenFuture as core::future::future::Future>::poll
8: switchyard::task::ThreadLocalTask::poll
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
thread 'main' panicked at 'Job panicked!', /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/switchyard-0.1.1/src/lib.rs:153:78

Looks like the API is hand-wired to use glam currently. Are there any barriers to expose mint instead, thus turning glam to be a private dependency?

New "scene-viewer" compiles and runs fine on Linux 20.04 LTS.

Tried cross-compiling to Windows. Compiles OK for "x86_64-pc-windows-gnu" target. Some additional DLLs from the MinGW libraries have to be copied to the directory containing the Windows executable. It gets far enough to open the graphics window, but aborts trying to initialize the Vulkan level.

This Wine patch, about three weeks old, might be relevant. Apparently other programs have hit this problem: https://source.winehq.org/patches/data/210588
The memory type requested is not compatible with what Wine is offering, apparently.

Error message:

Cross-compiled "scene-viewer":
cargo build --target=x86_64-pc-windows-gnu

wine ./scene-viewer.exe
fixme:d3d12_device_CheckFeatureSupport: Assuming device does not support tile based rendering.
fixme:d3d12_device_CheckFeatureSupport: Assuming NUMA.
fixme:d3d12_device_CheckFeatureSupport: Unhandled feature 0x12.
fixme:vkd3d_select_memory_type: Custom heaps not supported yet.
fixme:vkd3d_select_memory_type: Custom heaps not supported yet.
fixme:vkd3d_allocate_device_memory: Failed to find suitable memory type (allowed types 0x82).
[ERROR wgpu_hal::dx12] Texture creation failed: 0x80004005
[ERROR wgpu::backend::direct] wgpu error: Validation Error
   
   Caused by:
       In Device::create_texture
         note: label = `null D2 texture`
       parent device is lost
   

A lot of the techniques listed in #13 are there to facilitate rendering on desktop-tier graphics cards. We need to enumerate the performance we expect from rend3 at various points, as well as determine what the goal of the two main rendering pipelines are.

The following is a list of hardware that I have available to me and the performance characteristics I'd expect.

The main focus of the gpu powered pipeline should be mid to high end graphics cards. The main focus of the cpu powered pipeline should be lower end gpus that are memory bandwidth bound.

Currently, the gltf importer only supports gltf + bin + textures. While most exporters allow this as a format, we should support glb as well, though it is lower priority.

To properly determine the performance of rend3 in expected use cases, benchmark scene(s) should be created that provide a way to reliably and semi-deterministically get perf numbers. This benchmark should ideally be CC so it can be posted online, but that may not be possible.

This will also be supplemented by getting benchmarks from users with their own testing methodology.

I currently only technically support cutout objects, but should properly classify them and render all transparent objects (this will require a GPU side sort).

It's an open question if I want to do this automatically or foist this on the user.

• PBR/Materials
  • Ambient Occlusion (done by 9bd6bc1)
  • Normal mapping (done by #63)
  • #135
  • Anisotropy
  • Subsurface Scattering
  • Specular Glossiness (KHR_materails_pbrSpecularGlossiness
  • Clear coat (KHR_materials_clearcoat)
  • Transmission (KHR_materials_transmission)
  • Sheen (KHR_materials_sheen)
  • IOR (KHR_materials_ior)
• Lighting
  • Point Lights
    • Clustered Light Culling
    • Point light shadows
  • IBL
    • Prebaked light probes
    • Live-reloaded
  • Static shadow/probe caching
• Post-processing
  • SSAO
  • Bloom
  • Motion blur
  • Auto-exposure
  • TAA
  • SSR
  • SSGI (maybe)
• Statistics
  • CPU timing stats
  • GPU timing stats (requires gfx-rs/wgpu#721)

Various references:

• https://frostbite-wp-prd.s3.amazonaws.com/wp-content/uploads/2016/03/29204330/GDC_2016_Compute.pdf
• https://www.advances.realtimerendering.com/s2015/aaltonenhaar_siggraph2015_combined_final_footer_220dpi.pdf

If enough big enough objects are made, vertices go all over the place.

Some minor problem with gslang's build system. Gslang issue filed:

KhronosGroup/glslang#2572

Posted here mostly for reference. No action needed at this time.

We should use a builder api to create the renderer, this will let us have many optional configuration settings or use internal defaults.

All non-render function calls currently push an event on a queue to be processed at render time. This causes issues when there is a lot of texture processing to do. These should be made immediate, with lock usage optimized to allow concurrent access.

cc @John-Nagle

When running the demo, the memory usage increases continually.

When a scene is loaded, the loader returns a LoadedGltfScene to the caller, with useful info such as all the material handles. But the fields of LoadedGltfScene are all private, so the caller can't use the result.

Per email message, this was just an error, and those fields should be public. This is just to track that. Thanks.

Currently, rend3 uses the PUSH_CONSTANT | MAPPABLE_PRIMARY_BUFFERS features which are incompatible with the web. If people want rend3 to run on the web, we need to allow these features to be unsupported, ideally without removing the ability to use them on native.

While I don't particularly have much interest in web support, if someone else does, I'd be happy to support it.

The registry should be transformed from being IndexMap<usize, T> into being something like IndexMap<usize, (Arc<()>, T)>.

This will allow all handles to be refcounted. We should investigate the best way of storing this refcounting.

The renderlists need to support MSAA of at least 4 and 8. They should be most of the way there as it is, just need the final bits.

It would be cleaner if it accepted RendererConfiguration, or alternatively had no arguments and allowed doing something like:

rend3::RendererBuilder::new()
        .window(&window)
        .surface_size(UVec2::new(window_size.width, window_size.height)) // shouldn't be needed?
        .vsync(rend3::VSyncMode::On)
        .build(),

When writing LOD systems, it can be useful to do the following operation: 2048x2048 with 11 mipmaps -> 1024 with 10 mipmaps without needing to upload/regenerate all of the mipmaps. This can be a simple texture recreate + copy_texture_to_texture.

Investigation needs be done into if this can be done inplace or it will need to generate a new TextureHandle.

Support a set of occluder objects. These will be rendered into a depth buffer for use in Hi-Z culling of triangles.

See resources from #13 and https://www.nickdarnell.com/hierarchical-z-buffer-occlusion-culling/ which is a cpu powered implementation, but gives an intuition about what's going on.

@cedric-h @Noxime Due to some concerns brought to my attention I want to relicense the lib to a triple license MIT/Apache-2.0/Zlib. As you are the other contributors, I need your sign off, could you just copy the following:

I give permission for my contributions to the rend3 repository to be relicensed from MPL-2.0 to MIT/Apache-2.0/Zlib.

Cheers.

There should be a way of choosing which objects get drawn in a particular draw call. This way different shaders can be used for different rendering passes, as well as different pipeline settings.

Related: #37 will need to use this.

We also should be integrated with wgpu-profiler which provides an easy to use way to use timestamp queries to monitor gpu execution time.

Loaded more textures than will fit in a 2GB NVidia 640. This was detected by WGPU but the shutdown process caused an illegal instruction.

========

Loaded 11025 meshes, 520701 vertices, 775664 triangles, 0 materials. Duplicate meshes: 95640. duplicate materials: 103597)
basisu_transcoder::basisu_transcoder_init: Initializing (this is not an error)
wgpu error: Validation Error

Caused by:
In Device::create_texture
not enough memory left

thread '' panicked at 'Handling wgpu errors as fatal by default', /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-0.7.0/src/backend/direct.rs:1896:5
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
thread 'main' panicked at 'Job panicked!', /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/switchyard-0.1.1/src/lib.rs:153:78
1459.618951 ERROR(gpu_descriptor::allocator): DescriptorAllocator is dropped while some descriptor sets were not deallocated
thread 'main' panicked at 'assertion failed: (left == right)
left: 63,
right: 0: Allocator dropped before all sets were deallocated', /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/gpu-descriptor-0.1.0/src/allocator.rs:117:9
stack backtrace:
0: 0x55f50c9b68f0 - std::backtrace_rs::backtrace::libunwind::trace::h72c2fb8038f1bbee
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/../../backtrace/src/backtrace/libunwind.rs:96
1: 0x55f50c9b68f0 - std::backtrace_rs::backtrace::trace_unsynchronized::h1e3b084883f1e78c
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/../../backtrace/src/backtrace/mod.rs:66
2: 0x55f50c9b68f0 - std::sys_common::backtrace::_print_fmt::h3bf6a7ebf7f0394a
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:79
3: 0x55f50c9b68f0 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h2e8cb764b7fe02e7
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:58
4: 0x55f50c9d9a4c - core::fmt::write::h7a1184eaee6a8644
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/fmt/mod.rs:1080
5: 0x55f50c9af122 - std::io::Write::write_fmt::haeeb374d93a67eac
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/io/mod.rs:1516
6: 0x55f50c9b8dbd - std::sys_common::backtrace::_print::h1d14a7f6ad632dc8
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:61
7: 0x55f50c9b8dbd - std::sys_common::backtrace::print::h301abac8bb2e3e81
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:48
8: 0x55f50c9b8dbd - std::panicking::default_hook::{{closure}}::hde0cb80358a6920a
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:208
9: 0x55f50c9b8a68 - std::panicking::default_hook::h9b1a691049a0ec8f
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:227
10: 0x55f50c9b94a1 - std::panicking::rust_panic_with_hook::h2bdec87b60580584
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:577
11: 0x55f50c9b9049 - std::panicking::begin_panic_handler::{{closure}}::h101ca09d9df5db47
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:484
12: 0x55f50c9b6d5c - std::sys_common::backtrace::__rust_end_short_backtrace::h3bb85654c20113ca
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:153
13: 0x55f50c9b9009 - rust_begin_unwind
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:483
14: 0x55f50c9b8fbb - std::panicking::begin_panic_fmt::hf0503558fbe5b251
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:437
15: 0x55f50b745c2d - <gpu_descriptor::allocator::DescriptorBucket

as core::ops::drop::Drop>::drop::h5e4a19ead60be931
at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/gpu-descriptor-0.1.0/src/allocator.rs:117
16: 0x55f50b785c86 - core::ptr::drop_in_place::h5828905358069ef8
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
17: 0x55f50b7848a6 - core::ptr::drop_in_place::h4bda2bbdbd47fec9
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
18: 0x55f50b50784b - core::ptr::mut_ptr::<impl *mut T>::drop_in_place::he86a3cddf5a4d6a5
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mut_ptr.rs:963
19: 0x55f50b5b885f - hashbrown::raw::inner::Bucket::drop::ha47d523b956a0163
at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/hashbrown-0.9.1/src/raw/mod.rs:334
20: 0x55f50b5b4866 - <hashbrown::raw::inner::RawTable as core::ops::drop::Drop>::drop::h105ee02b6ea7cf65
at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/hashbrown-0.9.1/src/raw/mod.rs:1387
21: 0x55f50b7840cf - core::ptr::drop_in_place::h4786921e285cbfc4
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
22: 0x55f50b77c6e6 - core::ptr::drop_in_place::h0213673b67baf8c1
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
23: 0x55f50b78fe5a - core::ptr::drop_in_place::hacf55534fef6e1aa
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
24: 0x55f50b77f10f - core::ptr::drop_in_place::h1b46548e8012edf3
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
25: 0x55f50b791fef - core::ptr::drop_in_place::hbe8c27a9edba9352
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
26: 0x55f50b78ecd6 - core::ptr::drop_in_place::h9f77aeb4d1100c4b
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
27: 0x55f50b788836 - core::ptr::drop_in_place::h6f664697b36b8dee
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
28: 0x55f50b788b64 - core::ptr::drop_in_place::h70843b84556dce5c
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
29: 0x55f50b78b8b1 - core::ptr::drop_in_place::h86922aefa0a8ed15
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
30: 0x55f50b662695 - <alloc::vec::Vec as core::ops::drop::Drop>::drop::h7542706d30e0345a
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/alloc/src/vec.rs:2636
31: 0x55f50b780a86 - core::ptr::drop_in_place::h270d3a1f4531a1f6
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
32: 0x55f50b77d93f - core::ptr::drop_in_place::h0d2464cd9aa97aca
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
33: 0x55f50b78f18f - core::ptr::drop_in_place::ha1a0f77630897ed5
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
34: 0x55f50b7967a6 - core::ptr::drop_in_place::he13d6f40fd569a65
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
35: 0x55f50b7810e1 - core::ptr::drop_in_place::h2a2a04648e904b36
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
36: 0x55f50b78b00b - core::ptr::drop_in_place::h83ea081e6953d0c0
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
37: 0x55f50b784176 - core::ptr::drop_in_place::h47ac94a81d232930
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
38: 0x55f50b78a5c5 - core::ptr::drop_in_place::h7e3cd6914d149c5f
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
39: 0x55f50b793995 - core::ptr::drop_in_place::hcb1f637cd1356135
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
40: 0x55f50b6aa294 - alloc::sync::Arc::drop_slow::h201315f20f1d779c
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/alloc/src/sync.rs:934
41: 0x55f50b6acf96 - <alloc::sync::Arc as core::ops::drop::Drop>::drop::h6ca7779db10891ba
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/alloc/src/sync.rs:1454
42: 0x55f50b78a25f - core::ptr::drop_in_place::h7d7724a6ca05d6a8
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
43: 0x55f50a5561b5 - core::ptr::drop_in_place::h149b562205c5bed4
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
44: 0x55f50a5675ef - core::ptr::drop_in_place::hfc18b9422961468c
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
45: 0x55f50a55cf85 - core::ptr::drop_in_place::h7809123838c49547
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
46: 0x55f50a55932e - core::ptr::drop_in_place::h366826405ae70a82
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
47: 0x55f50a555c1e - core::ptr::drop_in_place::h10608e5e86d50673
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
48: 0x55f50a66f7e2 - alloc::sync::Arc::drop_slow::h32b75a7197f4384e
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/alloc/src/sync.rs:934
49: 0x55f50a56a324 - <alloc::sync::Arc as core::ops::drop::Drop>::drop::hd89e180652d5182f
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/alloc/src/sync.rs:1454
50: 0x55f50a5608be - core::ptr::drop_in_place::ha17f0dacadc87931
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
51: 0x55f50a5672ed - core::ptr::drop_in_place::hfa9e84442f022b56
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ptr/mod.rs:175
52: 0x55f50a50a679 - winit::platform_impl::platform::x11::EventLoop::run_return::hea8200ffd372b259
at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.24.0/src/platform_impl/linux/x11/mod.rs:392
53: 0x55f50a50bb1b - winit::platform_impl::platform::x11::EventLoop::run::h727d6fdff40e6337
at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.24.0/src/platform_impl/linux/x11/mod.rs:398
54: 0x55f50a4ce0de - winit::platform_impl::platform::EventLoop::run::h13ae2d1f1e555cb3
at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.24.0/src/platform_impl/linux/mod.rs:652
55: 0x55f50a57b854 - winit::event_loop::EventLoop::run::h89dd547d9cc80018
at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.24.0/src/event_loop.rs:154
56: 0x55f50a65bc21 - slscenetester::displaystate::h2be6aceb304627d8
at /home/john/projects/sl/SL-test-viewer/slscenetester/src/main.rs:342
57: 0x55f50a65d146 - slscenetester::main::h8e6f02da263145b5
at /home/john/projects/sl/SL-test-viewer/slscenetester/src/main.rs:616
58: 0x55f50a5535eb - core::ops::function::FnOnce::call_once::h17c7a85cc44fd5c7
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ops/function.rs:227
59: 0x55f50a47c77e - std::sys_common::backtrace::__rust_begin_short_backtrace::h419441424f556d8b
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:137
60: 0x55f50a579781 - std::rt::lang_start::{{closure}}::hc8f76a53b20d1856
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/rt.rs:66
61: 0x55f50c9b99b7 - core::ops::function::impls::<impl core::ops::function::FnOnce for &F>::call_once::he179d32a5d10d957
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ops/function.rs:259
62: 0x55f50c9b99b7 - std::panicking::try::do_call::hcb3d5e7be089b2b4
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:381
63: 0x55f50c9b99b7 - std::panicking::try::h7ac93b0cd56fb701
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:345
64: 0x55f50c9b99b7 - std::panic::catch_unwind::h7b40e396c93a4fcd
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panic.rs:382
65: 0x55f50c9b99b7 - std::rt::lang_start_internal::h142b9cc66267fea1
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/rt.rs:51
66: 0x55f50a579757 - std::rt::lang_start::h8665b9cdee759f71
at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/rt.rs:65
67: 0x55f50a65d19a - main
68: 0x7fe2654cabf7 - __libc_start_main
69: 0x55f50a47b32a - _start
70: 0x0 -
thread panicked while panicking. aborting.
Illegal instruction (core dumped)

The current plan for dealing with this is to have:

• Per-vert bone weights
• Consume bone matrices then apply them internally on the cpu.
• Transform the vertices on the gpu in a compute shader.

The current shadow implementation is very limited and only supports shadows around the origin. I should adopt cascaded shadow maps so that shadows properly follow the camera.

There are a million settings to tweak for shadows, I need to sit down and figure out what settings I should use as the shadow acne currently looks pretty bad.

There are a couple of advantages to an SOA vertex model. First is that any passes that only use position (such as a depth prepass) has to only use a single vertex buffer. This will be more useful as I add per-triangle culling which only requires the position. These are very quick passes, so keeping data in a cache optimal pattern will be beneficial.

I'm uploading a simple cube created with Blender in GLTF format. Upload works fine, including textures, but objects appear inside out, probably because the winding order is reversed. I know about flip_winding_order. But I can't use it when all I have is a mesh handle after the upload. I think it's too late by then.

So here's a unit cube created in Blender, with normals pointing out, back faces being culled, and rendering properly in Blender. Something needs to be flipped, but I'm not sure what.

unitcube.zip

Instead of #68, we should remove the render list and make rend3's components more externally accessible. All these components will then be exposed to a composable render function which directly issues wgpu commands onto command buffers.

There are automatic caching systems for:

• bind groups
• pipelines
• internal render textures

The user-provided rendering functions will be a single function that takes a rend3 context and then a certain set of needed arguments. There will be guides for designing these so be ideomatic.

Currently, pools and priorities are hardcoded. This should be user-configurable.

https://github.com/BVE-Reborn/rend3/blob/trunk/rend3/src/renderer/mod.rs#L175-L181

We need some solution to 2D rendering for doing UIs such as imgui. We have a couple of options:

• Integrate with imgui directly, taking a ready-to-render frame, and rendering it.
• Provide a 2D rendering interface that we could implement an imgui renderer on top of.
• Don't support it at all, letting external integration deal with it. This means a user could have rend3 render to the swapchain, then they would render the UI on top of it later (see #15)

Todo:

• Support external resources (#40 and #41)
• Imgui example (#42)
• Iced example