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.
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'm starting a hobby game project on Windows that will make heavy use of 3D graphics effects. It will most likely be written in C++.
Should I use OpenGL or Direct3D for my graphics backend? Why?
Or should I use a ready-made graphics engine such as OGRE 3D? Which one?
Some "how to get started" links would be useful. (On either technology, or both.)
Edit - Yes I really meant Direct3D, not DirectX, thanks to graham.reeds for clarification
Edit - Mihai Lazar pointed out that I could also use a graphics engine such OGRE 3D. Edited the question to reflect this alternative.
Start with OpenGL because there are good textbooks and other online references on it. Once you get the hang of writing 3D game, you would be able to make the judgment for yourself.
Finishing a game, even if it's really stupid and simple just to get you going, is more important than picking the right library. With glut, you can get some 3D object to show up on your screen in a day. Start with NeHe's tutorials.
If you're willing to consider C#, take a good look at XNA. For hobby projects, assuming what you want is to actually get a game up and running instead of tinkering with complex API code, I cannot recommend it highly enough. It is increasingly mature, well-documented, and, compared to D3D/OpenGL, very quick and easy to use. As a bonus, with a $100/year Creators Club membership, you can even use it to develop games for the Xbox 360.
You could also base your work on ogre they provide the abstraction themselves and they have really nice tools. Since this is a projects that's been around for over 6 years I think. The base library is not really for beginners since you need to know a bit about software design, but I found a lot of people that have written games using it.
It would be safer and quicker than learning the heavier stuff since it's already been abstracted. Plus after a couple of month you'll be talking 3D jargon anyways. There is also a book to get you started with Ogre, I think it's kinda old by now but a starting point anyways.
You must remember that DirectX is a collection of technologies - Input, Audio and Graphics. However to most people DX is synonymous with the renderer.
In my opinion D3D (or DirectGraphics) has not really been that hard since DX8. I have not tried DX9 or DX10.
Bernard is right - try to abstract as much as possible. Try to keep DX or OGL calls outside your object classes.
I have no previous OpenGL, DirectX or videogame experience and i have made have an open source race videogame with Ogre3d. Is a very good framework to start in videogames: well done code, plenty of docs and info in the net and very good starting tutorials.
The rendering engine is DirectX/OpenGl agnostic, you can later select to render your game with OpenGL or DirectX (withouth changes in your code)
I did my dissertation at uni on a comparison of OpenGL vs Direct3D. The real benefits of Direct3D are that it has a regular release schedule - it's always being updated to take advantage of the latest advances in graphics hardware. How long has it taken between the OpenGL 2.0 and 3.0 releases? Also, a lot of work has been done in extensions for OpenGL, which means only some rendering will work on some cards.
Having said that, OpenGL will be easier to start programming with. As Direct3D is based heavily in COM, it has a steep learning curve.
If it were me, I would be choosing DirectX over OpenGL. That's at the cost of non-platform independance.
Best thing to do would be to abstract over your renderer as much as possible, to make porting to the other technology as painless as possible.
For the situation that you describe, I would recommend Direct3D.
The primary reason to use Direct3D instead of OpenGL is that often video card vendors only do a good job on the OpenGL drivers for their "high end" cards.
The low end game type cards tend to get poor and generally buggy drivers, causing problems on your end user's machines.
If portability is important, then that would be a big reason to look at OpenGL or Ogre instead.
But if you never plan to port, then focus on Direct3D since it is a more widely stable platform with better IHV driver support.
The thing you should consider is the decision of platform independence. Do you want to tie your game to Windows, or would you like to release it to Mac OS X or Linux at some point. If you decide that you want to support Linux, OS X in the future, you will need to use OpenGL.
There seems to be a lot of goodwill by the Linux community if the game is at least semi-released for Linux.
To answer this question well requires more information about you:
what is your programming ability?
If it's high, I would probably start with Ogre (the best strictly rendering open source engine, IMHO) or another open source game engine, such as Delta3D, if you want additional features (sound, physics, etc.) that a game engine brings.
If you don't want to go with an engine, I would go with Direct3D, because it's being updated much quicker than OpenGL. I don't want to get into all the issues, but version 3.0 of OpenGL was announced during SIGGRAPH and most in the community were very disappointed with it. Direct3D puts you in a much better position to take advantage of shaders and other uses of the programmable pipeline.
If your programming ability is not too high, and you are doing this to learn programming, I would start with OpenGL, because it is easier to learn and there are more resources on the web (see http://nehe.gamedev.net for example).
It is my understanding that in Direct3D you must handle all resource allocation and management yourself, whereas the OpenGL specification leaves this to the driver/implementation rather than the application.
This allows Direct3D developers to use the best allocation and management methods suitable to the application, but is also extra work.
I have done the typical "Hello World" applications in each, and I prefer OpenGL over Direct3D, but that is just my opinion. You should try out both, spend a day or two learning and playing around with each, and decide for yourself.
I really agree with those telling you to learn Ogre3D. You said you'd use C++, so Ogre3D is a great choice. XNA uses C# and you'd have to learn the differences between it and C++, apart from learning the very XNA. Also XNA is neither Open Source nor cross platform, so if you wanna have a wider knowledge about game development, I'd suggest first learning SDL, and then Ogre3D.
To start with, we've got the Wikipedia comparison of OpenGL and Direct3D.
But I'd really like to hear some practical viewpoints, especially in the light of recent developments of OpenGL 3.0 and DirectX 10.
The suggestions for abstraction of an engine are good, assuming that you know what you are doing. It's difficult to write a good abstraction layer for graphics without having done it already.
I would suggest that you just pick one. You will pick up the concepts from either easily enough -- enough so that you can potentially work on an abstraction layer, or the other library easy enough. But just do it. I really wouldn't worry so much about which is the right one. They are both good, solid performers. DX10 (if you have Vista) may have the slight advantage of more up to date shader models, but for someone starting now, that is pretty irrelevant I think. GL has the advantage that some of the nigglier matrix/vector math operations are either hidden from you, or provided for you (although I think DX has some of these as well.)
While OpenGL is by far easy to start with and as some people already wrote - getting a triangle to show on screen and from there move to textures, particles and more can be done within a day.
I do however think that a good question to ask is what is your final goal.
If it is a simple game, no skeletal animation, and simple 3D - OpenGL is definitely the answer. If you aim way higher and don't want to put the time in developing all the technology from scratch (or go hunting for free libraries and putting all together) then DX is a good choice, I would go for DX9c until DX11 comes out.
If you don't mind messing with other languages other than C++ you should also take a look at the XNA development environment - it became quite mature and good.
Just as well, using an already existing engine is good if you know that it'll give you most of what you need, for the right price and will save you the time to develop it yourself, the main problem is that you'd need to go over several game engines (Ogre, Game Studio, Torque, etc..) and then make your choice based on limited experience - read as many reviews from casual developers as you can before you proceed, and try to take a look at the code if you intend to change it.
Hope it helped.
You have to think about what you want out of it, as it's a hobby project I'm assuming that "learning stuff" will be a major part of the experience so avoid picking up something that hides things from you and does stuff behind the scenes as this will only give you a fraction of the picture.
I'd go with Direct3D because it's got the better support, I find the docs easy to read and there are decent samples that come with the SDK. You can even use these samples as the base to build on if you want to get a kick start without the initial steep learning curve of getting things set up.
I started with OpenGL for the record, and after about a month went onto Direct3d (version 7 at the time). I found Direct3D forced me to be more aware of what I was wanting to do and how I was setting things up but I preferred this level of understanding.
Importantly IMO, whichever way you choose, take it step by step and get things on screen regularly. There's all sorts of reasons why something isn't on screen (it's transparent, the camera's inside the object, etc...) so by taking baby steps and getting stuff to display regularly you're both verifying things are still moving along and getting a little visual reward.
Don't start with Ogre.
Start with OpenGL GLUT (Win32), and a tutorial or two.
As soon as you can move to Win32 and take a look at this site, which is pretty old now, but still, quite good.
Clearly from the responses you've been getting, you can reasonably start with either D3D or OpenGL for your 3D graphics API. Triple-A gaming titles have been developed using both technologies, and they both have their strengths and weaknesses.
If you're already reasonably proficient in C++, either one will serve, however there's a number of other considerations to make in your selection:
Portability: OpenGL (and OpenGL ES) is available on Windows, Linux, OS X, iOS, Android, and other systems. D3D/DirectX locks you into MS platforms only.
Game Input: In DirectX, the DirectInput API gives you access to controllers. OpenGL doesn't have an equivalent here.
Sounds: DirectAudio supports sounds, OpenGL has no equivalent (however OpenAL is often used)
Physics: Depending on your game needs, you may need some advanced physics simulation
Typically the actual "gameplay" focus is on the AIs, combat, storyline, etc.
If you're still climbing the C++ learning curve (worthwhile, but takes some time), you might instead use C# and OpenTK. This would provide you with the benefits of a "gaming framework" like Ogre, reasonably direct access to OpenGL, and the significant benefits of using managed code (and IDE) for the game logic. OpenTK is cross-platform via Mono, so your code can run on OS X and Linux as well.
Have fun!
Ogre3D is great if you want to do cross platform coding and if you want to leave all the rendering to the engine. OpenGL is also great for cross platform coding, but it also makes you do all the boring parts -- however it provides greater control.
I would avoid DirectX in case you want to port your game to other platforms. Plan for the future. DirectX 10 may provide some advantages compared to OpenGL, but I really don't think you'll feel them unless you're a professional development. Otherwise, if you're pro-Microsoft, you should use XNA anyway, since as an amateur developer you won't need control provided by DirectX.
I'm coding with OpenGL for quite some time now and with Ogre3D for a few months now and I can't say I want anything else. I recently got a book on DirectX 7 and I consider it messy. Perhaps things changed, but from what I observed I don't find DirectX, and by extrapolation Direct3D, attractive.
My opinion is that OpenGL is best.
OpenGL SuperBible: Comprehensive Tutorial and Reference is a good reference.
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.