I'm making a game where the game's size varies, so I want to make my own shadows. The api i'm using can fill rectangles, make ellipses, horizontal lines etc. And supports rgba. Given this, how could I make a drop shadow? I tried making a black to white gradient and setting the alpha to 20%, but it didnt look very good... I'm not sure how they are done. Thanks
I would suggest:
copy the object,
move it in the opposite direction of the light source and use its distance as a weight,
turn it totally black,
blur it using the light source's distance as a weight, too,
put it behind the object,
lower the alpha if you want.
?????
profit.
Related
So for the game I am working on, I am trying to make a unique type of shader. The majority is very basic, there is just one difficult part. I only want to render what the player would see in their line of sight. This is a top-down 2D game so the player would normally be able to see rooms over. But take this image for example.
Obviously the player here is the orange circle. The area that he can see is the gray ( grey? ) filled in area. The black lines represent a room and the purple lines represent his field of vision through the door of the room. I want to only render the shaded area.
I am aware GLSL has a discard statement where you can remove specific pixels. This means that by making a boolean function I could just do the following code in my vertex shader.
if ( !playerCanSeePoint( params ) ) {
discard;
}
What I don't know how to do though is make the playerCanSeePoint function. One idea I had was to cast invisible lines from the player in all directions and find it's first intersection point. That would mean to first wall and would create the proper shape. This seems resource consuming though. So is there a good way to do this?
You start with a square the size of the view area and then for each wall you cut out a portion of it based on where the player is.
Then you can triangulate the polygon and use a stencil to prevent drawing outside of it.
I'm creating a comic book editor. I want to be able to use some fairly complex customisable shapes for the speech balloons.
I can draw the tail and then draw a balloon but that means I have the outline inside the shape and I want it only around the edge.
I assumed QPainterPath::simplified() would solve the problem but it doesn't seem to do anything.
At the moment my best idea is to draw a shape with a thick outline and then draw it again with no outline but I don't think that will work for "zero width" outlines.
I can think of two possible solutions here:
Draw both the "tail" and the main "balloon" as a single shape. In this case, you'd simply draw a single shape with a single outline and a single fill.
Draw them separately, but twice. Draw an "expanded" version of the shapes in black first, and then draw the "normal" version of the shapes in white over the top of it. You wouldn't draw any "lines" at all - the "expanded" version of the fill would serve the same purpose.
The first method would allow alternative line styles to be used (dotted or wiggly lines), but the latter would allow the "outline" to be slightly offset, so that it appeared thicker around some edges and thinner around others.
It turns out QPainterPath::simplified() does work. It depends on whether I draw clockwise or anti-clockwise (I believe it works when drawn clockwise), which I presume is down to how Qt's Winding Fill works.
// create a path representing the bubble and its "tail"
QPainterPath tail = tail.shape();
tail.addPath(bubble.shape());
tail.setFillRule(Qt::WindingFill);
painter->drawPath(tail.simplified);
I need to use a low-resolution (320 x 240) image in OpenCV and find a large exercise ball, either blue or red. The ball is 25 inches wide and is NOT guaranteed to be perfectly circular. I tried to use HoughCircles with a Canny-thresholded image. I had no success. What am I doing wrong and what is the best way to get the size of the ball in pixels and where it is? It'll let me calculate things like how far it is from the camera!
Let me collect all the other advice in one answer:
Use cv::inRange() to get the correct color (More Information on that). You might want to use something like RGB Normalization beforehand to make sure you retreive the complete ball.
Now you have all the pixel that relate to the ball (and maybe some noise that you have to get rid of). Retrieve the pixels that are farthest apart left/right and top/bottom in your ball (aka your connected Component that has a plausible size) to get the size of the ball. (If the ball doesn't have to be round you probably want to take the bigger value)
Compute the distance from the camera with the now known size of the ball in the picture. (You have to know the "real" size beforehand for this computation obviously ;))
There obviously are other ways (f.e. use edge detection), but this is imo the easiest.
It is easier to give you an answer if you post an example picture.
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'.
As seen in the image
I draw set of contours (polygons) as GL_LINE_STRIP.
Now I want to select curve(polygon) under the mouse to delete,move..etc in 3D .
I am wondering which method to use:
1.use OpenGL picking and selection. ( glRenderMode(GL_SELECT) )
2.use manual collision detection , by using a pick-ray and check whether the ray is inside each polygon.
I strongly recommend against GL_SELECT. This method is very old and absent in new GL versions, and you're likely to get problems with modern graphics cards. Don't expect it to be supported by hardware - probably you'd encounter a software (driver) fallback for this mode on many GPUs, provided it would work at all. Use at your own risk :)
Let me provide you with an alternative.
For solid, big objects, there's an old, good approach of selection by:
enabling and setting the scissor test to a 1x1 window at the cursor position
drawing the screen with no lighting, texturing and multisampling, assigning an unique solid colour for every "important" entity - this colour will become the object ID for picking
calling glReadPixels and retrieving the colour, which would then serve to identify the picked object
clearing the buffers, resetting the scissor to the normal size and drawing the scene normally.
This gives you a very reliable "per-object" picking method. Also, drawing and clearing only 1 pixel with minimal per-pixel operation won't really hurt your performance, unless you are short on vertex processing power (unlikely, I think) or have really a lot of objects and are likely to get CPU-bound on the number of draw calls (but then again, I believe it's possible to optimize this away to a single draw call if you could pass the colour as per-pixel data).
The colour in RGB is 3 unsigned bytes, but it should be possible to additionally use the alpha channel of the framebuffer for the last byte, so you'd get 4 bytes in total - enough to store any 32-bit pointer to the object as the colour.
Alternatively, you can create a dedicated framebuffer object with a specific pixel format (like GL_R32UI, or even GL_RG32UI if you need 64 bits) for that.
The above is a nice and quick alternative (both in terms of reliability and in implementation time) for the strict geometric approach.
I found that on new GPUs, the GL_SELECT mode is extremely slow. I played with a few different ways of fixing the problem.
The first was to do a CPU collision test, which worked, but wasn't as fast as I would have liked. It definitely slows down when you are casting rays into the screen (using gluUnproject) and then trying to find which object the mouse is colliding with. The only way I got satisfactory speeds was to use an octree to reduce the number of collision tests down and then do a bounding box collision test - however, this resulted in a method that was not pixel perfect.
The method I settled on was to first find all the objects under the mouse (using gluUnproject and bounding box collision tests) which is usually very fast. I then rendered each of the objects that have potentially collided with the mouse in the backbuffer as a different color. I then used glReadPixel to get the color under the mouse, and map that back to the object. glReadPixel is a slow call, since it has to read from the frame buffer. However, it is done once per frame, which ends up taking a negligible amount of time. You can speed it up by rendering to a PBO if you'd like.
Giawa
umanga, Cant see how to reply inline... maybe I should sign up :)
First of all I must apologize for giving you the wrong algo - i did the back face culling one. But the one you need is very similar which is why I got confused... d'oh.
Get the camera position to mouse vector as said before.
For each contour, loop through all the coords in pairs (0-1, 1-2, 2-3, ... n-0) in it and make a vec out of them as before. I.e. walk the contour.
Now do the cross prod of those two (contour edge to mouse vec) instead of between pairs like I said before, do that for all the pairs and vector add them all up.
At the end find the magnitude of the resulting vector. If the result is zero (taking into account rounding errors) then your outside the shape - regardless of facing. If your interested in facing then instead of the mag you can do that dot prod with the mouse vector to find the facing and test the sign +/-.
It works because the algo finds the amount of distance from the vector line to each point in turn. As you sum them up and you are outside then they all cancel out because the contour is closed. If your inside then they all sum up. Its actually Gauss's Law of electromagnetic fields in physics...
See:http://en.wikipedia.org/wiki/Gauss%27s_law and note "the right-hand side of the equation is the total charge enclosed by S divided by the electric constant" noting the word "enclosed" - i.e. zero means not enclosed.
You can still do that optimization with the bounding boxes for speed.
In the past I've used GL_SELECT to determine which object(s) contributed the pixel(s) of interest and then used computational geometry to get an accurate intersection with the object(s) if required.
Do you expect to select by clicking the contour (on the edge) or the interior of the polygon? Your second approach sounds like you want clicks in the interior to select the tightest containing polygon. I don't think that GL_SELECT after rendering GL_LINE_STRIP is going to make the interior responsive to clicks.
If this was a true contour plot (from the image I don't think it is, edges appear to intersect) then a much simpler algorithm would be available.
You cant use select if you stay with the lines because you would have to click on the line pixels rendered not the space inside the lines bounding them which I read as what you wish to do.
You can use Kos's answer but in order to render the space you need to solid fill it which would involve converting all of your contours to convex types which is painful. So I think that would work sometimes and give the wrong answer in some cases unless you did that.
What you need to do is use the CPU. You have the view extents from the viewport and the perspective matrix. With the mouse coord, generate the view to mouse pointer vector. You also have all the coords of the contours.
Take the first coord of the first contour and make a vector to the second coord. Make a vector out of them. Take 3rd coord and make a vector from 2 to 3 and repeat all the way around your contour and finally make the last one from coord n back to 0 again. For each pair in sequence find the cross product and sum up all the results. When you have that final summation vector keep hold of that and do a dot product with the mouse pointer direction vector. If its +ve then the mouse is inside the contour, if its -ve then its not and if 0 then I guess the plane of the contour and the mouse direction are parallel.
Do that for each contour and then you will know which of them are spiked by your mouse. Its up to you which one you want to pick from that set. Highest Z ?
It sounds like a lot of work but its not too bad and will give the right answer. You might like to additionally keep bounding boxes of all your contours then you can early out the ones off of the mouse vector by doing the same math as for the full vector but only on the 4 sides and if its not inside then the contour cannot be either.
The first is easy to implement and widely used.