I'm trying to make anaglyps to show antenna diagrams for my students. I used one of the classic techniques by using glAccum: Draw left eye, 'load' into the accumulator, draw right eye, and Accumulate, the bring the Accu back in front. (Note that I know this does not produce a perfect anaglyph. After all I'm not even using perspective projection - I use glOrtho (maybe that is the problem?). I am just concerned why glAccum isn't working as expected)
This seems to work, but only partly.
The image shows an axis system in 3D, which shows that the generation actually works, but at the left, RED incorrectly overwrites CYAN while at the right, CYAN actually mixes with RED producing white, as it should do. Maybe the following images are clearer:
The left image show expected color addition while the right image shows red overwriting cyan.
Can anyone shed some light on this? The actual plot is more complicated of course.
BTW, I know of the other methods to generate anaglyphs...
Well, #Bahbar's idea pointed me into the right direction. Though I have actually seen various pages with examples where it's not done, I suspected that clearing the depth buffer could have an effect on the graph. So I added
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
in between rendering both views, and the problem was solved!
Looking around more on the 'net, I actually found examples where it is done that way. I'm happy - I even added the correct, frustum-based stereo perspective. The result is:
Thanks for the attention, maybe this can help someone else...
Related
I needed to make an object in my game transparent, but it wasn't working properly. So, after some research, I later found out how to properly do alpha blending in Direct3D9 and implemented some code to make the object finally transparent. However, while I have a basic idea of it, I am still a bit confused on how it all works. I have done lots of research, but I have only found very vague answers which just left me more confused. So, what do these two lines of code really mean and do?
d3ddev->SetRenderState(D3DRS_SRCBLEND, D3DBLEND_SRCALPHA);
d3ddev->SetRenderState(D3DRS_DESTBLEND, D3DBLEND_INVSRCALPHA);
Alpha blending in D3D is done according to this equation
Color = TexelColor x SourceBlend + CurrentPixelColor x DestBlend
The setting you quote sets the "SourceBlend" to the alpha value of the source texture. The value of DestBlend is set to one minus the alpha value of the source texture. This is a classic post-blending setting. This kind of mode is used to "anti-alias" an image, for example to blur the edges of a circle so that they do not look pixelated. It is quite good for things like smoke effects or for semi-transparent objects like plastics.
Why do have to specify it? Well if you set the DestBlend to always be one, you get a kind of "ghosting" effect, like when you partially see a reflection in a pane of glass. This effect is particularly good when used with an environment map. Pre-blending can also be useful, but requires you change the format of your inputs.
I am currently working on my game-engine and I run into some troubles I can not figure out myself. I changed my mind about setting up my own math library so I went back to use GLM because it is a perfect solution.
But here comes the problem, with my Code everything worked well but now with the functions changed I get a problem with object clipping and intersection.
Zoomed In
This first image shows how my scene looks when it is zoomed in. Everything looks almost perfect and the plane intersects the cube properly.
Zoomed Out
Scrolling out the intersection gets randomly dissorted and I cannot explain what's happening nor do I have any clue where my problem is located.
This is the way I calculate my projection Matrix:
proj = glm::perspective((double)fovy, (double)aspect, (double)nearPlane,(double) farPlane);
and this is the way I calculate the view:
view = glm::lookAt(pos, tar, gameObject->transform.getUp());
I know I should poste more code but there is so much that I really don't know where to start. So please tell me which code could be of importance and I poste it. Thank you very much in advance and I hope somebody could help me. If more pictures are needed please tell me.
It looks like you don't have enough depth resolution. This happens when nearPlane is very small and farPlane is very large. For example, 0.0001 to 10000.0 will give you low depth resolution.
Make nearPlane larger and farPlane smaller.
I have made several attempts to fix this and read all I could find here/forum/google. I used a CCD treshold mush lower than my objects move speed and using a CCD radius much smaller than the objects half radius. The only thing this does is make the multisphere get stuck on seams. I also tried to set ERP/ERP2 to 0.9/1.0.
[EDIT] Ok, so after some more reading; CCD will not work if the sphere is already touching the ground and ERP only affeccts objectts with joints if I understand correctly.
The ground is a trimesh made in Blender and using the obtainStaticNodeShape to get the shape. I have tried to scale the mesh to get smaller polygons but even the smallest (for the game acceptable) size does not work, about 32k indices with 11k polys, 500x500 units, the multisphere has a radius of 0.45 units.
[EDIT] the multi-sphere is two spheres on top of each other and they are restricted to angular movement around the Y-axis only, so no rolling.
The sphere gets "sucked" fast through the ground it does not sink slowly. I tried to make the fixedtimestep smaller 1/420 with 64 substeps did not give any better results. This happens most often while ascending or descending a slope. My ground is gently sloped but an incline of 20% seems to be enough for it to fall through a lot but it can happen on level ground too, just not as often.
When I did my first test I used a big stretched out cube as ground and it worked well.
So my problem now is I don't even know why this is happening so I have no idea what to try next? Can anyone please give me a solution or some pointers.
Is there any use in increasing the multi-sphere size (for the game I can not increase more than 25-30%) I have not explicitly set any collision margins but I think this would just make my sphere float over the ground? Is there any profit in changing the ground from a static object to a kinematic?
Would it work to use a raytest from the sphere straight down and push it up if it is lower than the ground? I think not, why would it fall through if it could detect the ground in the first place..?
[EDIT: additional info]
There are quite a few occurrences of similar problems floating around on forums and also here at stack overflow. Most seem to be about very small objects. Small objects (>0.2m) is clearly not a good option for bullet unless you want to increase the number of simulation steps quite a lot. My problems does not seem to fall under this category since my smallest object is 0.9m in diameter?
I have now also done a debug draw to see the normals of the trimesh that I use as ground. I can not find any errors with the normals.
I also tried to increase the collission margins of the speheres but to no avail.
I further tried to use suggested settings:
((btDefaultCollisionConfiguration)world.collisionConfiguration).setPlaneConvexMultipointIterations(3,3); ((btDefaultCollisionConfiguration)world.collisionConfiguration).setConvexConvexMultipointIterations(3, 3);
No difference.
I did however read about big trimeshes not working very well for raycasting, my mesh is big 512x512 units but I am not sure if this could cause my object to fall through the mesh?
I also read that sphere shapes has problems with trimeshes, but again I am not sure if this would be my case? The sphere I am using is locked for rotation on all axes.
I have also tried using a btCapsule but it gave same results.. Would a cylinder work better?
[EDIT]
I have tried using a cylinder instead since sphere and capsule did not work. The cylinder is working a lot better. I have still got it to fall through once though. The clyinder was jerking around a lot before it went through where the sphere/capsule would just go through really fast and easy. Maybe this could be a clue of whats the underlaying problem? A cylinder is not the best for a character shape though..
An other possible reason could be if a triangle in the mesh has too long sides or a large ratio between sides. I found a few of those on a slope where my sphere always falls through. If this is indeed the problem can I do anything about it except manually editing the mesh in Blender?
As you can see there are a lot of these questions and a lot of possible answers and I have no idea which one corresponds to my case, someone with better insight giving some pointers would mean a lot, thanks!
I'm revising for an OpenGL exam and keep coming across this question on past papers. It's not something I've been taught and I was wondering if anyone could set me off in the right direction.
Sorry I haven't added what I have so far, there's not much because I don't really understand the question either.
"You wish to create a simple animation that shows a small red sphere shrinking and expanding. Specifically the radius oscillates sinusoidally between 0.3 and 0.5 in magnitude.
(i) Discuss the role of the glutIdleFunc in the animation.
(ii) Write the display method that performs the above animation;
assume the radius vector R is of type double and is declared with
global scope."
The glutIdleFunc documentation could set you off in a direction. Notice how it does calculations in the background, so a possible answer could be discussing how the animation behaves by setting or not setting (or simply leaving empty) that particular callback, respectively.
If you are allowed to use glutSolidSphere or glutWiredSphere the display method could be quite simple if you know the basics of OpenGL (assuming you've studied and attended class :). But if you have to use OpenGL 3.3 or 4.0+ you will probably have to think about coming up with an algorithm to first generate the vertices of the sphere (simpler) then the indices of the vertices (little bit trickier). There are numerous examples on the Internet and StackOverflow on how to do that, I do believe.
Good luck on your exam!
For the following code segement, my problem is that the two objects are intersected, but the views (lower figure) are not correct, object 1 (box) is inserted into the cylinder but the sideview (lower figure) is not correct, it looks like the yellow box is behind the cylinder. How can I make it look they are intersected?
glColor3f(1,1,0);
drawobj1(); // draw box
glColor3f(1,0.5,0);
drawobj2();draw Cyclinder() using gluCylinder
It is behind the cylinder. It is both inside and behind it. Part of the box is inside it, and part of it is behind it.
Imagine a fork embedded in the side of a can. You can rotate the can so that it appears like the cylinder in your diagram. The fork is still embedded in it, but from that angle, you can only suspect that it is based on what you know about the length of a fork.
Your problem is the lack of visual depth cues, brought on by the fact that this scene lacks lighting, textures, and everything else that your brain normally would use to actually interpret something.