People
Activity
    Aaron McLeod
    @agmcleod
    @kvark I did run with the --features option, do i need to add that somewhere else? 
    aaronmcleod@Aarons-MBP~/src/rust/wgpu$ cargo run --bin cube --features metal
    Finished dev [unoptimized + debuginfo] target(s) in 1.30s
    Running `target/debug/cube`
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:355:21
note: Run with `RUST_BACKTRACE=1` for a backtrace.
    Dzmitry Malyshau
    @kvark
    make gfx name=cube
    Aaron McLeod
    @agmcleod
    yep, that does it
    Dzmitry Malyshau
    @kvark
    your command line is good, just needs to be run from gfx-examples folder to work
    Aaron McLeod
    @agmcleod
    yeah i see the option the make added to run using the manifest file from that folder :)
    Dzmitry Malyshau
    @kvark
    you reminded me that we can print out something more informative upon not finding an adapter, thank you!
    mnivoliez
    @mnivoliez
    Hello, I'm currently working in a small project with ggez and specs. I am wondering what could be a "good" way to handle rendering with that setup. Most of the examples I found so far delegate render outside specs directly to ggez while rendering could be a system from specs perspective. I'm a little confuse by that.
    Zakarum
    @omni-viral
    Usually rendering needs to access lots of components
    And set of components may be unknown up front
    In case it is your own app, not engine, then you do know which components are required for rendering, so it is possible I guess
    mnivoliez
    @mnivoliez
    Well, I was thinking of a "ui-rendering-system" and a "game-rendering-system", both with context passed as a "Read" ressource
    but I don't see how it should interpolate with ggez
    Gray Olson
    @termhn
    With ggez as your “rendering engine” you need to do a thread local system anyway because it’s OpenGL. So the best you could do would be to have your “ui render system” and “game render system” essentially read data from the specs world and spit out a few buffers in some specified format that you know about, then in a thread local system afterwards you’d read those buffers and turn them into ggez draw commands
    Dzmitry Malyshau
    @kvark
    setting up android dev is such a pain... dozen of steps to follow witl lots of crap tool installations
    now I'm looking at "could not execute process `/hub/tools/android-ndk-r19c/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc" and losing my patience
    anybody seen this? "arm-linux-androideabi-gcc" is just not there. Followed the steps from https://github.com/rust-windowing/android-rs-glue
    Thomas Schaller
    @torkleyy
    Hmm... I had similar problems last time I tried
    I'd just use the Docker image by now.
    This suggests that a simple extraction isn't enough and you need the whole Android Studio..
    Dzmitry Malyshau
    @kvark
    Thanks @torkleyy
    David Harvey-Macaulay
    @alteous
    There a number of gltf users using nalgebra wishing to remove their dependencies on cgmath. Is there a ecosystem related reason for this, i.e. is nalgebra more common/popular/useful/interoperable than cgmath?
    Aleksi Juvani
    @aleksijuvani
    it seems to me that nalgebra is more commonly used than cgmath
    i was initially using cgmath because i was concerned that the amount of generics nalgebra uses makes it generate bad code, but it's actually very well written and optimizes exceptionally well
    benchmarks show identical performance between the two if i remember correctly
    cgmath is not actively developed anymore i don't think
    there are a few oddities in cgmath as well, regarding the coordinate systems.. nalgebra-glm handles this a lot more consistently and explicitly
    David Harvey-Macaulay
    @alteous

    Thanks, this is useful information.

    cgmath is not actively developed anymore i don't think

    This is an important distinction!

    In that case, it seems reasonable to switch from cgmath to nalgebra. The suggestions I'm receiving is to support both for the sake of dependency management but I don't have the time/patience/testing for that.
    Aleksi Juvani
    @aleksijuvani
    i have a feeling it would be a controversial decision since some people would want to avoid nalgebra for the sheer size of it alone
    David Harvey-Macaulay
    @alteous
    I'm tempted to roll my own math to avoid this problem.
    Aleksi Juvani
    @aleksijuvani
    what functionality is gltf using anyway? would it be reasonable to use, say a tuple of floats instead?
    David Harvey-Macaulay
    @alteous
    For (de)composing matrices to/from translation/rotation/scale. https://docs.rs/gltf/0.12.0/gltf/scene/enum.Transform.html
    Aleksi Juvani
    @aleksijuvani
    seems reasonable to me if this is the only place where it's needed
    for what it's worth, it would be possible to set up travis to test both nalgebra/cgmath if it was implemented through feature flags
    Dzmitry Malyshau
    @kvark
    My recommendation would be to use mint types at the API boundary and then it doesn't matter what the implication and the user use
    Dzmitry Malyshau
    @kvark
    are there people interested in maintaining cgmath? (re https://github.com/rustgd/cgmath/pull/483#issuecomment-489105803)
    Gray Olson
    @termhn
    @kvark i think the problem isn't types at api boundary (cgmath is never exposed and nalgebra wouldn't be either) but rather the need to pull in an extra (rather large) dependency that they wouldn't otherwise have
    @alteous I would say it might be best to literally just copy/paste (or rewrite) the necessary functions for that behavior. Seems a bit overkill to pull in all of cgmath or nalgebra for that purpose alone.
    Dzmitry Malyshau
    @kvark
    sorry, what purpose are you referring to?
    Gray Olson
    @termhn
    @kvark the question of nalgebra vs cgmath in gltf crate
    Aleksi Juvani
    @aleksijuvani
    @kvark any chance of a new release of cgmath soon? i'm trying to get rid of all my dependencies to the rand crate
    cgmath master no longer depends on rand but cgmath 0.17.0 does
    Dzmitry Malyshau
    @kvark
    Seems like a minor reason to do a breaking release, isn't it?
    It will not affect any mint users, but poor folks who have cgmath directly on their api will suffer...
    Aleksi Juvani
    @aleksijuvani
    i'd be fine with a patch release that marks rand optional
    but enabled by default
    David Harvey-Macaulay
    @alteous
    @kvark: are you maintaining cgmath at the moment? I've copied some code into gltf and want to make sure the copyright formalities are in place. https://github.com/gltf-rs/gltf/pull/223/files#diff-b2e459ded86685302d79df1ad4c8671c
    Dzmitry Malyshau
    @kvark
    It's unfortunate if I'm the only maintainer...
    Dzmitry Malyshau
    @kvark
    License seems fine, thanks for the heads up!