Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MathBox 2

acko.net

Post reply on HN
Print view View original

61–70 of 93 posts

Re: MathBox 2

#61

Post by unconed »

clebio wrote: post #54
unconed wrote: post #37

Earlier quoted context omitted.

MathBox 2 is built on top of threestrap (don't google it, you get shoes), to enable exactly this kind of extensibility without me having to do it all myself. Just by following a few basic conventions (e.g. binding the VR headset to three.camera), it should just work. Haven't tried it yet, too much to do, but I do know these guys who have a mocap studio being repurposed for free-walking VR experiments using a wireless…

I've used Mathbox some, and am still trying to get more familiar with it. Is MathBox 2 architecturally separate, or will the original Mathbox become a subset of MB2? I'll just keep plugging away at MB (the 1st). The comparison to D3js seems apt. MathBox is -- somewhat -- a 3D version of what D3 does. But D3 takes a bring-your-own-data approach, whereas mathbox is more directly about defining the mathematical structur…

MB2 is completely separate from v1. I replaced the tQuery dependency with Threestrap, which is much less opinionated and the opposite of monolithic. The shaders are now compiled in so it runs over file://. The API works mostly the same, only now you can nest views.

I could provide a best-effort v1 compatibility API if there is a demand for it, so you'd only need to replace your initialization code and e.g. call mathbox.v1() to get the old API. I don't know many people using MB1 though.

With regards to D3, I actually see it as quite complementary to MathBox 2. Take away all the DOM/SVG wrangling and you are left with tons of useful components, like all the geospatial stuff, for which MathBox can be the output layer. You don't actually have to use live expressions or GLSL transforms, you can just pass in a float array or a regular array of numbers, even a nested one.

Re: MathBox 2

#62

Post by unconed »

vosper wrote: post #59
unconed wrote: post #53

Earlier quoted context omitted.

You're kind of missing the point. Doing a single classic demoscene effect is indeed trivial. Doing arbitrary multi-stage, multi-frame video feedback effects is not, and you'd need to write dozens of lines of unique GL API code for each stage. Avoiding that work is what this is about. The fact that computer graphics from 1996 are still taught as if it was 1996 should be greater cause for concern. Or that math from the…

Fair point, and I should have made my comment clearly about WebGL, rather than the work of the author in creating this post - that is very impressive. What I really wanted to say is that I still find it disappointing that after so long WebGL seems to made so little progress when compared to any game running on the same underlying hardware. I'm happy that the graphics can be constructed more elegantly, but I wish they…

Some of this is because I'm wrapping it inside a ghetto CSS 3D presentation framework I've been reusing for almost 2 years, built when this stuff was buggy as hell. Mea culpa.

But compared to any game running on the same underlying hardware... Remember all the aimbots, wallhacks and more that people have been hacking in for years? How many crashes you've experienced? "Please install the latest driver". "You must restart the game to apply this setting". How about the fact that every game pretty much freezes the UI while it's first loading? You don't want web sites to work like that. WebGL has fundamentally different priorities, but they're not all bad.

GPU drivers have favored performance over stability for years. Modern games are a giant pile of hacks, but devs can afford the massive QA operation required to hide this fact. Heck, Nvidia turned game engine hacking into a feature, allowing you to add modern effects into old engines through their drivers.

See for example if you can figure out which vendor is which in this Valve developer's tell-all:

http://richg42.blogspot.co.uk/2014/05/the-truth-on-opengl-dr...

Re: MathBox 2

#63

Post by cdata »

elsigh wrote: post #55
reedlaw wrote: post #36

> Please view in Chrome or Firefox. Chrome is glitchy, Firefox is stuttery. I really want to get behind WebGL, but when is it going to have decent performance/compatibility? I tried this out in both FF and Chrome on a powerful desktop computer (i5-4670K, GTX760, 16GB RAM) and it was glitchy/stuttery as described. Firefox rendered some scenes at what seemed like 2-3 FPS. Chrome was much smoother, but I couldn't tell w…

I viewed this whole presentation on a MacBook Air plugged into a 32" monitor, and while 1 or 2 of the slides would pause here and there, overall it was amazingly smooth. Mind blown.

We've come a long way from cheesing a little extra performance out of the DOM by applying CSS 3D transforms, that's for sure ;)

Re: MathBox 2

#64

Post by m_mueller »

I'd really really like some in depth post on how these callback capabilities have been implemented. This is quite a big accomplishment for GPU code.

Re: MathBox 2

