No sign of OpenGL though, they decided to wrap it (and DirectX), which is the wrong path IMO.No please, I don't want to learn another 3D API, there are just too many of them. It's OpenGL or nothing for me.

Yet, this could open backdoors for the JOGL team, especially if all of this goes open source.

It seems they're wrapping it with high level concepts, basically they're making a scenegraph.Porting "low level" JOGL/LWJGL code to it will be more difficult, and we're losing a lot of control.And what if we don't need a scenegraph at all, or using our own already...

<rant>Is it me, or people at Sun/Oracle are so obsessed with object-ville they can't stop wrapping things into objects ?That's something I hate in the java ecosystem: this tendency to over wrap things into other things until we can't see the whole picture anymore.</rant>

Scenegraphs are great for simple tools & basic 3D and sucks for everything else. So it depends on the target audience. But OMG, Phong...are you kidding me? Cookie cutter materials? So 80s/90s. Get with the shader program (yuck, yuck) baby. I'm too lazy to try to dig-up and look at the source to see if there's a sane low level exposed...if not it's pretty worthless.

Scenegraphs are great for simple tools & basic 3D and sucks for everything else. So it depends on the target audience. But OMG, Phong...are you kidding me? Cookie cutter materials? So 80s/90s. Get with the shader program (yuck, yuck) baby. I'm too lazy to try to dig-up and look at the source to see if there's a sane low level exposed...if not it's pretty worthless.

I hope LWJGL/JOGL can benefit somehow.spasi ? Julien ? Save us with a good news please

JavaFX exposing a 3D API doesn't change anything for integration purposes, since it's at a level higher than the interesting stuff.

Speaking for LWJGL, we're exploring different options and we won't commit to anything until we try to integrate with JavaFX properly. We're currently waiting for Prism and Glass to be fully open sourced, then we'll see what's possible. There's been a lot of progress with the open sourcing of JavaFX (details here), but we'll have to a wait a few more weeks for Prism.

Spasi can confirm that it is already possible to use LWJGL to render some JavaFX thingy in a FBO, this code should not be difficult to port to JOGL 2.0 and it would benefit of some helpers allowing to have some fallbacks where FBOs are not available or too slow.

There is already a JOGL backend for JavaFX, it was working with a very old version (prior to JavaFX 2). I already talked to you about that in your bug report, I tried to be extremely accurate.

I don't want to be harsh but there are plenty of things to do with existing APIs. I won't port another temporarily trendy thing, especially if it is only used by a very few people. JavaFX has some interesting features but some of them are already present in JogAmp or we already plan to provide alternatives.

I need the whole source code of Quantum, Prism and Glass. I have to admit that I have other priorities for the next siggraph, your help would be welcome.

Yep I saw spasi's technique. I succeeded with glReadPixels and WritableImage. It's slow, but fixed pipeline must work in my case. Didn't try with FBOs.

I can't be of much help, I have zero knowledge of JOGL/LWJGL's inner working, and have my hands already more than dirty with a project using JOGL.I'll wait for what could be done when Quantum, Prism and Glass go open source, if they ever do...

In the meantime as you said there are workarounds: for me the easiest will be to mix JavaFX with Swing+JOGL.

I can't be of much help, I have zero knowledge of JOGL/LWJGL's inner working, and have my hands already more than dirty with a project using JOGL.I'll wait for what could be done when Quantum, Prism and Glass go open source, if they ever do...

I have spent a lot of time in improving the environment (the APIs) required for my own project using JOGL during 6 years. Why not sharing your findings? It would be better than nothing.

Please can you share your source code? I need something working with the fixed pipeline too. Maybe I could help you a little bit but I will start using JavaFX only when it works with OpenJDK.

Here it is.

It's a JavaFX app, that displays a red triangle on a black background using JOGL 2 rc11 (the only needed lib). The drawing is done in a hidden GLCanvas, then using glReadPixels copied into a WritableImage. You may have to click the "redraw" button to see the result at the beginning.

2 downsides: - The GLCanvas is inside a JFrame, which must be shown then hidden, otherwise all OpenGL calls will be ignored. So you can see the JFrame flashing when the app starts, which is a bit annoying.- it's very slow, it takes on average 11ms on my fairly good laptop (i7, gtx660m) mostly the call to glReadPixels I suppose

You're right but what do you mainly use in JavaFX? Personally, I'm interested in the charting API and a bit in CSS.

I need JavaFX 1) to do almost exactly what spasi did in his "Dope" project here http://www.java-gaming.org/topics/tool-dope/27389/view.html. A node-based interface. In the meantime I'm using the Netbeans Visual library, but I find it clunky. I'll definitely have to dump it at some point2) CSS GUI skinning. Swing + Nimbus is ok, but I'd prefer something more expressive.3) potentially the animation framework, and integrated browser, but laterThe neat thing with JavaFX is that it's part of Java, so (hopefully) very well supported. I try to use as few libs as possible.

Edit 3: <quote>Our current 3D implementation makes no use of the decora-compiler translator, which means that the 3d shaders are hand written which means they are different, and theoretically could introduce a bit of shader code that isn't as well tested (In practice it isn't that big of a deal). Prism's use of JSL itself is also in need of work since writing a shader is only half the battle. We need to be able to provide flexible vertex data objects/interfaces and manage these in a way that is simple and flexible if we are to provide shaders to developers.</quote>

I'm not sure I can follow what these guys are talking about, but it seems we're going to have to write OSL/Decora/Pixel Bender code, then it'll be automagically translated into GLSL / HLSL ? Well, why not... but although it'd make it easier (higher level) we could potentially be losing a lot of control if we need precise results, since we'd be relying on the underlying OSL/Decora/Pixel Bender-compatible renderer.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org