I think it's the other way around - american houses are typically way over built. I come from Australia, and when I first saw these multilayer houses being built I wondered why on earth they were putting so much useless material on them. In oz, houses are basically just the pine 2x4 frame with steel diagonal strips put in for the diagonals. No extra sheeting inside or out - just straight gyprock (sheetrock to americans), maybe insulation, then brick on the outside. That's it. Houses stand up just as long.
I can definitely confirm the data/code classification split. I've worked both sides of the fence in my career. My current company (Yumetech) does almost all OSS software development. One of our primary customers is the US Navy - both the Naval Postgraduate School and the Naval Undersea Warfare Center. It's been an explicit requirement of theirs for quite a number of years now that they release as much code as possible under an open source license (typically LGPL or BSD-style). You'll find quite a number of their libraries up on SourceForge. Only one of our applications is required to be closed-source, and at that, only a small part of it dealing with some simulation algorithms (terrorism related so you can imagine why they'd be not willing to release that source).
For all the other applications, it is only the data that they care about being classified. In a lot of cases, they encourage us to seek non-naval funding for our development efforts. For example, recently, one of our apps also got some NIST and NASA funding as well.
You'll find the proprietary code, such as the big C4ISR systems etc are that way more at the insistance of the contractors developing it, rather than the military. This is so that the contractors can then repackage it and sell it to other countries or so that they government has their hands tied for getting long-term maintenance of the code.
Basically any company you can purchase a software "solution" from. May be a single app, or a collection of applications bundled into a single set of services.
Go do some research on the Dynamo project from HP. Running native code inside a VM results in a 20-30% faster running application. Runtime optimisations for the actual code paths used will always result in faster execution than static optimisation.
How many parties exist in the US? From the coverage we get, it seems like there are only 2.
I'm not really sure, but they certainly don't have the level of public exposure like the aussie minority parties do. There's 3 major ones - Democrats, Republicans and Libertarians. I suspect there's a collection of equivalents to The Marijuana Party, but they don't seem to be very active or well known. I'm living in Seattle, pretty much home to all the "alternate lifestylers" where you would expect to see a lot of these sorts of minor parties. You don't see a word about them in either the mainstream local papers or even the street press, which typically favour such styles of politics. Since I can't vote here, I can't get in to see what the listing is like on the actual ballot papers.
The scary thing though is that they vote for everything. They even vote for their judges! That means the judicial system is based on a popularity contest, just like the politicians. That scares me a lot as it's not about application of the law any more, just those that pander to public opinion.
The reason why is because of the huge collection of Other Parties that one can vote for. Making a vote informal takes a lot of work. Now, if I can remember the rules rightly, an informal lower-house vote has one of the following traits:
Missing more than one box marked without a number
Tick or cross only for one candidate
An identifying mark of the voter such as their name (other stuff scribbled on the ballot paper is fine)
Two or more numbers that are the same
That's basically it. They do have a tendency to change a little from election to election so in one election a tick for the first preference and numbers for the rest are acceptable, but in the next election it might not be). All that the votes really require is a clear order of preference on who to elect. If you can determine that, it's formal. Upper house votes are even harder to make informal due to the dual-voting ability (above the line per-party or below the line per-candidate).
As for postal votes, yes the system is pretty good. When the envelope comes it, it gets your name marked on the roll as having voted. The envelopes are then stored until election day. At that point the envelopes are opened in a big pile at the AEC office in the electorate and all votes placed into a big pile. The pile is then sorted according to the normal procedure. There's very little chance of connecting the envelope with the vote of the voter. Of course, there's always a half dozen eagle-eyed scrutineers watching your every move too to make sure you don't accidently loose a vote or any other nefarious thing, particularly in the highly marginal seats.
Actually, there's very few. I've spent many years working in the polling booths for both state and federal elections both in NSW and WA. The last time, before I moved to the US, I was in charge of a booth, thus having the final say of whether a vote was invalidated or not. It was moderate size - taking about 3000 votes.
In almost every booth I worked in informal votes were extremely rare. In the order of 5-10 per 1000 votes counted. It takes a lot to make a vote informal, and voter education is very high and the Australian Electoral Commission spends a lot of money on ads to keep it that way. Voting is very simple, and outside each booth every political party hands out flyers with a listing of their preference order for people to use. Those that don't care for anything except their marginal candidate just copy the numbers down, drop the vote in the ballot box and walk out. Apart from the queuing to get your name marked off, less than a minute can be spent in the entire process.
The beneficial aspect of the aussie voting system is that because everyone must vote, everyone actually cares about and pays attention to the politics. It's a case of "well if I have to, I'm going to make sure I make a difference". There's lots of viable candidates from all political parts of the spectrum, and all of them have a pretty decent chance of getting voted in. For example, a party that was selling highly racist policies manages to get a collection of senate seats and a couple of lower house seats. Same thing with the heavy greenies, who happen to hold the balance of power in the senate. It works far better than the system here in the USA from my observation.
The GNU Readline library is also under the GPL. At least somewhat technically, so is glibc that comes with GCC. However, there is a special exception that has been added to GCC that allows you to use (make calls to) glibc as part of a non-GPL app.
Re:Reading OpenGL tutorials is such a harsh remind
on
OpenGL 2.0 Released
·
· Score: 3, Informative
So the simple way to understand OpenGL code is to think of a really big state machine. Each call just modifies the currently existing state. The state persists until the state is changed - even to the point of maintaining it between rendered frames.
If you want Java bindings for OpenGL, there's two major projects.
JOGL, which is the basis for the formal bindings in JSR 231.
LWJGL which is a community driven project and somewhat akin to DirectX in that it also merges audio and input device APIs as well.
If you need some tutorials to get started, check out http://opengl.j3d.org in a couple of weeks when it gets officially opened and has lots of beginner tutorials to play with.
Not really - they were asking whether hardware accelaration in general was worth bothering with, since their software implementations were far faster. DX really didn't come into the equation until DX8 was released. OpenGL has never really featured as a serious commerical game development API. Developers went from either custom coded or Renderware-based engines, straight to the DX series of APIs. id software is really the only standout amongst the crowd of developing professional quality games using OpenGL. (lots of simple amateur games, but they aren't the sort that cause major press releases to be issued all over the place when they go gold)
Or, do like us, and just not care about MS. We make all our money in applications other than dealing with microsoft. (FWIW, I'm the architect of Xj3D, one of the links provided in the article). Our money comes from developing custom applications using our toolkits that happen to support X3D, or providing complete solutions for devices like CAVES or other large-scale visualisation devices. We get paid to improve open source codebases, something which MS is not interested in.
FWIW, 3DIF is just Shockwave3D. This is Intel's 4th attempt at trying to standardise it. They'll fail yet again. Look at the architecture of it, it sucks badly in that it does everything it can to prevent hardware graphics acceleration (ie Modifier Chains). Academically, it's nice, but for it's theoretical stated objectives, it just cannot work. It can't handle the millions of polygons required of CAD visualisation and rendering - either at the file format level or interactive frame rates. Just wait another year and watch it sink beneath the waves again. All it is is a couple of managers at Intel trying to save their arse on an already-failed project.
The issue is the decompressed size. Fact is, you are going to have to decompress the data before you can parse it. Something like X3D is going to be HUGE compared to a binary 3D format.
Do you understand what you just wrote here? Compressed data is compressed data. Once you get it to the application level, it becomes uncompressed, regardless of the original format. 20K vertices is 20K vertices regardless of what file format it started life in. When you pass that to the video card, you still have an array of 20K times 3 floats. The whole point of compressed or not is just for transmission and parsing speed, not parsing size. Either way, you're going to end up with the same amount of in-application memory being used by the data.
Text-based formats are no different to binary. You can still stick them in a content chain and have it all work. The one advantage that being XML based is, is that you can make use of the rest of the XML toolchain for zero development cost. Got a CML (Chemical Markup Language) file, write one XSLT and suddenly every single CML file can now be visualised in 3D. There is no need to write some custom application to do it. Same thing applies to any other XML-based file format. You get easy, almost free, content-shifting and visualisation capabilities. Something that cannot be said for any binary format out there. That's the entire point of having XML capabilities. If you don't need it, then use the X3D binary format, or the VRML encoding. Flexibility is the key.
Those pages are rather old and do not represent the final format. There is two proposals right now and a vote to be taken on selecting the one to go forward in mid October. One of them is based on using the XML schema to automatically generate a compression scheme (which also happens to be one of the submissions to the W3C Binary XML WG) and the other is a custom X3D-only implementation, but is fairly standard in it's treatment of binary data. You should see more info on these surfacing in a couple of months, so ignore those pages for now.
The point that you have completely missed is that X3D is published to the website. Thus, it costs nothing (unlike most other ISO standards). The ISO spec got ratified just under a month ago and we have to go through one more round of editing (typos only) and we have to wait for ISO to formally publish it before it can be seen on the Web3d.org website. Prior to that, if you're a member of the consortium, you have access to it right now.
On your second paragraph, that's a matter of opinion, of which I vehemently disagree with you. Many large organisations will not touch something unless it is an ISO standard. This is particularly true with both the European companies and the US military complex. To give you an idea of just how that works - as soon as we had the announcement in hand, we had 2 different branches of the US military formally announce that they require it as their one and only 3D interchange standard. By not going to ISO, we end up with the same problem as before - a psuedo standard with multiple incompatible implementations thereof. This solves the problem up front.
Where Tony and I disagree is that X3D nor VRML has any use being a "Web" standard. Where VRML has been hugely successful is out in industry in places that don't care about the web. If you'd walked around the floor at any show where they do modelling and scanning data, you'll find every single scanner manufacturer uses VRML as their output file format. All the tools that take that raw data in and process it, use VRML etc etc. None of the success stories even use a web browser in the system. In the future, that is less and less likely to happen too. It's all about the back-end and integration work. X3D has been succeeding for a couple of years in there and will continue to succeed.
You'd get quite a kick out of Iain M. Banks' Feersum Enjun novel. One of the main characters writes entirely phonetically - chapter at a time (as you can see from the title spelling). I, surprisingly, found it quite hard to turn the brain off from cringing at all the "bad" spelling and just trying to read what was printed.
Eaxctly. One of our clients is the MOVES Institute, the part of the military that developed AA. I know the (former) project manager personally. The whole budget got canned about 2 months ago. The entire development area has been stripped bare, including all their mocap gear. In fact, we're helping them develop the area that the former AA development team occupied with new VR equipment and applications. There is no further development being done and there will be none in the future.
You need to work on your reading skills... You should retain more info from the book that is not in the movie than info actually in the movie..
Not at all. Recall abilities are highly dependent on the nature of the person. Some remember visual things far better than written, while others remember aural. Spend some time chatting with various friends and see how someone remembers the details of a given event. Some will relate the visuals, others will relate about what someone said or did etc. Just because one person doesn't remember something as well from written form versus someone else does not make their reading or watching skills any lesser, it just means that their brain functions differently. If you've ever spent any time teaching a lot of people, this is one of the first things that become evident - not everyone learns and recall things the same way.
Been there, done that:) There was a huge, rather vehement at times, discussion about this on the javagaming.org forums. There's the "make JOGL more like Java" camp and the "make JOGL exactly reflect C " camp. This extends to far deeper concepts too - namely how much of OpenGL extensions and the window-specific APIs (GLX, WGL etc) should be exposed to the end user. For example, there's the attitude of some that needing access to the GenLock functions is not needed because "Java doesn't do that sort of stuff". A decision has been made on these issues, but due to the JCP process rules we can't talk publically about it (which I really hate).
Third, Java just added type-safe enums. Use them.
That is a no-go right from the outset. JOGL has to remain as widely usable as possible - including the offshoot for the OpenGL-ES bindings that have to run with JME. Since that is a feature of 1.5 and a beta one at that, there is no consideration at all of using that as part of the spec.
Sun and SGI announced at last year's SIGGRAPH that they were planning native OpenGL 1.5 bindings. I don't know what has come of that project.
It's called JOGL. There's a JSR associated with it (JSR-231) that is doing the work of the formalised bindings. My company (Yumetech) is on the JSR committee for that one and things are progressing reasonably well, though not at the scheduled timetable. There is also a related JSR that is getting off the ground right now for the OpenGL-ES bindings, JSR 239, but is a little further behind.
Although, having a large higher-level 3D open-source library ready to use in Java might swing momentum in Java's favor.
There's at least two that have been underway for the last year - Xith3D and Aviatrix3D. Both are already far faster than Java3D in their respective application spaces (gaming and sci-viz respectively). Come try them out and you'll be surprised at just what sort of speed can really be obtained from 3D Java apps and toolkits.
Slashdot Mirror
Couldn't be - definitely a yank. He spelt "Mum" wrong.
I think it's the other way around - american houses are typically way over built. I come from Australia, and when I first saw these multilayer houses being built I wondered why on earth they were putting so much useless material on them. In oz, houses are basically just the pine 2x4 frame with steel diagonal strips put in for the diagonals. No extra sheeting inside or out - just straight gyprock (sheetrock to americans), maybe insulation, then brick on the outside. That's it. Houses stand up just as long.
I can definitely confirm the data/code classification split. I've worked both sides of the fence in my career. My current company (Yumetech) does almost all OSS software development. One of our primary customers is the US Navy - both the Naval Postgraduate School and the Naval Undersea Warfare Center. It's been an explicit requirement of theirs for quite a number of years now that they release as much code as possible under an open source license (typically LGPL or BSD-style). You'll find quite a number of their libraries up on SourceForge. Only one of our applications is required to be closed-source, and at that, only a small part of it dealing with some simulation algorithms (terrorism related so you can imagine why they'd be not willing to release that source).
For all the other applications, it is only the data that they care about being classified. In a lot of cases, they encourage us to seek non-naval funding for our development efforts. For example, recently, one of our apps also got some NIST and NASA funding as well.
You'll find the proprietary code, such as the big C4ISR systems etc are that way more at the insistance of the contractors developing it, rather than the military. This is so that the contractors can then repackage it and sell it to other countries or so that they government has their hands tied for getting long-term maintenance of the code.
I'm Mithrandir and I approve this message.
Independent Software Vendor
Basically any company you can purchase a software "solution" from. May be a single app, or a collection of applications bundled into a single set of services.
Ah, but it makes for great concrete! Send a few Italians up there and the place will be covered in concrete so fast, you'll never have to worry about the regolith ever again!
PS: Appologies in advance for those that don't understand aussie humour....
Programming is essentially a markup language surrounding mathmatical formulas and thus, should not be patentable.
ooooh, what a lovely sound-bitish summary. I see a new email sig in the making there.
Always two there are, Master and Apprentice.
Go do some research on the Dynamo project from HP. Running native code inside a VM results in a 20-30% faster running application. Runtime optimisations for the actual code paths used will always result in faster execution than static optimisation.
How many parties exist in the US? From the coverage we get, it seems like there are only 2.
I'm not really sure, but they certainly don't have the level of public exposure like the aussie minority parties do. There's 3 major ones - Democrats, Republicans and Libertarians. I suspect there's a collection of equivalents to The Marijuana Party, but they don't seem to be very active or well known. I'm living in Seattle, pretty much home to all the "alternate lifestylers" where you would expect to see a lot of these sorts of minor parties. You don't see a word about them in either the mainstream local papers or even the street press, which typically favour such styles of politics. Since I can't vote here, I can't get in to see what the listing is like on the actual ballot papers.
The scary thing though is that they vote for everything. They even vote for their judges! That means the judicial system is based on a popularity contest, just like the politicians. That scares me a lot as it's not about application of the law any more, just those that pander to public opinion.
That's basically it. They do have a tendency to change a little from election to election so in one election a tick for the first preference and numbers for the rest are acceptable, but in the next election it might not be). All that the votes really require is a clear order of preference on who to elect. If you can determine that, it's formal. Upper house votes are even harder to make informal due to the dual-voting ability (above the line per-party or below the line per-candidate).
As for postal votes, yes the system is pretty good. When the envelope comes it, it gets your name marked on the roll as having voted. The envelopes are then stored until election day. At that point the envelopes are opened in a big pile at the AEC office in the electorate and all votes placed into a big pile. The pile is then sorted according to the normal procedure. There's very little chance of connecting the envelope with the vote of the voter. Of course, there's always a half dozen eagle-eyed scrutineers watching your every move too to make sure you don't accidently loose a vote or any other nefarious thing, particularly in the highly marginal seats.
Actually, there's very few. I've spent many years working in the polling booths for both state and federal elections both in NSW and WA. The last time, before I moved to the US, I was in charge of a booth, thus having the final say of whether a vote was invalidated or not. It was moderate size - taking about 3000 votes.
In almost every booth I worked in informal votes were extremely rare. In the order of 5-10 per 1000 votes counted. It takes a lot to make a vote informal, and voter education is very high and the Australian Electoral Commission spends a lot of money on ads to keep it that way. Voting is very simple, and outside each booth every political party hands out flyers with a listing of their preference order for people to use. Those that don't care for anything except their marginal candidate just copy the numbers down, drop the vote in the ballot box and walk out. Apart from the queuing to get your name marked off, less than a minute can be spent in the entire process.
The beneficial aspect of the aussie voting system is that because everyone must vote, everyone actually cares about and pays attention to the politics. It's a case of "well if I have to, I'm going to make sure I make a difference". There's lots of viable candidates from all political parts of the spectrum, and all of them have a pretty decent chance of getting voted in. For example, a party that was selling highly racist policies manages to get a collection of senate seats and a couple of lower house seats. Same thing with the heavy greenies, who happen to hold the balance of power in the senate. It works far better than the system here in the USA from my observation.
The GNU Readline library is also under the GPL. At least somewhat technically, so is glibc that comes with GCC. However, there is a special exception that has been added to GCC that allows you to use (make calls to) glibc as part of a non-GPL app.
So the simple way to understand OpenGL code is to think of a really big state machine. Each call just modifies the currently existing state. The state persists until the state is changed - even to the point of maintaining it between rendered frames.
If you want Java bindings for OpenGL, there's two major projects.
JOGL, which is the basis for the formal bindings in JSR 231.
LWJGL which is a community driven project and somewhat akin to DirectX in that it also merges audio and input device APIs as well.
If you need some tutorials to get started, check out http://opengl.j3d.org in a couple of weeks when it gets officially opened and has lots of beginner tutorials to play with.
After that, the OpenGL Red Book is your friend.
Not really - they were asking whether hardware accelaration in general was worth bothering with, since their software implementations were far faster. DX really didn't come into the equation until DX8 was released. OpenGL has never really featured as a serious commerical game development API. Developers went from either custom coded or Renderware-based engines, straight to the DX series of APIs. id software is really the only standout amongst the crowd of developing professional quality games using OpenGL. (lots of simple amateur games, but they aren't the sort that cause major press releases to be issued all over the place when they go gold)
Or, do like us, and just not care about MS. We make all our money in applications other than dealing with microsoft. (FWIW, I'm the architect of Xj3D, one of the links provided in the article). Our money comes from developing custom applications using our toolkits that happen to support X3D, or providing complete solutions for devices like CAVES or other large-scale visualisation devices. We get paid to improve open source codebases, something which MS is not interested in.
FWIW, 3DIF is just Shockwave3D. This is Intel's 4th attempt at trying to standardise it. They'll fail yet again. Look at the architecture of it, it sucks badly in that it does everything it can to prevent hardware graphics acceleration (ie Modifier Chains). Academically, it's nice, but for it's theoretical stated objectives, it just cannot work. It can't handle the millions of polygons required of CAD visualisation and rendering - either at the file format level or interactive frame rates. Just wait another year and watch it sink beneath the waves again. All it is is a couple of managers at Intel trying to save their arse on an already-failed project.
The issue is the decompressed size. Fact is, you are going to have to decompress the data before you can parse it. Something like X3D is going to be HUGE compared to a binary 3D format.
Do you understand what you just wrote here? Compressed data is compressed data. Once you get it to the application level, it becomes uncompressed, regardless of the original format. 20K vertices is 20K vertices regardless of what file format it started life in. When you pass that to the video card, you still have an array of 20K times 3 floats. The whole point of compressed or not is just for transmission and parsing speed, not parsing size. Either way, you're going to end up with the same amount of in-application memory being used by the data.
Text-based formats are no different to binary. You can still stick them in a content chain and have it all work. The one advantage that being XML based is, is that you can make use of the rest of the XML toolchain for zero development cost. Got a CML (Chemical Markup Language) file, write one XSLT and suddenly every single CML file can now be visualised in 3D. There is no need to write some custom application to do it. Same thing applies to any other XML-based file format. You get easy, almost free, content-shifting and visualisation capabilities. Something that cannot be said for any binary format out there. That's the entire point of having XML capabilities. If you don't need it, then use the X3D binary format, or the VRML encoding. Flexibility is the key.
Those pages are rather old and do not represent the final format. There is two proposals right now and a vote to be taken on selecting the one to go forward in mid October. One of them is based on using the XML schema to automatically generate a compression scheme (which also happens to be one of the submissions to the W3C Binary XML WG) and the other is a custom X3D-only implementation, but is fairly standard in it's treatment of binary data. You should see more info on these surfacing in a couple of months, so ignore those pages for now.
The point that you have completely missed is that X3D is published to the website. Thus, it costs nothing (unlike most other ISO standards). The ISO spec got ratified just under a month ago and we have to go through one more round of editing (typos only) and we have to wait for ISO to formally publish it before it can be seen on the Web3d.org website. Prior to that, if you're a member of the consortium, you have access to it right now.
On your second paragraph, that's a matter of opinion, of which I vehemently disagree with you. Many large organisations will not touch something unless it is an ISO standard. This is particularly true with both the European companies and the US military complex. To give you an idea of just how that works - as soon as we had the announcement in hand, we had 2 different branches of the US military formally announce that they require it as their one and only 3D interchange standard. By not going to ISO, we end up with the same problem as before - a psuedo standard with multiple incompatible implementations thereof. This solves the problem up front.
Where Tony and I disagree is that X3D nor VRML has any use being a "Web" standard. Where VRML has been hugely successful is out in industry in places that don't care about the web. If you'd walked around the floor at any show where they do modelling and scanning data, you'll find every single scanner manufacturer uses VRML as their output file format. All the tools that take that raw data in and process it, use VRML etc etc. None of the success stories even use a web browser in the system. In the future, that is less and less likely to happen too. It's all about the back-end and integration work. X3D has been succeeding for a couple of years in there and will continue to succeed.
You'd get quite a kick out of Iain M. Banks' Feersum Enjun novel. One of the main characters writes entirely phonetically - chapter at a time (as you can see from the title spelling). I, surprisingly, found it quite hard to turn the brain off from cringing at all the "bad" spelling and just trying to read what was printed.
Eaxctly. One of our clients is the MOVES Institute, the part of the military that developed AA. I know the (former) project manager personally. The whole budget got canned about 2 months ago. The entire development area has been stripped bare, including all their mocap gear. In fact, we're helping them develop the area that the former AA development team occupied with new VR equipment and applications. There is no further development being done and there will be none in the future.
You need to work on your reading skills... You should retain more info from the book that is not in the movie than info actually in the movie..
Not at all. Recall abilities are highly dependent on the nature of the person. Some remember visual things far better than written, while others remember aural. Spend some time chatting with various friends and see how someone remembers the details of a given event. Some will relate the visuals, others will relate about what someone said or did etc. Just because one person doesn't remember something as well from written form versus someone else does not make their reading or watching skills any lesser, it just means that their brain functions differently. If you've ever spent any time teaching a lot of people, this is one of the first things that become evident - not everyone learns and recall things the same way.
Too bad development of it has been completely discontinued a few months ago.
First, JOGL mirrors the C API too closely.
:) There was a huge, rather vehement at times, discussion about this on the javagaming.org forums. There's the "make JOGL more like Java" camp and the "make JOGL exactly reflect C " camp. This extends to far deeper concepts too - namely how much of OpenGL extensions and the window-specific APIs (GLX, WGL etc) should be exposed to the end user. For example, there's the attitude of some that needing access to the GenLock functions is not needed because "Java doesn't do that sort of stuff". A decision has been made on these issues, but due to the JCP process rules we can't talk publically about it (which I really hate).
Been there, done that
Third, Java just added type-safe enums. Use them.
That is a no-go right from the outset. JOGL has to remain as widely usable as possible - including the offshoot for the OpenGL-ES bindings that have to run with JME. Since that is a feature of 1.5 and a beta one at that, there is no consideration at all of using that as part of the spec.
Sun and SGI announced at last year's SIGGRAPH that they were planning native OpenGL 1.5 bindings. I don't know what has come of that project.
It's called JOGL. There's a JSR associated with it (JSR-231) that is doing the work of the formalised bindings. My company (Yumetech) is on the JSR committee for that one and things are progressing reasonably well, though not at the scheduled timetable. There is also a related JSR that is getting off the ground right now for the OpenGL-ES bindings, JSR 239, but is a little further behind.
Although, having a large higher-level 3D open-source library ready to use in Java might swing momentum in Java's favor.
There's at least two that have been underway for the last year - Xith3D and Aviatrix3D. Both are already far faster than Java3D in their respective application spaces (gaming and sci-viz respectively). Come try them out and you'll be surprised at just what sort of speed can really be obtained from 3D Java apps and toolkits.