Hacker News new | comments | show | ask | jobs | submit login
Show HN: SVG 3D Builder – Build 3D Models with SVG (github.com)
157 points by captainwz 84 days ago | hide | past | web | favorite | 66 comments



If you think this is cool you might think AFrame is cool:

https://aframe.io/docs/0.8.0/introduction/


Aframe is awesome.


It's unbelievably slow. I'm confident it's not the developer's fault. It serves as a good warning. It just goes to show that Web technology still has a long way to go.

SVG (and to a lesser extent Canvas) are trainwrecks in terms of performance. It's really a sad story that HTML5 has been evangelized so strongly, yet even ten years later it can't hold a candle to Flash in many regards.


It's slow because it's abusing what SVG can deliver. It's only a good warning in regards to avoid using the wrong tool for the job. If you want want 3D in the browser, then go WebGL.

> It's really a sad story that HTML5 has been evangelized so strongly, yet even ten years later it can't hold a candle to Flash in many regards.

Not sad at all. It needs to be evangelized more since it's clear that other solutions did not work. By other solutions I mean a private company design something and forces it on the world. (Flash, Java applets, Real Player, Shockwave...)

We have all the features flash had now (and had it for many years now)


I agree with some of this but I get the sense you may not have been around for flash and may be just echo chambering popular commentary without context or first hand experience:

1) The HTML spec at the time flash rose could do nothing of what it could today. Flash, applets delivered - relatively speaking. They didn't 100% hit the one code base that works the same everywhere promise, but came close. Maybe webassembly will lick that problem.

2) HTML interpretation has be ever been consistent between browsers. Respectfully, ie6 was smooth sailing. I'd advise studying life around ie3-4.

3) When Flash fell out of favor thanks to Steve Jobs, Flash Lite ran already, just fine on a lot of phones. It was used on a lot of devices quietly and may very well have been the android of its day. It was just a personal move. Steve Jobs also locked down the iPhone around that time (no app store) at the time.

The "future", html5 was not ready at that time. The web was held back and suffered for a number of years while there wasn't a viable alternative to flash and HTML5/JS still needed to mature and be ready to go.

The dangerous thing about saying html has successfully replaced the past is, we're doomed to repeat the past if we don't understand it due to hubris.

4) Every tech has contributed something valuable. Flash caused me more grief than I ever care to get into.

Flash type browser plugins helped deliver experiences that nothing else could for a very long time, and frankly when the html spec didn't have the foresight, or the capabilities in browsers.

5) Flash saw the value of basing their entire scripting language on actionscript, which is ECMAscript, which is Javascript... more than a decade before anyone thought of using Javascript for building apps.

6) Today's practice of building apps in Javascript in part is inspired outright from what Flash could let a developer do.


I don't disagree with any of your points, these do provide the necessary insight of the two platforms. I was around when flash became a big thing, though never really developed in it deeply.

IE3-4 was probably nightmare to work with :)

> The dangerous thing about saying html has successfully replaced the past is, we're doomed to repeat the past if we don't understand it due to hubris.

I feel we will repeat some of the mistakes thanks to webassembly, but I'm not saying it shouldn't be the direction we are heading to. Luckily thanks to the open nature of developing these specs the process is more balanced between parties than ever.


Webassembly is the first tech I can think of that all browsers have unanimously agreed on and co-created.

The same can't be said for the design, interpretation or implementation of the html spec.

Open standards can also fall to paralysis of design by committee. Still, open is good (AV1 is also cause for optimism).

When open standards aren't possible or happening, innovation is undertaken by private companies.


>Webassembly is the first tech I can think of that all browsers have unanimously agreed on and co-created.

I like wasm, but this unabashed overstatement completely ignores smaller browsers. Best of luck getting elinks to commit to wasm support.


I think you took it literally (which is surprising for a place like HN). Still, I meant major browsers, all was a typo.

