Wikipedia:Reference desk/Archives/Computing/2015 August 5

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

August 5

Java 3D

Over the years, 3D/GL support for Java has shifted from one "This is the FINAL technology" to another "No, Seriously, This is the FINAL FINAL technology!" I will be teaching a 3D graphics course in the Spring and I've been asked to use Java instead of C/C++. Is there a current "final" 3D technology that is free for students to use in their projects? I prefer one that is at least similar to OpenGL because that is what the textbook uses. I tried to install and use Java3D. Got a test to compile, but couldn't make it run. I then tried JOGL. It won't compile the simple "Hello World" program used in the intro to the docs. Both libraries seem to be abandoned and I haven't found a third option (yet). 199.15.144.250 (talk) 15:58, 5 August 2015 (UTC)

You should be asking yourself this: If 3D graphics is so hard in Java - will anybody out there in the real world be using it for that? The answer is "No". I've been a 3D graphics programmer since before PC's existed and before the mouse was invented - and I used the first ever OpenGL-based graphics system (a wire-wrapped prototype as SGI headquarters) - so I know what I'm talking about.

I can't think of a single project that required Java for 3D work - or where using Java was even discussed. Although such projects may exist, I never worked for a company where that was needed. It's highly unlikely that your students will go on to do 3D graphics in Java in their future careers.

Interactive 3D graphics are mostly done in C, C++, C#, ObjectiveC (see a common thread here?!) and more recently in JavaScript. Java *is* used on Android phones & tablets - and it does support OpenGLES - but Android developers who are doing complex 3D work tend to use native-programming in C++ for the graphics bits - and put a Java wrapper around it for accessing system-level stuff.

If you want your students to learn anything of value - then dump the stupid Java requirement.

More importantly if you're teaching a graphics course that has any remote connection to modern practices - you'll spend a good chunk of your time teaching shader programming in one of GLSL/HLSL/Cg (which are all basically a C++ subset for the GPU). Shader programming is 90% of what you worry about as a graphics programmer anyway.

So I think you need to change the premise here.

