I know that openGL works wonders if you send textures to it that are static and rarely change for example like tiles. But not when you have constantly changing sprites?
Is it possible to create games like abduction purely from canvas and what would be its performance?
It is possible to create games like abduction using canvas, however eventually you are going to hit a stumbling block in terms of performance.
OpenGL whether moving or static will handle images exponentially faster, by accessing buffers and pixel processors on the gc capable of manipulating large arrays of pixels at once.
However OpenGL isn't easy it will take time to learn, and you will need to learn it's language. This said you will find tons of information on using openGL, I highly recommend the Lightweight Java Game Library (LWJGL) http://lwjgl.org/ and NeHe tutorials http://nehe.gamedev.net/.
Anyway take a look see what you think, it'll be hard but as with all hard work it'll pay off eventually.
Hope this helps.
Related
I am working on a game scene with multiple objects that need multiple materials. I extensively searched online, but I could not find any satisfactory solution.
My scene will have like a river flowing by and the material there will require a separate shader anyway (it will combine many specular and normal maps into what would look like a river) then there is a terrain that would mix two (grass and sand textures) requiring another shader. There is also a player with hands and amour and all.
EDIT: Essentially I wish to find out the most efficient way of making the most flexible multiple material/shader implementation.
Briefly, there is a lot of complex objects around requiring varied shaders. They are not many in number, but there is a lot of complexity.
So using glUseProgram() a lot of times dosn't seem like the brightest idea. Also Much of the shader code could be made univeral like point light calculation. Making a generic shader and using if's and state uniforms could possibly work, still requiring different shaders for the river and likewise diverging materials.
I basically don't understand the organization and implementation of such a generic system. I have used engines like Unreal or possibly Blender which use Node based materials and allowing the customization of every single material without much lag. How would such a system translate into base GPU code?
If you really face timing problems because of too many glUseProgram() calls, you might want to have a look at shader subroutines and use less but bigger programs. Before that, sort your data to change states only when needed (sort per shader then per material for example). I guess this is always a good practice anyway.
Honestly, I do not think your timing problems come from the use of too many programs. You might for example want to use frustum culling (to avoid sending geometry to the GPU that will be culled) and early z-culling (to avoid complex lighting computations for fragments that will be overriden). You can also use level of detail for complex geometries that are far away, thus do not need as much details.
I am creating a voxel engine. I have created chunk generation in addition to some simple simplex noise integration but it is extremely laggy due to all of the face of each quad being drawn even the ones you can't see.
To my understanding this is commonly dealt with using ray casting of which I understand the basic theory: you draw several rays from the camera and check for collision, if no collision is found then the face is not within view and therefor should not be rendered. Even though I understand the theory of it all I haven't yet been able to implement it due to lack of prior knowledge and what I found on the internet lacking i.e. they give the code but not the knowledge.
The steps I could imagine I need to take are as follows:
Learn OpenCL (though I haven't used it before to my understanding it allows you to better make use of your graphics card by the use of 'kernels' which I mentally associate with OpenGL 'shaders').
Learn the theory and math behind Ray casting. I have also have heard of ray tracing which I believe has a different use.
Learn how to use this information to not render hidden faces. Assuming I get a working implementation how would I go about telling OpenGL not to render the hidden faces? The cube is one object and to the best of my knowledge there is no way to manipulate the faces of an object in OpenGL only the vertices. Also how would OpenCL communicate with OpenGL? OpenCL isn't a graphics api so it isn't capable of drawing the rays.
Could anyone point me in the right direction? I also believe that there are pure OpenGL implementations as well but I would like to keep the OpenCL aspect as this is a learning experience.
I wouldn't recommend working with OpenCL or OpenGL in developing your first game, both will slow you down extraordinarily because each requires a different mindset.
Well done though on getting as far as you have.
You mentioned that you are currently rendering all quads all the time which you want to remove hidden ones. I have written a voxel engine for practice too and ran into this issue and spent a lot of time thinking how to fix it. My solution was to not draw faces that are facing another voxel.
Imagine two voxels next to each other, the two faces that are touching cant be seen and don't need to be rendered.
However, this will not make any difference if your method of talking with the GPU is the bottleneck. You will have to use buffered methods, I used Display Lists but it is also possible (but harder) to use VBOs.
I'd also recommend grouping large numbers of voxels into chunks for many reasons. Then you only need to recalculate the visible quads on the chunk that changed.
Regarding Ray Casting, If you adopt the chunk system I just described calculating visible entire chucks will be easier. E.g Chunks behind the player don't need to be rendered and that can be calculated with just one dot product calculation per chunk.
Learn OpenCL (though I haven't used it before to my understanding it
allows you to better make use of your graphics card by the use of
'kernels' which I mentally associate with OpenGL 'shaders').
Amd app sdk has many examples/samples from sorting numbers to doing 3d-fluid calculations on a teapot. You can also use cpu with opencl but multiple cpus can bee seen as single device. Also Nvidia and jocl and lwjgl has samples waiting to be reverese-engineered.
Learn the theory and math behind Ray casting. I have also have heard
of ray tracing which I believe has a different use
I only know that ray casting becomes a tracing if those rays cast new rays. Lots of vector algebra like cross products, dot products, normalizations of direction vectors, 3x3 4x4 matrix multiplications and many more. Higher order recursivity is bad for gpu. Try with iterative versions.
Learn how to use this information to not render hidden faces.
You can sort the distances of surface primitives that a ray intersecs and get the smallest distance one. Others shouldnt be seen if there is no refraction on that surface. Using an acceleration structure (bounded bolume hierarchy,..) helps.
The cube is one object and to the best of my knowledge there is no way
to manipulate the faces of an object in OpenGL only the vertices.
Generate in opencl, pass it to opengl, faster than immediate mode.
Also how would OpenCL communicate with OpenGL? OpenCL isn't a graphics
api so it isn't capable of drawing the rays.
Create the context with "sharing" properties to be able to use gl-cl "interop". This enables opencl-opengl communication get as fast as gpu-vram (300 GB/s for high end). Then use gl buffers as cl buffers in this context with proper synchronizations between cl and gl.(glFinish() compute() clFinish() drawArrays())
If it is not interop then communications will be as slow as pci-e bandwidth. Then generating from cpu becomes faster if compute to data ratio is low.
If there are multiple gpus to play with, then you should pack your data as short as possible. Check endianness, alignment of structures. Dont forget to define opencl(device)-side structures if there are any in host side and they must be 1-1 compatible.
I have been working on a graphical user interface which will display many 3D objects. These objects must be updated every 50 milliseconds, or at least, the colors of the objects need to be updated every 50 milliseconds. I have been using the graphics.fillPolygon() command to draw a few of these objects. So far, this has been working well for me, but is this an efficient way to draw graphics? Is there also a way to update only their color without telling the computer to redraw all of the polygons?
Java GUI is all that I know for drawing graphics, I will appreciate any recommendations for programming efficient graphics.
In your case Java is the perfect solution, java has very strong Graphics API for both 2D and 3D. Most of your task can be done easily.
If you are too much concerned with speed and you feel that Java is not performing very well than you will have to use C with OpenGL or GLUT. You might be thinking why I recomended OpenGL or Glut because they are written in C language and they can provide you thrilling fast speed.
But for now use Java, Java can make your work easier and it can give you good results.
Java and Android are almost similar so, if you get strong Java skills you can utilize them in android as well. That is a double benefit of Java.
I want to create an MMO 3D game and im looking for a 3D-Engine and my question is about javaFX 8, can i use it for render a lot of 3D cube, models and animation without lose performance or is best to use the lwjgl?
the final question is: javaFX 8 can be used as a 3D engine?
To answer your questions:
Can i use it for render a lot of 3D cube, models and animation without lose performance?
This has for many people (I think) been a question ... and while there is no clear cut answer, there are ways to make it work.
For example I had recently built a simple Cloth-Simulator,
(first Spheres for vertices, then an actual TriangleMesh)
at first I took the approach of using an AnimationTimer for my update loop, it worked, but only up to a certain range of calculations.
My second approach was to create a Timer, using ScheduledService at a fixed timeStep interval and setting it to update the UI on completion.
I was able to almost double the number of vertices before performance started to sway. Which was quite an improvement, as I was able to have 20k vertices (not that I recommend it).
You can see the results here on youtube:
ProtoType 1
ProtoType 2
Finished MeshView
So really it is all a matter of how much time you wish to spend creating solutions.
Can javaFX 8 can be used as a 3D engine?
Once again, it really all depends on how much time you want to spend developing the framework. I have personally been trying to build a tool-set for this very purpose,
not every thing pans out, but the journey is half the solution.
If you're interested in seeing my approach with the Cloth Simulation, you can find all the sources here: F(x)yzLib , as well as many other useful features/shapes etc...
Yes i think JavaFX 8 is fast enough for 3D games but it's not at the cutting edge of current 3D when it comes to shaders. I have been trying to get to grips with it but it lack's a Camera lookAt method like you get in Three.js.
Lwjgl and JMonkeyEngine are the better options for now for Java 3D game development.
I'm making this 3D space shooter with JavaFX:
http://lightspeedpatrol.weebly.com/features-and-info.html
So I can tell you that it mostly works, but the lighting options are really limited as Allan mentioned. It was a good learning tool since it was the first time i've done anything related to 3D, but in the long run I think I'd be better off using LWJGL.
javaFx is great for simple 2D games but in 3D games lwjgl or jmonkeyEngine is better than javafx ,i think it's too slow for 3D games(but in very simple things it maybe good)
So I've run into a bit of a pickle. I'm writing a library using JOGL to display 3D models (and consequently, 2D models) on a GLCanvas. Well, everything was running smoothly until I decided to call the draw method of the individual polygons of an Strixa3DElement into a thread to speed it up a bit. Before, everything drew perfectly to the screen, but VERY slowly. Now, as far as speed goes, it couldn't be better. But it's not drawing anything. Ignoring everything but what the draw method deals with, is there any reason that
https://github.com/NicholasRoge/StrixaGL/blob/master/src/com/strixa/gl/Strixa3DElement.java
shouldn't work?
Edit: Also, for the sake of avoiding concurrency issues in the thread, let's say any given element has no more than 100000 polygons.
It's better to leave render tasks in a gl thread for now.
You don't even using Display Lists. Sure, it will be very slow.
Even after that, rendering is not the speed problem: you can prepare data for rendering in another thread, leaving render loop clean and fast. (moving out this._performGameLogic etc)
You can use VBO, shaders (moving data and render logic from CPU to GPU), offscreen buffers etc etc to improve performance.
If you will continue, you should
check GLArrayDataServer class for use with VBO, unit tests and demos while writing you code.
not pass GL2 as argument: GLContext.getCurrentGL().getGL2();
should try GL2ES2: fixed functions are deprecated, allows using at mobile platforms.
join jabber conference
Some answers about JOGL&threads: Resources: Parallelism in Java for OpenGL realtime applications