Stephan van Hulst wrote:Yeah, it's easier to integrate JOGL into Swing components. Especially useful if you want to have 3D animation in a simple desktop GUI. LWJGL is more suited for AWT components and full-screen mode.
Jay Orsaw wrote:
Stephan van Hulst wrote:Yeah, it's easier to integrate JOGL into Swing components. Especially useful if you want to have 3D animation in a simple desktop GUI. LWJGL is more suited for AWT components and full-screen mode.
Yeah.... Why wouldn't LWJGL use swing, isn't it better than AWT in terms of graphics and performance(Even though we are running the Open GL using them...) Does LWJGL have to be in full screen, doesn't seem like it's a mandatory thing...
Stephan van Hulst wrote:LWJGL doesn't use Swing, because OpenGL is easier to use on heavyweight components. JOGL also mostly uses AWT, but provides a GLJPanel class that integrates with Swing, at a somewhat lower performance.
It's not necessary to use full-screen mode with LWJGL, it's just what's mostly associated with a graphics library like OpenGL.
I don't understand what you mean when you talk about printing.
Stephan van Hulst wrote:Where have you heard this? Can you quote your source?
I don't think printing and OpenGL have anything to do with one another.
Stephan van Hulst wrote:In JOGL, you can render your 3D model on a GLPBuffer, and then convert the buffer to a BufferedImage using Screenshot. Then I'm pretty sure there are plenty of ways to get the BufferedImage to print in a way you want.
Stephan van Hulst wrote:I was talking about the Screenshot class, which provides a method to convert from GLDrawable to BufferedImage. I can't imagine it compresses the image.
Stephan van Hulst wrote:Screenshot is a class in the JOGL API, not the standard API ;)
Stephan van Hulst wrote:Why are you jumping to conclusions? LWJGL can capture image data through a pbuffer just as well.
Just do a google search for whatever technology you want to use, and BufferedImage. You're bound to find something.