Results from 200 billion iris cross-comparisons shows how the false positive rate varies with the chosen threshold, and roughly shows the false negative rate too. If you have a good enough camera, it seems like there's not much problem in choosing a threshold that works very reliably, though you presumably have to make compromises in one direction or the other if you're not getting people to stand still and look straight into your camera - but false positives don't really matter if you're using it for targeted advertising. If you want it for airport security then you don't need to do it without the person's knowledge, and you can get good results:
In the UAE border-crossing deployment, nearly 2 trillion (2 million-million) iris comparisons have been performed to date, as all foreign nationals visiting the Emirates have their irises compared against all the IrisCodes (mathematical descriptions of registered iris patterns) stored in a central database. Some 40,000 persons have thereby been caught trying to re-enter the UAE with false travel documents since this deployment began. The Abu Dhabi Directorate of Police report that so far there have been no False Matches.
My name too. I've actually still got the certificate, dated 14 February 1998.
One day we hope to send space explorers to Mars and beyond. You could be that future explorer, but only if you stay in school and study hard, especially in the areas of math, science, and computer technology.
I did do what they suggested - but given the fate of the Mars Polar Lander, I'd want to think carefully before signing up for a future mission.
Re:XML is the best way to store data?
on
Collada
·
· Score: 1
I've only been working on amateur game development, where all the people are spread around the world and have different tools and there isn't really a traditional art pipeline. Batch conversion doesn't seem as suitable if everyone would have to download hundreds of megabytes over the internet each time the converted data changes, which is why we [are planning to, in the next few weeks] distribute just the COLLADA files to the people involved in development, and their copy of the game automatically converts and caches any changed files at load-time (so there's still the benefit of loading faster, all but the first time). If the converter is changed and every file has to be reprocessed, it'll take longer for each person when they next load the game, but it's still much quicker than having to download the result of a batch conversion process, and it still all happens transparently with no user intervention. It also lets the artists export a file and see it in the game almost immediately, with no manual steps and without us having to spend time on our own modelling program plugins. I expect it would be different if we could build all the data on one machine and send it over a LAN for everyone to load, and if we could afford development of better-integrated art tools, but this way seems to be the best we've found for our situation.
(When the game is eventually released it'll just have the already-converted fast binary files, so the COLLADA loading time and size are only relevant during development.)
Re:XML is the best way to store data?
on
Collada
·
· Score: 1
Besides this, your file sizes will balloon amazingly, as XML/ASCII doesn't have a very good information density when compared with binary data, which doesn't care about formatting and keywords.
It's not good, but it's not quite as bad as one could imagine. Most of space in COLLADA is not XML tags - it's the lists of numbers (arrays of coordinates, indexes into arrays, etc), and those tend to be what increase when you get millions of vertices. The coordinate data for a very small object looks like:
That list of numbers increases in size as the mesh gets more complex, but the XML is only an additive constant overhead per object. Storing numbers as strings is a constant factor, but it's not too horrendous - that example uses 588 bytes for 78 numbers, which is 7.5 bytes per number, and it'd be more like 9.5 bytes without the easily compressed 0s, so it's only about twice as much space as storing 32-bit floats (with about the same precision), which isn't quite "balloon[ing] amazingly" in size.
But it does hurt more in terms of loading time. With a 2.5MB 25K-poly skinned mesh [not a sensible mesh - I just tessellated a small one], it takes me about 200msec to parse the XML (using FCollada) and 150ms to process all the data (converting it into the game's binary format, which is actually 4MB of output but should be a third of that once I stop doing it so inefficiently), and I expect it could be quite a bit faster if it didn't have to parse XML. But our game engine only does that conversion once, and caches the binary version so it's much faster when you load the game a second time after modifying some data. That caching does require a bit more work, but it avoids the issue of slowly loading hundreds of megabytes of XML every time you start the program up, while still letting people export COLLADA files and have the game pick it up automatically - it seems to work well in practice at keeping the loading times sensible.
(The only real reason we're using COLLADA at all is that it's easier than writing our own exporter, particularly since we want to support Blender (to a limited extent) as well as 3ds Max - the fact that it's XML doesn't really matter, but if being XML has helped it gain some interoperability between tools then it seems to be worthwhile.)
Re:Mentioning that you were involved with VRML...
on
Collada
·
· Score: 1
Epic? Ships content in Collada format? Uses it for its own art pipeline?
I doubt anyone would ship it, since it's not suitable for that. I can't find any details of how UE3 actually uses it, so I couldn't do more than conjecture - and most other game developers also appear to keep quite quiet about what technology they're using (at least in public). I've not heard of any other games that have been released yet and are using COLLADA - they claim that "active users" include "THQ, EA, Konami, NCsoft, DoubleFine, Rockstar", but presumably the relevant games are still under development. COLLADA itself is pretty recent, so I guess it'll be a few years before anyone can really tell whether it has survived and found a place in the industry.
Why would you need XML to do this?
You certainly don't need XML - but it does those things already, and it's already understood and supported well enough that you could write a quick Python script to read a model and manipulate the DOM and spit it back out again, which saves some effort compared to writing yet more binary importers/exporters for every tool that has to process the file. There's obviously drawbacks to using XML, but it's not as obvious whether they outweigh the benefits.
unless the tool makers start making Collada exporters, and they do not do things like this
XSI mentions it in one of the main features. (They also mention the dotXSI "standard" - it looks like every modelling program has its own proprietary standard for interoperability... COLLADA is the only one I've seen that's somewhat vendor-neutral (but still flexible enough to handle at least some kinds of real data) - I've heard that Sony saw that the vendors themselves would never agree on any neutral standard, which is why they (as people who want to improve the game development process, rather than push their own tools) had to make one themselves.)
For example, using MAX, stacked skin modifiers get baked how? Answer: however the exporter guy wanted which is unlikely to be the way you wanted it done.
I tried a simple test with ColladaMax, with a sphere and two sets of bones and two Skin modifiers. It exports a scene with a Sphere01-node, using the Sphere01-mesh-skin-skin controller with the Bone05-node skeleton. The scene also contains the hierarchy of bones. It says Sphere01-mesh-skin-skin is skinning the Sphere01-mesh-skin object, and lists the relevant bones and the weights and bind pose matrices and things. It says Sphere01-mesh-skin is skinning the Sphere01-mesh object, and gives more weights and things. And it says Sphere01-mesh is a mesh with certain vertex data. (Incidentally, one advantage of XML is that I can actually look at the file in a text editor and see that reasonably complex hierarchy - the actual geometry data is a horrible mass of numbers, but for small scenes it's quite easy to see what's going on. You could make a visualisation tool for any other non-XML format, but it's helpful if there's no need.)
That seems to be fairly close to how it's represented in Max itself. Then you can (/have to) write your own code that loads that COLLADA file (using existing libraries to handle the boring standard bits), and do whatever conversions you want for your particular purpose. It's still a problem if you need e.g. the Character Studio animation curves from Max (instead of it exporting keyframes and you perhaps choosing to fit a curve back onto them) which the exporter doesn't do (because they're too non-standard). At least the exporter is open source and it might be feasible to hack new features in yourself, but it's annoying if you have to do that.
What's the benefit of it over.X for example?
Does
Re:Mentioning that you were involved with VRML...
on
Collada
·
· Score: 1
Who, exactly, do they think is going to use this besides amateurs and little tools companies (like the ones linked to in the article) who cater to amateurs...?
XML provides more than just a way of serialising a tree into text - I've not looked into the details very far, but what I've seen is that COLLADA uses XML Schema for validation, URIs for references between different locations (e.g. defining a piece of geometry, then adding several instances of it into a scene definition - and then changing it into an external URI if you don't want everything in the same file, or if you want to point to binary data instead of more XML, and having the standard XML tools deal with that correctly), and you can stick custom bits of XML into certain extension points (which standard tools can't parse but can pass along unchanged for later tools). You could do all that without XML, but the designers decided it would be more successful if they did use it.
If your artists can export a model from 3ds Max, load it into FX Composer and tweak the shaders to make it look good, load it into a physics simulator to make sure it reacts sensibly, then have it converted into the optimised native format for whatever engine you're using - and if you're no longer constrained in choice of tools (maybe you want to change from Max to Maya, or support a modding community with Blender, or load assets from your last game into your new engine) because they all support the same standard format, and you don't have to write all the code yourself - then it seems like it can have a practical benefit. I'm sure it doesn't work perfectly in practice, and it's not going to give groundbreaking improvements to the game development process, but it appears to go a long way in the right direction and it looks like it's gaining some real support.
Re:Mentioning that you were involved with VRML...
on
Collada
·
· Score: 1
It does support skinning - I've actually just finished writing a converter from COLLADA into a custom format for a game (since COLLADA is not suited (nor designed) as a final format for distribution to users; it's for interchange between development tools where efficiency isn't so critical), and that handles skeletal animations using the standard features with no need for extensions. There are importers/exporters here for Max and Maya, here for Blender, elsewhere for others. It's also the native format for Google SketchUp / Google Earth models. The list here has Ogre and Unreal Engine as supporting it too, and it's a "Standard part of the PS3 toolchain" (source (PDF)) - so it is being used for real in games.
Re:One main contributor not mentioned...
on
Collada
·
· Score: 1
To be specific, Feeling Software's exporters (ColladaMax, ColladaMaya) and their COLLADA manipulation library (FCollada) are under the MIT licence. The development process isn't particularly open (their Bugzilla is, but their code repository isn't and you have to just wait until the next official release to get any new fixes), but that hasn't been a problem for me in practice - I've had to make some local changes to get FCollada compiling on Linux, but it's easy to do that and to distribute patches since it's open source.
An interative javascript debugger, that includes the ability to run scripts in a 'step mode', override/block the execution of specific js statements (or force conditional branches), and change the contents of variables.
Have you tried Venkman? That does stepping and lets you change variables, though I don't think it helps with your second point. There's also FireBug, as a lighter-weight way to set breakpoints and step through code.
Full SVG support, integrated and sorted (should have been done before)
"Full SVG" doesn't make it entirely clear what you want, given the different versions and profiles. Most web browser developers seem to dislike the recent SVG Tiny 1.2, because its design is unsuitable for the web. Mozilla already has bloat problems with their SVG implementation (partly their fault, partly because the spec is large and complex), and some developers want a simpler SVG because most people don't actually need SVG - they just want proper scalable images in web pages. (The same applies for wanting animated PNGs, but not needing MNG). None of that is an excuse for bugs or missing features in what they've already decided to try to implement, though.
Whole page zoom seems to be an area where Firefox is falling behind at the moment - as far as I can see, the plan is to do that for Firefox 3 (which has a new graphics system) some time next year. I believe that new graphics system will let them do nicer image resizing too.
Firefox 2 has added a "Recently Closed Tabs" list in the History menu. It might not work as well as a sorted view of the whole history panel, if you want to get back a tab that you closed hours ago and it's fallen off the bottom of the list; but it's good if you realise soon after you accidentally close it.
In non-visual media, and in visual media with scripting disabled, the canvas element should be treated as an ordinary block-level element and the fallback content should therefore be used instead.
which sounds like what you want. Unfortunately Mozilla hasn't implemented that behaviour, which is a bug (https://bugzilla.mozilla.org/show_bug.cgi?id=3025 66) that ought to be fixed. (I guess you could get the right behaviour by creating the canvas element in script and adding it to the DOM, but that would be kind of nasty.)
The spec also says that authors should provide alternate content that "conveys essentially the same function or purpose as the bitmap canvas" and also "should not use the canvas element in a document when a more suitable element is available. For example, it is inappropriate to use a canvas element to render a page heading". I can't think how else they'd encourage the use of alternate content, but it'd be interesting to see any ideas of how to help overcome the laziness of authors. Chrome-spoofing (assuming you mean making canvas content that looks like part of the web browser) is usually no different to the issues caused by normal images, except that the drawWindow method (a Mozilla extension (not added through the proper extension mechanism, which isn't terribly polite of them – Opera has done it more properly)) would let scripts read the pixels from e.g. form buttons and work out what theme you're using – so that's currently limited to being run by JS code in extensions and it can't be used by web content, to avoid the security issues.
And SVG does seem a generally better way of doing vector graphics than canvas+JS; but it's worse at dynamic bitmap graphics, which is why both exist:-)
It's a roughly similar situation to <img> and <object> – you lose out on accessibility and on the ability to work in the widest possible range of browsers, but there are sensible fallbacks so you can provide an alternative implementation for those who can't see it. If a web developer doesn't want to provide an alternative implementation, then it's no worse than if they used Flash or AJAX or image maps or table layouts or 7pt font sizes and didn't care about everyone who couldn't see it properly. For those who do care about separating content and presentation, it's not much worse than img – all you need is <canvas id="dynamic_interactive_graph"><img src="static_graph_fallback.png" alt="Graph of global warming increasing as number of pirates decreases"></canvas> with the canvas scripting code split into a separate file in the same way that the static image data is split into a separate file.
Given that the canvas tag is already supported in three browsers (who agreed it was worth implementing) and has a written specification, it's a sign of much more cooperation than existed in the time of Netscape vs Microsoft.
Instead of ftp.mozilla.org, try the mirror page – currently it seems to list beta 1, but you should be able to modify the download URL to get the en-US beta 2.
One small area that has had a reasonable amount of improvement in Firefox 2 is canvas support – I've been working on a canvas-based FPS engine and get about 50% better performance in FF2 than in FF1.5, as well as lots of fixed bugs and memory leaks.
Most major changes (like the new graphics infrastructure that'll help provide hardware accelerated rendering, full-page zooming, HTML inside SVG, better printing, etc) are being left for Firefox 3, but FF2 seems like a solid improvement over the previous version.
The canvas is actually a nice example of progress on the web. After too many years with very little going on, the major modern browsers developers (Mozilla, Opera, Apple) are working in the WHATWG to add new features – it's a balance between proprietary extensions and W3C-style specifications, with browsers implementing features at the same time as the spec is being written and guiding its development. There's room for competition between browsers in terms of feature support, and we don't have to wait years for the standards to be completed first – but it's hopefully without the old problems of those features being proprietary and poorly designed. For example, Opera 9 supports much of Web Forms 2.0 and the Mozilla developers are just starting work on it too; and it's also designed to be backward-compatible, so the new forms are still usable in all browsers and can be emulated in some (e.g. IE) with JavaScript. Firefox 2 seems to be the first browser with client-side session and persistent storage, but web sites written to benefit from that feature will be able to immediately work with future versions of e.g. Opera that support it too.
With the popularity of trends like AJAX encouraging people to think about new ways to interact with users over the web, and browsers adding features to expand the possibilities open to web developers, it'll be interesting to see what happens in the next few years.
Re:Who are they hiding the features from?
on
Marketing Mozilla
·
· Score: 5, Informative
They're not hiding details from anybody, although they're also not widely publicising details to those who aren't interested in trying out pre-release software – the beta 1 release notes include a summary of new features, and there's more information for developers on how to use the features. (Beta 2 is expected for tomorrow and is primarily bug fixes; there won't be any significant changes to the feature set until Firefox 3, which seems to be the real major release.)
From the release notes:
Built in Phishing Protection.
Search suggestions now appear with search history in the search box for Google, Yahoo! and Answers.com
Changes to tabbed browsing behavior
Ability to re-open accidentally closed tabs
Better support for previewing and subscribing to web feeds
Inline spell checking in text boxes
Search plugin manager for removing and re-ordering search engines
New microsummaries feature for bookmarks
Automatic restoration of your browsing session if there is a crash
New combined and improved Add-Ons manager for extensions and themes
New Windows installer based on Nullsoft Scriptable Install System
Support for JavaScript 1.7
Support for client-side session and persistent storage
Extended search plugin format
Updates to the extension system to provide enhanced security and to allow for easier localization of extensions
Support for SVG text using svg:textPath
Features like phishing protection were actually announced for IE7 over a year ago, but it seems that Firefox will be the first to ship with them. (Firefox also defaults to an implementation that better protects your privacy than IE, using an automatically-updated blacklist of sites instead of sending every URL you visit to a web service run by a company you may or may not trust.)
Gordon at this time was working on a memory bank for EDSAC, which was several tubes about 6ft long 1" diameter 1/8" wall, filled with mercury and a crystal at each end. (What would health and safety say now to the mercury globules in the floorboards?)
I've never experienced that problem. Sometimes (maybe once every few months) it disappears immediately after I suspend-to-RAM then resume my PC, so I have to unplug it and put it back, but it hasn't ever done that while I've been using my computer.
Right now, I actually have it plugged in to the PS/2 port instead of the USB – if you've still got the mouse (and the USB->PS/2 adapter), and don't mind losing some of the less useful buttons, perhaps you could try that. Not exactly a proper solution, though.
I've got an MX1000 (which is really quite nice, and I even use it left-handed) which recharges when you stick it in the base station. The only problem is that I now have two cables, where a wired mouse would have one – there's the USB from the base station to the computer, plus a power cable from the wall to the base station. It doesn't help the tangled-cables-under-the-desk problem at all. But it's far more practical than a wired mouse for clubbing people on the head.
Acid2? The most irrelevant web standards test ever devised?
It's "irrelevant" only for IE7, because IE6 was so far behind that Microsoft still hasn't been able to catch up. For browsers that are already quite good at CSS, and web developers who are targeting those browsers, it helps to provide a valuable step up in standards compliance.
The Acid2 test is using real specified features that have some value to web developers, else they wouldn't even be in the CSS spec. It's certainly not the best test case to help the people who are trying to implement the features, because everything is mixed together and each feature is tested only a couple of times - but it provides the general public with a visible way to follow a significant part of the browsers' increasing standards compliance, which motivates the browser developers to fix their standards-compliance issues.
We should be happy that Microsoft is fixing IE6 bugs, and that they are starting with the most widespread and problematic ones instead of worrying about a single high-visibility test that is worthless if the more basic parts of CSS are not well supported. That's what they should be doing given their situation, and the IE developers should be thanked for the progress they've been making in that area. But it doesn't change the fact that IE7 has a worse implementation of standards than other major browsers, nor the idea that IE is holding back progress on the web.
Mac users would benefit if PC users were able to run a virtualised OS X.
VMware says "software developers" are one of the primary targets of their Workstation product, and web developers are a part of that. Web sites are naturally quite portable, so you can test in IE and Firefox and Opera under Windows and just hope that it is good enough in Safari. There's not enough reason to go out and buy a Mac to test your web site, because it's expensive and your site probably works 'okay' anyway. But that means Mac users visiting your site in Safari will see an untested and imperfect design – it should still be usable, but lacking the polish that was given to other browsers.
If it were possible to download a VMware-compatible copy of OS X that provides the web browser and development tools, even if it's locked into running inside VMware and is stripped down so as to not compete with the full Mac desktop experience, those web developers would have the ability to easily and cheaply test their sites in every operating system and every web browser.
This is particularly important now that most browsers work well on the current web standards, and are beginning to move on to new features and restore some innovation in the browser space – for example, the HTML canvas is something that's emerging as a widely-supported feature, but it's sufficiently new and experimental that every browser has quirks in its implementation. By making it easy and cheap for developers to test their sites under Safari on OS X, Apple can help them understand its quirks and support it to the same level as any other browser and any other OS.
Uh, sorry, that's what I get for posting at 3am and not bothering to check the equations and units. But I got the expected answer and it was dimensionally consistent, even if the intermediate calculations were rubbish. Isn't that what physics is all about?
A more correct version:
Density of tungsten: 19250 kg/m^3
Mass of 8cm-wide sphere: density * volume = 19250 kg/m^3 * (4/3 * pi * (4cm)^3) = 5.2 kg
Gravitational acceleration of negligible-mass object towards mass M at distance r: a = GM/r^2 = G * 5.2kg / (10cm)^2 = 3.4e-8 m s^-2
Acceleration of object rotating in a circle at speed w and distance r: a = r w^2
Hence a = 10cm w^2 = 3.4e-8 m s^-2, so w = 0.0006 s^-1 (radians per second)
0.0006 rad/sec = 19000 rad/year = 2950 orbits per year.
Density of tungsten: 19250 kg/m^3
Mass of 8cm-wide sphere: density * volume = 19250 kg/m^3 * (4/3 * pi * (4cm)^3) = 5.2 kg
Gravitational acceleration of negligible-mass object towards mass M at distance r: a = GM/r = G * 5.2kg / 10cm = 3.4e-9 m^2 s^-2
Acceleration of object rotating in a circle at speed w and distance r: a = r^2 w^2
Hence a = (10cm)^2 w^2 = 3.4e-9 m^s s^-2, so w = 0.0006 s^-1 (radians per second)
0.0006 rad/sec = 19000 rad/year = 2950 orbits per year. Which is about 3000, as they say.
These "$product-killer" descriptions remind me of book blurbs that always say things like "I know nothing comparable to it except The Lord of the Rings". It says very little about the book they're trying to sell - but it says a lot about the book it is being compared to.
one of the big goals of a lot of open source games is to be able to run on older hardware. This isn't necessarily a bad thing, but it does mean that it limits the quality of the artwork. Many commercial games are released when even a top-of-the-line gaming rig can barely get top performance, while many open source games tend to be written to run on any machine built in the last 5 or 6 years.
Five years ago saw the GeForce 3 (although admittedly as the high end, not "any machine"), which is perfectly capable of making good-looking games as long as you rely on decent art rather than just adding HDR and bloom and bump-mapping and specular highlights and hoping it'll look good - we've had some reasonable success using none of those features. Currently the only pixel shader in the game is for high-end water, and we have an equivalent effect for GF3/4s; pretty much everything else is just a plain texture map. You can even run modern games like Oblivion on a GeForce 3 and it looks good (though it doesn't run quite so smoothly).
It is a bit harder if you want to support the common integrated graphics chips with limited memory and processing power - but I'd tend to blame ugly games on bad art instead of a bad graphics engine. Anyone can download OGRE and set up a rendering system with modern features, but artists are much harder to find - contributions from people like you can make a big difference (at least when the programmers are happy to accept it)!
It is squarely intended at the hobby coder who wants to work on what the book calls "desktop games" -- not the multi-million dollar multimedia productions that demand a new graphics card every half year, but the games that you play while thinking out a knotty problem or that have some educational value for your kids. The kind of project a single coder, or a small team can complete and maintain while still staying sane.
That seems like pretty sensible advice - the phrase "game development" immediately brings to mind the big successful commercial games, but that's not the area in which open source seems capable of competing, and it is much more productive to realise that simple games can be more worthwhile to make.
As for why open source game development has problems when trying to emulate commercial game development, there was some discussion a while back; shamelessly reposting my comment from there:
there are hundreds or thousands of GPL game projects on SourceForge, and most of them are dead
Perhaps the open source idea of havings thousands of eyes, and encouraging anybody to jump in and out of the code making changes, is incompatible with the process of creating a game?
I don't know of any open source applications that are "finished", or even try to be - their early releases are at least slightly useful, and they are always releasing new versions and adding new features. And there always are new features that can be added, each of which will improve the application, so people can work on their favourite features and the project will continue on its path of continual improvement.
Traditional games don't work like that. They're barely recognisable as a game for a large part of their development time - during that time, there has to be a vision for the finished product, and everybody on the project has to work towards that distant vision. It'll be years before anybody can really see the results of their work. That's not very enticing for somebody who can only be certain of spare time for the next couple of months - they would rather work on something much smaller, like a mod or a tech demo, just to get visible results.
And unlike most open source projects, people can't just add features they think are cool and useful - everything has to fit into the overall design of the game. You cannot simply add features without considering the consequences on the whole of the rest of the game - and you can't consider all the consequences unless you've already spent months working on the game and getting a feel for how everything interacts.
For professional game development companies, they get people working towards the vision by simply paying them to do so. That won't work for community-based open source projects, so they need some other way of doing it.
But I don't know what way that would be. I've been working on a "freeware, hobbyist" game instead (0 A.D.), which is a full 3D RTS with its own game engine, comparable in scope to commercial games (or at least to those of a few years ago) - it's making use of various open source libraries (SpiderMonkey, Vorbis, Xerces, etc), but is not itself open source. And I think that's a factor in how it has kept going for so long: 'membership' is still open to anyone who has the right abilities and dedication, but that means there is a strong concept of membership - we're part of a team and feel some responsibility towards making progress, following the design, and seeing the game through until it's finished. I don't think that feeling would be as strong if we were primarily a loose community of people who are just poking around the code with no commitment, which is how I perceive most open source projects.
Slashdot Mirror
My name too. I've actually still got the certificate, dated 14 February 1998.
I did do what they suggested - but given the fate of the Mars Polar Lander, I'd want to think carefully before signing up for a future mission.
I've only been working on amateur game development, where all the people are spread around the world and have different tools and there isn't really a traditional art pipeline. Batch conversion doesn't seem as suitable if everyone would have to download hundreds of megabytes over the internet each time the converted data changes, which is why we [are planning to, in the next few weeks] distribute just the COLLADA files to the people involved in development, and their copy of the game automatically converts and caches any changed files at load-time (so there's still the benefit of loading faster, all but the first time). If the converter is changed and every file has to be reprocessed, it'll take longer for each person when they next load the game, but it's still much quicker than having to download the result of a batch conversion process, and it still all happens transparently with no user intervention. It also lets the artists export a file and see it in the game almost immediately, with no manual steps and without us having to spend time on our own modelling program plugins. I expect it would be different if we could build all the data on one machine and send it over a LAN for everyone to load, and if we could afford development of better-integrated art tools, but this way seems to be the best we've found for our situation.
(When the game is eventually released it'll just have the already-converted fast binary files, so the COLLADA loading time and size are only relevant during development.)
It's not good, but it's not quite as bad as one could imagine. Most of space in COLLADA is not XML tags - it's the lists of numbers (arrays of coordinates, indexes into arrays, etc), and those tend to be what increase when you get millions of vertices. The coordinate data for a very small object looks like:
That list of numbers increases in size as the mesh gets more complex, but the XML is only an additive constant overhead per object. Storing numbers as strings is a constant factor, but it's not too horrendous - that example uses 588 bytes for 78 numbers, which is 7.5 bytes per number, and it'd be more like 9.5 bytes without the easily compressed 0s, so it's only about twice as much space as storing 32-bit floats (with about the same precision), which isn't quite "balloon[ing] amazingly" in size.
But it does hurt more in terms of loading time. With a 2.5MB 25K-poly skinned mesh [not a sensible mesh - I just tessellated a small one], it takes me about 200msec to parse the XML (using FCollada) and 150ms to process all the data (converting it into the game's binary format, which is actually 4MB of output but should be a third of that once I stop doing it so inefficiently), and I expect it could be quite a bit faster if it didn't have to parse XML. But our game engine only does that conversion once, and caches the binary version so it's much faster when you load the game a second time after modifying some data. That caching does require a bit more work, but it avoids the issue of slowly loading hundreds of megabytes of XML every time you start the program up, while still letting people export COLLADA files and have the game pick it up automatically - it seems to work well in practice at keeping the loading times sensible.
(The only real reason we're using COLLADA at all is that it's easier than writing our own exporter, particularly since we want to support Blender (to a limited extent) as well as 3ds Max - the fact that it's XML doesn't really matter, but if being XML has helped it gain some interoperability between tools then it seems to be worthwhile.)
I doubt anyone would ship it, since it's not suitable for that. I can't find any details of how UE3 actually uses it, so I couldn't do more than conjecture - and most other game developers also appear to keep quite quiet about what technology they're using (at least in public). I've not heard of any other games that have been released yet and are using COLLADA - they claim that "active users" include "THQ, EA, Konami, NCsoft, DoubleFine, Rockstar", but presumably the relevant games are still under development. COLLADA itself is pretty recent, so I guess it'll be a few years before anyone can really tell whether it has survived and found a place in the industry.
You certainly don't need XML - but it does those things already, and it's already understood and supported well enough that you could write a quick Python script to read a model and manipulate the DOM and spit it back out again, which saves some effort compared to writing yet more binary importers/exporters for every tool that has to process the file. There's obviously drawbacks to using XML, but it's not as obvious whether they outweigh the benefits.
XSI mentions it in one of the main features. (They also mention the dotXSI "standard" - it looks like every modelling program has its own proprietary standard for interoperability... COLLADA is the only one I've seen that's somewhat vendor-neutral (but still flexible enough to handle at least some kinds of real data) - I've heard that Sony saw that the vendors themselves would never agree on any neutral standard, which is why they (as people who want to improve the game development process, rather than push their own tools) had to make one themselves.)
I tried a simple test with ColladaMax, with a sphere and two sets of bones and two Skin modifiers. It exports a scene with a Sphere01-node, using the Sphere01-mesh-skin-skin controller with the Bone05-node skeleton. The scene also contains the hierarchy of bones. It says Sphere01-mesh-skin-skin is skinning the Sphere01-mesh-skin object, and lists the relevant bones and the weights and bind pose matrices and things. It says Sphere01-mesh-skin is skinning the Sphere01-mesh object, and gives more weights and things. And it says Sphere01-mesh is a mesh with certain vertex data. (Incidentally, one advantage of XML is that I can actually look at the file in a text editor and see that reasonably complex hierarchy - the actual geometry data is a horrible mass of numbers, but for small scenes it's quite easy to see what's going on. You could make a visualisation tool for any other non-XML format, but it's helpful if there's no need.)
That seems to be fairly close to how it's represented in Max itself. Then you can (/have to) write your own code that loads that COLLADA file (using existing libraries to handle the boring standard bits), and do whatever conversions you want for your particular purpose. It's still a problem if you need e.g. the Character Studio animation curves from Max (instead of it exporting keyframes and you perhaps choosing to fit a curve back onto them) which the exporter doesn't do (because they're too non-standard). At least the exporter is open source and it might be feasible to hack new features in yourself, but it's annoying if you have to do that.
Does
Sony (PS3 SDK). Epic (Unreal Engine 3). Nvidia (FX Composer). AGEIA (physics).
XML provides more than just a way of serialising a tree into text - I've not looked into the details very far, but what I've seen is that COLLADA uses XML Schema for validation, URIs for references between different locations (e.g. defining a piece of geometry, then adding several instances of it into a scene definition - and then changing it into an external URI if you don't want everything in the same file, or if you want to point to binary data instead of more XML, and having the standard XML tools deal with that correctly), and you can stick custom bits of XML into certain extension points (which standard tools can't parse but can pass along unchanged for later tools). You could do all that without XML, but the designers decided it would be more successful if they did use it.
If your artists can export a model from 3ds Max, load it into FX Composer and tweak the shaders to make it look good, load it into a physics simulator to make sure it reacts sensibly, then have it converted into the optimised native format for whatever engine you're using - and if you're no longer constrained in choice of tools (maybe you want to change from Max to Maya, or support a modding community with Blender, or load assets from your last game into your new engine) because they all support the same standard format, and you don't have to write all the code yourself - then it seems like it can have a practical benefit. I'm sure it doesn't work perfectly in practice, and it's not going to give groundbreaking improvements to the game development process, but it appears to go a long way in the right direction and it looks like it's gaining some real support.
It does support skinning - I've actually just finished writing a converter from COLLADA into a custom format for a game (since COLLADA is not suited (nor designed) as a final format for distribution to users; it's for interchange between development tools where efficiency isn't so critical), and that handles skeletal animations using the standard features with no need for extensions. There are importers/exporters here for Max and Maya, here for Blender, elsewhere for others. It's also the native format for Google SketchUp / Google Earth models. The list here has Ogre and Unreal Engine as supporting it too, and it's a "Standard part of the PS3 toolchain" (source (PDF)) - so it is being used for real in games.
To be specific, Feeling Software's exporters (ColladaMax, ColladaMaya) and their COLLADA manipulation library (FCollada) are under the MIT licence. The development process isn't particularly open (their Bugzilla is, but their code repository isn't and you have to just wait until the next official release to get any new fixes), but that hasn't been a problem for me in practice - I've had to make some local changes to get FCollada compiling on Linux, but it's easy to do that and to distribute patches since it's open source.
An alternative to FCollada is the COLLADA DOM library, under the SCEA Shared Source License, which is similarly open.
Have you tried Venkman? That does stepping and lets you change variables, though I don't think it helps with your second point. There's also FireBug, as a lighter-weight way to set breakpoints and step through code.
"Full SVG" doesn't make it entirely clear what you want, given the different versions and profiles. Most web browser developers seem to dislike the recent SVG Tiny 1.2, because its design is unsuitable for the web. Mozilla already has bloat problems with their SVG implementation (partly their fault, partly because the spec is large and complex), and some developers want a simpler SVG because most people don't actually need SVG - they just want proper scalable images in web pages. (The same applies for wanting animated PNGs, but not needing MNG). None of that is an excuse for bugs or missing features in what they've already decided to try to implement, though.
Whole page zoom seems to be an area where Firefox is falling behind at the moment - as far as I can see, the plan is to do that for Firefox 3 (which has a new graphics system) some time next year. I believe that new graphics system will let them do nicer image resizing too.
Firefox 2 has added a "Recently Closed Tabs" list in the History menu. It might not work as well as a sorted view of the whole history panel, if you want to get back a tab that you closed hours ago and it's fallen off the bottom of the list; but it's good if you realise soon after you accidentally close it.
The spec states:
which sounds like what you want. Unfortunately Mozilla hasn't implemented that behaviour, which is a bug (https://bugzilla.mozilla.org/show_bug.cgi?id=3025 66) that ought to be fixed. (I guess you could get the right behaviour by creating the canvas element in script and adding it to the DOM, but that would be kind of nasty.)
The spec also says that authors should provide alternate content that "conveys essentially the same function or purpose as the bitmap canvas" and also "should not use the canvas element in a document when a more suitable element is available. For example, it is inappropriate to use a canvas element to render a page heading". I can't think how else they'd encourage the use of alternate content, but it'd be interesting to see any ideas of how to help overcome the laziness of authors. Chrome-spoofing (assuming you mean making canvas content that looks like part of the web browser) is usually no different to the issues caused by normal images, except that the drawWindow method (a Mozilla extension (not added through the proper extension mechanism, which isn't terribly polite of them – Opera has done it more properly)) would let scripts read the pixels from e.g. form buttons and work out what theme you're using – so that's currently limited to being run by JS code in extensions and it can't be used by web content, to avoid the security issues.
And SVG does seem a generally better way of doing vector graphics than canvas+JS; but it's worse at dynamic bitmap graphics, which is why both exist :-)
It's a roughly similar situation to <img> and <object> – you lose out on accessibility and on the ability to work in the widest possible range of browsers, but there are sensible fallbacks so you can provide an alternative implementation for those who can't see it. If a web developer doesn't want to provide an alternative implementation, then it's no worse than if they used Flash or AJAX or image maps or table layouts or 7pt font sizes and didn't care about everyone who couldn't see it properly. For those who do care about separating content and presentation, it's not much worse than img – all you need is <canvas id="dynamic_interactive_graph"><img src="static_graph_fallback.png" alt="Graph of global warming increasing as number of pirates decreases"></canvas> with the canvas scripting code split into a separate file in the same way that the static image data is split into a separate file.
Given that the canvas tag is already supported in three browsers (who agreed it was worth implementing) and has a written specification, it's a sign of much more cooperation than existed in the time of Netscape vs Microsoft.
Instead of ftp.mozilla.org, try the mirror page – currently it seems to list beta 1, but you should be able to modify the download URL to get the en-US beta 2.
One small area that has had a reasonable amount of improvement in Firefox 2 is canvas support – I've been working on a canvas-based FPS engine and get about 50% better performance in FF2 than in FF1.5, as well as lots of fixed bugs and memory leaks.
Most major changes (like the new graphics infrastructure that'll help provide hardware accelerated rendering, full-page zooming, HTML inside SVG, better printing, etc) are being left for Firefox 3, but FF2 seems like a solid improvement over the previous version.
The canvas is actually a nice example of progress on the web. After too many years with very little going on, the major modern browsers developers (Mozilla, Opera, Apple) are working in the WHATWG to add new features – it's a balance between proprietary extensions and W3C-style specifications, with browsers implementing features at the same time as the spec is being written and guiding its development. There's room for competition between browsers in terms of feature support, and we don't have to wait years for the standards to be completed first – but it's hopefully without the old problems of those features being proprietary and poorly designed. For example, Opera 9 supports much of Web Forms 2.0 and the Mozilla developers are just starting work on it too; and it's also designed to be backward-compatible, so the new forms are still usable in all browsers and can be emulated in some (e.g. IE) with JavaScript. Firefox 2 seems to be the first browser with client-side session and persistent storage, but web sites written to benefit from that feature will be able to immediately work with future versions of e.g. Opera that support it too.
With the popularity of trends like AJAX encouraging people to think about new ways to interact with users over the web, and browsers adding features to expand the possibilities open to web developers, it'll be interesting to see what happens in the next few years.
They're not hiding details from anybody, although they're also not widely publicising details to those who aren't interested in trying out pre-release software – the beta 1 release notes include a summary of new features, and there's more information for developers on how to use the features. (Beta 2 is expected for tomorrow and is primarily bug fixes; there won't be any significant changes to the feature set until Firefox 3, which seems to be the real major release.)
From the release notes:
Features like phishing protection were actually announced for IE7 over a year ago, but it seems that Firefox will be the first to ship with them. (Firefox also defaults to an implementation that better protects your privacy than IE, using an automatically-updated blacklist of sites instead of sending every URL you visit to a web service run by a company you may or may not trust.)
There were some of them in EDSAC back in 1949.
From reminiscences:
I've never experienced that problem. Sometimes (maybe once every few months) it disappears immediately after I suspend-to-RAM then resume my PC, so I have to unplug it and put it back, but it hasn't ever done that while I've been using my computer.
Right now, I actually have it plugged in to the PS/2 port instead of the USB – if you've still got the mouse (and the USB->PS/2 adapter), and don't mind losing some of the less useful buttons, perhaps you could try that. Not exactly a proper solution, though.
I've got an MX1000 (which is really quite nice, and I even use it left-handed) which recharges when you stick it in the base station. The only problem is that I now have two cables, where a wired mouse would have one – there's the USB from the base station to the computer, plus a power cable from the wall to the base station. It doesn't help the tangled-cables-under-the-desk problem at all. But it's far more practical than a wired mouse for clubbing people on the head.
It's "irrelevant" only for IE7, because IE6 was so far behind that Microsoft still hasn't been able to catch up. For browsers that are already quite good at CSS, and web developers who are targeting those browsers, it helps to provide a valuable step up in standards compliance.
The Acid2 test is using real specified features that have some value to web developers, else they wouldn't even be in the CSS spec. It's certainly not the best test case to help the people who are trying to implement the features, because everything is mixed together and each feature is tested only a couple of times - but it provides the general public with a visible way to follow a significant part of the browsers' increasing standards compliance, which motivates the browser developers to fix their standards-compliance issues.
We should be happy that Microsoft is fixing IE6 bugs, and that they are starting with the most widespread and problematic ones instead of worrying about a single high-visibility test that is worthless if the more basic parts of CSS are not well supported. That's what they should be doing given their situation, and the IE developers should be thanked for the progress they've been making in that area. But it doesn't change the fact that IE7 has a worse implementation of standards than other major browsers, nor the idea that IE is holding back progress on the web.
Mac users would benefit if PC users were able to run a virtualised OS X.
VMware says "software developers" are one of the primary targets of their Workstation product, and web developers are a part of that. Web sites are naturally quite portable, so you can test in IE and Firefox and Opera under Windows and just hope that it is good enough in Safari. There's not enough reason to go out and buy a Mac to test your web site, because it's expensive and your site probably works 'okay' anyway. But that means Mac users visiting your site in Safari will see an untested and imperfect design – it should still be usable, but lacking the polish that was given to other browsers.
If it were possible to download a VMware-compatible copy of OS X that provides the web browser and development tools, even if it's locked into running inside VMware and is stripped down so as to not compete with the full Mac desktop experience, those web developers would have the ability to easily and cheaply test their sites in every operating system and every web browser.
This is particularly important now that most browsers work well on the current web standards, and are beginning to move on to new features and restore some innovation in the browser space – for example, the HTML canvas is something that's emerging as a widely-supported feature, but it's sufficiently new and experimental that every browser has quirks in its implementation. By making it easy and cheap for developers to test their sites under Safari on OS X, Apple can help them understand its quirks and support it to the same level as any other browser and any other OS.
Uh, sorry, that's what I get for posting at 3am and not bothering to check the equations and units. But I got the expected answer and it was dimensionally consistent, even if the intermediate calculations were rubbish. Isn't that what physics is all about?
A more correct version:
Density of tungsten: 19250 kg/m^3
Mass of 8cm-wide sphere: density * volume = 19250 kg/m^3 * (4/3 * pi * (4cm)^3) = 5.2 kg
Gravitational acceleration of negligible-mass object towards mass M at distance r: a = GM/r^2 = G * 5.2kg / (10cm)^2 = 3.4e-8 m s^-2
Acceleration of object rotating in a circle at speed w and distance r: a = r w^2
Hence a = 10cm w^2 = 3.4e-8 m s^-2, so w = 0.0006 s^-1 (radians per second)
0.0006 rad/sec = 19000 rad/year = 2950 orbits per year.
Density of tungsten: 19250 kg/m^3
Mass of 8cm-wide sphere: density * volume = 19250 kg/m^3 * (4/3 * pi * (4cm)^3) = 5.2 kg
Gravitational acceleration of negligible-mass object towards mass M at distance r: a = GM/r = G * 5.2kg / 10cm = 3.4e-9 m^2 s^-2
Acceleration of object rotating in a circle at speed w and distance r: a = r^2 w^2
Hence a = (10cm)^2 w^2 = 3.4e-9 m^s s^-2, so w = 0.0006 s^-1 (radians per second)
0.0006 rad/sec = 19000 rad/year = 2950 orbits per year. Which is about 3000, as they say.
These "$product-killer" descriptions remind me of book blurbs that always say things like "I know nothing comparable to it except The Lord of the Rings". It says very little about the book they're trying to sell - but it says a lot about the book it is being compared to.
Five years ago saw the GeForce 3 (although admittedly as the high end, not "any machine"), which is perfectly capable of making good-looking games as long as you rely on decent art rather than just adding HDR and bloom and bump-mapping and specular highlights and hoping it'll look good - we've had some reasonable success using none of those features. Currently the only pixel shader in the game is for high-end water, and we have an equivalent effect for GF3/4s; pretty much everything else is just a plain texture map. You can even run modern games like Oblivion on a GeForce 3 and it looks good (though it doesn't run quite so smoothly).
It is a bit harder if you want to support the common integrated graphics chips with limited memory and processing power - but I'd tend to blame ugly games on bad art instead of a bad graphics engine. Anyone can download OGRE and set up a rendering system with modern features, but artists are much harder to find - contributions from people like you can make a big difference (at least when the programmers are happy to accept it)!
That seems like pretty sensible advice - the phrase "game development" immediately brings to mind the big successful commercial games, but that's not the area in which open source seems capable of competing, and it is much more productive to realise that simple games can be more worthwhile to make.
As for why open source game development has problems when trying to emulate commercial game development, there was some discussion a while back; shamelessly reposting my comment from there: