I just started to fiddle around with WebGL and three.js.
I would really like to create a thick line, which has rounded corners and endings. (see example picture)
Unfortunately I see that firstly the LineBasicMaterial's linecap property does not really work.
Three.js LineBasicMaterial
I started to think about using a tube, but then I think I will still not get a round cap...
Does someone have any ideas how I could create a line in the picture above? It does not necessarily have to made with three.js but WebGL would be a requirement. (I also want to animate this line further on...)
Thanks for any hints.
Cheers
There are a couple ways to draw 3d volumetric lines. The first is to do a vertex expansion in the shader. This is what the links in the comments do. Here is another one in case you need more material: http://codeflow.org/entries/2012/aug/05/webgl-rendering-of-solid-trails/.
Unfortunately it have visual artifacts when the line segment is viewed directly heads on. Check out the demo here: http://codeflow.org/webgl/trails/www/. Spin the scene around and you will notice some line segments facing directly towards the camera will spin rapidly. It looks a lot worse with a less noisy texture btw. If this is fine with you this is probably the preferred option.
The 2nd option is to just dynamically generate a capsule mesh for each line segment. Not much to say about it, beyond that this is a simple, abet somewhat inefficient method.
The 3rd option is to do a limited kind of ray tracing in the shader. Calculate the distance between the line segment and the fragment being shaded and we can use that to determine the appropriate color. Here is a link for that. Geometry shader is not currently supported in the webgl but there is nothing stopping you from generating the bounding line cuboid via javascript. Oh and if you need soft lines you probably need the blend_minmax extension. Probably the hardest method to setup but can be viewed at any angle and very customize-able compared to the other 2 methods.
I'm trying to figure out how to draw an stretchy/elastic line between two points in openGL/Cocos2d on iPhone. Something like this
Where the "band" get's thinner as the line gets longer. iOS uses the same technique I'm aiming for in the Mail.app, pull to refresh.
First of all, is there a name for this kind of thing?
My first thought was to plot a point on the radius of the starting and ending circles based on the angle between to the two, and draw a quadratic bezier curve using the distance/2 as a control point. But I'm not a maths whizz so I'm struggling to figure out how to place the control point which will adjust the thickness of the path.
But a bigger problem is that I need to fill the shape with a colour, and that doesn't seem to be possible with OpenGL bezier curves as far as I can tell since curves don't seem to form part of a shape that can be filled.
So I looked at using a spline created using a point array, but that opens up a whole new world of mathematical pain as I'd have to figure out where all the points along the edge of the path are.
So before I go down that rabbit hole, I'm wondering wether there's something simpler that I'm overlooking, or if anyone can point me towards the most effective technique.
I'm not sure about a "common" technique that people use, other than calculating it mathematically, but this project, SlimeyRefresh, is a good example of how to accomplish this.
I have an airplane. I use rectangle for bounding this airplane to detect collision and it works great. When the airplane begin falling down I rotate airplane's texture, but rectangle remains unchanged. I don't know how to rotate it. I need to rotate it with airplane's texture because my shell doesn't collide the airplane's tail and cabine.
How to rotate rectangle or perhaps create polygon shape to wrap all airplane? Any help will be appreciated!
#jellyfication's answer points to raycasting, but a different and also simple approach you could implement is the Separating Axis Theorem. The links below will show you in detail what the algorithm is about and how to implement it. They also have some interactive demos so you get the 'feel' for what the algorithm is doing.
http://www.metanetsoftware.com/technique/tutorialA.html
http://www.sevenson.com.au/actionscript/sat/
http://www.codezealot.org/archives/55 (this one has a lot of code)
http://gamedev.tutsplus.com/tutorials/implementation/collision-detection-with-the-separating-axis-theorem/
Good luck!
Use the polygon class to and draw your bounding Box.
Then within the polygon class there is a method to rotate.
Rotate and move the polygon with the plane.
I want to create a simple shape, let's say, a circle, it might have transparency, colors, etc. but it's still a simple circle.
In every tutorial I see, people use sprites. I am not sure what should I use for my case.
Should I use a sprite with a circle or should I try and draw the shape myself?
What are the advantages of each method?
Is there a line dividing them or is it just experience to know which one to use?
GPU geometry is composed of triangles or line segments so it'll be inefficient to draw a circle in this way, it'll require too many triangles for it to look smooth.
The two more efficient ways to do that are:
Use a sprite
Use a shader and draw the circle. Check ShaderToy, more specifically the "Shapes" preset.
I've got a problem with shadowrays in my raytracer.
Please have a look at the following two pictures
3D sMax:
alt text http://neo.cycovery.com/shadow_problem.gif
My Raytracer:
alt text http://neo.cycovery.com/shadow_problem2.jpg
The scene is lit by a very bright light, shining from the back. It's so bright that there is no gradient in the shading, just either white or dark (due to the overexposure).
both images were rendered using 3DStudioMax and both use the exact same geometry, just in one case the normals are interpolated across the triangles.
Now consider the red dot on the surface. In the case of the unsmoothed version, it lies in a dark area. this means that the light source is not visible from this triangle, since it's facing away from it.
In the smoothed version however, it lies in the lit area, because the interpolated normal would suggest, that the light would be visible at that point (although the actual geometry of the triangle is facing away from the lightsource).
My problem now is when raytraced shadows come in. if a shadowray is shot into the scene, from the red dot, to test whether the light-source is visible or not (to determine shadowing), the shadowray will return an intersection, independent of whether normals are interpolated or not (because intersections only depend on the geometry). Therefore the pixel would be shaded dark.
3dsamx is handling the case correctly - the rendered image was generated with Raytraced shadows turned on. However, my own Raytracer runs exactly into this problem when i turn on raytraced shadows (in my raytracer, the point is dark in both cases, because raytraced shadows determine the point lying in the shadow), and i don't know how to solve it.
I hope someone knows this problem and how to deal with it..
thanks!
The 'correct' solutions are either to tesselate triangles, or to solve the equation of the surface the triangle belongs to. I have seen only the tessellation. Tessellation gives you the controllable precision and so on...
Otherwise, you should test normal in the point (what I believe '3DStudio' does) and in the case the normal is not facing the light, just set the point as not lit. It has nothing to do with 'self-shading'. Easily this problem can be solved only with tessellation. Good luck!
I'm not sure if I understood your problem correctly.
It's kind of hard to get which version/result is obtained by which method and what result you
consider correct.
Isn't it the case when you need to threat intersection of shadowray with the triangle on which
The Red Point ;-) lies as special case.
You don't do geometry intersection, as with any other triangle,
but only direction check between interpolated normal and shadowray.
Or in more general sense, you say that shadowray stops at a triangle, any triangle, when:
a) they intersect and
b) interpolated normal of a triangle at intersection point has direction opposite to shadowray.
How you can do it:
If the interpolated normal at the point is facing towards the light then the surface is potentially facing the light. If facing away you are in shadow.
In the first case, the two things that would cause a shadow are other objects, and yourself if you are concave object. In the other object that is easy.
Now in the case of yourself, when you cast your ray at the light source, if you are truly 'convex inside point' you will hit yourself twice as you enter then leave the object, thus in shadow.
If you hit yourself a single time, then you must be on the edge of where the light is striking, but as we know at that point we are facing the light (via the smoothed normals) it means we are not shadowed.
Mat, I believe your problem could be that your shadow ray hits the same triangle that it originates from because it is so close to being tangential (note that it happens right on the border of the light-shadow transition). There are two ways of solving this problem: One approach is to use a "bias" that tests the distance from the ray origin, but I think a better solution is to store a reference to the originating triangle with the ray. If you do a test against this triangle, simply ignore it.
If you happen to be using a spatial index like a BVH, then you could try stepping out of the "box" containing the triangle before doing any intersection tests, but this is less simple than before-mentioned approach and must be approached with more care.
It's normal to shift an intersection by a small amount in the direction of the light source when firing shadow rays.
I.e. shadowRay.dir = shadowRay.dir * 0.0001
This avoids the shadow ray intersecting the same primitive as the primary / reflective / refractive ray did.
Perhaps your problem is because you did not do this?
I had the same issue and in my case an if statement where if the dot prod of the light direction and the normal is positive, did the trick.
the pseudocode is:
bool shadow_hit(light, shader_ctx){
....
if(dot(light.dir, shader_ctx.normal) > 0) return false
...
return true;
}