I have two modes to continue programming a hexagonal map in this moment, and I don't know what way is better. Maybe you can help me :)
I used a texture to represent the "grid", so the squad with this texture is static and don't move or edit in runtime.
In the first hand, I have a texture with 7700x6736 pixles, however, his size it's only 3.131KB, when I run in a random engine (Unity in this case) the frame rate it's nice (constants 60fps with VSynk and +100 without VSynk)
This texture is associated in one transparent material to the squad (2 triangles)
With the second mode, I have a 14 textures to 550x496 pixels and 21KB. But with this mode, I need 14 squads (28 triangles against 2) and 14 materials with differents textures, against 1 in the other way.
Too, with this second mode, I need asking the distance of every squad to hide or not hide (a simple occlusion culling)
What is the better way in your opinion?
While your 7k texture works on your dev machine it may be not supported in some of the platforms you'll target. I'd use a 2048^2 as a safe maximum, or even a 1024^2.
The second problem is that it may use 3MB as a JPG/PNG compressed file, but in your video memory it will be as an uncompressed one (unless you use some texture-specific compression, but you may have problems with platform support again).
Additionally - you should consider if you really need the Non Power Of Two textures, officially they should be supported ATM, but you can still get into problems on some older hardware.
In general your solution depends on the platforms that you want to target, and especially if you plan to target mobile devices (and which ones).
Related
So, Vulkan introduced subpasses and opengl implelemts similar behaviour with ARM_framebuffer_fetch
In the past, I have used framebuffer_fetch successfully for tonemapping post-effect shaders.
Back then the limitation was that one could only read the contents of the framebuffer at the location of the currently rendered fragment.
Now, what I wonder is whether there is any way by now in Vulkan (or even OpenGL ES) to read from multiple locations (for example to implement a blur kernel) without having a tiled hardware to store/load to RAM.
In theory I guess it should be possible, the first pass wpuld just need to render slightly larger than the blur subpass, based on kernel size (so for example if kernel size was 4 pixels then the tile resolved would need to be 4 pixels smaller than the in-tile buffer sizes) and some pixels would have to be rendered redundantly (on the overlaps of tiles).
Now, is there a way to do that?
I seem to recall having seen some Vulkan instruction related to subpasses that would allow to define the support size (which sounded like what I’m looking for now) but I can’t recall where I saw that.
So my questions:
With Vulkan on a mobile tiled renderer architecture, is it possible to forward-render some geometry and the render a full-screen blur over it, all within a single in-tile pass (without the hardware having to store the result of the intermediate pass to ram first and then load the texture from ram when bluring)? If so, how?
If the answer to 1 is yes, can it also be done in OpenGL ES?
Short answer, no. Vulkan subpasses still have the 1:1 fragment-to-pixel association requirements.
At work, I work with very large images.
I currently do my rendering via SDL2.
The max texture size on the graphics card my machine uses is 8192x8192.
Because my data sets are larger than what will fit in a single texture, I split my image into multiple textures after it is loaded, and tile them.
However, I have found that this comes at a very steep cost. Rendering only 4 textures around 5K by 5K (pixels) each completely tanks the framerate!
Conventional wisdom tells me that the fewer texture swaps the better, but with such large images I've found myself between a rock and a hard place.
One thing I've considered is that perhaps if I were to chunck the images up into many small textures, I could take advantage of culling which would hopefully be a net win. But there's a big problem with that approach - I need to be able to zoom out.
Another option would be to down scale the images. This seems promising as the analysis I am doing on the images do not require the high resolution that the images provide.
I know that OpenGL has mipmapping, but I am inexperienced with OpenGL and am weary of diving into it for a work project. I am not aware of a good way to downscale the images within the confines of SDL2, and for reasons specific to the work I am doing, scaling the images down offline (before I load them) is not appealing.
What is the best approach for me to get the highest framerate in this situation?
Non power of two textures are very slow in OpenGL ES 2.0.
But in every "render-to-texture" tutorial I saw, people just take screen size (which is never pow2), and just make texture from it.
Should I render to pow2 texture (with projection matrix correction), or there is some kind of magic with FBO?
I don't buy into the "non power of two textures are very slow" premise in your question. First of all, these kinds of performance characteristics can be highly hardware dependent. So saying that this is true for ES 2.0 in general does not really make sense.
I also doubt that any GPU architectures developed within the last 5 to 10 years would be significantly slower when rendering to NPOT textures. If there's data that shows otherwise, I would be very interested in seeing it.
Unless you have conclusive data that shows POT textures to be faster for your target platform, I would simply use the natural size for your render targets.
If you're really convinced that you want to use POT textures, you can use glViewport() to render to part of them, as #MaticOblak also points out in a comment.
There's one slight caveat to the above: ES 2.0 has some limitations on how NPOT textures can be used. According to the standard, they do not support mipmapping, and not all wrap modes. The GL_OES_texture_npot extension, which is supported on many devices, gets rid of these limitations.
I've found that the maximum texture size that my opengl can support is 8192 but the image that I'm working with is 16997x15931. As you can see in this link, I've completed the class COpenGLControl and customized it for my own use to work with a smaller 7697x7309 image and activated different navigation tasks for it.
Render an outlined red rectangle on top a 2D texture in OpenGL
but now in the last stages of work, I've decided to change the part where applies the texture and enable it to handle images bigger than the size 8192.
Questions:
Is it possible in my opengl?
what concept should I study mipmaps, multiple texturing?
Will it expand performance of code?
Right now my program uses 271 MB of ram for just showing this small image(7697x7309) and I'm going to add a task to it (for image-processing filtering processes) that I have used all my effort to optimize the code but it uses 376 MB of ram for the (7697x7309) image(the code is already written as a console application will be combined with this project). So I think the final project would use up to 700 MB of ram for images near the 7000x7000 size. Obviously for the bigger image (16997x15931 ) the usage of ram will be alot higher!
So I'm looking for a concept to handle images bigger than the MAX_TEXTURE_SIZE and also optimize the performance of the program
More Questions:
What concept should I study in OpenGL to achieve the above goal?
explain alittle about the concept that you suggest?
I've asked the question in Game Developement too but decided to repeat the question here maybe it will have more viewers. As soon as I get the answer, I will delete the question from either on of the sites. So don't worry about multiple questionings.
I will try to sum up my comments for the original question.
know your proper opengl version: maybe you can load some modern extension and work with even the recent version of opengl.
if it is possible you can take a look at Sparse Textures (Mega Textures): ARB_sparse_texture or AMD_sparse_texture
to reduce memory you can use some texture compression:
How to: load DDS files in OpenGL.
another simple idea: you can split the huge texture and create 4 smaller textures (from 16k x 16k into four 8k x 8k) and somehow render four squares.
maybe you can use OpenCL or CUDA to do the work?
regarding mipmaps: it is set of smaller version of your input texture, mipmaps improve performance and final quality of the filtering, but you need another 33% more memory for a texture with full mipmap chain. In your case they could be very helpful. For instance when you look at a wall from a huge distance you do not have to use full (large) texture... only a small version of it is enough. g-truc on mipmaps
In general there is a lot of options, but it depends on your experience what is simpler and fastest to implement.
I am interested in learning about 3D video game development, but am not sure where to start really.
Instead of just making it which could be done by various game makers, I am more interested in how it is done.
Ideally, I would like to know in which format general 3D models, etc. are stored.(coordinate format etc.) and information on how to represent the 3D data on the screen from a certain perspective such as in general free roaming 3D video games like Devil May Cry.
I have seen some links regarding 3D matrices but I really don't understand how they are used. Any help for beginners would be much appreciated.
Thanks
Video game development is a huge field requiring knowledge in game theory, computer science, math, physics and art. Depending on what you want to specialize on, there are different starting points. But as this is a site for programming questions, here some insights on the programming part of it:
File formats
Assets (models, textures, sounds) are created using dedicated 3rd party tools (think of Gimp, Photoshop, Blender, 3ds Max, etc), which offer a wide range of different export formats. These formats usually have one thing in common: They are optimized for simple communication between applications.
Video games have high performance requirements and assets have to be loaded and unloaded all the time during gameplay. So the content has to be in a format that is compact and loads fast. Often 3rd party formats do not meet the specific requirements you have in your game project. For optimal performance you would want to consider developing your own format.
Examples of assets and common 3rd party formats:
Textures: PNG, JPG, BMP, TGA
3D models: OBJ, 3DS, COLLADA
Sounds: WAV, MP3
Additional examples
Textures in Direct3D
In my game project I use an importer that converts my textures from one of the aforementioned formats to DDS files. This is not a format I developed myself, still it is one of the fastest available for loading with Direct3D (Graphics API).
Static 3D models
The Wavefront OBJ file format is a very simple to understand, text-based format. Most 3D modelling applications support it. But since it is text based the files are much larger than equivalent binary files. Also they require lots of expensive parsing and processing. So I developed an importer that coverts OBJ models to my custom high performance binary format.
Wave sound files
WAV is a very common sound file format. Additionally it is quite ideal for using it in a game. So no custom format is necessary in this case.
3D graphics
Rendering a 3D scene at least 30 times per second to an average screen resolution requires quite a lot calculations. For this purpose GPUs were built. While it is possible to write any kind of program for the GPU using very low level languages, most developers use an abstraction like Direct3D or OpenGL. These APIs, while restricting the way of communicating with the GPU, greatly simplify graphics related tasks.
Rendering using an API
I have only worked with Direct3D so far, but some of this should apply to OpenGL as well.
As I said, the GPU can be programmed. Direct3D and OpenGL both come with their own GPU programming language, a.k.a. Shading Language: HLSL (Direct3D) and GLSL. A program written in one of those languages is called a Shader.
Before rendering a 3D model the graphics device has to be prepared for rendering. This is done by binding the shaders and other effect states to the device. (All of this is done using the API.)
A 3D model is usually represented as a set of vertices. For example, 4 vertices for a rectangle, 8 for a cube, etc. These vertices consist of multiple components. The absolute minimum in this cases would be a position component (3 floating point numbers representing the X, Y and Z offsets in 3D space). Also, a position is just an infinitely small point. So additionally we need to define how the points are connected to a surface.
When the vertices and triangles are defined they can be written to the memory of the GPU. If everything is correctly set, we can issue a Draw Call through the API. The GPU then executes your shaders an processes all the input data. In the last step the rendered triangles are written to the defined output (the screen, for example).
Matrices in 3D graphics
As I said before, a 3D mesh consists of vertices with a position in 3D space. This positions are all embedded in a coordinate system called object space.
In order to place the object in the world, move, rotate or scale it, these positions have to be transformed. In other words, they have to be embedded in another coordinate system, which in this case would be called world space.
The simplest and most efficient way to do this transformation is matrix multiplication: From the translation, rotation and scaling amounts a 4x4 matrix is constructed. This matrix is then multiplied with each and every vertex. (The math behind it is quite interesting, but not in the scope of this question.)
Besides object and world space there is also the view space (coordinate system of the 'camera'), clip space, screen space and tangent space (on the surface of an object). Vectors have to be transformed between those coordinate systems quite a lot. So you see, why matrices are so important in 3D graphics.
How to continue from here
Find a topic that you think is interesting and start googling. I think I gave you quite a few keywords and I hope I gave you some idea of the topics you mentioned specifically.
There is also a Game Development Site in the StackExchange framework which might be better suited for this kind of questions. The top voted questions are always a good read on any SE site.
Basically the first decision is wether to use OpenGL or DirectX.
I suggest you use OpenGL because its Platform independent and can also be used for mobile devices.
For OpenGL here are some good tutorials to get you started:
http://www.opengl-tutorial.org/