Personally, I think you should use the OpenGLES API (it's a subset of full OpenGL), and using either JavaScript (via WebGL), C++ (via full-up OpenGL) or C# (probably using OpenGLES) - because the choice of base language is largely irrelevant - and 90% of your teaching efforts need to be in teaching a shader language...which should be GLSL (IMHO).

1. JavaScript + GLSL + WebGL == 3D graphics for the web.
2. C# + GLSL + OpenGLES == 3D graphics for mobile.
3. C++ + GLSL + OpenGL (or C++ + HLSL + Direct3D) == 3D graphics for PC's and game consoles.

If you have time, teach a little Unity3D too! Everyone should get some time playing with a decent game engine.

SteveBaker (talk) 18:46, 5 August 2015 (UTC)

If you want to teach OpenGL, and can find a working OpenGL wrapper for Java, then I see no reason not to use Java; practically everything you teach will carry over to any other language's OpenGL bindings. -- BenRG (talk) 03:42, 6 August 2015 (UTC)

I can tell you one reason not to use Java for graphics: performance. And I don't mean to disparage Java: I love Java - it's a great language, and for many workloads, Java bytecode can outperform native machine code (for a variety of reasons). But for graphics - and for OpenGL in specific - this is categorically not the case: JOGL will lame your graphics program and your code will never be able to fully utilize the power of your GPU (unless you've got a really ancient GPU).

OpenGL is already notorious because it requires a huge amount of CPU work in tandem with the execution of any and all GPU work. The OpenGL state machine is resident in a software driver on your CPU; and this complicated software state-machine has to be synchronized with the hardware, seriously impeding the programmer's capability to offload and parallelize rendering work to the GPU.

If you aren't familiar with this "hidden bottleneck," here's an article from Anandtech written earlier this summer: Comparing OpenGL ES To Metal On iOS Devices With GFXBench Metal. "One of the biggest issues caused by this is reduced draw call throughput. A simple explanation of a draw call is that it is the command sent by the CPU which tells the GPU to render an object (or part of an object) in a frame. CPUs are already hard-pressed to keep up with high-end GPUs even with a low level API, and the increased overhead of a high level graphics API further reduces the amount that can be issued in a given period of time. " He's talking about the CPU overhead of a native code implementation being the bottleneck - the GPU is starved and waiting for work! This happens on iOS devices, where the operating system and the graphics driver (and all the hardware) are tightly controlled, and bound together by platform-optimized software. The problem of CPU-bottlenecking-the-graphics-calls gets worse on desktop and server systems that run Linux or Windows - because the GPU drivers and the system software aren't so tightly integrated. And in Java with JNI, this problem gets even worse.

JOGL uses JNI for every single function call. Every data transfer, texture preparation, polygon draw operation, and shader call must navigate across an extra boundary - through the JVM and through the operating system. This significantly limits performance. Your GPU can handle a certain number of operations per second in OpenGL; but when you use JOGL, your application is limited by the ability to perform JNI work on the CPU. To make matters worse, all the of fancy technologies that optimize JVM bytecode cannot work when there is native code involved: every single byte of data that crosses the JNI interface is inherently a data hazard. That data lives outside the JVM; JVM cannot make optimized assumptions about it for the purposes of prefetch, cache, and so on. This is a real, measurable problem.

I used to manage a GPL-licensed, JOGL-based scientific rendering software. It was great - JOGL made the software cross-platform, and the software was sold (!) to clients who ran Windows, Mac OS X, and a few variations of Linux. However, after a few years, the benefits of having a cross-platform program wore through; and the performance needs necessitated a native implementation. My application could run on servers with state-of-the-art GPUs - gigabytes of graphics RAM, and literally thousands of graphics cores - but the serial, single-threaded JNI interface limited my rendering performance to somewhere in the neighborhood of 10,000 polygons per frame (that's less than a million polygons per second)! For reference, that's slower than the typical performance we got out of our GeForce2 cards when we played video games as kids! This wasn't the CPU's fault, and it wasn't the GPU's fault - it was a software design-bottleneck necessitated by JNI's thread model (that's the software piece that connects the JVM to the operating system, permitting native calls). You can build your own GPU driver; you can build your own JOGL; but unless you rewrite the Java Virtual Machine and build it into your operating system, you can't make JNI go any faster.

To make matters worse, JOGL 1.0 and JOGL 2.0 are not mutually compatible. This is probably why our OP is finding so much sample code that doesn't compile in the modern JOGL maintained by JogAMP. For my application, I eventually had to fork the JOGL 2 source-code, and maintain a local copy of the library source code, in order to preserve compatibility with the native OpenGL drivers on Ubuntu, CentOS, Windows XP, and OS X. If you aren't willing to do this work to keep your Java code cross-platform, you aren't reaping the greatest reward of Java: so you might as well pick a platform and adopt the best toolkit for native graphics development on that platform.

JOGL is free software, licensed under a BSD-esque license; but on the level, if you can't afford commercial support, you probably can't afford the free software.

Alternately - as Steve's excellent advice points out - perhaps you should not be writing primitive graphics operations at the abstraction layer provided by OpenGL. Instead, you can find a good high-quality graphics engine. Steve's Unity3D suggestion works great for games; if you're doing professional graphics or scientific computing, there are lots of alternatives. Let the engine designers and graphics programmers deal with the native code issues, and you can focus on writing higher-level application-graphics logic.

Nimur (talk) 17:38, 6 August 2015 (UTC)

This is a class teaching 3D graphics concepts, not a game company developing a game, so I doubt that performance will be an issue.

The overhead of JNI calls is on the order of 10ns according to some random web pages, so it seems unlikely to be a bottleneck. Other overheads associated with Java could be an issue. OpenGL requires rendering calls (to a single target) to be made on a single thread even in C programs. Calls to OpenGL can't be inlined or otherwise optimized in C programs either; it's a system library and as far as I know it's dynamically linked on all major platforms.

This post discusses some of the problems with OpenGL that are driving the development of new APIs like Metal and Vulkan. -- BenRG (talk) 04:40, 7 August 2015 (UTC)

It appears that JOGL and Java 3D are quite different: the former is just a Java wrapper for OpenGL, while the latter is a scene graph library. If you want to teach low-level OpenGL programming in Java then I think you should use JOGL or LWJGL. JOGL doesn't appear to be abandoned: the most recent release was 4 months ago according to the Wikipedia article. If you want to teach higher-level game programming, then you may want to follow Steve's suggestion and use Unity (which doesn't support Java). This thread from 2011 lists some higher-level 3D engines for Java. The only ones with Wikipedia articles are jMonkeyEngine and Ardor3D (and Java 3D). -- BenRG (talk) 03:42, 6 August 2015 (UTC)

I feel that Steve's argument strengthens my resolve to use C/C++ and OpenGL. I looked at LWJGL, but it apparently requires an IDE. I'm blind, so it is very very difficult to IDE. I prefer a simple text-based command line. I know the students could use one, but I couldn't work with their code or make examples. I've used OpenGL multiple times in the past and the book is based on OpenGL (technically, it looks a hell of a lot like NeHe's lessons). So, I will give them some base code and have them work only on the graphics part. 209.149.114.32 (talk) 14:44, 6 August 2015 (UTC)

I'm glad I could stiffen your resolve. I could be one of the people employing your students in future years - and for me, the paramount things you can pass on are:

1. Comfort with 4x4 homgeneous matrices, linear algebra, dot & cross products. Not rote knowledge - comfort.
2. An understanding of the limitations of depth-buffering - especially in the context of translucent objects.
3. Recite three times before breakfast: "Lighting is everything"
4. A love and passion for playing with shaders. Teach GLSL. Truly, shaders unleash the artist in every programmer. We're only just beginning to scratch the surface of what can be done with them. The field is wide open for innovators to make a name for themselves with a clever trick and a SigGraph presentation.

SteveBaker (talk) 05:21, 7 August 2015 (UTC)

Indeed, a strong second vote for teaching "comfort" with the math. Your students should spend all semester living in the projective plane, inside and outside of class. Nimur (talk) 16:07, 7 August 2015 (UTC)

Where can I get a good cheap used computer in Vancouver Canada?

This user has been indeffed as a multiple account abuser, see the various SPI investigations of neptunekh, as well as venustar84 and her IP socks. The modus operandi includes questions about the Vancouver area, as well as weight and health issues (see this IP's contributions) as well as threats of self harm. Please contact blocking admin Jayron32 if you suspect this is not the same user. As of this point, advice is to remove all edits on sight, see the talk page for links. μηδείς (talk) 00:22, 9 August 2015 (UTC)

• The IP that posted here is a Vancouver Public library address, rather unfair of Medeis to ban posts from a public library. DuncanHill (talk) 00:41, 9 August 2015 (UTC)

How to enable Java on Windows 98 ?

I fired up an old Windows 98 box to see if it was still functional. I ran into an error saying Java was disabled. I know it's installed, as I have a Java icon in the Control Panel. I am using the Firefox 2.0.0.20 browser. How can I enable Java there ?

Thanks, StuRat (talk) 20:56, 5 August 2015 (UTC)

You may not be able to. I'm still using an XP machine and Java has ceased functionally properly (it runs... kind of, but I'm constantly having to fiddle the settings just to get enough to view the few webpages I frequent that require it). In order to get it working again, I would need to update it, but in order to update it, I would need a new version of Windows, which isn't going to happen right now. I imagine a Win98 machine is even further down that road than I am and may be practically non-functional any more. Sorry; I'm not sure there's a workaround; I just avoid java. :) 64.235.97.146 (talk) 17:04, 7 August 2015 (UTC)

How do I get it to run, even a little ? You might be right that it won't be enough, but I'd like to at least try it. StuRat (talk) 20:27, 7 August 2015 (UTC)

Download stand-alone java from portable app modern update version Erunaquest (talk) 23:15, 7 August 2015 (UTC)

Very good chance that won't work. Portable apps may still rely on essential Windows components, and often won't modify an application which will refuse to run, whether or not it will work. As per [1] and Java version history, Java v5 was the last version of Java to officially supported 9x. As per that page, you can download it from here [2]. Whether this will work on the Firefox browser I have no idea. I presume this computer isn't internet connected, since only an idiot, or a security researcher would be running 98 on a internet connected computer nowadays, so can't you just run whatever you want to run outside the browser? Nil Einne (talk) 07:57, 8 August 2015 (UTC)

Thanks, but everyone seems to be missing that I ALREADY HAVE JAVA INSTALLED. I'm just asking how to turn it on in Firefox. StuRat (talk) 14:59, 9 August 2015 (UTC)

I don't recall the specific series of actions I used to get Java to run on XP, but I did not need to hack the registry or anything of that nature - it was mostly changing settings and ignoring various warnings (which I only agreed to because NoScript keeps my browser locked down very tightly). Even after that, I still constantly need to grant permission to run it. However, trying to (re)install Java might be instructive for you as it may highlight what the problem is (though my guess is that you'll just get a warning that you need to update Windows first). Besides that, it's also possible that your program has become corrupted - and reinstalling would also serve to fix that. 64.235.97.146 (talk) 13:26, 10 August 2015 (UTC)

Apologies I was mostly responding to the two responses to your question rather than your specific question. Anyway what version of Java do you have installed? Does the version you have installed come with a plugin for the version of Firefox you have installed? Did you actually install the Java plug in? It's a completely moot point having Firefox installed if you either didn't install the Firefox plugin, or the Firefox plugin isn't compatible with your version of Firefox, or the version of Java you have doesn't even have a Firefox plugin. Firefox 2 came out in 2006 and Firefox 3 came out in 2008. So it's easily possible that the version of Firefox you have installed doesn't support the Java plugin that came with the Java you have installed. That said, the first thing to try would probably be to try freshly installing the latest version of Firefox which supports 9x (apparently 2 so get the latest 2) and after you have down that and restarted, install the latest version of Java that supports 9x (this would I presume be the latests JRE 5). It doesn't matter if you already have Firefox and Java installed, since something is obviously not working. If need be, you should uninstall Firefox and Java before starting the installs. It's important that you carry out a proper fresh install. If that doesn't work, try earlier versions of Java, perhaps versions of Java that came out around the time of Firefox 2. If that still doesn't work, you should really consider why you're trying to run Java on Firefox on a 9x nowadays. Is there no way you can run the program locally? May be you can ask the local server admin for whatever Java program you're trying to run to reconsider how they're setting things up since it's bad enough they're forcing you to use 9x, it's even sillier they're forcing you to access a local server with a Java program. Nil Einne (talk) 19:14, 10 August 2015 (UTC)

Actually seems I was remembering the dates wrong. 2009 was the date Java 5 support was abandoned, not when it was release. Java 5 was released in 2004. Java 6 in 2006. So it's possible that Java 5 never properly supported Firefox 2, or at least the latest Firefox 2. So you may have to try older versions of Firefox 2, or even Firefox 1. Alternatively, our article suggests Java 6 update 7 worked on 9x, so you could try that. Anyway the main point remains, you need to make sure the version of Java you have installed supports the version of Firefox you have installed. There is also a possibility they don't support each other on 9x even if they do in general. BTW, [3] suggests Java 6 update 1 may work on Firefox 2.0.0.20, and Java 6 if you don't need the developer console. Nil Einne (talk) 19:25, 10 August 2015 (UTC)

Nobody is forcing me to use Windows 98, I was just curious if my old home PC was still usable, so fired it up and tried it out, as it would be nice to have it as a backup if my main PC goes down. Not having Java in Firefox was the main impediment to actually using it. It does have Internet access. I originally installed Java specifically for Firefox, but then I believe I disabled it out of security concerns at some point, so now I just want to enable it again. (As for security, it's no longer used for anything important, so if it gets hacked it's no big deal.) StuRat (talk) 19:29, 10 August 2015 (UTC)

There are more secure and options than 9x on an old PC if you ever decide you don't want to continue to contribute to making the internet a bad place, so I can no longer offer any help and would discourage anyone from doing so. It may seem no big deal to you, but when I get spammed by the botnet you're part of, or you DOS a site I use or whatever else, it's obviously a big deal to me. In fact, even when it doesn't affect me personally, it's still a big deal to me. It's bad enough that there are people who don't know better who allow themselves to become part of such malicious activities. It's far worse when people who do know better do so. Nil Einne (talk) 19:37, 10 August 2015 (UTC)

It may be a setting under about:config. WegianWarrior (talk) 17:28, 9 August 2015 (UTC)