Plugin Update
Wednesday, October 7, 2009 | 3:30 PM
Labels: O3D API Blog
A new version of the O3D plug-in (0.1.42) is now on its way! This release contains a few bug fixes along with some exciting new functionality including more flexible ways for manipulating image data via the new Bitmap object and support for Data URLs both for reading back the contents of the render buffer and for creating Raw Data buffers. For more details on what's included with this release, please take a look at our Release Notes. As always, if you are an existing O3D user, your plug-in will be updated automatically soon, but if you just can't wait, you can go to our home page and install it manually.
An interesting bit of trivia here is that this is likely the last release we'll make using our old build system. We now have all the pieces in place to switch our build over from scons to GYP. As you can imagine, switching build systems mid-flight in a product the size of O3D can be fairly challenging, but it looks like most of the hard work is now behind us. Switching to the new build system was a necessary step for getting O3D integrated into Chrome, but it also provides some additional benefits to developers who work with the O3D source code. GYP will generate native project files (Visual Studio on Windows and XCode on the Mac) which makes the edit/compile/debug cycle a lot faster than before. In addition, we'll soon be exposing our Buildbot-based continuous build system to everyone so that you can monitor the build progress in real time and even pick up binaries built from the top of our trunk! Stay tuned for detailed instructions.
As always, we appreciate your support and comments. Please continue using the o3d-discuss group for sending your feedback and questions and the o3d issue tracker for filing bugs.
10 comments:
gpakosz said...
"GYP will generate native project files (Visual Studio on Windows and XCode on the Mac) which makes the edit/compile/debug cycle a lot faster than before."
ok right, smells good
however, why GYP? looks like another wheel when cmake is established, stable and praised
is there something REALLY mandatory that cmake doesn't provide?
October 8, 2009 at 12:39 AM
Another Developer said...
I agree why didn't you just use CMake. Hmm, sounds like not invented here syndrome.
October 8, 2009 at 7:20 AM
hbridge said...
see this thread on the chromium-dev group for more info on GYP and why the Chromium project uses it.
October 8, 2009 at 3:22 PM
Sanford said...
Vangelis -
Any news on resolving the Intel integrated chipset issue you discussed on May 2009?
http://o3d.blogspot.com/2009/05/o3d-plugin-update.html
We have an Intel Corporation
Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) and need it to work.
Any thoughts on your next release?
Sanford
December 11, 2009 at 1:08 PM
Erwin said...
Interesting, yet another meta-build system that can autogenerate projectfiles, similar to cmake and premake.
A quick comment on Gyp versus cmake based on the arguments made here:
gyp versus cmake
The two main reasons stated were that
>>cmake only supports absolute paths
This is not entirely accurate, because cmake can create projectfiles (MSVC, Xcode etc) with relative paths when you use the option CMAKE_USE_RELATIVE_PATHS. Unfortunately cmake has some bug related to pdb files still using absolute paths, although there is a patch available that fixes it.
>>users have to install cmake in order to build stuff
You can use cmake to generate projectfiles, and include them in the tree, using the MAKE_SUPPRESS_REGENERATION option.
Then developers don't need cmake installed. But if your project already requires python, it makes sense to use something like Gyp. I've been using cmake for a few years now, and my main issue with it is that it is hard to customize: it requires recompiling your custom version of cmake.
As both Gyp and cmake are meta-build systems, it might be possible to auto-generate/convert from one to the other.
Cheers,
Erwin
December 20, 2009 at 9:52 PM
Unknown said...
any interesting news? why is there no blog post since months? :)
January 30, 2010 at 7:44 AM
Andrew said...
I'm interested in this question too.
Is o3d going anywhere, or is it quietly being dropped by the way side?
Is o3d going to be another one of these projects that google throws out there and then abandons when it doesn't immediately take off?
February 9, 2010 at 7:26 AM
Andrew said...
My previous comment left here is still waiting to be moderated?
Is this an abandoned project now?
Think it would be really kind ("doing no harm") to tell developers what is happening before we put lots of work into a project that no longer has any support.
February 23, 2010 at 3:14 PM
Videometry.net said...
I can only echo the concerns of my fellow developers. While the discussion groups is still active, I was beginning to think my RSS feed was broken. The lack of blog posts does leave one wondering whether to dive into this technology.
March 15, 2010 at 12:41 PM
wisewit said...
I've been watching the 3d web plugin scene for about 15 years now (starting back when VRML was new), and every plugin I've seen died in the end. Most of them were badly designed. o3d looked better--until I found out that it didn't have 3d sound and there were no plans for it. That was a deal breaker for me. That was typical for 3d plugins: they were always missing something that the developers didn't realize was necessary. Oh well, nice try Google. o3d still has potential.
wisewit
April 27, 2010 at 6:00 PM
Post a Comment