Can graphics rendered using OpenGL work with graphics rendered not using OpenGL?
I am starting to learn OpenGL, but I am still shy when it comes to actually coding everything in OpenGL, I feel more comfortable drawing them out with JPanel or Canvas. I'm assuming that it wouldn't cause much issue code wise, but displaying it all at the same time could cause issues? Or am I stuck with one or the other?
Integrating OpenGL graphics with another non-OpenGL image or rendering boils down to compositing images. You can take a 2D image and load it as a texture in OpenGL, such that you can then use that texture to paint a surface in OpenGL, or as is suggested by your question, paint a background. Alternatively, you can use framebuffers in OpenGL to render an OpenGL scene to a texture, when can then be converted to a 2D bitmap and combined with another image.
There are limitations to this approach of course. Once an OpenGL scene has been moved to a 2D image, generally you lose all depth (it's possible to preserve depth in an additional channel in the image if you want to do that, but it would involve additional work).
In addition, since presumably you want one image to not simply overwrite the other, you're going to have to include an alpha (transparency) channel in one of your images, so that when you combine them, areas which haven't been drawn will end up showing the underlying image.
However, I would suggest you undertake the effort to simply find one rendering API that serves all your needs. The extra work you do to combine rendering output from two APIs is probably going to be wasted effort in the long run. It's one thing to embed an OpenGL control into an enclosing application that renders many of it's controls using a more conventional API like AWT. On the other hand, it's highly unusual to try to composite output from both OpenGL and another rendering API into the same output area.
Perhaps if you could provide a more concrete example of what kinds of rendering you're talking about, people could offer more helpful advice.
You're stuck with one or the other. You can't put them together.
Related
I'm looking for some way to set background image with barrel distortion effect(FishEye/FOV) for node using JavaFX. I found algorithm with pixel manipulation, but I want to find some another way(some hack) for reach it. This effect will be use for create node background high definition image changing animation(animation wil be change factor(power/value/degree?)) of this effect.
I'd like to offer an alternative approach which is much more efficient (real-time capable). Any solution which is based on direct pixel manipulations is doomed to be very inefficient especially for a "high definition image".
Instead I'd propose to use a TriangleMesh for this and use the image as its texture. You can then apply any kind of distortion you like by just manipulating the texture coordinates. This approach can be easily integrated into any 2D graphics via the JavaFX scene graph.
I am actively using this concept for on-the-fly reprojection of raster map tiles, so I know it works.
I will answer this question in the spirit that it was asked, i.e. no code.
JavaFX has an effect framework.
There is no in-built fisheye effect.
You could create your own custom fisheye effect implementation and plug it into the effect framework if you are a skilled developer.
Easier would be to apply your algorithm using a WritableImage with a PixelWriter or Canvas. Perhaps that could even plug into the effect framework (if you actually needed to do that, which you probably don't) using an ImageInput.
For an example of applying an algorithm to the pixels in an input image see:
Reduce number of colors and get color of a single pixel
Of course, you would use a fisheye algorithm (coded for JavaFX instead of the linked implementations) for a fisheye transform.
To animate use an AnimationTimer or, again for skilled developers, create a custom transition that plugs into the JavaFX animation framework.
You can add properties to your custom effect and manipulate them using additional properties defined on the custom transition you create.
Providing a complete solution is out of scope for a StackOverflow answer. To get help with individual tasks, split the problem up into different pieces, e.g. creating a custom effect, manipulating pixels to create a fisheye, animating an effect on an image or timeline, etc. Write the code and ask questions about the actual code with a minimal example for the problem portion you are trying to solve when you get stuck.
I'm having quite a bit of difficulty wrapping my head around the actual display side of things with libgdx. That is, it just seems fairly jumbled in terms of what needs to be done in order to actually put something up onto the screen. I guess my confusion can sort of be separated into two parts:
What exactly needs to be done in terms of creating an image? There's
Texture, TextureRegion, TextureAtlas, Sprite, Batch, and probably a
few other art related assets that I'm missing. How do these all
relate and tie into each other? What's the "production chain" among
these I guess would be a way of putting it.
In terms of putting
whatever is created from the stuff above onto the monitor or
display, how do the different coordinate and sizing measures relate
and translate to and from each other? Say there's some image X that
I want to put on the screen. IT's got it's own set of dimensions and
coordinates, but then there's also a viewport size (is there a
viewport position?) and a camera position (is there a camera size?).
On top of all that, there's also the overall dispaly size that's
from Gdx.graphics. A few examples of things I might want to do could
be as follow:
X is my "global map" that is bigger than my screen
size. I want to be able to scroll/pan across it. What are the
coordinates/positions I should use when displaying it?
Y is bigger
than my screen size. I want to scale it down and have it always be
in the center of the screen/display. What scaling factor do I use
here, and which coordinates/positions?
Z is smaller than my screen
size. I want to stick it in the upper left corner of my screen and
have it "stick" to the global map I mentioned earlier. Which
positioning system do I use?
Sorry if that was a bunch of stuff... I guess the tl;dr of that second part is just which set of positions/coordinates, sizes, and scales am I supposed to do everything in terms of?
I know this might be a lot to ask at once, and I also know that most of this stuff can be found online, but after sifting through tutorial after tutorial, I can't seem to get a straight answer as to how these things all relate to each other. Any help would be appreciated.
Texture is essentially the raw image data.
TextureRegion allows you to grab smaller areas from a larger texture. For example, it is common practice to pack all of the images for your game/app into a single large texture (the LibGDX “TexturePacker” is a separate program that does this) and then use regions of the larger texture for your individual graphics. This is done because switching textures is a heavy and slow operation and you want to minimize this process.
When you pack your images into a single large image with the TexturePacker it creates a “.atlas” file which stores the names and locations of your individual images. TextureAtlas allows you to load the .atlas file and then extract your original images to use in your program.
Sprite adds position and color capabilities to the texture. Notice that the Texture API has no methods for setting/getting position or color. Sprites will be your characters and other objects that you can actually move around and position on the screen.
Batch/SpriteBatch is an efficient way of drawing multiple sprites to the screen. Instead of making drawing calls for each sprite one at a time the Batch does multiple drawing calls at once.
And hopefully I’m not adding to the confusion, but another I option I really like is using the “Actor” and “Stage” classes over the “Sprite” and “SpriteBatch” classes. Actor is similar to Sprite but adds additional functionality for moving/animating, via the act method. The Stage replaces the SpriteBatch as it uses its own internal SpriteBatch so you do not need to use the SpriteBatch explicitly.
There is also an entire set of UI components (table, button, textfield, slider, progress bar, etc) which are all based off of Actor and work with the Stage.
I can’t really help with question 2. I stick to UI-based apps, so I don’t know the best practices for working with large game worlds. But hopefully someone more knowledgeable in that area can help you with that.
This was to long to reply as a comment so I’m responding as another answer...
I think both Sprite/SpriteBatch and Actor/Stage are equally powerful as you can still animate and move with Sprite/SpriteBatch, but Actor/Stage is easier to work with. The stage has two methods called “act” and “draw” which allows the stage to update and draw every actor it contains very easily. You override the act method for each of your actors to specify what kind of action you want it to do. Look up a few different tutorials for Stage/Actor with sample code and it should become clear how to use it.
Also, I was slightly incorrect before that “Actor” is equivalent to Sprite, because Sprite includes a texture, but Actor by itself does not have any kind of graphical component. There is an extension of Actor called “Image” that includes a Drawable, so the Image class is actually the equivalent to Sprite. Actor is the base class that provides the methods for acting (or “updating”), but it doesn’t have to be graphical. I've used Actors for other purposes such as triggering audio sounds at specific times.
Atlas creates the large Texture containing all of your png files and then allows you to get regions from it for individual png's. So the pipeline for getting a specific png graphic would be Atlas > Region > Sprite/Image. Both Image and Sprite classes have constructors that take a region.
I have spent a bit of time researching about whether it is possible to draw on top of a VLCJ movie within a Java application. I have found a few bits of conflicting advice some saying it is not possible and some referencing articles which have moved on oracle.com.
Can someone clarify if it is or is not possible to draw java2d graphics like rectangles/lines which also have transparent backgrounds so the video stream underneath can be viewed whilst the shapes are present on screen?
If this is not possible with vlcj what would be a good alternative for a linux and windows compatible media player allowing for annotation over a playing video stream? Please note i do not have to be limited to java but something where i can get re-use out of developed drawing routines for multiple platforms would be ideal.
Yes, you can do it. For the normal hardware rendered video player, you need to have at least Java 6u10 (preferably 7) and achieve this by overlaying a transparent JWindow on top of the VLC canvas (it's not too hard to add events to the canvas to check for updates in position / size and then move the overlayed window correspondingly.)
The other way that doesn't involve using overlaid windows is to use a DirectMediaPlayer, where you have access to the framebuffer directly (and can therefore do what you like with the pixels, including wrapping them as textures round 3D objects and so on.) So with this approach, you could simply draw what you wanted onto the frame buffer before rendering it to screen in the way you chose. This is the most flexible approach, but comes with the downside that if you're not very careful about your implementation, you lose all the GPU acceleration and end up crippling the CPU, especially for HD video.
If a simple overlay would do the trick, I'd try that first, and just resort to a DirectMediaPlayer if you have to.
I need a suggestion/idea how to create a 3D Tag Cloud in Java (Swing)
(exactly like shown here: http://www.adesblog.com/2008/08/27/wp-cumulus-plugin/)
, could you help, please?
I'd go either with Swing and Java2D or OpenGL (JOGL).
I used OpenGL few times and drawing text is easy using JOGL's extenstions (TextRenderer).
If you choose Swing, than the hard part will be implementation of a 3D transformation. You'd have to write some sort of particle system. The particles would have to reside on a 3D sphere. You personally would be responsible of doing any 3D transformation, but using orthogonal projection that would be trivial. So it's a nice exercise - what You need is here: Wiki's spherical coord sys and here 3d to 2d projection.
After You made all of the transformation only drawing is left. And Java2D and Swing have very convenient API for this. It would boil down to pick font size and draw text at given coordinates. Custom JPanel with overriden paintComponent method would be enough to start and finish.
As for the second choice the hardest part is OpenGL API itself. It's procedural so if You're familiar mostly with Java You would have hard time using non-OO stuff. It can get used to and, to be honest, can be quite rewarding since You can do a lot with it. If you picked OpenGL than you would get all the 3D transformations for free, but still have to transform from spherical coordinate system to cartesian by yourself (first wiki article still helpful). After that it's just a matter of using some text drawing class, such as TextRenderer that comes with JOGL distribution.
So OpenGL helps You with view projection calculations and is hardware accelerated. The Java2D would require more math to use, but in my opinion, this approach seems a bit easier. Oh, and by the way - the Java2D tries to use any graphic acceleration there is (OpenGL or DirectDraw) internally. So You are shielded from certain low-level problems.
For both options You need also to bind mouse coordinates s to rotational speed of sphere. Whether it's Java2D or OpenGL the code will look very similar. Just map mouse coordinates related to the center of panel to some speed vector. At the drawing time You could use the vector to rotate the sphere accordingly.
And one more thing: if You would want to try OpenGL I'd recommend: Processing language created on MIT especially for rich graphic applets. Their 3D API, not so coincidentally, is almost the same as OpenGL, but without much of the cruft. So if You want the quickest prototype that's the best bet. Consult this discussion thread for actual example. Note: Processing is written in Java.
That's not really 3D. There are no perspective transformations or mapping the text on some 3D shape (such as, say, a sphere). What you have is a bunch of strings where each string has an associated depth (or Z order). Strings "closer" to you are painted with a stronger shade of gray and larger font size.
The motion of each string as you move the mouse is indeed a 3D shape which looks like a slanted circle around a fixed center - with the slant depending on where the mouse cursor is. That's simple math - if you figure it for one string, you figure it out for all. And then the last piece would be to scatter the strings so that they don't overlap too much, and give each one the initial weight based on their frequency.
That's what most of the code is doing. So you need to either do the math, or translate the ActionScript to Java2D blindly. And no, there is no need for JOGL.
Why don't you just download the source code, and have a look? Even if you can't write PHP, it should still be possible to read it and figure out how the algorithm works.
I'm in the process of writing a custom heatmap generator. I'm wondering what the fastest way is to draw boxes (up to around 1 million) in Java. Most questions I've found have concentrated on dynamic images (like in games), and I'm wondering if there's a better way to go for static images. I've tried using swing (via a GridLayout and adding a colored canvas to each box), drawing directly on the panel with Graphics2D, and also by using the Processing libraries. While Processing is pretty fast and generates a clean image, the window seems to have problems keeping it; it generates different parts of the image whenever you minimize, move the windows, etc.
I've heard of OpenGL, but I've never touched it, and I wanted some feedback as to whether that (or something else) would be a better approach before investing time in it.
For static images, I paint them to a BufferedImage (BI) and then draw that via Graphics2D.
I keep a boolean that tells me whether the BI is up to date. That way I only incur the expensive painting cost once. If you want to get fancy, you can scale the BI to handle minor resizing. For a major resizing you'll probably want to repaint the BI so as not to introduce artifacts. It's also useful for overlaying data (such as cross hairs, the value under the cursor, etc) as you're only painting the BI and the data.