Is it possible to run Java3D applications on Nvidia 3D Vision hardware?

Is it possible to run Java3D applications on Nvidia 3D Vision hardware? - java

Is is possible to run a Java3D application on Nvidia 3D Vision hardware?
I've got an existing Java3D application that can run in stereoscopic 3D. In the past, I've always run the application on Quadro cards using the OpenGL renderer and quad buffered stereo.
I now have access to a laptop with the nVidia 3D Vision system (with a GeForce GTX 460M). From the documentation, it seems like it should be possible to run my application in stereo if I use the DirectX bindings and let the nVidia drivers take care of the stereo, however, this does not seem to be the case.
If I run a Java3D application with j3d.rend=d3d, the nVidia 3D Vision API doesn't seem to recognize it as a DirectX application.
How can I get the nVidia 3D Vision drivers to detect a Java3D application and render in stereoscopic 3D?

I'm disappointed that so far everyone has dismissed this as impossible right out of the gate. I've been working on this for the past several days, and made some headway. So far, I've found that it is possible, but with a few caveats:
You need the latest drivers from nVidia (280.29 as of this writing)
You need to use the Direct3D renderer, not the OpenGL renderer (-Dj3d.rend=d3d)
You need to force Direct3D to run in fullscreen mode. (-Dj3d.fullscreen=REQUIRED)
You need to run using a ConfiguredUniverse in fullscreen mode (I'm using the provided j3d-1x1.cfg that is available in the Java3D documentation)
In order to get it working on a 64-bit machine, I had to use the 64-bit dlls for Java3D, which someone has helpfully provided on the Java3D forums (http://home.java.net/node/705510) This may or may not be required on a 32-bit system.
Future releases of the nVidia drivers promise improved support for windowed-mode stereo, so its possible that this will become easier in the future (possibly eliminating the need for option 3 and/or 4 above)
I'll also investigate if rebuilding the Java3D source with some additional nVidia bindings can eliminate the fullscreen requirement, and repost with the results.

Java3D uses something called "Quadbuffer Stereo", i.e. two distinct doublebuffered framebuffers, one for the left and one for the right eye. NVidia considers this thing "professional grade", although it is impossible to to proper stereoscopy without accurate control of the content of both eyes.
3D Vision however inserts some shaders to create an in-situ stereo separation. This however only works with programs giving it some hints through the 3D Vision API. Java3D doesn't.
Let's just hope that Microsoft will indeed push Quadbuffered Stereo as a core requirement of DirectX 12 Graphics, so that NVidia has no longer lame excuses to keep this from "consumer grade" OpenGL.

java3D does not support the 3d vision api but it may work with any direct x program

This is may outdated, but I have the binary DirectX libs for Java3D 64. It is the j3dcore-d3d.dll .
If someone needs it, send a message to me.
From readme.txt file :
======
README
Java3D DirectX 9.0 Renderer for 64bits
January, 2010
Hi
The companion j3dcore-d3d.dll is a Java3D renderer
for Microsoft DirectX D3D in 64bit. This uses exactly
same source code from 32bits, but compiled with Visual
studio 2005 for Windows 64bits.
It was tested with Windows XP Pro. 64bit Edition,
Vista 64 and Windows-7 64. In both nVidia and ATI drivers.
Usage
Drop the j3dcore-d3d.dll in the same folder you have j3dcore-ogl.dll.
Dependency
Use it with a 64bit JRE.
It requires Java3D for Windows AMD 64, available at
https://java3d.dev.java.net/binary-builds.html
It also needs a DirectX driver update
You can get it http:\www.microsoft.com\directx
Current full link for DirectX Web Setup :
http://www.microsoft.com/downloads/details.aspx?familyid=2DA43D38-DB71-4...
This last link points to a very small web updater for DirectX runtime.
Disclaimer
This is for testing purposes only. Use it at your own risk.
This IS NOT endorsed or supported by Sun, Oracle or any other company.

Related

JavaFX 8 HiDPI Support

I just tried out the JavaFX Hello World Example on a 4k screen on Arch Linux, but unfortunately the GUI does not scale.
The documentation says
Hi-DPI support. JavaFX 8 now supports Hi-DPI displays.
So how can I make my application dpi aware?

Hi-DPI support on various devices
For OS X Macs with retina display it should "just work" - JavaFX is aware of Hi-DPI Macs and will scale the UI appropriately. If you set the spacing in a VBox to 8, then that is a device independent unit; on a non-retina display mac it will take up 8 pixels, on a retina display which has double the resolution, the spacing will take up 16 pixels. Because the retina display also has twice the DPI as well as twice the resolution of the non-retina display, the physical screen measurement of the space will be the same regardless of device.
For Windows and Linux devices, your results may be less satisfactory as JavaFX 8u20 does not currently by default work out arbitrary DPI resolutions on such devices and scale to them appropriately. What you could do is perform most of your measurements in css as em units (which are based on the point size of the scene's root's default font) and similarly for fxml, and then set the point size of the scene root's default font appropriately depending on what you determine from querying the screen's DPI resolution. See the discussion in this answer for further information and sample code: javafx automatic resizing and button padding.
Specific to Gnome
Gnome 3 has a setting for the scaling factor which can be controlled by this command:
gsettings set org.gnome.desktop.interface scaling-factor 2
You can query this scaling factor by reading the user's gnome profile settings and use this in conjunction with querying the screen DPI to work out how an appropriate scaling factor then apply the scaling using the techniques described above.
Just a personal anecdote - when I tried using Gnome 3 scaling (CentOS 7 and also a recent Fedora release) on a Hi-DPI display a couple of days back, I found the overall support for Hi-DPI across applications running under Linux to be pretty spotty. Certainly, the support was much improved from CentOS 6 when I attempted that, but there was still quite a way to go to achieve quality Hi-DPI support across windowing toolkit, standard apps and third party apps. For this reason, I believe that running HiDPI Gnome desktops is still quite a bleeding edge thing which is definitely not for everyone - I am sure that this situation will change over time.
Bitmapped Images
From a JavaFX team lead blog entry on Hi-DPI:
In Apple’s applications (starting with the iPhone and iPad with their retina displays), the solution to the problem is for the application developer to supply two images instead of one for each image asset. For example, the splash screen will be supplied with two images, one at normal resolution and one at 2x the resolution. The files are named the same but the 2x one is named according to some convention, such that at runtime the platform will lookup the 2x version on retina behind the scenes. In such a way, your application says “fooImage.png” but “fooImage#2x.png” is looked up instead when on a machine with a retina display.
I do not know whether this bitmapped image choosing functionality for Hi-DPI displays is currently in Java 8u20 or not - you might have to implement it yourself by querying the screen with screen.getDpi(), then loading the appropriate bitmap.
4K Devices
4K is a lot of pixels to push. JavaFX will by default use hardware a accelerated graphics pipeline when such a graphics pipeline is available. Some graphics hardware may not be fully optimized for 4K display (e.g. not enough video ram), which might lead to an application which either does not work or performs poorly. I also don't believe that currently a lot of effort has gone into investigating JavaFX performance on various 4K devices - it might "just work", but it might not either. You will need to test your application on the target hardware to determine the current capabilities of JavaFX applications when running on that hardware. You might also need to tweak the application according to some of the suggestions above.
A user has reported an issue with JavaFX 8u20 when attempting to display a 4K video using JavaFX:
JavaFX Ultra HD (4K) video
Background
Supporting Hi-DPI under OS X was (likely) simpler than Windows/Linux devices as the target devices are either retina or non-retina display with one being an exact 2x scale of the other and direct support from the OS X system can be leveraged to help achieve the retina scaling. With Windows/Linux, probably what is required is an ability to scale at factors other than just 2x, and that is covered by the (currently outstanding and scheduled) feature request RT-32521 Support global coordinate scaling with DPI-based default. Scaling by an integral amount usually gives the best visible results.
Additional Resources
Kynosarges discussion of JavaFX DPI Scaling.
The JavaFX team load wrote a blog on JavaFX on retina Macs (this is a little dated now, as JavaFX now supports retina Macs).
Randahl's perspective on JavaFX: Designing for Multiple Resolutions.
Apple have some nice advice on optimizing applications for high resolution devices, it's not JavaFX specific and some of the advice does not apply to JavaFX, but there are still some useful general principals and techniques there.
A complete guide to coding for Hi-DPI devices is outside the scope of this particular answer - you can google various web resources to get more information.
If you have further questions on Hi-DPI support for JavaFX, I suggest you ask them on the openjfx-dev JavaFX developer mailing list.
Wiki Answer
This answer may have some possible inconsistencies or errors and may date over time. I have made the answer community wiki. If you are aware of specific corrections, device and OS limitations or support model support for Hi-DPI on JavaFX, please feel free to edit this answer or move it to the OpenJFX wiki (where it probably belongs anyway).

I faced the same problem. I built javaFX application in my surface pro 3, which did not scale but the fxml apps did. then I installed jre8u221 withiout replacing the updated version it suggested. It fixed the problem

Guidance on Java issue on Mac

I have come across a major wall and hopefully someone can help me out.
Preface:
We have a desktop application (JavaFX based). It speaks to Canon camera using Canon's SDK. Hence one can download the latest Image taken, get notifications about camera events and so on. And it works all well on Windows.
Now the SDK is 32-bit based and hence the JVM we use has to be 32-bit based (64-bit JVM is incompatible, fullstop).
Coming to Mac
There is no Java-7 for 32-bit Mac. Hence we have got to us Java-6 which is no Issue (WIth -d32 VM argument). But it turns out that there is no Java-FX for Java6 on Mac. How can I bundle my application with Java6 and Java-FX? Any nightly build wil help? Or any other manual tweaks? Else it will demand a lot of restructuring of the code.

PlayN java desktop version slower than web version?

so i've been playing with google PlayN, and i built a small sprite sheet loader for explosions.
what is weird thought is that the desktop java version (that uses the same core code) runs way slower than my web version.
for instance my web version: sapropwns.appspot.com (click with left mouse button and drag the pointer), as you can see its pretty smooth. on the other hand the java desktop version lags every like 2 secs and doesnt draw as much as this web version (the trail doesnt have as much drawing even though both use the same mouse callback for drawing at the same speed).
is there a limitation on the PlayN library that im missing?
thanks in advance.

It's been a while since I looked at PlayN (I was poking at it for a little while for fun). But performance for desktop apps may not be great for certain applications since they are using straight-up Java2D for their rendering. I'm also guessing it's not all that optimized at this point.
There is some discussion on the PlayN group about improving performance by switching from Java2D to LWJGL (Lightweight Java Game Library). This would improve performance greatly for desktop apps (Minecraft uses LWJGL).