I'm planning on doing an interactive AR application that will use a laser sensor (for distances), GPS technology to get a location, and then use compass/gyroscope for tracking 6DOF viewfinder
movements. The user can choose from a number of ready-made 3D-models, and should be able to place them by selecting the desired location on the screen.
My target platform will be a 8"-handheld-device, running on windows8.
Any hints what would be the best AR-SDK or 3D-viewer to work with?
thanks in advance!
There are quite a few 3D viewers that are working in the browsers. But most recently and most notably: va3C viewer
It is webgl based app and doesnt require a server, so if your handheld device supports webgl, then you are good to go, however, whether it works on IE or not is questionable ;).
Although based on my experience and your usecase, I believe client side JS libraries do not provide enough access to the device's hardware. So you might have to serve the information like GPS, Gyroscope, from the server side, then gather this on the client using something like socket.io and then mash it up alongside the geometry.
I am trying to do something similar, although havent quite done it yet. Will keep you posted.
Another approach I am exploring is X3DOM, which gives the ability to write 3D data like XML alongside HTML, which is quite declarative and simple to pickup. X3DOM derives from X3D.
Tell me if you need more info.
Also, worth exploring for its motion abilities, is Robot Studio, which is a desktop app with SDK.
Related
Is there any way to have three.js running server-side on a headless server (standalone server, Amazon AWS or similar)?
Currently I fall back to canvas rendering (wireframe only for performance reasons) when user's browser does not support WebGL. This is good enough for realtime interaction, but for the app to make sense, users would really need to somehow be able to see a properly rendered version with lights, shadows, post processing etc. even if it comes with great latency.
So... would it be possible to create a server-side service with functional three.js instance? The client would still use tree.js canvas wireframe rendering, but after say... a second of inactivity, it would request via AJAX a full render from the server-side service, and overlay it simply as an image.
Are there currently any applications, libraries or anything that would allow such a thing (functional javascript+webgl+three.js on a headless, preferably linux server, and GPU-less at that)?
PhantomJS comes to mind, but apparently it does not yet support WebGL: http://code.google.com/p/phantomjs/issues/detail?id=273
Or any alternative approaches to the problem? Going the route of programmatically controlling a full desktop machine with a GPU and standard chrome/firefox instance feels possible, while fragile, and I really really wouldn't want to go there if there are any software-only solutions.
In its QA infrastructure, Google can run Chromium testing using Mesa (see issue 97675, via the switch --use-gl=osmesa). The software rasterizer in the latest edition of Mesa is pretty advanced, involving the use of LLVM to convert the shaders and emulate the execution on the CPU. Your first adventure could be building Mesa, building Chromium, and then try to tie them together.
As a side note, this is also what I plan (in the near future) for PhantomJS itself, in particular since Qt is also moving in that direction, i.e. using Mesa/LLVMpipe instead of its own raster engine only. The numbers actually look good. Even better, for an offline, non-animated single-shot capture, the performance would be more than satisfactory.
Some inputs in this thread : https://github.com/mrdoob/three.js/issues/2182
In particular this demo shows how to generate some images on server side using nodejs.
Thanks,
Nico
Links below will not resolve your problem with AWS but will give you a hint.
I am working on the application with a similar architecture and came across with these examples:
Multiplayer game with realtime socket.io
My original question on similar architecture
I am gonna develop a lesson in two platforms(firstly in webgl and then a similar lesson in unity 3d).
the aim of this research is to see the best of these platforms in terms of performance and speed to use it in e-learning environments.
my question is this :
how can i measure the performance (processor, memory, graphic card) for these platforms?
also, I am very appreciated if any one give me ideas or a suggestions to improve this research.
WebGL and Unity are not platforms. Unity is a library that has support for multiple platforms; its performance depends on what hardware its running on. WebGL is a JavaScript API for browsers that allow them to access OpenGL ES 2.0. This also isn't a platform; it is utterly dependent on the hardware it is running on.
Sure, each incurs overhead, but they also do completely different things. Even if one is seen as faster for a particular piece of hardware, that doesn't mean that you can use it. Unity makes applications. Something you download and install. WebGL is for web pages: HTML+JavaScript. The reasons to use one are not the same reasons you would have to use the other.
Making a "WebApp" is very different from making a regular application. You generally decide first off whether you want to make a WebApp or a regular application, then use the tools that are available to the one you pick.
There are platforms that don't support WebGL. Namely, Internet Explorer. Microsoft has already stated that they aren't going to implement WebGL. So WebGL's performance on IE is effectively 0.
Also, WebGL is a low-level rendering API; Unity is a game engine. Unity provides more functionality towards making a game than WebGL, so there are productivity differences you must take into account.
Your desire to compare the performance of these simply is not the most useful criteria for deciding which one to use.
OK, your later answer clued me in to the idea that you're focusing on browser-based tools.
WebGL is not available on Internet Explorer. So again, half of your customer base is gone. However, Unity's browser plug-in is a plug-in and therefore must be downloaded by the user. Quite a few users are against that. Also, Unity's browser plug-in doesn't work on mobile systems; you would be expected to write an app for those.
So which matters more to you: reaching out to mobile users (where WebGL is available), or reaching out to Internet Explorer users? Again, this is something you need to deal with long before you answer questions of performance.
I am thinking of building a web based face recognition system. I know there are a few like KeyLemon, and others offered by different manufacturers that allows the laptops users to login into Windows using their face. I am wondering if this functionality could be transfered to a web application.
suggest you use this as the basis
OpenCV (Open Source Computer Vision) is a library of programming functions for real time computer vision.
There was an excellent podcast on OpenCV on Hacker Medley which has various references that are useful. From that i understand that the library tends to move quite fast in development terms so needs close attention.
You may use thing like flash to access to camera ... , and then use the same algorithm to recognize the face ..
I've written a web application which does something similar. And I have to say - I'm quite disappointed at the level of technology we're currently at for such things. The system in question used a 10mpix Canon camera and a special flashlight stand. It had to have a perfectly white background, the head had to be tilted exactly the right way, couldn't be rotated by more than a few degrees, and had to have very precise distances to the edges of the picture. And even then it gave a lot of false positives and negatives.
So maybe they've come up with something better today, but I doubt that. This was all 2 years ago and the software was some commercial product by a company that specializes in that sort of thing.
So all in all I say - better don't. Biometrics are cool, but currently they are way too unstable to be deployed in anything more than niche situations.
Keylemon provides web api to enroll faces and their later recognition. You can use this web apis to integrate in your application to provide face recognition functionality. It works like this. During enrollment six photographs are taken and a bio metric model is generated. A model id is returned to the client. This model id needs to be stored in application database. For face recognition, web camera streaming combined with model id is passed to the keylemon server. If the model id and stream matches the face is authenticated.
Is it possible to develop an 3D application in .Net (XNA or WPF) that would take advantage of Windows 7's multi touch support.
Is it possible to do so ?
Where is the best place to start ?
First: The nature of what you display is independent of whether your application supports multitouch or not.
Second: I don't believe there's a great value in having 3D interfaces whether using multitouch or not: the thing you touch is probably plain (a monitor or something the like). Better go with 2.5D (use shadows to give the whole thing a pseudo 3D look, stay away from 3D cubes).
Third: Have a well concept of user experience. What will be touchable, how will the application react (animations, etc.). Have a great look (graphics) designed and be prepared to have them changed while implementing a multitouch application. Technically, make yourself familiar with gestures, APIs and whatever it takes (the hardware is a factor as well),
The second point can (and probably should) be seen as a personal taste...
Start with gestures
Then dive into the API
We provide a web application with a frontend completely developed in Adobe Flash. When we chose Flash 6 years ago, we did so for its large number of features for user interaction, like dragging stuff, opening and closing menus, tree navigation elements, popup dialogs etc.
Today it's obvious that AJAX/JS offers roughly the same possibilities and because of the number of frameworks that are readily available, it's very feasible to implement them.
Is there a technical reason one should choose either technology over the other? By "technical", I mean performance, security, portability/compatibility and the like. I don't mean aspects such as the very non-programmer way development is done in Flash or whether it makes sense to switch an app from one to the other.
As I just explained in another question, it seems to me that JS is way ahead in terms of market share and I'm wondering whether we are missing some important point if we stick to Flash.
In addition to what others have said, Flash is constrained in the "rectangle" and cannot be added to a normal html page in an un-obtrusive manner.
#Gulzar I think when more browsers will support the video tag like mozilla 3.1 does we'll see even more adoption of ajax/js over flash.
Adobe Actionscript is a statically typed language, Javascript is dynamically typed. Depending on your point of view, this may be a good thing or a bad thing.
With Javascript/HTML/CSS you're going to be heading into cross-browser compatibility hell, especially if you want to support older browsers. This can be mitigated by the libraries that are available, but it's still a big headache. With Flash, you write the code once and it just works in all browsers.
Even with the libraries available, Flash user controls are simply more advanced than anything you can find in the world of Javascript/HTML. In Javascript, you are not going to find anything that comes close to the simplicity and power of a databound user control that Flash provides.
I don't see how Javascript has more of a "market share" than Flash. Pretty much anyone with a web browser has a Flash plugin installed. I'd be curious to know how many people disable Javascript but have a Flash plugin.
Also keep in mind that you're going to be in for a huge learning curve and lots of development time if you decide to switch your technology base so you'd really better have a good business reason to do it.
This decision also has a lot to do with what your application does and who your install base is.
Edit: I see people have mentioned that the iPhone doesn't have Flash support. I would expect this to change with the install base of the iPhone - Adobe would be crazy not to support it.
Correctly designed AJAX apps are more googleable than Flash
Correctly designed AJAX apps are more easily deep linkable than Flash
AJAX doesn't require a plugin (Flash is pretty ubiquitous, so it's not really a big deal)*
AJAX isn't controlled by a single company the way Flash is
Edited to add:
* Except for the iPhone, as Abdu points out.
JS and Flash both have great presence on the web with overlapping capabilities. One area JS is still lacking is in rendering video.
Flash, used well, allows easy localization and internationalization.
Furthermore, it is much easier to use Flash in an accessible manner; you can feed screen readers the right text, instead of having them iterate over all of the possible form elements.
I think Flash should be limited to online games, videos and animation. Otherwise use html and Ajax. It's a web standard and supported by almost all devices.
AFAIK, the iPhone doesn't support Flash. That's a fast growing segment you're blocking out already. Keep it simple and efficient.
Although flash is pretty ubiquitous on desktop browsers, mobile support is very limited (flash lite? yeah, right). I get really frustrated looking up a restaurant on my phone only to find the entire site is flash based and I can't even get a phone number or address!
One benefit of Flash is that it has a few facilities to help do cross domain type operations safely, which can be helpful. Flash also has (limited) support for some hardware, which is not possible with Javascript.
Personally, I'd try to use as much Ajax as possible before turning to something like Flash. From the UI perspective, it is better in that the controls and basic authoring is a little more developed. The Sound Manager project is a good example of effectively using a small amount of Flash while keeping the remainder in Javascript.
I suspect one of the reasons javascript is becoming more popular is that it's more easy to retrofit into an existing application.
As I can't accept two answers, I'm going to merge Christ Upchurch's and 17 of 26's answers in my own post. I think, these two together pretty much sum up what I wanted to know. Thanks guys!
If you're dealing a lot with polygons, then Flash is still easier to program and debug. With AJAX there are a lot of libraries to handle polygons, but the more libraries your app uses, the slower it gets.