Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

27 loading models #13

Open
wants to merge 95 commits into
base: master
Choose a base branch
from

Conversation

matthew-russo
Copy link
Contributor

No description provided.

…t creation, updates create_command_buffers to map memory to our uniform buffer, reverses the order of vertices drawn
@bwasty
Copy link
Owner

bwasty commented Feb 16, 2019

This is crashing for me in different ways on Windows 10 (Nvidia GTX 1070 / Intel UHD 630):

1: immediate crash

     Running `target\debug\27_model_loading.exe`
error: process didn't exit successfully: `target\debug\27_model_loading.exe` (exit code: 3221225477)

Similar to the one mentioned in #18, but note that the line with the supported extensions is not there.

2: after rendering successfully for a few seconds

validation layer: " [ VUID_Undefined ] Object: 0x2d99d366100 (Type = 28) | Added callback"
thread 'main' panicked at 'assertion failed: {
    let dur = Some(Duration::new(0, 0));
    self.fence.as_ref().map(|f| f.wait(dur).is_ok()).unwrap_or(true)
}', C:\...\.cargo\registry\src\github.com-1ecc6299db9ec823\vulkano-0.11.1\src\swapchain\swapchain.rs:867:13
note: Run with `RUST_BACKTRACE=1` for a backtrace.
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "PoisonError { inner: .. }"', src\libcore\result.rs:1009:5

I just wanted to retry it with RUST_BACKTRACE but now it doesn't happen anymore...

It also may not be related to the 'preferred graphics processor' setting, since it's now more random and I'm not sure anyway how the setting would affect Vulkan since we are choosing the device. I think it makes sense to log the name of the GPU after device selection...

And I suspect it may not be related at all to this tutorial step.

@mortzdk
Copy link

mortzdk commented Mar 24, 2021

Isn't the claim about de-duplication

Unlike the C++ tutorial, vertex deduplication is not necessary as it is handled by tobj

False?

As I understand it, TOBJ reuses positions. However your code still creates a vertex for each of the indices. The amount of vertices could be reduces by almost a factor 4 simply by checking the existence of the index using a hashmap:

let mut unique_vertices = HashMap::new();
match unique_vertices.get(&index) {                             
    Some(_) => {}                                               
     None => {                                                   
        unique_vertices.insert(index, vertices.len() as u32);   
       vertices.push(vertex);                                  
        }                                                           
     }                                                               
                                                                       
indices.push(*unique_vertices.get(&index).unwrap())

I go from:

Amount of vertices 11484
Amount of indices 11484

to

Amount of vertices 4730
Amount of indices 11484

The program seems to be running fine after this adjustment, but maybe I misunderstood something?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants