redering engine.

[adam-zethraeus]

So I poked around the closure code for a nice place to start working on the renderer. I can't really find one.

I'm going to start a separate project which will initially just port the deferred renderer from MVBG to JavaScript. This shit should be modular anyway.

So main question: do y'all have any preferences for the interface we'll use. I'd like to try to make it as scene graph independent as possible, to whatever extent that's even possible. Either way, I'm planning to start it as just taking in a .json defined mesh.

Secondary question: was there anything about the MVBG deferred renderer that should not be used as inspiration?

[pbwilmot]

We should definitely go over the scenegraph design next meetign

On Fri, Dec 7, 2012 at 11:38 AM, Adam Zethraeus notifications@github.comwrote:

So I poked around the closure code for a nice place to start working on the renderer. I can't really find one.

I'm going to start a separate project which will initially just port the deferred renderer from MVBG to JavaScript. This shit should be modular anyway.

So main question: do y'all have any preferences for the interface we'll use. I'd like to try to make it as scene graph independent as possible, to whatever extent that's even possible. Either way, I'm planning to start it as just taking in a .json defined mesh.

Secondary question: was there anything about eh deferred renderer that should not be used as inspiration?

— Reply to this email directly or view it on GitHubhttps://github.com/vorporeal/acorn/issues/8.

Peter Wilmot

[vorporeal]

Main question answer: Nope. If you want, let me know when you're planning on thinking about/working on it, and we can brainstorm.

Secondary question answer: Not as far as I remember. I have an interesting idea about how to handle shaders that we should discuss though. (In essence, using Closure's template system to generate shaders on-the-fly.)

[adam-zethraeus]

on the fly from what and for what purpose?

[vorporeal]

It'll be easier to explain "in person", but from my research, it seems like the accepted way of using shaders with WebGL is to have them attached to the DOM in <script> tags. If we make these HTML snippets using soy (Closure's template system), we can nicely modularize the shaders (instead of writing them into the main HTML file).

Using that as a base, we can do more interesting things like pulling in shaders as dependencies to the compiled JS, and possibly using the template system as a way of constructing shaders from fragments at runtime.

I'm not sure if it would have any real benefit (besides modularization of code), but we can probably find something interesting to do with it.

[adam-zethraeus]

They're just text in the dom. There are lots of ways to get them there.

i don't understand this: 'possibly using the template system as a way of constructing shaders from fragments at runtime.' Can you explain what there fragments are / would be?

[vorporeal]

They could be functions or just sections of code. I guess the question I'm asking is, given this idea of shaders in templates, what would the templates be? What cool things could we do?

For example, imagine a template like this:

void main()
{
  vec3 outputColor = vec4(vec3(0.0), 1.0);
  // call color template
  gl_FragColor = outputColor;
}

We could define a color template (containing a bit of GLSL code) that produces a flat color.

outputColor = vec4(1.0, 0.0, 0.0, 1.0);

Or a blinn shader.

// Fuck it.

Or texture mapping.

// Too much effort.

Could be interesting.

[adam-zethraeus]

Cool. Definitely potentially interesting.