The major browsers in marketshare.. being Safari, Chrome, Firefox and Microsoft are all on board with wasm.

Is there another thing you can find they agreed on to this degree relative to market share?

The wording of your comment makes me wonder if you know a bit more about wasm, particularly with smaller browsers (I am a fan of Opera too), so please feel free to share the smaller browser perspective.


Java was open source and Sun wanted Netscape to embed Java in their browser. According to Brendan Eich, Netscape considered having both JS and Java along with a canvas element both could draw on, but time constraints dictated otherwise. So Java ended up being used as a plugin.



Was java ever truly free though? Oracle's shenanigans indicate otherwise.


> Was java ever truly free though? Oracle's shenanigans indicate otherwise.

It probably could have been, pre-Oracle.


No, Sun was not looking to open it up and even got in a spat with Microsoft over Java. MS responded by pulling Java out of Windows, which broke Outlook Web Access and required fast work to implement the first XMLHttpRequest Active X implementation of that now-standard XHR (=> Fetch) API as replacement for the Java async-io class that OWA used while Java was in Windows.


I meant that Oracle is less amenable to fixing the social issues they create surrounding their products, which hamper their usefulness.


Wow, this really would have been a different past - similarly if flash had been able to draw into elements in the dom properly.


Alas we could not lure Andrew C. Myers away from his PhD at MIT under Liskov, which would have dashed his academic future hopes (he is a professor at Cornell).

Netscape also had Jonathan Gay and his brother stop by to try to sell FutureSplash (what became Flash) to us post IPO, but so many companies were crowding the door, and the marketing guy vetting them was harsh, so they went to Macromedia. That was for the best: Netscape would not have built the great tools that Macromedia did.

So two "what if" near-misses re: early canvas-for-HTML. Sad but true!


> We have all the features flash had now (and had it for many years now)

Unfortunately not. We still can't measure text without putting it into the DOM and waiting for update, nor can we have weak references. And SVG is miles behind the performance that Flash's scenegraph had 10 years ago.

xigma 84 days ago [flagged]

> We have all the features flash had now (and had it for many years now)

You have absolutely no idea what you are talking about, yet you're evangelizing HTML5, that's the problem.

Talk to somebody who tried to bring Video or 2D(!) animated content over from Flash to the Web. It was (and remains) a total clusterfuck. Not just because of performance but because of compatibility. Flash just worked. Web video or (god forbid) WebRTC are still problematic.

That's not to say that I want Flash back, but ignoring that it was proprietary, it was the better technology.


Of course I have no idea, I'm only following the development of web technologies since IE6.

Web video was "fixed" in the dying years of Flash. I remember cursing on HMTL5 video, but it was suddenly got performing really well and switched YouTube to it and never looked back. Just pick a graphics library and you'll be fine if you want to move vector stuff around. If you miss the flash IDE, then it still exists and can export to HTML5 standards.

Being proprietary was just part of the problem. I'm glad it showed us the way but it needed to be gone.

xigma 84 days ago [flagged]

> Of course I have no idea, I'm only following the development of web technologies since IE6.

You followed other people doing the development at great expense. You're in no position to evangelize anything.

> Just pick a graphics library and you'll be fine if you want to move vector stuff around. If you miss the flash IDE, then it still exists and can export to HTML5 standards.

Hahahaha, yeah please use it. Please, I beg you. Use it and then come back and tell me it's just as good.

> I'm glad it showed us the way but it needed to be gone.

If it showed the way, people didn't quite see it, they went ahead with nonsense like SVG, which didn't work, so other people created Canvas, which still was massively slower than Flash. Just literally copying Flash would've been better.


I should have said developed as well (I thought that implies it), but your head is too deeply buried in the sand to maintain a conversation.

I did use many graphics libraries before, thanks, they are fine.


Please don't reply to a comment that broke the HN guidelines by breaking them yourself. That only makes this place worse.

https://news.ycombinator.com/newsguidelines.html


I have no idea what exactly you did, but I can't fathom how you would form such opinions from hands-on experience with both technologies.

You say things like "just export to HTML5 from Adobe Animate/Flash", but if you had actually used that, you would probably tell people to stay away from it, or at least acknowledge the caveats.


I'm not a big fan of Flash, either, but you should probably chill out with the abrasive and sneering tone. (which is why I imagine you're being downvoted) If you'd like to conduct discussions like this, maybe Reddit is a better choice.


Euh... Yeah? Shoehorning SVG into 3D models ought to be slow. Manipulating DOM nodes for animation has it's limits. If you want 3D perf in the browser, use WebGL.

The canvas can be quite fast if used right, but again, it's not the right tool for every job.


The problem is, the right tool does not exist on the Web.

WebGL doesn't have very good support, especially on mobile. That's why one would choose to use SVG.

Also, just to get it to do something requires a lot more expertise and code.

Would this project have worked out better on Canvas? Yes, most certainly, but some people have to find out the hard way.


> WebGL doesn't have very good support, especially on mobile. That's why one would choose to use SVG.

This statement isn't even vaguely true. SVG support is quite incomplete and inconsistent across all browsers (both desktop and mobile), while Webgl has been comparatively well supported on mobile for many years (Android 4.4 lacked support; Android 9 is now out).

The only issues you might have with most common webgl applications on mobile is performance & battery drain but that's equally true of SVG.

xigma 84 days ago [flagged]

Another opinion from someone who presumably looks at "browser support" tables and green checkmarks and forms an opinion that way.

How much actual WebGL vs. SVG development have you done? How many devices have you tested?


You've repeatedly violated the site guidelines in this thread. That will get you banned on HN—especially the way you've been abusing others. Could you please review https://news.ycombinator.com/newsguidelines.html and follow the rules from now on? The idea here is: if you have a substantive point to make, make it thoughtfully; if you don't, please don't comment until you do.

You obviously have experience in this area that is great to share in a way people can learn from. But first it's necessary to be civil, as all users need to be here.


This applies to a few of your comments, but: you're not telling us anything interesting, you're just antagonistic. GP's experience is not really relevant here. If you think you have more experience, tell us about your opinions and how your justify them. Knee-jerk disagreeing and suspecting everyone to have less experience than you will just get you downvoted everywhere.


> you're not telling us anything interesting

First of all, that's a pretty condescending thing to say and you're obviously not speaking for everyone. I wouldn't mention that if you weren't tone-policing me.

I'm telling you that if you make technical decisions based on "feature support" charts, you're going to fall flat on your face with WebGL. That's pretty useful information unless you never have to do any actual work with that technology, but then your opinion is also irrelevant.

> Knee-jerk disagreeing and suspecting everyone to have less experience than you will just get you downvoted everywhere.

Nobody who has experience with WebGL and SVG will say WebGL is better supported across the board. You'll have to take that at face value, there's no scientific study for it and I'm not going to just give out more information than I'm comfortable with.

I'm getting downvoted across the board here, presumably for using "bad" words like "terrible" to describe everyone's favorite Web technology they never really used. Or if they have used it, they don't know how poorly it compares to something "evil" like Flash. People want "the good guys" to win, which means "free and open source" and "standard". It makes them upset when somebody criticizes that harshly, but it's the reality.

I got some upvotes initially, by the way. Not that I care either way, I'm not paid in upvotes.


Padorn? Yeah, poor Opera mini users will suffer.

https://caniuse.com/#search=webgl


@xigma technically true but not a widespread problem these days statistically. The blacklists cover a small usage percentage.


The fact that a browser supports WebGL tells you nothing about which devices support it.

It all depends on the GPU and its drivers, browsers have blacklists of GPUs, but even if your device is not blacklisted, it may simply screw up, especially on mobile.


