Is COLLADA a dead format? - opengl

I've been reading lots of musings on the net that COLLADA is a dead file format? In that applications are not updating their support for it etc. Is this true? It was originally designed to be a format that could be almost application independant so my question is in 2 parts. Is it a dead format? And if so, what is the current accepted format to maximise inter-application development (and to use with OpenGL applications)?

Most applications are supporting COLLADA, new support is announced all the time.
Follow COLLADA on twitter to get daily updates... far to be dead.
Hard to keep track in fact.
BTW, Khronos just released the COLLADA reference card. free at http://www.khronos.org/files/collada_reference_card_1_4.pdf , making it easier to implement.
Still the missing piece was the conformance test, to make sure applications are correctly following the specification, and it has been released recently
In short, expect improved support, more applications, better interoperability. One thing for sure is COLLADA is a published standard, (as opposed to be a proprietary technology), so it is there to stay and safe to invest in as it is not impacted by mergers, bankruptcies, change in company policies...
...
also, we are in the process of rebuilding collada.org. There is an incomplete list of products , and a forum for your questions.

COLLADA was supposed to be an intermediate format while producing content. That is why there are more plugins and libraries for modeling packages than there are for 3d engines and libraries.
A custom OpenGL graphics engine will tend to use its own model format so it can implement new features that are not in COLLADA.

There's a lot of middle-ware support for COLLADA, so I don't think you can call it dead. However, it hasn't become The One Format To Rule Them All, as some was hoping for. Basically, it's the best common middle-ground for 3d-asset exchange between different software-packages, but it's not a very good fit for in-engine usage.

I am not really optimistic about the future of the COLLADA format. Nothing happened since the publication of specification 1.5. There is no tool which supports the complete COLLADA functionality.
OpenCOLLADA is a nice library which helps the format alive for now, but it is not enough. Format itself should improve through the time, too. I have tried to work with physics libraries of COLLADA, the only tool I can find to create a reasonable example was Maya. And not without extra effort to install plugins, etc. Most of the importers for COLLADA does not support 1.5, and when they support the version they do not support some of the elements. COLLADA model repository server is down for ages, it is difficult to find good examples with variety to work with.
AutomationML format uses COLLADA as graphic format, which brings the possibility to be spread for industrial usage. But there are already some strong competitors in this field like JT.
An extra problem, COLLADA supports MathML in element but during MathML improves as a format, COLLADA stays put and new versions of MathML format cannot be used.
I liked the idea of the COLLADA, but it is far away from its goals because of the lack of support and applications.

Related

3D model files & creating triangle meshes from it

