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

71–80 of 93 posts

Re: MathBox 2

#71

Post by kp25 »

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…

Not really great specs.. works great on my lappy(4GB RAM, i5, Radeon HD 7670M)

Re: MathBox 2

#72

Post by [deleted] »

unconed wrote: post #69
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.

[deleted]

Re: MathBox 2

#73

Post by m_mueller »

unconed wrote: post #69
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.

Ah, so you do inlining of your script code? I see, that's the most straightforward way. I don't know WebGL well, but in CUDA it's a little bit easier nowadays, you can call kernels within kernels and you can link kernel code together.

Re: MathBox 2

#74

Post by clebio »

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…

Thanks for the comments, and for the immense amount of work you've put into building this. I wouldn't care much if it didn't support MB1, just wanted to understand that relationship.

As I thought about it more after posting, I imagined what you describe -- feeding in data sets (via an internal REST interface, say) and figured that would be simple enough.

I'm most interested in the multi-viewport idea, which I imagine is related to nested views. Presumably it lets you define linked representations of the same structures? Linked in the sense of brushing-and-linking [1]. I'm curious to try building some linked representations of real- and phase-space diagrams.

[1]: http://bl.ocks.org/mbostock/4063663

Re: MathBox 2

#75

Post by rpwverheij »

wow, just wow. amazing stuff Steven. I've been working on a framework for very easy data structure creation and instance management in a 3D environment. I was building it in 3D flash first, and have tried to build exactly those kind of curved arrows, though everything was calculated on the CPU. I've also been wanting to get to generating geometries from a static set of properties/datatypes for a while, and I was wondering to what degree I'm gonna have to get my 'hands dirty' and learn new things to do that. So wow, am I glad there's people like you building libraries like these!

I'm just about ready with rewriting the underlying semantic web framework to typescript and will soon be plugging it in to either Away3D TS or Three.js. Since I already know Away3D and it's written itself in Typescript I thought I might try that first, but seeing this ... and knowing how much more tested three.js is... I think I'm gonna go with Three.js

I really can't wait to play it with once you release it. I hope you can find some time for good documentation though. Cause at the moment I know just too little of the concepts involved to understand everything you explain in the slides.

Thank you already for this amazing presentation

Re: MathBox 2

#76

Post by rsp1984 »

zabcik wrote: post #4

I gave up trying to understand it and just clicked through for the eye candy. Cool stuff as usual from Steven Wittens.

If I understand it correctly a lot of the geometry effects build on the ability to do texture reads in the vertex shader (OpenGL calls it "vertex texture fetch"), a not much-noticed, but incredibly powerful feature of modern WebGL implementations. The reason it is so powerful is because one texture can be used as a write target for the fragment shader and as a read target for the vertex shader, essentially creating a feedback loop that lives entirely on the GPU.

Not all browsers support the feature though (check the MAX_VERTEX_TEXTURE_IMAGE_UNITS constant). Mobile devices could be problematic too since most (if not all) OpenGL ES 2.0-era devices don't support it in hardware.

Still this is one of the most impressive WebGL demos I've seen. Fantastic stuff.

Re: MathBox 2

#77

Post by exDM69 »

Finally, something useful with WebGL. So far we've seen lots of techdemos, but WebGL being so far behind the state of the art, it's like watching techdemos from 10-15 years ago but in the browser, with glitches.

But this is something I really want to see. WebGL and GPU acceleration being put to use in the Web proper. Not just a box of 3d graphics inside a web page. Plotting neat 3d graphs with nice shading, fast and smooth rotate and zoom, etc. While you could probably do this using Canvas or SVG, you probably couldn't match the performance.

Now I'd like to see this technology being used outside of tech demos. Some real world data plotted this way.

Re: MathBox 2

#78

Post by exDM69 »

rsp1984 wrote: post #76
zabcik wrote: post #4

I gave up trying to understand it and just clicked through for the eye candy. Cool stuff as usual from Steven Wittens.

If I understand it correctly a lot of the geometry effects build on the ability to do texture reads in the vertex shader (OpenGL calls it "vertex texture fetch"), a not much-noticed, but incredibly powerful feature of modern WebGL implementations. The reason it is so powerful is because one texture can be used as a write target for the fragment shader and as a read target for the vertex shader, essentially creating a…

The major weakness in using textures as intermediate targets is the loss of precision from the texture formats as well as the intermediate values. OpenGL ES 2 (and thus WebGL) does not require a full 32 bit floating point pipeline, so the results may vary if you run on mobile devices (that are not the latest generation GL ES 3.x devices).

In proper OpenGL, you'd be able to use transform feedback to write in to buffers with no loss of precision. And using buffers is less limited than texture fetches in the vertex pipeline.

For applications where precision matters (ie. everything scientific), WebGL on GLES2 devices is a no-go. WebGL standardization should pick up the pace to better match the development of OpenGL.

Re: MathBox 2

#80

Post by ygra »

unconed wrote: post #67
saidajigumi wrote: post #56

Earlier quoted context omitted.

> 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 eve…

Sort of unrelated, but when I saw TermKit I couldn't help the surface similarities with PowerShell. In fact, I believe what you had there could almost work as a PowerShell host, although things like http://poshconsole.codeplex.com/ share some of the same ideas.
Post reply on HN