Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I've an application using OpenGL to draw some content in a window (based on the example from here). Everything looks good when application running on my desktop PC with NVIDIA GeForce GTS 450 graphic card, but it looks terrible on other computers (I've tried on 2 notebooks with intgrated Intel graphic cards, and on the virtual machine running on VirtualBox).
The effect looks like this:
I've tried to manipulate gluPerspective function but without results.
What may be the reason for such effect?
EDIT:
Correct files from computer with NVIDIA attached:
I't looks like some kind of z-fighting. That is you have several geometries with overlapping or very similar Z values, and precision errors in the calculations of the Z values make that some parts of your objects are hidden.
The fact that it works in some machines and not in others may be caused by the Z-buffer being 32-bits or 16-bits, depending on the machine.
Note that even if forcing your Z-buffer to 32-bits may solve the issue, you should consider fixing the Z-values of your objects. There are (used to be?) some hardware out there that doesn't support 32-bit Z-buffers.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I’m developing an iOS app and solved the interoperability Swift-C++ in the CPU side wrapping the C++ classes in Objective-C. But on the GPU side, I don’t Know if exists any way of call and retrieve data from a pure C++ class (not MSL). Since MSL is C++ based my intuition says that yes but I didn’t find any information in that way…
I’m trying to use libraries like CGAL or FastNoise to update a massive number of particles.
Welcome!
I'm afraid you can't just access any data from any class in your GPU code. Programming for the GPU requires a very different paradigm. You have to explicitly send data to the GPU, trigger computational tasks a.k.a. "kernels" to run on the GPU, wait for their completion, and transfer the data back to the RAM.
I recommend you check out some tutorials on Metal. Here is for example a sample project where image data is modified on the GPU using compute kernels.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have tried blending and this seems to provide a basic glass effect but I feel there must be a better way to generate a glass or ice style effect. What would people suggest ? Is there something that can be done with semi-transparent textures ?
This is a very broad and complex question and the answer entirely depends on what kind of result (in terms of realism etc.) you are trying to get, what kind of lighting you want etc. Most of these effects, and materials in general, are the domain of shaders. A lot can be achieved with choosing the right textures with the right material parameters - again depending on what you consider an acceptable result.
GPU Gems book has a chapter on glass simulation (see 19.3.2):
GPU Gems 2 - Generic Refraction Simulation
When it comes to ice, there are again a ton of different things to consider depending on the complexity you want - see this answer here:
How to render realistic ice?
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 9 years ago.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Improve this question
I have a shader that is currently doing some raytracing. The shader used to take the scene information as uniforms to render the scene but this proved to be way too limited so we switched to using SSBOs (shader storage buffer objects). The code works perfectly on two computers, but another computer is rendering it very slowly. The video card for that computer is a radeon HD 6950. The video cards that are rendering it correctly are a GTX 570 and a radeon HD 7970. The scene is shown correctly on the three computers but the radeon HD 6950 is rendering it very slowly (1 FPS when we are rotating around the scene). We thought it was a openGL version problem but it doesn't seem to be the case since we updated the drivers and it still doesn't work. Any idea where the problem might be?
There are a few possibilities:
You could be falling off the fast path on that particular card. Some aspect of your rendering may not be implemented as efficiently on the lower-end card, for example.
You may be hitting the VRAM limit on the 6950, but not on the other 2 cards and OpenGL is essentially thrashing, swapping things out to main memory and back
You may have triggered software rendering on that card. There may be some specific OpenGL feature you're using that's only implemented in software for the 6950, but is hardware accelerated on the other cards.
You don't say which OS you're working with, so I'm not sure what to tell you about debugging the problem. On MacOS you can use OpenGL Profiler to see if it's falling back to software and use OpenGL Driver Monitor to see if it's paging out. On iOS you can use Xcode's OpenGL profiling instrument for both of those. I'm not sure on Windows or Linux as I don't have experience with them.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
This is a question about 3D programming in general, but I'm learning OpenGL if that makes the answer any different. What I wonder is if all of the work in displaying a image always has to start from scratch for each new frame, or if there's some way to save intermediate data that could be reused when rendering the next frame, instead of having to be recomputed? Let's say you're standing right next to a mountain, then the stuff on the other side of the mountain are occluded by the mountain, there could be a lot of stuff on the other side of the mountain that simply doesn't have to be rendered because it can't be seen. Now assume that your character can't walk particularly fast, then there's no way that the stuff on the other side of the mountain could be visible already in the next frame, or maybe not even the next 100 frames. Is it possible to avoid having to do the same occlusion check in each frame?
The problem you're referring to is called "hidden surface removal" and "occlusion culling".
In realtime graphics it's usual to rerender each frame from scratch. However every good renderer will omit all the things that are definitively not visible. There are various algorithms for this.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have a model designed in Blender that i am going to render, in my game engine built using opengl, after exporting it to collada. The model in blender is divided into groups. These groups contains vertices normals and textures with there own index. is it a good thing to do if i rendered each group as a separate vbo or should i render the whole model as a single vbo?
Rules of thumb are:
always do as few OpenGL state changes as possible;
always talk to OpenGL as little as possible.
The main reason being that talking to the GPU is costly. The GPU is much happier if you give it something it'll take a long time to do and then don't bother it again while it's working. So it's likely that a single VBO would be a better solution, unless it would lead to a substantial increase in the amount of storage you need to use and hence run against caching elsewhere.