I'm new here. I'm learning C++ yet so I don't have a big knowledge about things ( well, I have a lot of experience with programming but with other languages. I also know how to work with a computer xD ). I decided to start working on a game engine. I know it ain't easy but that's one reason why I want to do it - trying/getting experience is the best way for me to learn.
So, I'm starting with the renderer but I have no idea how could I make a 3D model file which as it says in the name it would have a 3d model and it could be loaded into a triangle mesh in the C++ engine and I could use it with Direct3D. I don't want you to do anything except giving me an idea how to start.
Thank you very much if you decided to read this & help.
This is a great question and rings so true because you are in exactly the same place that I was 3 years ago. I looked around at various applications that I could use to generate 3D content. I didn't want to spend time learning various applications because I wanted to get coding my game engine. I couldn't find anything quick enough to learn to make it worth my while (that was free of charge) so in the end I put some scripts together to create the 3D models (vertex arrays). These developed into a GUI driven interface which developed into my own fully functioning 3D Modelling Tool. Now, after 3 years, my Game Engine is on the back burner and MeshCreator (check out http://www.MeshCreator.co.uk) is now my ongoing project.
You need a way of loading in Vertex arrays. OBJ files (wavefront) are Text Based and fairly easy to read. The output from MeshCreator is also ASCII based and there are details on the website on how to interpret the file format.
The File output from MeshCreator is designed for easy import into any 3D project. You could also look at .OBJ files as they are supported by most 3D apps (including mine). OBJ files can get a little complex though.
In short, you need an easy to use tool. It took me 3 years to write my own so I wouldn't recommend it. Try out MeshCreator, MilkShape 3D and maybe Google Shetchup. Also, there are many sites that have royalty free 3D content that you can use in your projects and many are available in OBJ format.
3D model file formats can be very complicated, mostly in the sheer amount of types of things they can contain (meshes, primitives, curved surfaces, materials, lighting, etc. etc.). Which also means that it can be very hard to come up with your own format too. So, there are really two options here: find off-the-shelf libraries to handle the loading of models; or, pick pre-existing formats and write your own code to load those files (and use a standard editor to create them).
The main problem with using an off-the-shelf library to load the models is often that these libraries are often intimately tied to a particular renderer and usually very complex in the (possible) data structures that are generated when loading the files. So, this is often a better solution only if you are prepared to adopt the renderer of which this model-loading-library is a part of or tied to. There are options like Irrlicht, Ogre3D, Coin3D, etc., which all have reasonable capabilities at loading fairly standard 3D model file formats.
If you are going to pick a pre-existing file format and create the loading code yourself (and thus, tied to your own renderer), then you should pick carefully. The 3ds file format is very widely used and its internal structure is nice and fairly simple, with the advantage that you can easily skip elements that you can't support yet (this is useful when you are incrementally writing your rendering code). Most other formats have similar features (forward and backward compatibility, and ability to skip "unsupported" elements). There are also important open-standard formats, vrml and x3d, that you might want to take a look at. Also, there are some simpler formats associated to some open-source 3D editors like Blender. It is important to have a good 3D editor that can output in a file format that you can load. That's why you shouldn't create your own file format, because you will have a lot of extra work to do, either in creating custom "export" scripts (or plugins) for some 3D editor, or in creating your own editor (a monumental task).
Search around. If you want to base your engine on DirectX, I believe the SDK comes with code samples explaining the basics, like loading meshes.
If you're just learning C++, I'd recommend you start with a much simpler project like making a simple game with an engine like Irrlicht or OGRE, but that's up to you.
I think you need something like obj files. You can find online free files to play with. If you want to generate your own, I think you need some 3D rendering software. You can also search how to parse them and load their content in your programs.

Use a html renderer in an embedded environment [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm working on a project where I will design a GUI for an embedded device and would love to go with HTML for this. I hope you guys can help me find a render engine that suits my needs.
Requirements:
The web-page must be rendered into a memory buffer. I will then transfer the memory buffer to the display.
I must be notified though callback or event that the render engine need to fetch a new item. HTML page, image, etc. The reason for this is that I must fetch the resource and feed it to the render engine (the reason is that the device does not have TCP/IP in all configurations and will then need to fetch the item over serial line, and also for security I need to validate that the request is allowed).
I must be able to inject mouse and keyboard events into the rendering engine.
Only C and/or C++
Must be easily portable and lack dependencies to libraries that only exist for win/linux/mac. The device I have runs a custom OS...
Small footprint and memory consumption, I can probably get away with 10MB footprint and 5-10 MB allocated memory during rendering. But not much more.
Both open source as well as commercial solutions are welcome
I do NOT need full HTML5 and CSS3 support, I mean if I can use "basic HTML and some CSS" I'm more than happy.
I have looked at some WebKit, chromium, gecko, berkelium and awesomium but not really found that they fit my needs.
Is there anything out there that comes close to what I need? Or should I just give up this idea and build the GUI in some other way? I appreciate any help!
Good question! It turns out there are a few options within this space, and as you've surmised, many of them are based on Webkit. Some of them aren't, though, and those are the ones that I believe you're most interested in.
Links
The simplest, 0th-level browser that's going to meet your needs is the graphical version of the Links web browser. It's suitably cross-platform (admittedly, you will require some of the libraries from Cygwin for Windows environments), open source, carries a small memory footprint, and in some of its forked or enhanced incarnations (for example, Elinks), has enhanced functionality like Javascript support, full mouse functionality, and the bells and whistles that you desire in your problem statement.
Of course, it's written in C.
Konqueror/Embedded
Exploring some of the other options within this space, Konqueror/Embedded is something to consider and watch in the future. Yes, it is based on Qt/Embedded and Webkit (mumble mumble), but they're aiming to provide a slimmed down version of both their browser and their library stack to meet this need specifically. Once again, Windows is going to be the odd child out here, but it's workable.
Fennec
One last cross-platform option to explore is the slim version of Mozilla Firefox, Fennec. While providing a much larger code base, Mozilla is working on its embedded version very aggressively, and any help you can provide here would be greatly appreciated. From what I understand, the slimmed version is still pre-alpha (Fennec, however, lives on), but it should become a workable option in the future.
And a Gamut of Others to Explore
In addition to the gamut of web browsers currently competing in this space, proprietary options like ANT Galio may also meet your needs. It seems there are many other proprietary solutions out there, but the majority of them (for example, Internet Explorer Mobile, Mobile Safari) only service a small number of platforms. Good, proprietary, cross-platform solutions that aren't based on Webkit seem to be quite rare.
SpliFF also offered an excellent suggestion in his answer: try libRocket. As he recommends, it's lightweight, cross-platform, currently and actively maintained, easy for you to hook into, and provides for the automation cases that you seek. In this case, it's programmed in C++, with Python bindings for additional convenience.
In conclusion, given your needs, you'll still need to evaluate the strengths, weaknesses, and API specifications for the options listed above.
I recommend starting with Links, because it's the most feature-rich and robust option while optimizing on a very small memory footprint and codebase. Its biggest strength is that this was a design goal from the outset, and the entire code tree is built with this design philosophy in mind.
Do let us know what you go for. This is a common enough need in the community that I'm sure others will benefit from your experience.
Have a look at librocket. It meets your requirements of being HTML+CSS, lightweight, handling events and rendering to a buffer. I looked though a bunch of projects recently looking for basically what you asked and this was the match I found.
libRocket is the C++ user interface middleware package based on the HTML and CSS standards. It is designed as a complete solution for any project's interface needs.
libRocket uses the time-tested open standards XHTML1.0 and CSS2.0
(while borrowing features from HTML5 and CSS3), and extends them with
features suited towards real-time applications. Because of this, you
don't have to learn a whole new proprietary technology like other
packages in this middleware space.
Cross platform architecture (Windows, Mac, Linux, iPhone, ...).
Dynamic layout system.
Efficient application-wide styling, with a custom-built templating engine.
Fully featured user control set: buttons, sliders, drop-downs, etc.
Runtime visual debugging suite.
Easily integrated and extensible with Python scripting.
Abstracted interfaces for plugging in to any game engine (samples for OpenGL, DirectX and Ogre3d).
Decorator engine allowing custom application-specific effects that can be applied to any element.
Generic event system that binds seamlessly into existing projects.
Have a look at DS Organize, a homebrew DS browser, and also ES Operating System by Google (for an OS originally developed by Nintendo).
I have suggested looking at DS Organize as the Nintendo DS has only 4MB of RAM (8MB with the memory extension that most DS browsers use). And you might also be able to get away with rendering directly to VRAM, saving you a few 100kb, depending on your memory model and how much freedom you have with VRAM writes outside of VBlank.

html5 d3d application menus/hud

I'm looking to use html5/css/js for the menu system and hud of a C++ d3d application. Ideally I'd like a 64bit MSVC10 library that I can statically link to.
So far I'm looking at:
Berkelium
chromiumembedded
QtWebKit
Awesomium
Before I commit alot of time I'd like to understand the which library would be the best for my purposes (not just from the list above). Could I use WebKit directly? Or chromium?
Even though this concept seems to be catching on right now I can hardly find a single example showing how to do it or collating relevant information.
You may also look at GUI toolkits that embed/integrate/have plugins for your listed HTML renderers (MyGUI comes to mind, with Berkelium/Awesomium integration).
Berkelium or Awesomium in general are probably a good bet, they're rather widely used for embedding Webkit and will work well. Berkelium is somewhat newer, and may have a few less features, but documentation tends to be better.
Of note is the long history Awesomium's developers have of flip-flopping licenses and suddenly trying to get money out of users (they've had free licenses before, which then were retconned into a pay-when-you-release), so that should be taken into careful consideration before touching it.
I'm not familiar with chromiumembedded and Qt has gone heavily OpenGL, severely damaging its value in graphics apps in general and likely making it useless to you.

Three.js ported to native code?

I've been playing with WebGL quite a bit lately and I really dig Three.js. It's really lightweight and just serves as something that makes wrangling most of the GL calls a bit easier, and provides a quick way of creating basic primatives like a sphere.
Now, in native land, it seems that all the frameworks want to be so much more than that. Things like Oolong, UDK, Unity, Cocos, etc. I did a bit of googling, and the closest thing I could find was iSGL3D but I'm not thoroughly convinced it is the right answer.
Is there something more similar to Three.js that is written in native C, C++ or Objective-C that I can't find?
Here is a port of three to C++: https://github.com/jdduke/three_cpp
Core - 75% complete (TODO: Morph targets, shadows, plugin support)
Extras - 5-10% complete (TODO: Pretty much everything)
Examples - 25% complete (TODO: Examples involving morph targets an)
You're asking for a strict graphics engine only, in the same direction as OpenGL (in comparison to DirectX which again wants to be so much more than that). I'd advise Ogre3D for iPhone as the philosophy behind Ogre3d is to be a strict graphics engine.
The other one that comes to mind is recently perused MoSync mobile sdk which offers excellent OpenGL support across a wide range of platforms (albeit limited; to maintain portability).
If you're more interested in loading shaders and having the graphics engine manage the rest, I'd pick Ogre3D for iPhone.
You can always take the initiative (if you have the time of course) to write your own or start off from the ones mentioned here!
Or you can use a JavaScript engine (JSAPI for example) in a C++ editor and then move three.js on top of that. This is great as you'll only update the JSAPI and Three.js without breaking functionalities and your C++/JSThree engine will stay up to date with minimal maintenance.
Just some ideas of course!
Although I would also prefer to see a port of three.js for iOS, recently stumbled up on iSGL3d (http://isgl3d.com/).
This project serves a simple, encapsuled way to build an manipulate an opengl scene graph by code. Otherwise than some creative coding frameworks like cinder, iSGL3d comes in pure Objective C.
Works well for me yet.
You could also give Ejecta a go. They just added WebGL/three.js support.
https://github.com/phoboslab/Ejecta/tree/next
Three_cpp is good, but has stopped updating since 3 years ago. It does not support VS version below 2012.
Ogre is another good choice, which is much similar to the logic of Threejs:)
And the official site provides a very detailed tutorial, making it easy to use!
After some more searching I found a stripped down version of SIO2 called GFX that looks promising.
If you're looking for strictly ease-of-use, I'd highly recommend Panda3D. It's cross-platform (Windows, Unix, Mac), really easy to use, has extensive documentation, and a nice community around it.

What is the best approach to use openGL in the web?

I wrote a program in C++/OpenGL (using Dev-C++ compiler) for my calculus 2 class. The teacher liked the program and he requested me to somehow put it online so that instead of downloading the .exe I can just run it on the web browser. Kinda like java applets run on the browser.
The question is:
How if possible, can I display a C++/OpenGL program in a web browser?
I am thinking of moving to JOGL which is a java interpretation of OpenGL but I rather stay in C++ since I am more familiar with it.
Also is there any other better and easier 3D web base API that I can consider?
There is a lot activity recently with WebGL. It is a binding for Javascript to native OpenGL ES 2.0 implementations, designed as an extension of the canvas HTML5 element.
It is supported by the nightly builds of Firefox, Safari, Chrome and Opera.
Have a look at these tutorials, based on the well known NeHe OpenGL tutorials.
Several projects based on WebGL are emerging, most notably Scenegraphs APIs.
From Indie teams: SceneJS, GLGE, SpiderGL.
From Google: the team behind O3D plugin is trying to implement a pure WebGL backend (source) for the project, so that no plugin will be necessary.
From W3C/Web3D: There is an ongoing discussion to include X3D as part of any HTML5 DOM tree, much like SVG in HTML4. The X3DOM project was born last year to support this idea. Now it is using WebGL as its render backend, and is version 1.0 since March 2010.
I'm almost sure that WebGL is the way to go in the near future. Mozilla/Google/Apple/Opera are promoting it, and if the technology works and there is sufficient customer/developer demand, maybe Microsoft will implement it on IE (let's hope that there will be no "WebDX"!).
AFAIK, there's only 3 options:
Java. it includes the whole OpenGL stack.
Google's Native Client (NaCL), essentially it's a plugin that let's you run executable x86 code. Just compile it and call it from HTML. Highly experimental, and nobody will have it already installed. Not sure if it gives you access to OpenGL libraries.
Canvas:3D. Another very experimental project. This is an accelerated 3D API accessible from JavaScript. AFAICT, it's only on experimental builds of Firefox.
I'd go for Java, if at all.
OTOH, if it's mostly vectorial works (without lots of textures and illumination/shadows), you might make it work on SVG simply by projecting your vectors from 3D to 2D. In that case, you can achieve cross-browser compatibility using SVGWeb, it's a simple JavaScript library that allows you to transparently use either the browser's native SVG support or a Flash-based SVG renderer.
Do you really have the time to rewrite it? I thought students were meant to be too busy for non-essential assignment work.
But if you really want to do it, perhaps a preview of it running as a flash movie is the easiest way. Then it's just a matter of doing that and you could provide a download link to the real application if people are interested.
Outside of Java, in-browser OpenGL is really in its infancy. Google's launched a really cool API and plugin for it though. It's called O3D:
http://code.google.com/apis/o3d/
Article about the overall initiative:
http://www.macworld.com/article/142079/2009/08/webgl.html
It's not OpenGL, but the Web3D Consortium's X3D specification may be of interest.
Another solution is to use Emscripten (a source-to-source compiler).
Emscripten supports C/C++ and OpenGL and will translate the source into html/JavaScript.
To use Emscripten you will need to use SDL as a platform abstraction layer (for getting an OpenGL context as well as loading images).
Emscripten is currently being used in Unreal Engine and will also be used in the Unity 5 engine.
Read more about the project here:
https://github.com/kripken/emscripten
Two approaches:
Switch to Java. However, your application will suffer from a loss of performance as a trade off for portability. But since Java is everywhere, this approach ensures that your code can be executed in most browsers.
Use ActiveX, which allows you to run native binary code for Microsoft Windows. This is not recommended in production because activeX is well known as a potential security hole, but since your lecturer is the one viewing it, security doesn't seem to be a big deal. This is applicable for Microsoft platform (Windows+IE) only.