If you rely on WebGL on mobile then I would feel insecure too, but progressive enhancement is a thing.

I got recently asked to do a project in WegGL and the target audience has the latest gadgets so it will fly on mobile as well. A transaction will cost around $50k so it's a safe assumption, but I'll do more research.


Hoping WebAssembly will eventually be in a position to help.


Why does WebGL not have very good support on mobile?


Because mobile GPUs have terrible drivers that rarely get updated and browser vendors can't be bothered to deal with that combinatorial explosion.

Having said that, iOS isn't that bad.


I dunno, WebGL and other open browser standards have come a long way and do things now that I don't think were ever possible in Flash.

When done right (for example: http://awards.paris/new-micra-experience/ ) 3D in the browser can be impressive.


Flash had a 3D API (Stage3D) seven years ago, which was quite similar to WebGL. It wasn't used much, because Flash was already on its way out.


I remember seeing 3D in Flash, but it never had the equivalent performance of WebGL..

Although maybe that's just a result of computing power and GPU progress..

Also WebGL has been around at least that long, if not longer..


How is canvas a "trainwreck" in performance? I've used it extensively and have found it a very well performing framework.

https://cryptowat.ch/markets/kraken/btc/eur

https://ballpoint.io/files/examples/starbucks


The difference in performance with Flash is huge, modifying the context is quite expensive, resetting it is expensive, which is problematic because it is stateful.

You have to compare it to non-Web technology to get an idea of how bad it really is. Compared to SVG/HTML, it's of course massively faster.


> It's really a sad story that HTML5 has been evangelized so strongly

SVG is not a part of HTML 5, it is older, while Canvas actually is, and Canvas is as fast as the now defunct Flash. Maybe applying the right technology to a problem would solve the speed issue...


> SVG is not a part of HTML 5, it is older

Maybe not formally, but making that distinction makes no difference to my point.

> Canvas is as fast as the now defunct Flash

...not even close.


> SVG is not a part of HTML 5

https://html.spec.whatwg.org/multipage/embedded-content-othe... begs to differ.


which is why both WebGL and Web Assembly exist

This could be an interesting "worst case" polyfill.


Those don't fill the same void at all, you need tons of code to do something useful with those, all of which needs to be downloaded, compiled and executed.

Show me the library using WASM/WebGL that loads as quickly as SVG or Canvas content.


http://www.adultswim.com/etcetera/elastic-man/

619KB in total, 362KB wasm binary

Edit: Three.js is such a library with qualities you described:

https://threejs.org/examples/#webgl_postprocessing_dof


That's not a library, that's a demo and it takes several seconds to load, just like a flash applet would.

I'm aware of minimalist things that can put stuff on-screen instantly, but not of something that's a fleshed out solution like SVG or Canvas that still loads instantly (like SVG or Canvas).

Edit: I'm sorry, my brain was still in 2d/Canvas/SVG/Flash land, you were talking about 3D stuff all along. You're right threejs stuff can load quickly, shaders can become a bottleneck though. I was thinking of a library that basically does "Flash Lite" with good performance and yet remains competitive with Canvas/SVG content in terms of load time. I'm not aware of such a solution, but I'd be glad to learn whether it now exists.


The haxe ecosystem is pretty great.

http://haxeflixel.com/demos/


SVG is HTML for arbitrary 2d shapes (yes, technically XML). Writing a 3d engine with it is akin to rendering PNG images by arranging colored divs. It is a hack with much better existing alternatives.


It's not a "3D engine", it's basic line and shape drawing.

With SVG, you will easily run into the same performance issues with any kind of dynamic content, 3D or not.

With Canvas, you may or may not run into them, depending on how much content you have.

In either case, performance is terrible compared to what you can do in a native application.


I'm reminded of vrml. That was in the 90s. Back then I expected more by now.


We did get more. And less. Many of the innovations of VRML-97 have been forgotten, ready to be rediscovered. But progress on other fronts has been amazing.

Mostly the notion of treating your entire app as a simulation, just like games do. VRML-97's event loop, warts and all, made things a lot easier.

VRML-97 also had a true prototype/instance class system, way more like David Unger's Self language than what we have today. (Ironically, JavaScript is moving away from prototypes and more towards classes each iteration. Too bad.)

Scene graphs, of course. Really just a DSL for describing object graphs. Very succinct & powerful.

A few things deflected VRML-97.

Sun placed their bets on Java3D and ignored OpenGL. In addition to scene graphs, Java3D had the notion of live (active) objects, sending messages to each other. It was the 90s, people still bought into OO. It was an idea worth exploring that didn't pan out. No shame in trying.

The bigger mistake was the VRML steering committee went all in for XML and switched to Web3D. Completely stopped all the hard earned momentum. Classic example of Joel Spolsky's "Don't Rewrite" rule. This idea was not worth exploring.

Source: Implemented VRML-97 browser, wrote some games and authoring tools, coauthored the original JavaGL bindings with "Alligator Descartes", lobbied Sun & SGI for years to drop Java3D and promote JavaGL (which they eventually did, but too late).


three.js has an SVG renderer that does a decent job - https://threejs.org/examples/#svg_sandbox


Dude, this is the kind of stuff I could run in realtime on an Amiga. Maybe not at the same resolution, but the resolution isn't the bottleneck in this demo either, I'm struggling to hit 40Hz at any scale.


On the Amiga, you didn't go the stupid way around and represent your object as a series of text path strings which need to be parsed into objects and then finally displayed for each frame.

You can get your Amiga performance with canvas; and you can get way better with WebGL. This is just a case of wrong-tool-for-wrong-job.


Do you realize that in Canvas colors are represented as a "series of text strings" that need to be parsed?

Did you know that drawing paths requires a ton of pretty expensive Javascript calls or alternatively passing "a series of text strings"? Maybe the string way is actually faster, I haven't tested it because it isn't supported everywhere.

Were you aware that vector rendering is not usually done on GPUs, mainly because of the high overhead of state changes when using a graphics API, especially one like WebGL?

I guess you could do all your rendering in software in Javascript (which for these purposes is nowhere close to what you can get with C/C++) to a byte buffer and then do the final transfer to Canvas. Even in that case, you might be surprised how much overhead that final transfer has...


> Were you aware that vector rendering is not usually done on GPUs, mainly because of the high overhead of state changes when using a graphics API, especially one like WebGL?

But it's actually worse than that, isn't it? It's not only that I can't render a complex SVG path on the GPU, but I can't even apply a GPU accelerated transform on existing child nodes of an SVG.

Why is it that <div> can get a GPU-accelerated transform but <g> can't?


> Why is it that <div> can get a GPU-accelerated transform but <g> can't?

Something that could either be called laziness or difficulty, depending on your perspective.


2D Canvas can be populated with byte buffers


>> three.js has an SVG renderer that does a decent job

And SolveSpace will let you export a CAD model to an html file with a built-in three.js viewer.


So, I actually built this exact thing, a long long time ago, for Adobe when they were building their browser plugin. Mine was a 3D molecule viewer.

I had almost the exact same math in there and it performed about the same until I showed it to an old-school guy I worked with who used to do game programming at sega. He goes "try this" and proceeds to replace a couple screens of trig with:

    d = 0.001;
    x = x + d * y;
    y = y - d * x;
This rotates an object around the z axis with enough fidelity to spin on the screen for days. Making d smaller makes it turn less, but is more accurate. You can repeat this with x and z to rotate around y, or y and z to go around x.

It took me a lot longer than I'd care to admit to understand why that works, but it does. Maybe this will help you. I also tried doing solid models, but the layering was difficult enough that I lost interest and focused on wireframes. If you'd like I can try to find my old source for this.


Would it be possible to embed the JS within the SVG itself?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: