Dart #discussion

[Goutte]

Hello !

I tried Dart a bit, and it's growing on me.

I'm playing with the canvas right now, but I'll soon enough want to move to WebGL again. Right now, I only found a port of Three.js.

I prefer Jax's design, elegantly factored by a clever test-driven approach.

Do you know of freshly brewed or hard-to-find (disclaimer: I had a hard time finding Jax) Dart libraries closer to Jax ?

@sinisterchipmunk : do you think it would be a good idea to port Jax to Dart ? The mistakes you would not make if you had to rewrite everything ?

---

There's no (at this time) Leap Motion Controller support for Dart. They're gathering information on the language though, and fatefully they'll like what they'll see.

[sinisterchipmunk]

Admittedly I don't know a lot about Dart. It's been on my "things to check out" list for a while but I still need to do a deep dive into what it is and what it isn't.

Based on the FAQ, it sounds like although Dart is intended to eventually run natively, as of today the only option for running Dart code in a browser is by first compiling it into JavaScript. Therefore, at least for now, it seems to me that a shim or API to make the Jax core files (which are ultimately almost exclusively JavaScript) easier to use from a Dart application might be more viable and easier to maintain than porting the whole of Jax into Dart.

To be clear, I'm not saying "no" because I don't understand enough about this suggestion to confidently give an answer yet, one way or the other. At this point I'm just throwing out other (possible?) options.

[Goutte]

Dart just got its ECMA spec, which is a good step towards native run everywhere.

Right now, calling dart from javascript is not an option (and it looks like it might not be for a good while), and calling javascript from dart is somewhat painful.

I delayed the webgl part I need as much as I could, but there's only so long I can procrastinate, and I'm keeping a watchful eye on the related dart libraries ; writing a scene manager / renderer is a daunting task, even in the footsteps of Jax.

Besides, coffeescript is pretty addictive, and coffeedart does not exist yet.

---

My options are :

1. Suck it up, fork three.dart and build on it. There's a lot of work to do, so it is not that easy a solution. And I'll have a codebase I'm not satisfied with.
2. Try to make a bridge between jax and my codebase in dart, but as it'll be one-way, it's pretty hard and might not be that easy to maintain.
3. Buckle up and start from scratch ; I need basic features (pretty much the same as Cyx), so maybe I could pinpoint what I want and rush it. I don't know how to sanely test the canvas/visual output of webgl. Per-pixel checks ? Comparison with an image ? The usual human validation, with demos ? ("You should see a spinning red cube", etc.)
4. Make coffeedart, and then port jax. Not a chance, but that would be the high road. :]

---

I'm weighing these options against one another, and right now the third has a small edge.

Would you mind if I shamelessly started ripping off designs from jax to pour them into a sibling library in Dart (say, dax ?). Of course, there'd be backlinks to jax and licence compatibility, I'm just asking 'cause maybe that is something you'd rather do yourself ;)

[sinisterchipmunk]

Sure, go for it. Backlinks would be appreciated but are not absolutely necessary. You're right that option 3 is probably your best bet in the short term.

For testing, I've tried a few things and this is a hard area to cover. Maybe I can save you some time by documenting my findings...

Comparison with an image is pretty brittle, and small things like browser updates (or just testing with a different browser) can break it in unpredictable ways -- not good if the whole point is to support many different browsers!

