These are chat archives for bjz/gfx-rs

18th
Jun 2014
Dzmitry Malyshau
@kvark
Jun 18 2014 02:55
test
Brendan Zabarauskas
@brendanzab
Jun 18 2014 02:55
ohai
Dzmitry Malyshau
@kvark
Jun 18 2014 02:56
awesome
this is what I have in mind
Brendan Zabarauskas
@brendanzab
Jun 18 2014 02:57
Awesome, will look
firsts up - spaces man
:D
rust coding guidelines!
Dzmitry Malyshau
@kvark
Jun 18 2014 02:59
ok
Brendan Zabarauskas
@brendanzab
Jun 18 2014 02:59
sorry!
but yeah, that looks similar
Dzmitry Malyshau
@kvark
Jun 18 2014 02:59
updated
not sure about DuplexStream (didn't happen to do any comm stuff yet), but regular channel has the same type for the response, which is not what we need
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:00
I had some very crude stuff sketching around: https://gist.github.com/bjz/bf4efe9a8fa62fd8b2f1
(not modularised or anything)
Copy is implicitly implemented?
Dzmitry Malyshau
@kvark
Jun 18 2014 03:01
yeah
from your code, only the platform loop and render task are meant for gfx-rs, right?
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:03
aye
was just blocking out the code
flow I mean
not sure how to nest the tasks - taking into account task failure
Dzmitry Malyshau
@kvark
Jun 18 2014 03:04
I don't see where they are nested
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:04
yeah - they aren't in this
whether they should be
Dzmitry Malyshau
@kvark
Jun 18 2014 03:05
actually, main() is the task, and it spawns others
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:05
yep
Dzmitry Malyshau
@kvark
Jun 18 2014 03:05
why is main() a separate task?
it doesn't matter, I guess...
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:06
the opengl/windowing stuff needs to be on the main thread
If I dispatched DrawClear, what would the answer be?
Dzmitry Malyshau
@kvark
Jun 18 2014 03:07
no answer
same for DrawMesh
that's why dispatch returns an option in my case
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:08
ahhhh
Dzmitry Malyshau
@kvark
Jun 18 2014 03:08
could return Result<> instead
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:08
neat way of doing it
OTP servers have separate call and cast functions for that
Dzmitry Malyshau
@kvark
Jun 18 2014 03:09
OTP?
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:09
with erlang
I implemented it in Rust with an enum { Call(T), Cast(U) } under the hood
Dzmitry Malyshau
@kvark
Jun 18 2014 03:10
where is it in your code?
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:11
not there - that was a long time ago
Dzmitry Malyshau
@kvark
Jun 18 2014 03:12
I'll try to make something actually rendering, and then integrate into your Platform thing, and then we'll see if we can port it to gfx (if we get there)
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:12
not very useful
Dzmitry Malyshau
@kvark
Jun 18 2014 03:13
that's helpful to understand what you mean
you are concerned that the presence/need for the reply is not expressed in the type system
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:14
Not concerned - just curious - trying to understand
Dzmitry Malyshau
@kvark
Jun 18 2014 03:15
I agree that would be more expressive, but we can do that after the draft
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:15
sure thing
better to get something rendering!
Dzmitry Malyshau
@kvark
Jun 18 2014 03:16
I like to get something working first, even if a bit dirty, especially when exploring paths I didn't go before
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:16
indeed
we can probably hard code lots of stuff like the gl and glfw stuff for now - then split things up later
so long as we start building up the task-based architecture
me and chip (photex) were also experimenting with using the command pattern for communicating with the platform IO
Dzmitry Malyshau
@kvark
Jun 18 2014 03:20
if you were experimenting with it, why did you have nothing rendered?..
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:20
haha
...rabbit holes...
Dzmitry Malyshau
@kvark
Jun 18 2014 03:24
oh, now I see that glfw examples also use native::start
it used to be different last time I touched it
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:25
aye
I have updated glfw quite a bit
It is now quite ruthless in terms of making sure the right stuff is run off the main thread
Dzmitry Malyshau
@kvark
Jun 18 2014 03:26
yeah, got it
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:26
ie. you will get type errors if you try to move the context off the main thread
:P
Dzmitry Malyshau
@kvark
Jun 18 2014 03:27
type errors?
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:27
yup
Dzmitry Malyshau
@kvark
Jun 18 2014 03:27
not the run-time assertions?
wow
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:28
you can do that with the markers in {core,std}::kinds
Dzmitry Malyshau
@kvark
Jun 18 2014 03:28
interesting, I'll look into it
Dzmitry Malyshau
@kvark
Jun 18 2014 03:31
thanks!
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:31
You can tear off a sharable render context though
Dzmitry Malyshau
@kvark
Jun 18 2014 03:32
do we need to use it?
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:32
the shared context only implements a subset of the glfw functionality though
no, not really
Dzmitry Malyshau
@kvark
Jun 18 2014 03:32
ah, I see, interesting
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:32
wait, this is per-window btw
so what can I be working on so I don't tread on your toes?
Dzmitry Malyshau
@kvark
Jun 18 2014 03:34
hmmm... Platform stuff?
unsure
where is glfw function loader?..
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:36
glfw.get_proc_address
the gl-rs examples might be useful
Dzmitry Malyshau
@kvark
Jun 18 2014 03:36
will look
thanks
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:37
but probably not all that much
so I'm wondering, what would the entry point for the user look like?
Dzmitry Malyshau
@kvark
Jun 18 2014 03:39
super_function(creation_params) -> Receiver
where Receiver = comm::DuplexStream<Request, Answer>
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:40
yeah, I think a free function would be nice
Dzmitry Malyshau
@kvark
Jun 18 2014 03:40
but this piston code is not client code
I mean, it's not the entry point for the user
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:41
that is an example though?
Dzmitry Malyshau
@kvark
Jun 18 2014 03:41
oh it is, my bad then :)
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:42
would the user specifiy things like glfw and opengl at the entry point, or would that be handled under the covers?
Dzmitry Malyshau
@kvark
Jun 18 2014 03:42
so they implement Game trait, create an instance and run
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:42
yeah
I'm not sure if that is the best
I dunno
Dzmitry Malyshau
@kvark
Jun 18 2014 03:43
I don't see why we'd need the user to do that. All our interface results in a channel end
which allows the user to send commands and receive something
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:43
yeah
Dzmitry Malyshau
@kvark
Jun 18 2014 03:44
I'll keep thinking about it, esp after getting something running ;)
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:44
that would be nice
sorry!
Dzmitry Malyshau
@kvark
Jun 18 2014 03:44
no worries
is that pretty much what Gitter (and the like) does? a chat?
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:45
we might need to eaither return an object to allow the user to manually pump the platform loop, or return the reciever from via a proc that the user passes into the runction
Dzmitry Malyshau
@kvark
Jun 18 2014 03:47
return via a proc? how is that?
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:48
fn run(opts: _, f: proc(Result<DuplexStream<_, _>, _>); vs fn run(opts: _) -> (DuplexStream<_, _>, Platform)
Dzmitry Malyshau
@kvark
Jun 18 2014 03:48
why would anyone want the first variant?
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:49
abstracts over the platform looping, but it is less flexible
the former would spawn the f within a new task, then block on the main thread, running the platform loop
the other would allow the user to pump the platform on the main thread themselves
dunno if that makes sense
but I think you are right, the latter is the better one
Dzmitry Malyshau
@kvark
Jun 18 2014 03:52
are you saying the former proc is gonna be called by the plaform loop?
I thought procs are only executed once
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:52
before the platform loop
Dzmitry Malyshau
@kvark
Jun 18 2014 03:53
I'll need to look at the platform again
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:54
~~~rust
fn run(f: proc(_)) {let result = spawn_renderer(); spawn(proc() { proc(result) }
ack
Dzmitry Malyshau
@kvark
Jun 18 2014 03:55
thats a bunch of tasks and procs
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:55
fn run(f: proc(_)) {let result = init(); spawn_renderer(); spawn(proc() f(result)); loop { /* platform stuff */ } }
that is not correct
result is not right
but yeah - I think we would not want to go that way
Dzmitry Malyshau
@kvark
Jun 18 2014 03:56
I'll have a look at that tomorrow with a fresh head, sorry for being dumb
Brendan Zabarauskas
@brendanzab
Jun 18 2014 03:56
np!
I am excited!
^_^
fn spawn_renderer(options: ()) -> Result<(Renderer, Platform), ()>
Renderer is a struct with the duplex stream
Dzmitry Malyshau
@kvark
Jun 18 2014 04:00
what else is there?
Brendan Zabarauskas
@brendanzab
Jun 18 2014 04:00
probably not that much
Brendan Zabarauskas
@brendanzab
Jun 18 2014 04:11
the idea is you just call regular functions on the Renderer, and the messaging is handled internally
Dzmitry Malyshau
@kvark
Jun 18 2014 04:12
oh
hmm
Brendan Zabarauskas
@brendanzab
Jun 18 2014 04:12
not sure
Dzmitry Malyshau
@kvark
Jun 18 2014 04:12
neat
Brendan Zabarauskas
@brendanzab
Jun 18 2014 04:12
but that might be inflexible
I dunno
Dzmitry Malyshau
@kvark
Jun 18 2014 04:12
I like it
Brendan Zabarauskas
@brendanzab
Jun 18 2014 04:12
it's what they do in erlang land
enum InitError {}

struct Renderer;
struct Platform;

fn start(options: ()) -> Result<(Renderer, Platform), InitError> {
    init_platform(options).map(|(drawer, platform)| {
        ((spawn_renderer(options, drawer), platform))
    })
}
Dzmitry Malyshau
@kvark
Jun 18 2014 04:14
looks good
Brendan Zabarauskas
@brendanzab
Jun 18 2014 04:23
enum InitError {}

struct Platform;
struct Device;

fn init_platform(options: ()) -> Result<(Device, Platform), InitError> {
    unimplemented!()
}

struct Renderer;

fn spawn_renderer(options: (), device: Device) -> Renderer {
    let (renderer, inner_thing) = (Renderer, ());
    spawn(proc() {
        let _ = inner_thing;
        let _ = device;
    });
    renderer
}

fn start(options: ()) -> Result<(Renderer, Platform), InitError> {
    init_platform(options).map(|(device, platform)| {
        ((spawn_renderer(options, device), platform))
    })
}
Dzmitry Malyshau
@kvark
Jun 18 2014 04:24
perhaps, Device instead of Drawer ?
Brendan Zabarauskas
@brendanzab
Jun 18 2014 04:25
YES!
that is much nicer
updated
Dzmitry Malyshau
@kvark
Jun 18 2014 04:26
can't complain, you are in the right direction ;)
Brendan Zabarauskas
@brendanzab
Jun 18 2014 04:26
okbye
Dzmitry Malyshau
@kvark
Jun 18 2014 04:28
leaving?
Dzmitry Malyshau
@kvark
Jun 18 2014 04:39
ok, I kinda got the basic example that loads a shader program (nothing rendered just yet)
there is a tiny problem that the program fails to link, not sure why, but I'll proceed in case this is just a mistake in error handling on my side
see ya tomorrow
Brendan Zabarauskas
@brendanzab
Jun 18 2014 04:43
back home! ^_^
Dzmitry Malyshau
@kvark
Jun 18 2014 13:06
shader linking is fixed, all good
Dzmitry Malyshau
@kvark
Jun 18 2014 14:18
Can it be that Q^3 already had something like this implemented?
Dzmitry Malyshau
@kvark
Jun 18 2014 15:35
... catching up on the data-oriented design by following the links in research.md ...
Brendan Zabarauskas
@brendanzab
Jun 18 2014 15:50
awesome!
I have a high level stucture of the engine almost done
I will push to gfx-rs
Then I must get back to servo
Dzmitry Malyshau
@kvark
Jun 18 2014 16:05
ok, cool
Dzmitry Malyshau
@kvark
Jun 18 2014 16:51
how come we don't see photex here?
Chip Collier
@photex
Jun 18 2014 17:04
o/
Dzmitry Malyshau
@kvark
Jun 18 2014 17:04
nice
I started sketching yesterday to get at least something going. Protocol is here (https://github.com/kvark/blade-engine/blob/gfx/src/proto/mod.rs), and the example program is here (https://github.com/kvark/blade-engine/blob/gfx/examples/proto.rs)
so far it starts in a window and links a simple program
I feel there are a lot of architectural questions that need to be deeply discussed, but so far just trying to get anything rendered
Dzmitry Malyshau
@kvark
Jun 18 2014 17:09
(spent about 2 hours on that, had the shader loading implemented before)
Here is my current implementation of the "data" setup
I use this for each type of engine data
vbos, shader programs
and so on
I haven't figured out the best way to deal with invalidating handles
Dzmitry Malyshau
@kvark
Jun 18 2014 17:11
awesome! I'll have a good look right after I grab some lunch
Initial stuff blocked out
Chip Collier
@photex
Jun 18 2014 17:20
yeah, the rest of my sketches and work at this is in the graphics module of voyager still
at the moment we have a grey screen that compiles a default shader
the shader program and vertex buffer implementations are workable though
Brendan Zabarauskas
@brendanzab
Jun 18 2014 17:21
:)
@photex did you see @kvark's work with blade?
Chip Collier
@photex
Jun 18 2014 17:21
not sure if they are supposed to fit in gfx-rs or not but they probably could
Brendan Zabarauskas
@brendanzab
Jun 18 2014 17:21
yeah
Chip Collier
@photex
Jun 18 2014 17:21
not yet
Chip Collier
@photex
Jun 18 2014 17:23
ah, so we'll use channels to make api calls?
it's like actors
Brendan Zabarauskas
@brendanzab
Jun 18 2014 17:23
here is what gw used at his old job: https://gist.github.com/glennw/8d243db87186aab36b33
Chip Collier
@photex
Jun 18 2014 17:23
message passing
Brendan Zabarauskas
@brendanzab
Jun 18 2014 17:23
yeah pretty much
based off the OTP (erlang) gen_server module
Chip Collier
@photex
Jun 18 2014 17:24
this is very fortunate, because I was going to ask what you thought about this kind of architecture
Brendan Zabarauskas
@brendanzab
Jun 18 2014 17:24
:)
Chip Collier
@photex
Jun 18 2014 17:24
specifically for building a network of "operators" that define the game world
or something to that effect
Brendan Zabarauskas
@brendanzab
Jun 18 2014 17:25
so yeah, we can put the command setting methods into device::Server
the user will be able to make thier own game task
and pump the device server on the main platform thread
Brendan Zabarauskas
@brendanzab
Jun 18 2014 17:30
@photex @kvark so you are happy with the gfx stuff I have laid out so far?
Chip Collier
@photex
Jun 18 2014 17:33
Looks great so far
Brendan Zabarauskas
@brendanzab
Jun 18 2014 17:33
I know it is very much a skeleton
I can work on the input stuff tonight
Chip Collier
@photex
Jun 18 2014 17:33
I think I can see where the vertexbuffer and shaderprogram implementations would sit
gfx-rs shouldn't handle input should it?
Brendan Zabarauskas
@brendanzab
Jun 18 2014 17:33
yeah I don't know how to split this stuff out
Chip Collier
@photex
Jun 18 2014 17:34
You need a generic platform interface
that users of this library need to provide a concrete implementation of
Brendan Zabarauskas
@brendanzab
Jun 18 2014 17:34
should we have a separate crate abstracting over context creation?
Chip Collier
@photex
Jun 18 2014 17:34
like in voyager
the context has to be provided
by something outside this crate
Brendan Zabarauskas
@brendanzab
Jun 18 2014 17:35
ok, sounds good
could you sketch out what you mean by that?
Dzmitry Malyshau
@kvark
Jun 18 2014 17:36
@bjz Why is main platform thread a device::Server? I thought of the render thread as a server, and the main platform thread as a client, since it asks the server to do something
Chip Collier
@photex
Jun 18 2014 17:36
@bjz getting an opengl context is too specific of a task
Brendan Zabarauskas
@brendanzab
Jun 18 2014 17:36
@kvark The OpenGl calls will be happening on the main thread
@kvark The render task is sending stuff to the main task
Chip Collier
@photex
Jun 18 2014 17:37
so whatever implements the Platform interface can have a function that provides an opengl context to gfx-rs
Brendan Zabarauskas
@brendanzab
Jun 18 2014 17:38
@photex Ok, sounds good
Chip Collier
@photex
Jun 18 2014 17:38
people who want to use gfx-rs have to implement Platform using whatever library they like (sdl2, glfw)
Dzmitry Malyshau
@kvark
Jun 18 2014 17:38
@bjz ok so the user task interacts with render task, which asks the main platform thread to do stuff
correct?
Brendan Zabarauskas
@brendanzab
Jun 18 2014 17:38
@kvark correct
Chip Collier
@photex
Jun 18 2014 17:38
we can always make a seperate optional crate with a test implementation of Platform
Dzmitry Malyshau
@kvark
Jun 18 2014 17:38
@bjz in this case why didn't you order them like that (platfrom, then render, then user) in the graph? that's what confused me
Chip Collier
@photex
Jun 18 2014 17:39
gfx-platform-glfw, or gfx-platform-sdl2
Brendan Zabarauskas
@brendanzab
Jun 18 2014 17:39
@kvark and the user pumps the device::Server manually in an update loop so that they can do stuff on the main thread if they want
Chip Collier
@photex
Jun 18 2014 17:39
or something less terribly named
Brendan Zabarauskas
@brendanzab
Jun 18 2014 17:40
@kvark I'll do some tweaks to that diagram
Dzmitry Malyshau
@kvark
Jun 18 2014 17:45
I wish Gitter didn't just drop the code in the middle of the conversation
I got complains
Chip Collier
@photex
Jun 18 2014 17:46
let shader_programs = EngineData::new();
ShaderProgram::new(vert_src, frag_src)
.and_then(|program| {
Some(self.shader_programs.add(program))
})
this has been the approach so far
our materials are defined in json
not too concrete
Dzmitry Malyshau
@kvark
Jun 18 2014 17:48
1) I don't think GL error should be inspected in the production code. It is meant to be for debugging only.
Chip Collier
@photex
Jun 18 2014 17:48
when the app runs, we load the configuration, build any shader programs defined
Dzmitry Malyshau
@kvark
Jun 18 2014 17:49
2) VBO construction consumes a Vec, and the type of it is Vec<f32> ? both are questionable
3) a program is only the one that has a VS and a PS?
Brendan Zabarauskas
@brendanzab
Jun 18 2014 17:49
extern crate gfx;

#[start]
fn start(argc: int, argv: **u8) -> int {
    native::start(argc, argv, main)
}

fn main() {
    // spawn render task
    let (renderer, platform) = gfx::start(()).unwrap();

    // spawn game task
    spawn(proc {
        let _ = renderer; // do stuff with renderer
    })

    loop {
        platform.update(); // update platform
    }
}
@kvark ^
Chip Collier
@photex
Jun 18 2014 17:50
2) not sure how you'd create a vbo without a Vec
and f32 isn't that outrageous as a placeholder while we figure out what our needs are
Dzmitry Malyshau
@kvark
Jun 18 2014 17:51
@bjz thanks! how does user platform fit into this?
Brendan Zabarauskas
@brendanzab
Jun 18 2014 17:51
@kvark not sure yet
Dzmitry Malyshau
@kvark
Jun 18 2014 17:51
2) &Vec<u8> then
2) or better &[u8]
Brendan Zabarauskas
@brendanzab
Jun 18 2014 17:51
@kvark I'm guessing you would pass it in as an argument to gfx::start
Chip Collier
@photex
Jun 18 2014 17:52
2) slice has to be built from a Vec right? I just went from the gl-rs examples there. u8 works for me
Brendan Zabarauskas
@brendanzab
Jun 18 2014 17:53
could there be some kind of trait for VBO-able things? like, the cgmath stuff could implement it
like, points and vectors
Dzmitry Malyshau
@kvark
Jun 18 2014 17:53
2) yeah, sure, I just got an impression that gfx is about being very general
Brendan Zabarauskas
@brendanzab
Jun 18 2014 17:53
and then implement it on Vec
yeah, true
just musing
Chip Collier
@photex
Jun 18 2014 17:53
3) I wasn't aware that you could have shaders independent of a shader program so I just rolled that together to get us going
less unsafe{}, more generic
Brendan Zabarauskas
@brendanzab
Jun 18 2014 17:54
neat!
Chip Collier
@photex
Jun 18 2014 17:55
ok, so you're saying to independently manage shaders and programs
Dzmitry Malyshau
@kvark
Jun 18 2014 17:55
@bjz I'm slightly against a VBO trait... For the needs of GL it's just a chunk of memory and nothing more
photex @photex was mostly just planning to write a couple of uber shaders and drive them via parameters and have that be the definition of a material
Brendan Zabarauskas
@brendanzab
Jun 18 2014 17:56
@kvark no worries
Chip Collier
@photex
Jun 18 2014 17:56
but again, this wasn't being considered for a general crate
just our game
Dzmitry Malyshau
@kvark
Jun 18 2014 17:56
@photex is material concept in scope of gfx-rs?
Chip Collier
@photex
Jun 18 2014 17:56
yeah
at least the consideration of it
Brendan Zabarauskas
@brendanzab
Jun 18 2014 17:56
I don't think materials would be out of scope
Chip Collier
@photex
Jun 18 2014 17:56
how else can you sort your draw calls
Dzmitry Malyshau
@kvark
Jun 18 2014 17:56
@photex material are difficult, and everyone would want them different
@photex by shader program
Chip Collier
@photex
Jun 18 2014 17:57
how can you plan the parameters and uniforms and all that?
Brendan Zabarauskas
@brendanzab
Jun 18 2014 17:57
yeah, it's a challenge
Chip Collier
@photex
Jun 18 2014 17:57
it's more complicated than that @kvark
same program but different sets of uniform
those should get sorted
and essentially seem to me at least to amount to a material
Dzmitry Malyshau
@kvark
Jun 18 2014 17:58
@photex I know, I've been there. There are solutions that do not force material concepts
a lower level solutions
Chip Collier
@photex
Jun 18 2014 17:59
back to 1) real quick
checking GLError during a frame is bad
but you should do it when loading resources
Brendan Zabarauskas
@brendanzab
Jun 18 2014 17:59
would be interested to hear you experiences @kvark - as gw says, these things take lots of iterations to get right
Dzmitry Malyshau
@kvark
Jun 18 2014 17:59
@photex also, about independent management of shader objects vs programs - that's not very beneficial for OpenGL, since the driver recompiles everything upon linking, but DX11, Mantle, GNM, and everything else has a separate concept of shader objects, and these should be reused where possible
1) ok, I can live with that
Chip Collier
@photex
Jun 18 2014 18:00
1) also, we can gate that with a build profile I think
Dzmitry Malyshau
@kvark
Jun 18 2014 18:01
@bjz what I came up with for my project is a "map<name,parameter>" that is provided separately from the shader program, generated by materials and renderphases (to have material info, lights, and so on). I do believe that gfx-rs needs something entirely different though, more data oriented
@bjz the shader program knows what parameter it needs, and it fetches the values from the map, updating itself if needed
@bjz might not be the fastest solution, but it's very low-level, hence allowing arbitrary material implementations
brendanzab @bjz is also curious where shadows will come intoi play - gw said that it will affect the structure of the engine
Chip Collier
@photex
Jun 18 2014 18:05
that's also going to require the concept of render layers which we don't have yet
Dzmitry Malyshau
@kvark
Jun 18 2014 18:05
layers?
Chip Collier
@photex
Jun 18 2014 18:05
yerp
Dzmitry Malyshau
@kvark
Jun 18 2014 18:05
what do you mean by that?
Chip Collier
@photex
Jun 18 2014 18:05
skybox, scene, post-processing
skybox, scene-opaque, scene-transparent, shadows, post-processing
etc
Brendan Zabarauskas
@brendanzab
Jun 18 2014 18:06
@photex from what gw was saying at the servo workweek, it seems that deferred shadow maps might be a good way for voyager
Chip Collier
@photex
Jun 18 2014 18:06
UI
Brendan Zabarauskas
@brendanzab
Jun 18 2014 18:06
ack, so many things to consider - difficult to break things down - sorry for derailing this
Chip Collier
@photex
Jun 18 2014 18:07
FX are sometimes a layer
Dzmitry Malyshau
@kvark
Jun 18 2014 18:07
this is pretty high-level, I'd like to focus on getting the device/platform rock solid first
Brendan Zabarauskas
@brendanzab
Jun 18 2014 18:08
sure, sounds good
Chip Collier
@photex
Jun 18 2014 18:08
it's high-level, but also it's specifically something that the device/platform needs to be able to accomodate
Brendan Zabarauskas
@brendanzab
Jun 18 2014 18:08
this is more related to the Renderer
Chip Collier
@photex
Jun 18 2014 18:08
it has to sort everything and render in a specific order
Dzmitry Malyshau
@kvark
Jun 18 2014 18:09
@photex it would be a task for the render thread, right?
Chip Collier
@photex
Jun 18 2014 18:09
yeah, I must be misunderstanding something!
Dzmitry Malyshau
@kvark
Jun 18 2014 18:09
I wonder if sorting criterias could be generically abstracted from the renderthread
Chip Collier
@photex
Jun 18 2014 18:09
are we not talking about this?
Dzmitry Malyshau
@kvark
Jun 18 2014 18:10
@photex I'm just trying to be on the same page, sorry if it obvious
Chip Collier
@photex
Jun 18 2014 18:10
no way, I think I've just misunderstood something about how this is laid out
Dzmitry Malyshau
@kvark
Jun 18 2014 18:11
dump your mental model please, and I'll diff with it
if anyone misunderstands, that should be me. I feel like missing a lot of context from your past discussions..
Chip Collier
@photex
Jun 18 2014 18:11
well, I think I understand now
the device is dealing entirely with receiving a command list from the renderer
doesn't care
just executes
Dzmitry Malyshau
@kvark
Jun 18 2014 18:12
yeah, it can be done independently from all high-level concepts, and that's what I'd like to focus on
Chip Collier
@photex
Jun 18 2014 18:12
the renderer is still implemented in gfx-rs and what a game would typically interact with
Brendan Zabarauskas
@brendanzab
Jun 18 2014 18:12
"Device don't care" #honeybadger
Chip Collier
@photex
Jun 18 2014 18:12
the renderer doesn't deal with any device details,
and that's where all this concept of sorting and layers and so on will ive
live
Dzmitry Malyshau
@kvark
Jun 18 2014 18:13
@photex I don't see where our models diverge, so far so good ;)
Chip Collier
@photex
Jun 18 2014 18:13
sorry @kvark I think I've been working on some merged concept
and I've just come to understand the design here more clearly
:)
hhuzaah
Brendan Zabarauskas
@brendanzab
Jun 18 2014 18:14
:cat2:
Chip Collier
@photex
Jun 18 2014 18:16
so mixing the platform and device together is a slippery slope
Dzmitry Malyshau
@kvark
Jun 18 2014 18:16
lol. @photex about your EngineData struct - since both arrays (data and generation) are sampler often together with the same index, wouldn't it be better to have one Vec<(T,u16)> instead?
Chip Collier
@photex
Jun 18 2014 18:16
@kvark it's based on the media molecule engine blog
pretty verbatim, I don't hold a strong opinion on the matter to be honest
all I know is that you swap remove and increment the generation
and I never got a point where I was working with this design
sorry, not media molecule
where is that link?
part 2 detailed the Handle
Dzmitry Malyshau
@kvark
Jun 18 2014 18:19
I'm in process of reading it. Still thinking Vec<(T,u16)> is better
Chip Collier
@photex
Jun 18 2014 18:20
sounds fine to me
after all these guys didn't have Rust
Brendan Zabarauskas
@brendanzab
Jun 18 2014 18:20
^_^
Chip Collier
@photex
Jun 18 2014 18:21
ok I realllly have to get back to work for a while
Brendan Zabarauskas
@brendanzab
Jun 18 2014 18:21
me too
Chip Collier
@photex
Jun 18 2014 18:21
I'm very much behind
Dzmitry Malyshau
@kvark
Jun 18 2014 18:21
@photex so the platform thread will hold and manage EntityData thingies for all types of resources, and Handle thingies will travel back and forth (from render thread on drawing, to render thread on resource creation)
Brendan Zabarauskas
@brendanzab
Jun 18 2014 18:21
thanks guys, this is exciting!
Dzmitry Malyshau
@kvark
Jun 18 2014 18:21
@bjz cheers
Chip Collier
@photex
Jun 18 2014 18:22
I'll be lurking and more available this evening
Brendan Zabarauskas
@brendanzab
Jun 18 2014 18:22
I will work on the glfw Platform abstraction - initialization and input. for now I will just have it as a separate crate in gfx-rs
we can move it into a separate repository later
Dzmitry Malyshau
@kvark
Jun 18 2014 18:23
I'll try to get something rendered this evening
Brendan Zabarauskas
@brendanzab
Jun 18 2014 18:23
\o/
Dzmitry Malyshau
@kvark
Jun 18 2014 18:23
@bjz where would opengl device implementation live? I think I can start porting some of the shader loading code
Brendan Zabarauskas
@brendanzab
Jun 18 2014 18:24
not sure - I recon we can just hard code for now
then abstract it later
Dzmitry Malyshau
@kvark
Jun 18 2014 18:24
ok I see
Brendan Zabarauskas
@brendanzab
Jun 18 2014 18:24
same with glfw
just hardcode - then I will move it into a Platform trait later
Dzmitry Malyshau
@kvark
Jun 18 2014 18:25
sure thing
Brendan Zabarauskas
@brendanzab
Jun 18 2014 18:25
or whatever name
that way we can at least have something rendering rather than waiting for me to figure out the high level user facing stuff
@kvark getting stuff actually 'doing stuff' seems like your forte :D
which is awesome
Chip Collier
@photex
Jun 18 2014 18:27
yeah! nice to be working with you @kvark
Dzmitry Malyshau
@kvark
Jun 18 2014 18:27
@photex nice to have such a great team here!
brendanzab @bjz decides to close gitter for now
Brendan Zabarauskas
@brendanzab
Jun 18 2014 18:27
:)
photex @photex too
Chip Collier
@photex
Jun 18 2014 18:27
bbl
and irc
o/
Dzmitry Malyshau
@kvark
Jun 18 2014 18:29
I'll stay here alone then...
Brendan Zabarauskas
@brendanzab
Jun 18 2014 20:44
@sebcrozet ohai
Dzmitry Malyshau
@kvark
Jun 18 2014 21:12
yay @sebcrozet
anticipating the future proposals, here is my mesh prototype: https://gist.github.com/kvark/acc34971492086273b5b
Dzmitry Malyshau
@kvark
Jun 18 2014 21:19
It's linear and generic
Brendan Zabarauskas
@brendanzab
Jun 18 2014 21:34
Looks quite nice
Why multiple attributes?
Also, you can do doc comments on fields - like /// blah
Dzmitry Malyshau
@kvark
Jun 18 2014 22:12
An attribute is what goes into the shader. Perhaps, you mean "why multiple vertex buffers?"
if so, for generality. I don't want to restrict users to 1 VB per mesh constraint
is sebcrozet with us in the team, or just a guest?
Dzmitry Malyshau
@kvark
Jun 18 2014 22:21
I updated the gist with a bit more comments and a Slice type
Brendan Zabarauskas
@brendanzab
Jun 18 2014 22:25
Just a guest I think - he is working on kiss3d - I'm guessing he was just curious
Brendan Zabarauskas
@brendanzab
Jun 18 2014 22:32
What is index_opt?
Dzmitry Malyshau
@kvark
Jun 18 2014 22:34
optional index buffer with its element count
some meshes are not indexed
one thing that I'm not sure about (@photex may help) is whether index_opt should be a part of the Mesh or the MeshSlice. The latter may seem wrong, but in fact has several benefits. 1) the meaning of the slice becomes explicit (as it is now - it's either a vertex slice or an index slice, depending on what mesh has). 2) allows reusing the same mesh without its indices (e.g. for doing skinning on GPU)
Brendan Zabarauskas
@brendanzab
Jun 18 2014 23:22
Ahh ok
I wonder if it would be more self-explanatory to have:
enum Mesh {
    Mesh(MeshData),
    IndexedMesh(MeshData, BufferHandle, ElementCount)
}
Disadvantage being you would always have to pattern match to work with the data :(
so actually that would be not very good
index_opt -> index_buffer might be better
brendanzab @bjz wishes we had better units of measure
Brendan Zabarauskas
@brendanzab
Jun 18 2014 23:27
then ElementCount could be a unit
Dzmitry Malyshau
@kvark
Jun 18 2014 23:31
I believe MeshData should be available straight on, without matching. Indexing is optional, and it doesn't change the semantics of attributes and vertex count (which are what you call MeshData, I assume)
what do you mean by ElementCount being a unit?
pub type VertexCount = u16;
pub type IndexCount = u16;
pub enum Slice {
    VertexSlice(VertexCount,VertexCount),
    IndexSlice(BufferHandle,IndexCount,IndexCount),
}
With that, we don't even need the total number of indices (and no index_opt in Mesh). Then MeshSlice could become:
pub struct SubMesh {
    pub mesh : MeshHandle,
    pub material: MaterialHandle,
    pub slice: Slice,
}
Dzmitry Malyshau
@kvark
Jun 18 2014 23:36
Oh, I got your proposal about units. I'm not really into it (don't want the language to be more complicated for something, the benefit of what is not obvious)
@photex one problem with glGetError is that it may have happened before your function, so if you use it, you need to verify the clean error state at the beginning as well as after creation.
@bjz I'm missing google wave... threads are so useful. Here we are discussing several things interleaved, at times, which is not that effective