Is there any way to use your own custom GLSL shaders with JavaFX? I am currently using Java 8 162 and find that there is a serious lack of JavaFX 3D documentation.
Is there any way to use your own custom GLSL shaders with JavaFX?
No. GLSL shaders are compiled at runtime and are bound to the OpenGL graphics pipeline, which is internal. There was a request for this in the past, but no one put in the work for it.
You might be able to hack something in if you build JavaFX locally. It depends on how extensive the changes you want to make are. You can add shaders like the one in modules/javafx.graphics/src/main/resources/com/sun/prism/es2/glsl/main1Light.frag (and main2Lights and main3Lights). You will then need to change com.sun.prism.es2.ES2PhongShader accordingly, at the very least.
What shader are you trying to make? Maybe it can be built into JavaFX if it's reasonable.
there is a serious lack of JavaFX 3D documentation
Yes. Many internal classes have "TODO: 3D - Need documentation" comments on them too. I suggest that you write to the mailing list a request for what documentation you would like to see exactly.
Related
I have started working on javafx . I wanted to know the difference between javafx and Tornadofx . How they are inter-related and different from each other.
Also when to use what.
Are there any cases where javafx is more useful/advised to use than Tornadofx or vice-versa?
JavaFX is more like a toolkit (it has all the foundation needed for building a GUI). It is a feature-complete "toolkit", but it is very verbose, and the syntax contains boilerplate code, which makes it hard to maintain. That's where TornadoFX comes in. TornadoFX is like a framework based on that toolkit, which does away with all the boilerplate code, and makes the GUI building declarative, to the point that it resembles HTML.
Also, even though TornadoFX can be used from Java, it is meant to be used from Kotlin (JavaFX can be used from Kotlin also, without any issues).
TornadoFX simplifies and streamlines the GUI building process (makes the code cleaner), but it uses JavaFX "under the hood", and as such, is interoperable with JavaFX.
For example, you can create a widget in pure JavaFX code, and then use it within TornadoFX, or, for example, create a whole window in TornadoFX, and then call it from JavaFX.
The main takeaway here is that TornadoFX doesn't restrict JavaFX in any way, and you can still reach low-level JavaFX stuff from TornadoFX.
Besides just the GUI builders, TornadoFX also contains useful tools like the ViewModel classes, which separate the GUI and logic (which is available, but not mandatory in any way), and some other useful tools.
Personally, I'd always use TornadoFX, because it makes the code very concise and easily-maintainable, while, at the same time, no features of JavaFX are lost.
Currently accepted answer didn't answer this part
Are there any cases where javafx is more useful/advised to use than
Tornadofx
The point of the accepted answer is that for standard simple GUIs Kotlin combined with TornadoFX will get you up an running quick. This is true.
Some examples where straight JavaFX is better:
JavaFX 3D subscenes
interops with Swing (I'm not sure how you would even use Kotlin here, but maybe TornadoFX by itself would work)
Canvas based renders
High Performance custom Event processing
Clearly these are scenarios that do not represent the majority of GUI apps, rather high performance and custom render type applications. So generally speaking if you are starting from scratch... ie... you aren't already well versed in JavaFX, then using TornadoFX is a good starting point.
On that note opting to use Kotlin as a starting point is interesting as well. I personally don't find it that advantageous over just writing in JavaFX, but I have a lot of experience with JavaFX so I might be biased. Also while you are not forced to do so... it is painful to develop in kotlin without intelliJ which is all part of that company's plan for making Kotlin in the first place.
All that said:
and the syntax contains boilerplate code
This is true to an extent and Tornado does reduce the boilerplate a bit by forcing you to go through a standardized set of APIs.
But...
which makes it hard to maintain.
I disagree. It is not "hard" to maintain. It's code you copy/paste one time and likely never changed again. We should not be rushing so fast to obscure and encapsulate every last ASCII character from our code bases in the name of "maintainability" while shooting a torpedo into the side of our performance.
I am working on OpenGL to create a GUI .I want to create some tabs which will help me to display different things in different windows. How is this possible using OpenGL? I read in some articles that we can use QT for that. Since I have already developed some of the GUI part in OpenGL using GLUT library ,is it possible to use the same code in QT? If so brief me how to make settings for OpenGL libraries in QT creator.
In my GUI I am trying to create a Car which is following a track.
I think you might be mixing some things up: OpenGL is a API with which you can instruct drivers to draw visual primitives, like lines, boxes, 3D triangles, pictures from buffer onto a render plane.
GLUT is a library that gives you a minimal environment around that, ie. it handles creating a window etc.
Neither of them are high-level UI description tools. Qt is really most likely what you want, as it will not only give you things like tab widgets etc, but also a feature-rich framework to do things like defining what should happen when you click a button, close a window etc.
There's a lot of examples of OpenGL usage within Qt widgets. In fact, a lot of visualization frontends use Qt and OpenGL. Qt has extensive documentation on how to generate OpenGL contextes and draw inside Qt applications.
I have been looking far and wide to find out how, if it’s possible, you can fill a particular area in a QML screen with an OpenGL context and do custom OpenGL only in that context. I’ve seen plenty of demos where the QML components like buttons, etc lay on top or below a screen-wide OpenGL context (as is typically required by games), but I’d like to be able to situate several distinct OpenGL contexts within QML and have the QML file define how large they are, where they are positioned, etc.
Now, since Qt 5 is all OpenGL under the hood, it makes me wonder if using a Canvas element with custom drawing via javascript could result in similar rendering performance as custom OpenGL? This would be a meaningful alternative but it’s not clear to me how the javascript drawing is handled via runtime compared to custom OpenGL drawing.
What is it that you want to draw? QQuickPaintedItem may be the simplest way to go about it. When you're using QOpenGLFramebufferObject as the target, the painter will use OpenGL to paint the texture. It might be easier than writing your own OpenGL code if all you're doing is 2D.
I have enabled qt+OpenGl+SimpleGl on one of the ARM platform and was able to run opengl example programs.
I also has a qt+Webkit, which is working with a graphic plugin.
I wanted to use simpleGl context for every thing, instead of using the normal graphic screen. So, when I try to run Qt+Webkit with simpleGl, I just get a blank screen.
Does QT support this? If so how can we make it?
Yes, this is correct. OpenGL draws directly to the framebuffer. The simplegl driver doesn't handle what is drawn using the raster paint engine of the QWS, so you may see only black.
Using simplegl for "everything" means you want everything to be drawn using OpenGL in your EGL full-screen window? This is possible under some assumptions. You have to write all your applications to be rendered using the Qt OpenGL paint engine (using the opengl graphics system is not supported under Qt/E). This is possible also for QtWebKit, I'm doing it now. Note that this does not mean that everything is rendered using hardware acceleration. You'll have to write your applications "the right way" to get all actually hardware accelerated. Consider that you'll have to handle the mouse pointer some other way in this case.
The other way is to just modify the simplegl driver to allow for the use of Qt applications using the raster paint engine. This is possible as well with some limitations. Qt can use blit to place its own windows over OpenGL. Look for the framebuffer driver inside the Qt source tree to know how to do this. You can then have common Qt applications and OpenGL Qt applications some way. I'm doing this as well. Not everything can be done anyway.
EDIT: I'm sure you already did, but in case, give this http://doc.qt.io/qt-4.8/qt-embeddedlinux-opengl.html much attention.
Unfortunately I don't know anything about SimpleGL, but I do know that there is a way to render a standard Qt widget in a QGLWidget. Maybe have a look at this Qt Quarterly which I think is somewhat related to your question:
http://doc.qt.nokia.com/qq/qq26-openglcanvas.html
I need an appropriate rendering engine to render a 3D model into Qt, and use Qt then as an event handler to this model. Thank you.
As for the rendering engine, you can go several directions, but I'll mention two. Qt comes with an OpenGL widget. You could make use of this by either:
writing your own rendering code to render your model using OpenGL
or
making use of a rendering engine/framework which has it's own Qt Widget (possibly derived from Qt's OpenGl widget). I know OpenSceneGraph has Qt integration available. And I seem to remember Ogre does as well. This just to mention two options. Just Google for Qt and your favorite engine and you'll most likely find something suitable. And if not, it is usually not that difficult to write your own integration if you feel like it.
Whichever option is more suitable for you depends on the exact specification of what you're trying to achieve. You probably know that better than we do.
As for the event handling, you might want to be a bit more specific as to what you mean.