It still shows that you're living a fairly long way in the Java past. Java has not had internal bounds checking every array access since the advent of the Hotspot JVMs. Most of the array access checks are optimised away either by the compiler or by the JIT compilation from the hotspot, particularly in places where it matters like tight for loops. Random access are still checked some of the time, but anything that is performance critical, those checks are discarded by the JVM well before they become a performance issue.
I'm not acknowledging any performance hits at the UI level because, quite frankly, none of our users or our clients see them. In fact, many of our clients are surprised that the code has been written in Java. Sure, anyone can code a crappy UI, and with Swing it's incredibly easy to do so (in fact, seems to be the default way that it's implemented), but with a very small amount of attention to detail, they perform just as good as any other language. With some of the Java 6 work where it is using OpenGL under the covers for all the 2D rendering, it is a heck of a lot faster too than a lot of the Vista crap that we've seen.
Where we have seen performance hits in the past is in very heavy array/pointer access code such as that used in image decoding. In fact we wrote our own native code wrappers to get around this problem. However, starting with Java 5 and now 6, the supplied JVM image decoding is even faster than our light wrappers around libjpeg/libpng etc.
One of the reasons why you don't see Java3D in games is that it has some serious internal architecture issues. The absolute primary one that killed it for our customers is that If you use a behaviour to set a transform and a geometry (vertex) change in the same frame, the geometry update appear rendered one frame before the transform takes effect. When we've pressed them about that, the Sun engineers have never seen this as a critical problem! Now, try writing a high-performance game in an environment that acts like that.
You're almost correct on the surface management side. For the most part, the JVM does manage it, but there are times where you have to do explicit management, and there are API calls to do this as part of the JAWT bridge library. One of the libraries I work heavily with is JOGL, and specifically the SWT port of JOGL, so I'm (unfortunately) more than a little aware of the surface locking protocols that one needs to go through. However, the only people that ever have to worry about this are those of us that implement native heavyweight renderers, such as JOGL. There's a lot of platform-specific surface locking going on under the covers - X11 code locks and unlocks surfaces at different times to Win32 or OSX, for example. You need to lock the surface for doing things like context management. makeCurrent() can't just be made at any random time, even though JOGL lets you do that, there's a whole raft of code under the covers that takes care of all the timing issues involved that you normally would have to deal with in a native code version of the same thing.
I have plenty of examples for you where our Java code is not only faster than competitors written in C or C++, but the margin of speed differences are double or greater. This is implementing open standards development work, so we're all playing on the same page, not comparing different game engines or so forth. In fact, our scene graph APIs are more than twice as fast as Java3D for the same content and typically 10+% faster than native-code based scenegraphs like OpenSceneGraph. Take a look at the j3d.org site or anything involving Xj3D.
Java is more than fast enough for full graphics. FWIW, I do high end scientific, medical visualisation and a fair amount of military work on the side. The places where highly optimised code for the task at hand is the order of the day.
In a previous life, I did a lot of work on major structural repairs to composite fibre airframe structures - and more specifically on sailplanes. I had several qualifications for inspection and maintenance on them, and worked in a shop that did everything up to and including spar repairs. There's actually less requirements for inspections on any form of composite structure than metal or wooden frame. And when there was inspections, it was much simpler. For example, the spar is tested simply by taking two identical tuning forks, placing one on one end of the spar, ringing the second one, placing it on the other end of the spar. If the other one rang in sympathy, things were fine. The wing surface itself is very easily checked for delamination by simply tapping and listening. When you're more experienced, you can feel it in the way your tapping object responds to the impact. That's far easier that some of the x-ray type inspections we had to do on the metal aircraft. That sort of level of inspection was only done once a year, or every 200 hours, whichever came first. Given the rest of the aircraft industry inspection schedules, I highly doubt that anything will change for the 787.
You are correct that microfine stress fractures are impossible to see in a pure carbon structure. To work around that, every object has a very fine fibreglass layer (070 or thinner) on the outside surface. When stress is applied, the fibreglass shows the stress marks and you can then visually see that something is wrong.
The biggest issue with C/f structures is design life. At the time when I was last working in the industry (mid 90's), they weren't even sure what the maximum life was. There was no data anywhere in the world. The sailplane factories were stating that 10K hours was the minimum and they would test after that (metal airframes were 30K hours before EoL). There were studies being done at Melbourne's RMIT (Australia). The last I heard there was they got to 17K hours before failure of one wing. Given the absurd number of hours a commercial airliner does compared to a sailplane, I would hope and expect that they have done some lifetime studies beyond that. I haven't yet seen any numbers from Boeing about expected airframe life for their pure composite structures.
That is compensated for by averaging. If there is an unsafe driver, a suicidal driver, or even a deliberate lying broadcaster, he gets averaged out. ( Actually the process is a tad more complex. A mode value calculation removes the freaks. Compare that to the average, and you know if there is a freak. )
You are way overthinking the problem. Look up the Byzantine Generals Problem. It is solved for you right there and has been for decades.
Rounding, in the end has no adverse effects on the cost of living. They did that in Oz about 10 years ago and removed the copper coins completely. Smallest value is now 5c. Everything gets rounded such that totals ending in 1, 2, 6 and 7 round down, 3, 4, 8 and 9 round up. Everything is still priced normally and the rounding only applies to the total, not individual items - with the extra proviso that it only applies to cash transactions. Electronic (cheques basically don't exist in Oz anymore) transactions are still the normal non-rounded price.
As a result, on average, you are no different. If you're at the point where a 2c increase is effecting your cost of living then you probably have a lot of other things to worry about before that.
What you need to implement is org.xml.sax.EntityResolver. There's several methods that need to be implemented that are the different ways the SAX parser could query for stuff. Basically it will give you the Public ID and/or System ID and ask you to return a stream to what that resolves to. Then, in your code, all you do is run a hashmap that maps a given ID to a local resource (eg file or database BLOB) and then do your own stream opening/processing from there.
I attempted to post some example code but seems like that trips the lameness filter:( So, just have a look at the interface. The code required is pretty trivial to implement. If that fails, you should be able to work out my email address from the website address under my profile - send me an email and I'll send you the code we use in one of our projects.
Just replying to your graphics performance point: Have you tried out the JDK 6 graphics performance? They've gone the same way as OS X, Vista and Xgl and now use the native 3D hardware for all rendering operations (in this case it is OpenGL). This has made graphics intensive areas like Swing amazingly fast compared to the previous generations of Java.
This is going to be a negative is for anything based on SWT, which doesn't use the AWT infrastructure, so the Eclipse folks are going to have to get moving on that front or left behind (FWIW, I maintain a port of the OpenGL JSR 231 code to run under SWT so I have a foot in both camps here).
Anyway, other than toolkits and general systems (a Linux based workstation to compile code on, use OpenOffice to write documents, and such) there's not going to be a lot of OSS that will be reusable for the developers since they will be writing software for missile guidance systems and interfacing to hardware not generally available to the public. Some GUI toolkits, maybe, and GCC, of course.
Fortunately, you are wrong on this. The majority of the work that my company does is OSS work for the military and research institutions. Much of the work is sharable between those worlds, and increasingly, commercial entities. One such example is a command and control system for autonomous underwater vehicles. Not only useful to the military, but also to the many different marine research institutes, both privately and publically funded.
We have many other applications that have started in one side of the field or the other as research projects, then with a bit of munging to be useful as a "commericial" application, have ended up being usable by other parties. Another example is a world builder and behavioural analysis program. Build the world from real models, apply agent-based behaviours, then toss it at a large grid computing backend to provided monte-carlo-style analysis of the results. That basic infrastructure has all sorts of uses both commercial and private. Most of them have been originally funded by military development, with the explicit contract provisions that it be made open sourced (typically with no specific license required, but the preference for GPL or LGPL depending on where the code sits in the application stack).
While this sort of business model was a struggle even 2 years ago, things are radically different now. Almost everywhere we go the military types are specifically looking for either open source or open standards. The big change we noticed in that was at I/ITSEC last year. Siggraph this year was also very much along that way. Way too many in the government side of military contract have been bitten by proprietary data and now are actively seeking to free themselves of it.
Cthulu HoroClix is Wizkids. But, as another MechWarrior fan, it's not surprising that they didn't mention much about it. There's not much "new" in the system, just another release coming at the end of next month and Ares. Ares hasn't changed the rules at much, except for the multiple dial setup, unlike the Age of Destruction did. They just made stuff bigger. Most of this is at the noise level for gamers that don't know the systems.
Can you imagine trying to code a java app without netbeans or eclipse or IDEA?
Yes. In the large groups of libraries and apps that I hang around in, vi/emacs or similar text editor use far outweights the IDE crowd. In my own case, I have several multi-hundred thousand line libraries that I develop, all using a combination of text editors and make. Conservative estimate of the main projects totals about 2 million LoC that I actively maintain on a daily basis.
The converse to your statement is true - try managing those huge projects in an IDE. Things like context highlights and suggestions grind the entire IDE to a halt. Netbeans is particularly bad for this and Eclipse isn't that much better. Pulling the largest of my projects into Eclipse can grind my dual core machine with a couple of gigs of ram to a screaming halt. I can easily outtype Eclipse's abilty to respond. It's far more frustrating to use an IDE than it is to use simple text editors that do nothing more than syntax highlighting.
If you want firefox support look for Octaga. They have a pretty decent browser that handles everything thrown at it and has decent performance and spec coverage.
As for your other standards, none of the cover the same ground as X3D. OpenGL is a programming API. SVG is a 2D graphics API to replace flash. DX is the same as OpenGL.
The X3D spec itself is well settled now. Around 2000 we were still mincing over just what the spec should look like. Now we have a formally certified ISO spec and in the process of going through the second set of revisions to add new capabilities (eg compositing, rigid body physics, volume rendering etc). The hype is gone and now it's just people using it for real tasks far away from the populist web.
There's a couple of browsers out there - Flux and Bit Management's Contact are browser plugins that support both VRML and the successor specification called X3D. If you want to play with standalone apps for viewing content, have a look at either our toolkit called Xj3D (if you're a Java-based person) or FreeWRL.
X3D has some pretty good capabilities and there are various projects out there showing far better models than anything you'll find on Google Earth. Have a look at some of the city modeling that Planet9 does. Various other projects around that replicate what Google Earth does with large-scale terrain rendering, city modelling etc.
Disclaimer up front: I am one of the authors of the VRML and X3D specs and have a small OSS company that makes money from these specs.
All scene graphs have some form of limitation. VRML, and it's successor X3D, have a very standard approach of the DAG structure. What is a little unconventional is the curly bracket syntax, which is a holdover from the Open Inventor file format that it originally came from. VRML suffered pretty badly from a lot of browsers doing their own thing and ignoring large chunks of the spec. X3D is fixing that problem by having real conformance tests and being very picky about what a conformant browser is allowed and not allowed to do. And, if I get my way, the browsers will be pretty anal about the content; Anything non-conformant should not display from the start, thus forcing the content creator to fix the problems before it gets out into the wild.
X3D, however, has changed that a lot - you can now use XML to represent the same thing. One of the really nice things about that is that all you have to write is one XSLT and you have instant 3D visualisation of your pre-existing XML encoded content. We're finding that by far the majority of our users of X3D are making use of this capability in industry-specific verticals (CAD visualisation happens to be the first such vertical that we're making some very significant inroads into).
It is true that the hype of VRML really killed it before it could do what it wanted to. However, the acceptance is huge under the radar. X3D in particular is now being required as part of many government standards pushes - particularly in Europe, where the ISO nature of the spec is a major benefit.
If this is written for the US government, remember that they are immune to patent claims. Since the offer came from MA government to pay for someone to develop this, I'm sure the ODF foundation can tweak their offering to fit to the letter of the offer and law such that they too would be immune to any patent shenanigans that MS may try to pull.
I hang around on the ODE mailing lists and I've not seen any mention of this card, or even implementing the Havok/NVidia-SLI style of setup.
The project somewhat stalled for a while as the main developer with write access to the head sort of disappeared. In the last month they've moved to sourceforge, subversion, moved all the old unstable code into the head, and added a wiki. They're pushing very quickly towards a 0.6 release (0.5 has been out for about 2-3 years now). This has caused quite a bit of rejuvination of interest recently, so maybe we'll see something along those lines pop up in the post 0.6 code?
Gah! How many times do I have to keep reminding you not to use the volcanos as your personal trash disposal? Now look what you've done! You've stirred up another Balrog. I ain't gonna deal with this one. Look what happened last time! You can sort this one out for yourself!
Bah, I'm going on holiday. Say, where did those little ones go? I could do with some more weed. Helps relax you know....
Re:"workstation cards" what r they 4?
on
ATI's 1GB Video Card
·
· Score: 3, Interesting
I work a lot with the visualisation end of the market and recently have been working with NASA on the CEV project(s). Some models that we deal with are in the gigabyte file size just for the geometry for a single subassembly. This card would make viewing some of these things far easier as you can preprocess and schlepp almost all the geometry to the video card as a VBO and never have to pass it over the bus again. Makes for tremendous performance gains.
What about those using mobile phones and happen to be on the opposite coast from where they live? There could be as much as a 5 hour time difference between the home area code and that of the current caller's location (more if they're say east coast USA and in Hawaii).
The mechanical load that the alternator presents to the engine increases proportionally to the electrical load on its output, exactly as the laws of thermodynamics predict.
That assumes you have an alternator that only delivers the amount of current needed by the system. Have a look at how the regulation system works. Many are shunt-type, meaning that the alternator always produces the same amount of current and the regulator deliberately wastes any that is not used by the system through heat. If you've ever owned a mid-80's + Honda motorcycle you'll know all about this problem as they all burn reg/recs on a frequent basis because of this design.
The HP Dynamo project is probably what you are refering to. It was done on PA-RISC, not MIPS. The performance increases of running native code (ie C/C++) inside a VM was in the order of 20-30%. A quick google brought up the Ars Technica article on it, but there's plenty more.
Portable data is something that is of great interest to NIH. They're not scared of it at all, actively encouraging it, in fact. There's at least half a dozen SBIRs out there now on the very topic (of which my company is placing bids). One of the things that is of major interest to them is Informed Consent. That is, NIH wants to have PCs in every doctor's surgery and have them gathering medical information, putting it into a simple to view application and sending it home with the patient. The first target is MRI and CAT scan data - those very DICOM images you're talking about.
Another side to this is that NIH/NLM are seriously looking at how to combine large scale medical databases. That also is feeding into this desire to distribute patient data to the patient. They have a number of projects that have been funded for the last couple of years for creating huge single-subject, national level databases, particularly of research data. Now they have a couple of open-bid SBIRs on providing integration applications for those. That is, someone should be able to combine the virus database, with the visible human data, with the heart disease databases into a single visual system. This can then either be used for teaching/training, general education, or combined with individual patient records on that take-home CD so that they can see how the individual compares to The Masses(TM). We're doing a lot of this work in combination with UW here in Seattle.
There is a defined legal concept known as "The Common Man" that Common Law countries use. I am specifically aware of the concept in the UK, Canada and Australia.
Loosely put, the definition is "if the common man would not find that to be a reasonable action, you loose". For example, going swimming in a large storm on a beach with signs saying beach closed due to dangerous conditions, a person going swimming and breaking their neck has no legal grounds for suing. It very effectively stops so many of the stupid lawsuits you see here in the USA before they get anywhere.
Slashdot Mirror
It still shows that you're living a fairly long way in the Java past. Java has not had internal bounds checking every array access since the advent of the Hotspot JVMs. Most of the array access checks are optimised away either by the compiler or by the JIT compilation from the hotspot, particularly in places where it matters like tight for loops. Random access are still checked some of the time, but anything that is performance critical, those checks are discarded by the JVM well before they become a performance issue.
I'm not acknowledging any performance hits at the UI level because, quite frankly, none of our users or our clients see them. In fact, many of our clients are surprised that the code has been written in Java. Sure, anyone can code a crappy UI, and with Swing it's incredibly easy to do so (in fact, seems to be the default way that it's implemented), but with a very small amount of attention to detail, they perform just as good as any other language. With some of the Java 6 work where it is using OpenGL under the covers for all the 2D rendering, it is a heck of a lot faster too than a lot of the Vista crap that we've seen.
Where we have seen performance hits in the past is in very heavy array/pointer access code such as that used in image decoding. In fact we wrote our own native code wrappers to get around this problem. However, starting with Java 5 and now 6, the supplied JVM image decoding is even faster than our light wrappers around libjpeg/libpng etc.
One of the reasons why you don't see Java3D in games is that it has some serious internal architecture issues. The absolute primary one that killed it for our customers is that If you use a behaviour to set a transform and a geometry (vertex) change in the same frame, the geometry update appear rendered one frame before the transform takes effect. When we've pressed them about that, the Sun engineers have never seen this as a critical problem! Now, try writing a high-performance game in an environment that acts like that.
You're almost correct on the surface management side. For the most part, the JVM does manage it, but there are times where you have to do explicit management, and there are API calls to do this as part of the JAWT bridge library. One of the libraries I work heavily with is JOGL, and specifically the SWT port of JOGL, so I'm (unfortunately) more than a little aware of the surface locking protocols that one needs to go through. However, the only people that ever have to worry about this are those of us that implement native heavyweight renderers, such as JOGL. There's a lot of platform-specific surface locking going on under the covers - X11 code locks and unlocks surfaces at different times to Win32 or OSX, for example. You need to lock the surface for doing things like context management. makeCurrent() can't just be made at any random time, even though JOGL lets you do that, there's a whole raft of code under the covers that takes care of all the timing issues involved that you normally would have to deal with in a native code version of the same thing.
Please provide proof of your assertions.
I have plenty of examples for you where our Java code is not only faster than competitors written in C or C++, but the margin of speed differences are double or greater. This is implementing open standards development work, so we're all playing on the same page, not comparing different game engines or so forth. In fact, our scene graph APIs are more than twice as fast as Java3D for the same content and typically 10+% faster than native-code based scenegraphs like OpenSceneGraph. Take a look at the j3d.org site or anything involving Xj3D.
Java is more than fast enough for full graphics. FWIW, I do high end scientific, medical visualisation and a fair amount of military work on the side. The places where highly optimised code for the task at hand is the order of the day.
In a previous life, I did a lot of work on major structural repairs to composite fibre airframe structures - and more specifically on sailplanes. I had several qualifications for inspection and maintenance on them, and worked in a shop that did everything up to and including spar repairs. There's actually less requirements for inspections on any form of composite structure than metal or wooden frame. And when there was inspections, it was much simpler. For example, the spar is tested simply by taking two identical tuning forks, placing one on one end of the spar, ringing the second one, placing it on the other end of the spar. If the other one rang in sympathy, things were fine. The wing surface itself is very easily checked for delamination by simply tapping and listening. When you're more experienced, you can feel it in the way your tapping object responds to the impact. That's far easier that some of the x-ray type inspections we had to do on the metal aircraft. That sort of level of inspection was only done once a year, or every 200 hours, whichever came first. Given the rest of the aircraft industry inspection schedules, I highly doubt that anything will change for the 787.
You are correct that microfine stress fractures are impossible to see in a pure carbon structure. To work around that, every object has a very fine fibreglass layer (070 or thinner) on the outside surface. When stress is applied, the fibreglass shows the stress marks and you can then visually see that something is wrong.
The biggest issue with C/f structures is design life. At the time when I was last working in the industry (mid 90's), they weren't even sure what the maximum life was. There was no data anywhere in the world. The sailplane factories were stating that 10K hours was the minimum and they would test after that (metal airframes were 30K hours before EoL). There were studies being done at Melbourne's RMIT (Australia). The last I heard there was they got to 17K hours before failure of one wing. Given the absurd number of hours a commercial airliner does compared to a sailplane, I would hope and expect that they have done some lifetime studies beyond that. I haven't yet seen any numbers from Boeing about expected airframe life for their pure composite structures.
Same goes for us non-businesses that have their own personal Class C address space too...
You are way overthinking the problem. Look up the Byzantine Generals Problem. It is solved for you right there and has been for decades.
Rounding, in the end has no adverse effects on the cost of living. They did that in Oz about 10 years ago and removed the copper coins completely. Smallest value is now 5c. Everything gets rounded such that totals ending in 1, 2, 6 and 7 round down, 3, 4, 8 and 9 round up. Everything is still priced normally and the rounding only applies to the total, not individual items - with the extra proviso that it only applies to cash transactions. Electronic (cheques basically don't exist in Oz anymore) transactions are still the normal non-rounded price.
As a result, on average, you are no different. If you're at the point where a 2c increase is effecting your cost of living then you probably have a lot of other things to worry about before that.
What you need to implement is org.xml.sax.EntityResolver. There's several methods that need to be implemented that are the different ways the SAX parser could query for stuff. Basically it will give you the Public ID and/or System ID and ask you to return a stream to what that resolves to. Then, in your code, all you do is run a hashmap that maps a given ID to a local resource (eg file or database BLOB) and then do your own stream opening/processing from there. I attempted to post some example code but seems like that trips the lameness filter :( So, just have a look at the interface. The code required is pretty trivial to implement. If that fails, you should be able to work out my email address from the website address under my profile - send me an email and I'll send you the code we use in one of our projects.
Just replying to your graphics performance point: Have you tried out the JDK 6 graphics performance? They've gone the same way as OS X, Vista and Xgl and now use the native 3D hardware for all rendering operations (in this case it is OpenGL). This has made graphics intensive areas like Swing amazingly fast compared to the previous generations of Java.
This is going to be a negative is for anything based on SWT, which doesn't use the AWT infrastructure, so the Eclipse folks are going to have to get moving on that front or left behind (FWIW, I maintain a port of the OpenGL JSR 231 code to run under SWT so I have a foot in both camps here).
Fortunately, you are wrong on this. The majority of the work that my company does is OSS work for the military and research institutions. Much of the work is sharable between those worlds, and increasingly, commercial entities. One such example is a command and control system for autonomous underwater vehicles. Not only useful to the military, but also to the many different marine research institutes, both privately and publically funded.
We have many other applications that have started in one side of the field or the other as research projects, then with a bit of munging to be useful as a "commericial" application, have ended up being usable by other parties. Another example is a world builder and behavioural analysis program. Build the world from real models, apply agent-based behaviours, then toss it at a large grid computing backend to provided monte-carlo-style analysis of the results. That basic infrastructure has all sorts of uses both commercial and private. Most of them have been originally funded by military development, with the explicit contract provisions that it be made open sourced (typically with no specific license required, but the preference for GPL or LGPL depending on where the code sits in the application stack).
While this sort of business model was a struggle even 2 years ago, things are radically different now. Almost everywhere we go the military types are specifically looking for either open source or open standards. The big change we noticed in that was at I/ITSEC last year. Siggraph this year was also very much along that way. Way too many in the government side of military contract have been bitten by proprietary data and now are actively seeking to free themselves of it.
Cthulu HoroClix is Wizkids. But, as another MechWarrior fan, it's not surprising that they didn't mention much about it. There's not much "new" in the system, just another release coming at the end of next month and Ares. Ares hasn't changed the rules at much, except for the multiple dial setup, unlike the Age of Destruction did. They just made stuff bigger. Most of this is at the noise level for gamers that don't know the systems.
Yes. In the large groups of libraries and apps that I hang around in, vi/emacs or similar text editor use far outweights the IDE crowd. In my own case, I have several multi-hundred thousand line libraries that I develop, all using a combination of text editors and make. Conservative estimate of the main projects totals about 2 million LoC that I actively maintain on a daily basis.
The converse to your statement is true - try managing those huge projects in an IDE. Things like context highlights and suggestions grind the entire IDE to a halt. Netbeans is particularly bad for this and Eclipse isn't that much better. Pulling the largest of my projects into Eclipse can grind my dual core machine with a couple of gigs of ram to a screaming halt. I can easily outtype Eclipse's abilty to respond. It's far more frustrating to use an IDE than it is to use simple text editors that do nothing more than syntax highlighting.
If you want firefox support look for Octaga. They have a pretty decent browser that handles everything thrown at it and has decent performance and spec coverage.
As for your other standards, none of the cover the same ground as X3D. OpenGL is a programming API. SVG is a 2D graphics API to replace flash. DX is the same as OpenGL.
The X3D spec itself is well settled now. Around 2000 we were still mincing over just what the spec should look like. Now we have a formally certified ISO spec and in the process of going through the second set of revisions to add new capabilities (eg compositing, rigid body physics, volume rendering etc). The hype is gone and now it's just people using it for real tasks far away from the populist web.
There's a couple of browsers out there - Flux and Bit Management's Contact are browser plugins that support both VRML and the successor specification called X3D. If you want to play with standalone apps for viewing content, have a look at either our toolkit called Xj3D (if you're a Java-based person) or FreeWRL.
X3D has some pretty good capabilities and there are various projects out there showing far better models than anything you'll find on Google Earth. Have a look at some of the city modeling that Planet9 does. Various other projects around that replicate what Google Earth does with large-scale terrain rendering, city modelling etc.
Disclaimer up front: I am one of the authors of the VRML and X3D specs and have a small OSS company that makes money from these specs.
All scene graphs have some form of limitation. VRML, and it's successor X3D, have a very standard approach of the DAG structure. What is a little unconventional is the curly bracket syntax, which is a holdover from the Open Inventor file format that it originally came from. VRML suffered pretty badly from a lot of browsers doing their own thing and ignoring large chunks of the spec. X3D is fixing that problem by having real conformance tests and being very picky about what a conformant browser is allowed and not allowed to do. And, if I get my way, the browsers will be pretty anal about the content; Anything non-conformant should not display from the start, thus forcing the content creator to fix the problems before it gets out into the wild.
X3D, however, has changed that a lot - you can now use XML to represent the same thing. One of the really nice things about that is that all you have to write is one XSLT and you have instant 3D visualisation of your pre-existing XML encoded content. We're finding that by far the majority of our users of X3D are making use of this capability in industry-specific verticals (CAD visualisation happens to be the first such vertical that we're making some very significant inroads into).
It is true that the hype of VRML really killed it before it could do what it wanted to. However, the acceptance is huge under the radar. X3D in particular is now being required as part of many government standards pushes - particularly in Europe, where the ISO nature of the spec is a major benefit.
If this is written for the US government, remember that they are immune to patent claims. Since the offer came from MA government to pay for someone to develop this, I'm sure the ODF foundation can tweak their offering to fit to the letter of the offer and law such that they too would be immune to any patent shenanigans that MS may try to pull.
I hang around on the ODE mailing lists and I've not seen any mention of this card, or even implementing the Havok/NVidia-SLI style of setup.
The project somewhat stalled for a while as the main developer with write access to the head sort of disappeared. In the last month they've moved to sourceforge, subversion, moved all the old unstable code into the head, and added a wiki. They're pushing very quickly towards a 0.6 release (0.5 has been out for about 2-3 years now). This has caused quite a bit of rejuvination of interest recently, so maybe we'll see something along those lines pop up in the post 0.6 code?
Gah! How many times do I have to keep reminding you not to use the volcanos as your personal trash disposal? Now look what you've done! You've stirred up another Balrog. I ain't gonna deal with this one. Look what happened last time! You can sort this one out for yourself! Bah, I'm going on holiday. Say, where did those little ones go? I could do with some more weed. Helps relax you know....
I work a lot with the visualisation end of the market and recently have been working with NASA on the CEV project(s). Some models that we deal with are in the gigabyte file size just for the geometry for a single subassembly. This card would make viewing some of these things far easier as you can preprocess and schlepp almost all the geometry to the video card as a VBO and never have to pass it over the bus again. Makes for tremendous performance gains.
What about those using mobile phones and happen to be on the opposite coast from where they live? There could be as much as a 5 hour time difference between the home area code and that of the current caller's location (more if they're say east coast USA and in Hawaii).
The mechanical load that the alternator presents to the engine increases proportionally to the electrical load on its output, exactly as the laws of thermodynamics predict.
That assumes you have an alternator that only delivers the amount of current needed by the system. Have a look at how the regulation system works. Many are shunt-type, meaning that the alternator always produces the same amount of current and the regulator deliberately wastes any that is not used by the system through heat. If you've ever owned a mid-80's + Honda motorcycle you'll know all about this problem as they all burn reg/recs on a frequent basis because of this design.
The HP Dynamo project is probably what you are refering to. It was done on PA-RISC, not MIPS. The performance increases of running native code (ie C/C++) inside a VM was in the order of 20-30%. A quick google brought up the Ars Technica article on it, but there's plenty more.
Portable data is something that is of great interest to NIH. They're not scared of it at all, actively encouraging it, in fact. There's at least half a dozen SBIRs out there now on the very topic (of which my company is placing bids). One of the things that is of major interest to them is Informed Consent. That is, NIH wants to have PCs in every doctor's surgery and have them gathering medical information, putting it into a simple to view application and sending it home with the patient. The first target is MRI and CAT scan data - those very DICOM images you're talking about.
Another side to this is that NIH/NLM are seriously looking at how to combine large scale medical databases. That also is feeding into this desire to distribute patient data to the patient. They have a number of projects that have been funded for the last couple of years for creating huge single-subject, national level databases, particularly of research data. Now they have a couple of open-bid SBIRs on providing integration applications for those. That is, someone should be able to combine the virus database, with the visible human data, with the heart disease databases into a single visual system. This can then either be used for teaching/training, general education, or combined with individual patient records on that take-home CD so that they can see how the individual compares to The Masses(TM). We're doing a lot of this work in combination with UW here in Seattle.
Please define "reasonable person".
There is a defined legal concept known as "The Common Man" that Common Law countries use. I am specifically aware of the concept in the UK, Canada and Australia.
Loosely put, the definition is "if the common man would not find that to be a reasonable action, you loose". For example, going swimming in a large storm on a beach with signs saying beach closed due to dangerous conditions, a person going swimming and breaking their neck has no legal grounds for suing. It very effectively stops so many of the stupid lawsuits you see here in the USA before they get anywhere.