Per-pixel checks are a generally decent way to go, and the WebGL conformance tests frequently do this, picking particular areas of the image where the result is known to be in some range and ignoring the rest of the canvas. (Example: view-source:https://www.khronos.org/registry/webgl/sdk/tests/conformance/rendering/triangle.html ) The weakness here is that if you're testing, say, a set of shaders you've written, then the difficulty of writing a single test will directly correlate to the complexity of the shader. As the shader itself grows in complexity, you'll find the unit test becoming more and more brittle. If you're testing things more fundamental than your own shaders, I would argue at that point you're rewriting the conformance tests, and shouldn't be wasting your time.

One idea that sounded great on paper was that of a GLSL simulator. That is, a standards compliant JavaScript library that parses GLSL code and returns numeric results that can be sanely tested against. (Aside: the linked library was originally, primarily meant to introduce a Coffee-like syntax for GLSL authoring and implemented the simulator as a way of unit testing itself; I've since lost interest in the Coffee-ish idea, tantalizing as it was. When WebGL 2.0 comes out, that whole concept will implode.) I actually did start on this project, and though I never finished it, I made enough progress that I actually adopted it for unit testing shaders in Jax. It runs quite fast enough for unit testing, but obviously I would never employ it as an actual renderer. And then it falls down quite severely when you try to throw texturing of any kind at it. You basically need to mock up the texture lookups, a process I never quite found a way to easily do. In the interest of actually shipping some real code, I stopped trying to make the simulator work with textures.

The single best answer I've come to so far, is not much of an answer at all. In Jax, I abstracted out the idea of a "Renderer", which basically in the current implementation is just a wrapper around all of the GL method calls. Ultimately I'd like to see the Renderer do some higher-level processing, but I haven't found time to define exactly what that'd look like. Until then, it allowed me to swap out the "real" Renderer with a "headless" Renderer that was actually just a black hole. Then in my tests I set up expectations that the Renderer would receive certain method calls at expected times, and trusted that if my tests are authored properly -- that is, the tests are ensuring that I'm consuming the WebGL API as its spec indicates I should -- then I basically trust the underlying WebGL driver itself to do its job. A major fringe benefit of this is that since I no longer rely on a real WebGL context, I can throw node.js at it and do true offline testing. This has increased productivity tenfold as I no longer have to wait on the browser to do a full-stack test. Prior to releasing anything, I can swap the headless Renderer back out for the "real" Renderer and ensure I'm not fooling myself into consuming WebGL APIs that don't exist.

This usually works, but doesn't always. Sometimes I think I'm doing things right, and the tests validate what I think I should be doing, but I'm just wrong. I misread the spec, or passed it the wrong data, and although the unit tests pass I end up with a blank screen. Because in the end, if you are wrong, then no amount of testing you do will make it right, because the tests themselves are written against a flawed understanding and thus are only serving to enforce your own mistakes. Maddening.

This is the reason for the interactive tests. I've actually made a decision to start putting more actual effort into the tests. I don't want to click through and say "yep, it's a triangle" any more. I'd like the human-driven portion of the tests themselves to appear on a Jax homepage one day, and showcase the engine. Because ultimately, the part of the test that requires a human, is basically a demo. As long as I'm stuck writing this sort of demo, I might as well make it a good demo worth showing off, and kill a couple extra birds with the same stone.

Anyway, that last paragraph is what I've been working toward. It's obviously not where Jax is at, but where it's heading. Ultimately, I'll set up a landing page where you can not only see demos (tests) built with Jax, but execute Jax itself -- not unlike the CoffeeScript homepage that allows you to not only see what CS generates, but execute CS code itself.

[Goutte]

After reading, I'm leaning towards :

1. Make a (badass) demo.
2. When it works, snapshot a render in fixed-size canvas.
3. Save the snapshot. (it's either dart:io OR dart:html, so this may not be trivial, unless HTML5 provides)
4. Link the snapshot to the demo.
5. Refactor everything ; Break stuff.
6. Test-run demo suite by comparing earlier snapshots to current renders. Maybe do a somewhat tolerant comparison, so we don't have to regenerate the snapshots all the time.

It's not test-driven, more like test-fasten, but I think it'd prove useful nonetheless.

---

I'll start with :

• Application
• Controller (using the game_loop package, probably)
• World
• SceneGraph
• SceneNode (abstract)
  • Group
  • Light
  • Model
    • Mesh
    • Material
  • Camera
• Renderer
• WebGLRenderer
• Buffer (and other WebGL goodies)
• Renderable (interface)
• and misc utils and custom exceptions, on the fly

I've advanced to the point where I can render an empty world with a dark cosmic background.

main() {

  test('is a SceneGraph', () {
    World world = new World();
    expect(world is SceneGraph, isTrue);
  });

  test('has an almost pitch-black cosmic background', () {
    World world = new World();
    expect(world.background is Color, isTrue);
    expect(world.background, isRgb(1,1,1));
  });

}

The browser demo looks a bit bleak. :)

Next step: triangles 🚩 !

[Goutte]

Also, why does Jax binds Jax.Buffer to multiple contexts ?

[Goutte]

Context juggling is for when you want multiple canvases to render the same World (from a different perspective, for example?)

[Goutte]

I rushed into some code (and got a basic demo running), and then my computer crashed, so I pushed my code to github, out of fear. It's not satisfying my needs yet, and present features are incomplete and expected to bug in quite a number of ways, but at least I can sleep.

This is light-years away from Jax ; I really am out of my comfort zone, but it's more fun than expected !

[Goutte]

In the world of test-fasten : Say I know this code in that git branch ouputs something as expected (in our case, a series of images). I can't properly/easily/thoroughly express what it is using the usual assertions (our problem, somewhat), but I can look at it and validate it.
Run new dev branch against old validated branch, compare outputs, yell.
Caveat : lots of work to make dartium a slave (jasmine-like). And Dart's unittest still needs work just to embed a canvas in the testing suite. Just a thought.

Repo-wise benchmarks comparing git branches also sometimes make sense in leaf apps (not libraries).