Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 05:15
    bors[bot] closed #3097
  • 05:15
    bors[bot] commented #3097
  • 05:15

    bors[bot] on hal-0.4

    Backport of #3096 to hal-0.4 br… Bump gfx-backend-dx11 to 0.4.3 Merge #3097 3097: Backport of … (compare)

  • 04:56

    bors[bot] on staging.tmp

    (compare)

  • 04:56

    bors[bot] on staging

    Merge #3097 3097: Backport of … (compare)

  • 04:56

    bors[bot] on staging.tmp

    Backport of #3096 to hal-0.4 br… Bump gfx-backend-dx11 to 0.4.3 [ci skip][skip ci][skip netlify… (compare)

  • 04:56

    bors[bot] on staging.tmp

    [ci skip][skip ci][skip netlify] (compare)

  • 04:56
    kvark commented #3097
  • 04:12
    moxian edited #3097
  • 04:11
    moxian opened #3097
  • 01:54
    bors[bot] closed #3095
  • 01:54

    bors[bot] on master

    Upgrade to smallvec 1.0 Merge #3095 3095: Upgrade to s… (compare)

  • 01:54
    bors[bot] commented #3095
  • 01:14

    bors[bot] on staging.tmp

    (compare)

  • 01:14

    bors[bot] on staging

    Upgrade to smallvec 1.0 Merge #3095 3095: Upgrade to s… (compare)

  • 01:14

    bors[bot] on staging.tmp

    Upgrade to smallvec 1.0 [ci skip][skip ci][skip netlify… (compare)

  • 01:14

    bors[bot] on staging.tmp

    [ci skip][skip ci][skip netlify] (compare)

  • 00:56
    bors[bot] closed #3096
  • 00:56
    bors[bot] closed #3092
  • 00:56
    bors[bot] closed #3092
Brendan Zabarauskas
@brendanzab
<3 <3 <3
Dzmitry Malyshau
@kvark
lol, bye!
Brendan Zabarauskas
@brendanzab
I'm wondering if what we actually want for the 'calls' are futures... dunno whether the overhead of them is too high. apparently aturon wants to refactor them
Dzmitry Malyshau
@kvark
@bjz nope, I hasn't got into Metal yet. Are you pitching it for the sake of gfx-rs portability or just as a general interest?
kvark @kvark still remembers S3 MeTaL... ah those sweet times in UT
Brendan Zabarauskas
@brendanzab
just general interest
@kvark So how high level do you think the renderer will be?
Dzmitry Malyshau
@kvark
@bjz my basic vision is pretty much explained in #3, though no-one seem to have reacted to that
Brendan Zabarauskas
@brendanzab
I'll look again! :D
Brendan Zabarauskas
@brendanzab
will we be thinking about things like cameras, shadows and culling?
if not, maybe we could think about scrapping the render task...?
Dzmitry Malyshau
@kvark
@bjz basically, renderer should operate on meshes, target sets, programs, render states, and environments. The last one is the only that really need to be designed. It is supposed to capture all the shader parameter values (which, together with the render states, are covering any high-level material needs, supposedly)
@bjz I believe cameras, shadows, and culling can be left to a higher level engine outside of the renderthread, but I'll need to think this through...
Brendan Zabarauskas
@brendanzab
sure thing
Dzmitry Malyshau
@kvark
@bjz We need to define the scope of each layer. For example, device layer just abstracts over API and potentially does some caching to reduce number of calls to that API
Brendan Zabarauskas
@brendanzab
yep, agreed
Dzmitry Malyshau
@kvark
Render layer scope may be to translate high-level concepts (meshes, target sets, programs, render states, environments) into sets of device commands, potentially sorting the draw calls on the way.
@bjz if we want to make render layer aware of the cameras and culling, this would require us to lock on a particular spatial structure, which is the last thing we need for gfx-rs. I believe the spatial stuff is high-level, and should live (and be married to) physics and skinning.
Brendan Zabarauskas
@brendanzab
cool
could there be multiple render layers?
Dzmitry Malyshau
@kvark
@bjz do you mean gfx-rs to provide an even higher level of abstraction with the spatial system of sorts (or at least templated by it)? I see no reason why it shouldn't be possible, and I'd definitely like it. It is a bit far from where we are though...
@bjz I got a question. It should be forbidden for the device module to use anything from render, right? I'm trying to figure out where the mesh structure (and such) should be defined.
Brendan Zabarauskas
@brendanzab
do you mean in reference to my previous comment, or in relation to my question about cameras etc?
hmm
Dzmitry Malyshau
@kvark
My second (last) question is unrelated to the discussion. It's just something I'm working on right now.
brendanzab @bjz is thinking
Brendan Zabarauskas
@brendanzab
Is the mesh structure going to be user facing?
Dzmitry Malyshau
@kvark
I think mesh handle is what user is going to see, not the structure.
It is still a question whether we should expose everything to the user on demand. Would anyone want to know the number of vertices, for example, of the mesh? I think we should do our best to completely abstract that.
Brendan Zabarauskas
@brendanzab
Yeah, travis is being weird with my latest makefile :( https://travis-ci.org/bjz/gfx-rs/builds/28138624#L392-L401
it is working for you locally right?
Dzmitry Malyshau
@kvark
My local command appears to be different from Travis one:
rustc -L deps/gl-rs/lib -L deps/glfw-rs/lib --out-dir=lib --cfg=gl --cfg=glfw -O src/gfx/lib.rs
@bjz Should I remove the source branch (cleanups for the matter) after accepting your PR?
Brendan Zabarauskas
@brendanzab
sure
Dzmitry Malyshau
@kvark
So what was the problem with Makefile? You got the fix?
Brendan Zabarauskas
@brendanzab
@kvark it is different because the lib dir variable is constructed before the submodules have been inited
Dzmitry Malyshau
@kvark
@bjz Do Rust coding guidelines forbid ":" alignment in struct definitions? Like that:
struct Foo {
    let x         : int,
    let y_long    : int,
}
Brendan Zabarauskas
@brendanzab
yeah, normal rust code seems to just have foo: bar
we will be getting rustfmt at some stage, when pcwalton gets around to finishing it
Dzmitry Malyshau
@kvark
That would be greatness
Brendan Zabarauskas
@brendanzab
yayy
Dzmitry Malyshau
@kvark
@bjz thanks! I'm glad you got that sorted out
Dzmitry Malyshau
@kvark
@bjz about usage of Future for calls. Can we really do that? I mean, the future must be holding the stream somehow, so we will not be allowed to do anything while it's alive.
Dzmitry Malyshau
@kvark
@bjz are you still around? have a look at #17
alright, see you tomorrow then
Brendan Zabarauskas
@brendanzab
@kvark still reading your patch :)
Dzmitry Malyshau
@kvark
@bjz I'm not sure what to do with the Attribute::name field. Making at a String would make it impossible to have a static ATTRIB_EMPTY, which helps a big deal of initializing the Mesh. It'd be nice to have a fixed-capacity string that is not owned.
@bjz there is also a problem of how the user is going to specify all these attributes at once. Currently the fact that we have a single attribute with 2 components and stride of 8 is hard-coded.