#65

Post by tremendo »

reedlaw wrote: post #36

> Please view in Chrome or Firefox. Chrome is glitchy, Firefox is stuttery. I really want to get behind WebGL, but when is it going to have decent performance/compatibility? I tried this out in both FF and Chrome on a powerful desktop computer (i5-4670K, GTX760, 16GB RAM) and it was glitchy/stuttery as described. Firefox rendered some scenes at what seemed like 2-3 FPS. Chrome was much smoother, but I couldn't tell w…

I was expecting another disappointment but no, on this somewhat dated system it runs great, and I was really impressed with several of the demos, even manipulating/rotating them in real time with the mouse, all running quite smoothly: Chromium Version 36.0.1985.125 Ubuntu 14.04 (283153), i5 2.8 Ghz, 6 Gb RAM

Re: MathBox 2

#67

Post by unconed »

saidajigumi wrote: post #56
unconed wrote: post #49

Earlier quoted context omitted.

Right now, very dead. It was more of an idea than a real thing, badly architected, but with some good ideas waiting to be reimplemented on a non 0.x stack. Still perpetually disappointed every new "neo terminal" is monospace tho.

> Still perpetually disappointed every new "neo terminal" is monospace tho. Have you thought of ways around the path dependence[1] on monospace imposed by existing bodies of textmode UIs (and source code)? It seems unlikely that a new terminal-esque tool would succeed without some kind of legacy support. The best concept I've come up so far with is to build in affordances which handle legacy vs. new-world user intera…

Formatting legacy stuff was always part of the deal, but at the same time, I was never interested in being able to host vim. Some people disagreed rather vocally.

One of the things I discovered was just how much legacy cruft is really around. Not just things like ANSI colors, but e.g. grotty syntax. It made no sense until I realized it was created for teletype printers... it underlines things by backspacing after every character and printing a "_". It bolds by backspacing and repeating the character. I had to parse this to support man pages, and I assume the default TTY still does too.

The other thing was that so much of Unix workflow really only works by accident. The fact that you can ssh + sudo + ssh + ... is because the pipes are too dumb to fuck it up. Take for example SSH escape sequences... [1] they only work on the first hop. The proper solution is out-of-band signaling.

From an architecture point of view, the whole termcaps / stdio thing is crazy. The Unix principle is supposed to be about simple agnostic composition, and yet most tools have to sniff out their environment in order to maintain this illusion. Text files are for people, not machines. And if you want to see a never ending discussion, just ask a bunch of greybeards how to write a shell script that can handle files with spaces in their name.

[1] http://lonesysadmin.net/2011/11/08/ssh-escape-sequences-aka-...

Re: MathBox 2

#68

Post by kelmop »

unconed wrote: post #61
clebio wrote: post #54

Earlier quoted context omitted.

I've used Mathbox some, and am still trying to get more familiar with it. Is MathBox 2 architecturally separate, or will the original Mathbox become a subset of MB2? I'll just keep plugging away at MB (the 1st). The comparison to D3js seems apt. MathBox is -- somewhat -- a 3D version of what D3 does. But D3 takes a bring-your-own-data approach, whereas mathbox is more directly about defining the mathematical structur…

MB2 is completely separate from v1. I replaced the tQuery dependency with Threestrap, which is much less opinionated and the opposite of monolithic. The shaders are now compiled in so it runs over file://. The API works mostly the same, only now you can nest views. I could provide a best-effort v1 compatibility API if there is a demand for it, so you'd only need to replace your initialization code and e.g. call mathb…

Is this open source? Can we see that somewhere? Any way good job, thank you.

Re: MathBox 2

#69

Post by unconed »

m_mueller wrote: post #64

I'd really really like some in depth post on how these callback capabilities have been implemented. This is quite a big accomplishment for GPU code.

Just pretend it's C and imagine how you might merge by hand a couple of .c + .h files into a single .c file that compiles. That's basically how it works.

Re: MathBox 2

#70

Post by meemoo »

anigbrowl wrote: post #58

It's driven by code though, it's not a graphical UI. I hoe someone builds the latter on top of it, since the flow-based paradigm is so effective in these contexts. Excellent presentation.

I'd be interested in making a Flowhub [1] runtime for ShaderGraph 2 graphs. (Flowhub runtimes talk a protocol [2] to define what nodes are available, code new nodes, and build up graphs.)

1. http://flowhub.io/ 2. http://noflojs.org/documentation/protocol/

Post reply on HN