I was reading the Three.js wikipedia page and it states "Three.js runs in all browsers supported by WebGL." If you use canvas renderer will the application/game created with Three.js run in browsers that support canvas but not webGL. Also are there any know issues with Three.js and mobile browsers.
Actually all browsers are supported which have support for canvas. We do not support polyfilled canvas. Mainly because most of the time, we use other things beside the canvas that are not implemented by the browser.
Checkout the browser compatibility list here:
http://caniuse.com/webgl
There's another site with a pretty neat breakdown of the OS + device/browser combination support for WebGL:
http://webglstats.com
Edit: To answer your second question on mobile, problems will be unlikely if the mobile browser supports WebGL since WebGL is basically based off of Open GL 2.0 ES (Embedded Systems). "ES" is mainly targeted things like mobile devices
You can take a look at WebGL plugin for Internet Explorer 10 and below.
Related
An open question to the three.js community.
As far as I know, the Three.js framework has different "enhancements" like OrbitControls.js that allow us to use the mouse or a touchscreen to explore a 3D scene.
Now my question:
Is out there another "enhancement" for Three.js that allows the usage of joysticks, gamepads or 3D mouses?
If not, how easy or difficult do you think it can be to implement their functionality?
The link by juagicre is useful.
Here are some more
This one checks that signals from your connected gamepad are being received:-
html5gamepad.com
html5rocks.com gamepad tester with image
stemkoski html5 demo
stemkoski THREE.js demo.
html5rocks tuorial
I just picked up a cheap unbranded USB gamepad in a thrift shop today. Using Firefox 38.0.5 or Chrome 47.0.2526.58 beta-m) it works for (1) and (2) but not yet for (3), (4), (5).
The official THREE.js website Examples does not seem to include a gamepad example (look in the section /misc).
Here is some info regarding the gamepad state in the web.
Looks like nowadays there is still a way to wait until this gets widely supported.
Have fun!
I'm having a heck of a time getting a map to render properly in IE8 or IE compatibility mode. I've tried examples and demos, I've changed maps multiple times... All features seem to work and look great except IE compatibility mode or antiquated versions of IE. Maps ARE rendering on IE8 or below on the jvectormap website just not for the examples offered.
I've even gone as far as trying to replicate the maps on http://jvectormap.com, linking right to it's JS files. Still nothing.
Thanks so much for your time.
I reviewed the link you gave. The only issue I see is an absence of region border in IE8 or compatibility mode. The problem behind this is inability of VML engine to render borders with fractional width. Setting border as 1 makes the example work as expected.
I have created an augmented reality application using Monodroid and it works fine on a technical basis. However, the graphics I used were drawn on a canvas and are really too slow.
The application is a simple heads-up compass and speed display a-la luke-skywalkers binoculars.
I am trying to get a camera preview going with an openGL translucent/transparent overlay and yes, I have read whats available but its all pure Android SDK / Java.
Does anyone know of a method of getting this effect in C# and Monodroid possibly using the AndroidGameView? Whatever I do I can see one or the other but never both at the same time.
Unhelpful jerks are a pleasure to work with.
http://bobpowelldotnet.blogspot.fr/2012/10/monodroid-camera-preview-as-opengl.html
This question is more philosophical than technical.
I've trained myself as a web developer back when web developers were called webmasters and my tool of choice was FrontPage, moving onto Evrsoft 1st Page 2000.
That was the last time I used an HTML image map.
Now it's HTML5, AJAX, vector canvasses, CSS 3D, jQuery, local storage, touchscreen Safari, you name it. The image map has faded into an obscurity where not even Google comes up with too many relevant results; a mandatory W3C Schools entry and some forum posts from 2004.
Obviously creating a website navigation or similar triviality using an image map was a bad idea back then and it certainly is inexcusable today.
But right now I have a task to create a polygon clickable area on top of a div with a background image.
I'd have no issue doing this in image map since it seems like it was designed for a use case exactly like this, and while I've done no tests, I couldn't imagine any browser dropping support for an element that worked beautifully for years. But I can't help but think that there must be a better way to do this today.
My web creation philosophy is to develop for IE5.5, and then design for Chrome edge. This means that the site first needs to work on a basic level on even the most antiquated browser, and then start adding JS & CSS to make it more beautiful, more usable, faster, simpler, friendlier and better.
As such, while I know I could do a canvas in Raphaël and add all kinds of snazzy hover effects and things, I think making functionality as simple as this shouldn't require a 89 kb (or X kb) JS library. Or even JS at all.
I don't know if CSS3 has capabilities to define polygonal areas, but while recognizing the great possibilities introduced by CSS3, I prefer keeping anything defined there as non-essential flair that would degrade gracefully.
So in today's webdev world, what would be the most cross-browser way to define a polygonal click area (preferably in a way that's grabbable by a jQuery .hover(), or at least a CSS :hover), that isn't dependent on JavaScript or CSS attributes available in a minority of browsers? Is image map really the only way to do it? What of mobile devices?
Why is using image maps for navigation inexcusable? It's a tool like any other; it has a time and place. Using imagemaps with javascript enhancements is backward compatible, degrades gracefully, and has 100% browser support. They don't need a plugin like flash.They've been supported practically since the dawn of the web browser. Just because something's old doesn't mean it isn't useful; quite the opposite, it means it's well supported.
I wrote a jquery plugin called ImageMapster to add effects to imagemaps so you could create interactive images without using flash. It would be easy to implement a tool that had the same functonality without Javascript support by replacing with a list in those cases. Personally, I think trying to write for the web without javascript is like trying to drive a car without tires. 99% of the web doesn't work without it any more. This isn't 1995. But if you really are concerned, the nice thing about imagemaps is the basic navigation functionality still works. There's no way to accomplish that just with CSS -- not even CSS3 if you have irregular shaped areas.
We have a website that currently serves drawings to users via the SVG Viewer plugin. We have one client that sees it through IE8. With IE8, when they do a Change Zoom Level on the browser to anything other then 100%, the viewer tries to occupy the new space and zooms correctly. However, when the user tries to manipulate the frames inside that bound the viewer (it's a frameset website with the viewer being in the center) the entire site hangs. IE8 also shows that it takes up CPU cycles on the client computer, so it's trying to do something but hitting a loop.
I don't think this is actually our code and might just be something with SVG and how IE8 handles plugins and it's zoom. Does anyone know if this is a real problem and if there's a good solution?
If you are referring to the Adobe SVG Viewer plug-in, then I recommend that you (ideally) get your clients to start using a web browser that supports SVG natively — i.e. Chrome, Safari, Firefox, Opera; even IE9 (to some extent) — or use a different shim like SVGWeb to provide SVG support for those users of older browsers who also have Flash installed.
I found out what the problem was. I thought it was the SVG viewer trying to do something with the frames, when it turned out that I was just setting the frameset's initial size to the clientHeight and clientWidth, and then subtracting something from the height. That subtraction was a toolbar based in the frameset and, when you change the zoom level in the browser, there's a lock up that can occur with you trying to pull a components size and the client's size. At least, this is what I was seeing.