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.
Related
I've been working on a 3D image made with CSS, the idea was to add some kind of animation to it and use it as a center piece in my portfolio, unfortunately I've been having trouble getting the animation to look smooth.
I am unsure if this is caused by a limit of CSS animation or by the fact that I am working in 3D, but I have not been able to get it to look quite right.
So far I've tried a lot of different values as well as adding more keyframes in the hopes the animation would smooth itself out but I have not had any luck.
I have a Codepen with all of the code, it can be found here.
I placed said keyframe animation at the top of the CSS file, it is named loading-cube
Unless I have been staring at this for too long and my eyes are playing tricks on me, the animation as it is currently has a "bounce".
This Codepen is a more accurate representation of how I would like my rotation to look like.
Your order of the 2 different rotations is wrong, you should set the rotateX before the rotateY. If you do so, the animation is much more easy, just a 360 deg turn on the Y axis:
#keyframes loading-cube {
0% {transform: translateZ(-800px) rotateX(-19deg) rotateY(0deg);}
100% {transform: translateZ(-800px) rotateX(-19deg) rotateY(360deg);}
}
edited demo
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 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...
Question on how this could be done, if possible.
I have sprites in each of the following directions (up, down, left, right, upright, upleft, downright, and downleft). I am making a similar game to the old school zelda, running around a tile map (using tiled editor). This is working well, until now, I want to be able to shoot arrows/spells at any location on the map. I can do so, but the graphics look horrible because my guy will only turn each 45 degrees.
I have corrected this so I can only shoot in the direction my guy is facing, but now I can't hit them if they are not at a 45 degree angle from me. To fix this, I need to have a sprite at every 1 degree, or somehow combine the images say at 0 degrees (up) and 45 degrees (upright) to be able to get say 10 degrees via interpolation. Is this possible? Any ideas on how to do this?
I am looking into working with key animations since I wouldn't have to have so many sprites and use much less video memory (and smoother animations), but I still run into this same problem. Would like to know if this is conceptually possible and if so, a little psuedo code or snipit would be much appreciated.
One other question, if this is possible, do I need to be rendering this via openGL in 3D? Didn't really know if 3d would help in a 2d (orthogonal tile) game, but it might help spells falling look like they are falling downward more than moving across tiles from above to below?
I have a collsion map, and some places that I want to be light sources. The light source provides light that is actually a shape where I can see the ground. It now looks like this:
So the light goes through the walls. I want to make it look like this:
(I marked the collisions with walls with dark yellow)
So the light rays stop when meeting the wall. I want to get the shape of the correct light, the best would be bitmap containing it)
My first idea was to cast rays from the source and check when they collide with the wall (I know how to do this), but then I would need to cast ray each 0.001 deg for example, so its too much time to generate lights. The next thing is that The light shape isn't always circle, sometimes it can be ellipse or half-ellipse, even triangle or part of the circle. Generally, I have the bitmap with light that doesnt collide anything, and I want to subtract it a bit to make it look like on the second image.
And the last thing, Im using allegro 4.2.1, but all previously mentioned bitmaps are 2-dimmension arrays with 0's and 1's.
Thanx for any help, sorry for long question and my bad english.
The basic idea is that you calculate the shadow region of your walls and just not color that.
This article should give you a good start.
In your particular example you can easily brute-force it by checking the line-of-sight from each (empty) pixel to the center of your light source. If you have line-of-sight and the distance is within the falloff, then you have light there. If not, then it's dark.
The MadKeithV solution need O(number of pixels^2) time.
My solution is a expanded MadKeithV idea, but run in O(number of pixels) time. With some improvements, it will work in O(number of pixels in light)
First, start with the pixel containing the source of light. Then using BFS procedure 'infect' nearest pixels with light and store angle range of which direction the light can progress from each point.
In following BFS instances, repeat this procedure, considering only pixels in 'infect range'.