Re:Java on top of OpenGL is happening...
on
The State of OpenGL
·
· Score: 2, Informative
You may want to have a look at JSR-231 then, which is the official bindings of OGL in Java. If you need something more immediate, the JOGL project, which is the baseline for the JSR, should be checked out. It can be found on the java.net site.
OpenGL has not lagged behind D3D, they have targetted different markets. OpenGL sees itself as visualisation oriented and raw performance. D3D sees itself as a gaming API. Even at the lowest level, this means several significant differences in approaches taken to a given subject. For example OGL has had 3D texturing and accumulation buffers since almost the beginning of time, but D3D barely supports the equivalent functionality. Given OpenGL's focus, I can hardly see it ever being the preferred API for game development. Try to do a serious simulation application in D3D and you'll see the same situation, just in reverse.
Re:OpenGL ES with hardware support?
on
The State of OpenGL
·
· Score: 2, Informative
The simplistic reason for this is that the full OGL spec, or even the "miniGL" drivers are still waaay to complex for what is needed on these devices. Things like multitexturing, and anything that requires readback from the state is especially costly. The point was that on these devices they dont want full OGL support. If they did, they wouldn't have even bothered starting this spec. It is to provide a spec that has a greatly reduced footprint (memory, API coverage, etc) that allowed first class 3D graphics on smaller devices. If you want full OGL support, you do full OGL, not a partial implementation. There is no point "working upwards to full OGL" because they are never going to get there with this spec. Once a device wants to head towards desktop OGL support, then they bite the bullet and implement the complete API.
It was also determined that most of that sort of functionality was not needed. Other things like 1D and 3D textures, attribute stacks, display list etc are just non existant. On the other end, there are things that never existed in OpenGL, such as the fixed point maths support, along with defined accuracy measures etc.
In the beginning, OGL-ES had two primary targets - small footprint mobile devices, and safety critical markets (ie avionics displays etc). In the former, they needed basic functionality, but enough to do things like overlays and texturing. In the latter, they needed a very small API footprint that can be verified IAW with various authorising bodies (eg FAA for avionics, NIH for medical devices etc). In both cases, a miniGL driver was just not good enough because miniGL still assumes the full OpenGL spec and only for one particular application. Both groups required a formalised spec that they can point to and claim "this is what we support", complete with some logo branding. miniGL still assumed a desktop based system, neither of the target groups for OGL-ES could make a lot of those assumptions (for example floating point abilities at all)
FWIW, I was a member of the ES spec development group until about 3 months ago and still am on the spec mailing lists.
Mud carp are freshwater fish. Australia is an independent continent that has no connection to anywhere else. There's no way it could spread. Also, the carp are an introduced species so wiping them out is very desirable as they completely ruin the local river ecosystems. However, they've been trying to do that with rabbits, boar and foxes for about 100 years now with no success. I doubt this one will either.
Sun cannot ever proclaim anything dead. It is admission of failure to them and therefore not acceptable. If you are waiting for them to declare it as dead, you'll probably die before they will state that. JSDT is still officially "on hold" too - it has been for the last 4 years...
When evertything has been cancelled, and their developers are now not answering emails on the java3d list, and have been assigned to other parts of Sun, it is dead. Also, we already have been told that we'll have access to parts of Java3D - either completely open source, or access to the patents. Either way, they are not doing any more development on it, nor are there any intentions to return to develop it in the future.
Not on hold - its officially dead. All of the resources working on the project have been moved off and are now working on either JSR-184 or the new OpenGL bindings JSR (once it gets started).
We're involved in various efforts to replicate and replace Java3D with another scene graph. If you need something immediate, take a look at the Xith3D project from Dave Yazel and the MagiCosm guys. Alternatively, if you can wait a couple of months, we're in the process of ripping our OpenGL scene graph out of the core of Xj3D to turn it into a separate project. The difference between the two is that Xith3D is focused on games (it has primitive objects for particle systems, for example) where our work is focused on CAVEs, powerwalls, linux clusters etc.
Am I the only one here who'd like to some day be rendering serious 3d graphics through Java?
No, but I've been doing it for years. Don't know which closet you've been hiding in, but there are heaps of alternatives for doing 3D graphics in java. Java3D, GL4Java, LWJGL and more. In fact, our (open source) toolkits use all of these and we have hundreds of users running on everything from PDAs up to CAVEs all done in Java. We've just released code to handle Elumens Domes/VisionStations too, which, again, is in Java (although that one required a small amount of native code to slap Java3D into gear to do it).
All of it - at least as far as they are going to tell you. Unfortunately, the way the MPEG group works is everyone submits that they have x number of patents to the -LA group. It totals up all the patents, divides the money received and sends the proportional amount to the individual patent holders. It's a core problem with the spec because nobody knows exactly what is patented and which patent applies where, just that there are a lot of them. In fact, it is known that many of the patent claims are bogus (expired, not actually applicable), but there's so many (thousands last I heard) that it's not even worth their while to sort out the mess.
In the earlier processes, the patents were on the compression technology, not on the encoding or decoding. That's what Fraunhofer were going after all the free players with trying to force them to cough up non-existant money for licensing their patented compression technology. In that case, the patent was on how to compress the audio in a meaningful way and then extract the audio channel back again in hardware. They then managed to extend that claim to software implementations. The only reasone we know they had the patents on that particular piece of technology was that they stood out from the crowd and said "we own this, cough up the money now". Most of the time that doesn't happen - it just goes into an anonymous pool run by MPEG-LA.
I am a spec writer, I don't play one on TV. I authored the EAI for VRML97 and the various programming APIs for X3D. These are ISO specs, so they come with a lot of weight behind them from the conformance perspective.
As someone who is involved in specification writing of APIs I can tell you that a "compile test" is wholly insufficient for checking class/method signatures. (for this reply, I'm using method as being interchangable for any message passing system - C functions, Java methods, RPC calls whatever)
The first and major problem is not that the methods exist - everyone can cut and paste the spec document - but ensuring that nothing else exists. The bane of every spec writer is the company/individual that decides that they don't like the spec and then proceeds to extend it with their own methods within the same class - often overloading existing method calls. It is these extensions that a spec writer dreads because the (often) clueless end user makes use of them and then wonders WTF their code won't run on another "conformant" implementations of that spec.
Checking signatures is there for one thing and one thing only - making sure the implementors don't embrace and extend the specification in a way that is not permitted by the spec. Creating derived interfaces with new method signatures is fine, adding new method signatures to the specification-defined collection is not. A good conformance test suite will look at everything about the signatures to make sure everything is there, and nothing that should not be is not there.
IN oz, the mod chips aren't defined as an illegal device. They aren't legal either, but there is no law saying you cannot do it. For DVD players, stores openly advertise region-free devices or mod chips to make them region free.
Also, there are a number of other laws that contribute to this - reverse engineering is a legal right, so someone can build mod chips in Oz (where do you think the majority of Samba core developers are?). In addition, our local consumer & competition board are investigating the whole region locking thing. From the various news reports going around, it seems like they are about to make region locking illegal because it is classed as anti-competitive. If that does happen (probably >80% chance given previous actions of Prof Fels) then mod chips will most definitely be legal in Oz.
Nope. Web3D Consortium that is overseeing this has a very strict - No IP, No Patents stance. Before any group is allowed to sign up to the consortium they must sign the waiver. Intel, who is doing the bulk of the member recruiting for this group is also fiercly insisting on the waiver too. Don't expect this to become another MPEG.
Unfortunately you will be disappointed then by the outcome of this working group. Their explicit goal is a binary format, not text. Text is too bloated for the sorts and amount of data they want to provide.
No, Intel and the OpenHSF folks came to the consortium and asked if they could use us to build a standard. What they want is the way we can process standards through official channels like ISO. We have the contacts, we have the expertise in house. They need a neutral body to help them through it. It works well. The CAD WG is not VRML97, nor is it the latest variant of VRML called X3D. It is a separate working group defining their own file formats and doing their own thing. They may choose to suck bits from the X3D spec, but I doubt it because of their requirements - which are high-resolution CAD data, not realtime, interactive, scriptable worlds.
As for Microsoft's participation, wait and see....
Unless the XFree86 team is doing it, it's a non-standard band-aid "solution"
Why should a team which is devoted purely to graphics rendering pipelines be at all concerned about installing drivers or configuring applications? X is platform independent. Just because I install a driver for my x86 Linux box where the client application resides, does not mean that it will work for the Solaris/SPARC machine that I am viewing the application on.
If the XFree team got involved in writing configuration utilities I would be most disturbed. XFree doesn't even both deal with writing "simple" applications like terminal screens (thing XTerm), so why should they be writing much higher-level, system-specific applications like desktop configuration managers?
In this case the internet community was getting very pissed off with Robert Elz, the guy running it. He was slow, made very arbitrary decisions and there were huge backlogs. The internet user community had been complaining about him for a good 4-5 years before auDA finally took over - and they dramatically increased the quality of the service. This is very different to the south african situation.
No, I didn't miss your point at all - you're not reading what I said. HP have a series of research papers where they run native code in its own VM and that code runs 20-30% faster than running native code straight on the CPU with no VM. PA-RISC/x86 ASM, whatever, is no different to Java bytecode. They are all just considered intermediate formats for the VM. That's how my Java code runs as faster, if not faster than traditional native code today, using today's JVMs such as hotspot.
Not wistful thinking at all. For the past 2 years or so, using the Hotspot-based VMs, most of my code has been running faster than the equivalent native code applications. This is not GUI stuff (SWING sucks), but server-based code doing number crunching, file format translations, and plenty of other stuff. It takes a little while for the dynamic compilation to analyse the code and build the appropriate structures, but on a long-lived server application, that's really trivial amount of time. Take a dig for the HP paper mentioned where they do the same thing with native code running inside a VM. Even there they claim a 20-30% improvement of already compiled native code. Don't just blindly believe stuff you've been taught in the past. VM technology is superior to standard systems and only going to get better.
Care to tell us how that is done? Java3D 1.3 beta only supports NIO for the geometry input through the data buffers, with no support for textures. Are you doing custom image loading and then putting the pixels in a VolatileImage to do that? Enquiring minds want to know if you are use Java3D or GL4Java, because it ain't in the spec for J3D.... Send me a private email on the link above if you want.
*yawn*. One more clueless idiot that speaks without any actual knowledge. In some cases, Java runs faster than native code, in other cases, about the same. Got search google for performance comparisons. Go read the article where they talk about the games available today that have just as good framerates as anything written in C/C++. And, if you'd even had any more of a clue, you might do a history search on this site.
There's a nice little article about 12 months ago from HP research department where they started putting native code into the same VM concept as Java uses and were getting 20-30% speed increase by interpreting the native code. Static optimisations are only useful in some cases. Dynamic optimisation that a VM can do as it analyses the code as it runs to optimise it for real world conditions give heaps of performance benefits. Guess what Java VMs have been doing for the past two years at least?
Slashdot Mirror
You may want to have a look at JSR-231 then, which is the official bindings of OGL in Java. If you need something more immediate, the JOGL project, which is the baseline for the JSR, should be checked out. It can be found on the java.net site.
OpenGL has not lagged behind D3D, they have targetted different markets. OpenGL sees itself as visualisation oriented and raw performance. D3D sees itself as a gaming API. Even at the lowest level, this means several significant differences in approaches taken to a given subject. For example OGL has had 3D texturing and accumulation buffers since almost the beginning of time, but D3D barely supports the equivalent functionality. Given OpenGL's focus, I can hardly see it ever being the preferred API for game development. Try to do a serious simulation application in D3D and you'll see the same situation, just in reverse.
The simplistic reason for this is that the full OGL spec, or even the "miniGL" drivers are still waaay to complex for what is needed on these devices. Things like multitexturing, and anything that requires readback from the state is especially costly. The point was that on these devices they dont want full OGL support. If they did, they wouldn't have even bothered starting this spec. It is to provide a spec that has a greatly reduced footprint (memory, API coverage, etc) that allowed first class 3D graphics on smaller devices. If you want full OGL support, you do full OGL, not a partial implementation. There is no point "working upwards to full OGL" because they are never going to get there with this spec. Once a device wants to head towards desktop OGL support, then they bite the bullet and implement the complete API.
It was also determined that most of that sort of functionality was not needed. Other things like 1D and 3D textures, attribute stacks, display list etc are just non existant. On the other end, there are things that never existed in OpenGL, such as the fixed point maths support, along with defined accuracy measures etc.
In the beginning, OGL-ES had two primary targets - small footprint mobile devices, and safety critical markets (ie avionics displays etc). In the former, they needed basic functionality, but enough to do things like overlays and texturing. In the latter, they needed a very small API footprint that can be verified IAW with various authorising bodies (eg FAA for avionics, NIH for medical devices etc). In both cases, a miniGL driver was just not good enough because miniGL still assumes the full OpenGL spec and only for one particular application. Both groups required a formalised spec that they can point to and claim "this is what we support", complete with some logo branding. miniGL still assumed a desktop based system, neither of the target groups for OGL-ES could make a lot of those assumptions (for example floating point abilities at all)
FWIW, I was a member of the ES spec development group until about 3 months ago and still am on the spec mailing lists.
Mud carp are freshwater fish. Australia is an independent continent that has no connection to anywhere else. There's no way it could spread. Also, the carp are an introduced species so wiping them out is very desirable as they completely ruin the local river ecosystems. However, they've been trying to do that with rabbits, boar and foxes for about 100 years now with no success. I doubt this one will either.
Sun cannot ever proclaim anything dead. It is admission of failure to them and therefore not acceptable. If you are waiting for them to declare it as dead, you'll probably die before they will state that. JSDT is still officially "on hold" too - it has been for the last 4 years...
When evertything has been cancelled, and their developers are now not answering emails on the java3d list, and have been assigned to other parts of Sun, it is dead. Also, we already have been told that we'll have access to parts of Java3D - either completely open source, or access to the patents. Either way, they are not doing any more development on it, nor are there any intentions to return to develop it in the future.
Not on hold - its officially dead. All of the resources working on the project have been moved off and are now working on either JSR-184 or the new OpenGL bindings JSR (once it gets started).
We're involved in various efforts to replicate and replace Java3D with another scene graph. If you need something immediate, take a look at the Xith3D project from Dave Yazel and the MagiCosm guys. Alternatively, if you can wait a couple of months, we're in the process of ripping our OpenGL scene graph out of the core of Xj3D to turn it into a separate project. The difference between the two is that Xith3D is focused on games (it has primitive objects for particle systems, for example) where our work is focused on CAVEs, powerwalls, linux clusters etc.
That's what classloaders take care of. Each ClassLoader instance is it's own object space.
Rip down that Godawful Alaskan way Viaduct.
Hey, I'd agree to that! I live in the HarborSteps and it would give me a much nicer view >:}
Its a health hazard in the next Major quake.
That it is...
Am I the only one here who'd like to some day be rendering serious 3d graphics through Java?
No, but I've been doing it for years. Don't know which closet you've been hiding in, but there are heaps of alternatives for doing 3D graphics in java. Java3D, GL4Java, LWJGL and more. In fact, our (open source) toolkits use all of these and we have hundreds of users running on everything from PDAs up to CAVEs all done in Java. We've just released code to handle Elumens Domes/VisionStations too, which, again, is in Java (although that one required a small amount of native code to slap Java3D into gear to do it).
Take a look at Xj3D for more information.
I think you mean the
Segway Type R
All of it - at least as far as they are going to tell you. Unfortunately, the way the MPEG group works is everyone submits that they have x number of patents to the -LA group. It totals up all the patents, divides the money received and sends the proportional amount to the individual patent holders. It's a core problem with the spec because nobody knows exactly what is patented and which patent applies where, just that there are a lot of them. In fact, it is known that many of the patent claims are bogus (expired, not actually applicable), but there's so many (thousands last I heard) that it's not even worth their while to sort out the mess.
In the earlier processes, the patents were on the compression technology, not on the encoding or decoding. That's what Fraunhofer were going after all the free players with trying to force them to cough up non-existant money for licensing their patented compression technology. In that case, the patent was on how to compress the audio in a meaningful way and then extract the audio channel back again in hardware. They then managed to extend that claim to software implementations. The only reasone we know they had the patents on that particular piece of technology was that they stood out from the crowd and said "we own this, cough up the money now". Most of the time that doesn't happen - it just goes into an anonymous pool run by MPEG-LA.
I am a spec writer, I don't play one on TV. I authored the EAI for VRML97 and the various programming APIs for X3D. These are ISO specs, so they come with a lot of weight behind them from the conformance perspective.
As someone who is involved in specification writing of APIs I can tell you that a "compile test" is wholly insufficient for checking class/method signatures. (for this reply, I'm using method as being interchangable for any message passing system - C functions, Java methods, RPC calls whatever)
The first and major problem is not that the methods exist - everyone can cut and paste the spec document - but ensuring that nothing else exists. The bane of every spec writer is the company/individual that decides that they don't like the spec and then proceeds to extend it with their own methods within the same class - often overloading existing method calls. It is these extensions that a spec writer dreads because the (often) clueless end user makes use of them and then wonders WTF their code won't run on another "conformant" implementations of that spec.
Checking signatures is there for one thing and one thing only - making sure the implementors don't embrace and extend the specification in a way that is not permitted by the spec. Creating derived interfaces with new method signatures is fine, adding new method signatures to the specification-defined collection is not. A good conformance test suite will look at everything about the signatures to make sure everything is there, and nothing that should not be is not there.
oh, it's a Token Tolkien Ring....
Almost as good a The Real Thing(TM)
[groan]
Or ride a motorcycle. They're not allowed to do the pumping for you if you're on a bike. Considering I own 4 and don't own a car, no problem :)
Also, there are a number of other laws that contribute to this - reverse engineering is a legal right, so someone can build mod chips in Oz (where do you think the majority of Samba core developers are?). In addition, our local consumer & competition board are investigating the whole region locking thing. From the various news reports going around, it seems like they are about to make region locking illegal because it is classed as anti-competitive. If that does happen (probably >80% chance given previous actions of Prof Fels) then mod chips will most definitely be legal in Oz.
Past tense:
bin laden
Nope. Web3D Consortium that is overseeing this has a very strict - No IP, No Patents stance. Before any group is allowed to sign up to the consortium they must sign the waiver. Intel, who is doing the bulk of the member recruiting for this group is also fiercly insisting on the waiver too. Don't expect this to become another MPEG.
Unfortunately you will be disappointed then by the outcome of this working group. Their explicit goal is a binary format, not text. Text is too bloated for the sorts and amount of data they want to provide.
No, Intel and the OpenHSF folks came to the consortium and asked if they could use us to build a standard. What they want is the way we can process standards through official channels like ISO. We have the contacts, we have the expertise in house. They need a neutral body to help them through it. It works well. The CAD WG is not VRML97, nor is it the latest variant of VRML called X3D. It is a separate working group defining their own file formats and doing their own thing. They may choose to suck bits from the X3D spec, but I doubt it because of their requirements - which are high-resolution CAD data, not realtime, interactive, scriptable worlds.
As for Microsoft's participation, wait and see....
Unless the XFree86 team is doing it, it's a non-standard band-aid "solution"
Why should a team which is devoted purely to graphics rendering pipelines be at all concerned about installing drivers or configuring applications? X is platform independent. Just because I install a driver for my x86 Linux box where the client application resides, does not mean that it will work for the Solaris/SPARC machine that I am viewing the application on.
If the XFree team got involved in writing configuration utilities I would be most disturbed. XFree doesn't even both deal with writing "simple" applications like terminal screens (thing XTerm), so why should they be writing much higher-level, system-specific applications like desktop configuration managers?
In this case the internet community was getting very pissed off with Robert Elz, the guy running it. He was slow, made very arbitrary decisions and there were huge backlogs. The internet user community had been complaining about him for a good 4-5 years before auDA finally took over - and they dramatically increased the quality of the service. This is very different to the south african situation.
No, I didn't miss your point at all - you're not reading what I said. HP have a series of research papers where they run native code in its own VM and that code runs 20-30% faster than running native code straight on the CPU with no VM. PA-RISC/x86 ASM, whatever, is no different to Java bytecode. They are all just considered intermediate formats for the VM. That's how my Java code runs as faster, if not faster than traditional native code today, using today's JVMs such as hotspot.
Not wistful thinking at all. For the past 2 years or so, using the Hotspot-based VMs, most of my code has been running faster than the equivalent native code applications. This is not GUI stuff (SWING sucks), but server-based code doing number crunching, file format translations, and plenty of other stuff. It takes a little while for the dynamic compilation to analyse the code and build the appropriate structures, but on a long-lived server application, that's really trivial amount of time. Take a dig for the HP paper mentioned where they do the same thing with native code running inside a VM. Even there they claim a 20-30% improvement of already compiled native code. Don't just blindly believe stuff you've been taught in the past. VM technology is superior to standard systems and only going to get better.
using the NIO to load textures into video memory
Care to tell us how that is done? Java3D 1.3 beta only supports NIO for the geometry input through the data buffers, with no support for textures. Are you doing custom image loading and then putting the pixels in a VolatileImage to do that? Enquiring minds want to know if you are use Java3D or GL4Java, because it ain't in the spec for J3D.... Send me a private email on the link above if you want.
There's a nice little article about 12 months ago from HP research department where they started putting native code into the same VM concept as Java uses and were getting 20-30% speed increase by interpreting the native code. Static optimisations are only useful in some cases. Dynamic optimisation that a VM can do as it analyses the code as it runs to optimise it for real world conditions give heaps of performance benefits. Guess what Java VMs have been doing for the past two years at least?