Develop Reference

Bezier curve with control points within the curve

Please see the image below.
This path object is created using 4 Bezier curve on each side.
Currently I am facing a problem when I try to get bounds of this path object created using cubic brazier curves. As you can see top and bottom sides have control point away from the curve which makes bounds totally inaccurate.
So my question is is it possible to create a jigsaw puzzle piece like in the image having all control points on or at the level of the curve. ( That is creating a curve and perfect mirror of it, all points within the bounds of the curve)

Don't calculate the bounds by using the control points, then. At least if you need tight bounds and don't want a quick check for potential visibility in a given clipping rectangle.
This awesome site can help a lot with common Bézier curve calculations, including bounding box.
Alternatively, switch to splines where the control points are on the curve, but then you could end up with the opposite effect where the curve extends beyond the bounds imposed by its control points.

You can easily convert your BEZIER cubic control points into Interpolation cubic. Just by reversing this:
BEZIER vs. interpolation cubic
so:
/* bezier = interpol
1 | ( x0)=X1;
t | (3.0*x1)-(3.0*x0)=(0.5*(X2-X0));
tt | (3.0*x2)-(6.0*x1)+(3.0*x0)=(3.0*(X2-X1))-(X2-X0)-(0.5*(X3-X1));
ttt|( x3)-(3.0*x2)+(3.0*x1)-( x0)=(0.5*(X2-X0))+(0.5*(X3-X1))+(2.0*(-X2+X1));
1 | ( y0)=Y1;
t | (3.0*y1)-(3.0*y0)=(0.5*(Y2-Y0));
tt | (3.0*y2)-(6.0*y1)+(3.0*y0)=(3.0*(Y2-Y1))-(Y2-Y0)-(0.5*(Y3-Y1));
ttt|( y3)-(3.0*y2)+(3.0*y1)-( y0)=(0.5*(Y2-Y0))+(0.5*(Y3-Y1))+(2.0*(-Y2+Y1));
*/
// input: x0,y0,..x3,y3 ... Bezier control points
// output: X0,Y0,..X3,Y3 ... interpolation control points
double x0,y0,x1,y1,x2,y2,x3,y3,m=1.0/9.0;
X0=x0-(x1-x0)/m; Y0=y0-(y1-y0)/m;
X1=x0; Y1=y0;
X2=x3; Y2=y3;
X3=x3+(x3-x2)/m; Y3=y3+(y3-y2)/m;
Hope I did not make any algebraic mistake. This will move all control points into your curves directly while the shape will be unchanged. Beware that for BBOX computation you should only use (X1,Y1) and (X2,Y2) as the used parameter t=<0,1> is interpolating between them !!!.
But even this can provide inaccuracy as you can have some extremes without control point. In case even that is a problem (The BBOX is a bit smaller than should) you can re-sample your shape to set of points (for example 10 per cubic) on the curve with some step (0.1) and do the BBOX from those points. That will be much more precise but slower of coarse...

One property of Bezier curves is that as you split them, the distance between the smooth curve and the CVs shrinks.
So, one way to fix those CVs on the top and bottom is to split the related Bezier into two Beziers using the De Casteljau algorithm.
You could even do this algorithmically:
Find tight bounding box and CV-based bounding box.
If the difference is greater than your tolerance, find the max/min CVs and their related Bezier curves
Split all of the related Bezier curves into two Bezier curves each
Repeat
Eventually you'll hit your tolerance. You might have a lot of Beziers by then though if you have a very tight tolerance or tricky data.

Java collision detection with 3d obj models

I was looking around a lot but only found how to check collision for 2d objects.. for my current project I want to check colisions in 3d (I'm using obj models) - I could probably figure out something myself the problem is that I only know the center point of each object..
Is there a way to get the boarders of the object so I can check if it touches the boarders of another object? What would be the best way to get this information?
Edit: Some more information that might help:
I'm using lwjgl 2.8,
my objects are obj files,
I can get position, scale and the rotation of an object
EDIT: This is what I found on youtube:
https://www.youtube.com/watch?v=Iu6nAXFm2Wo&list=PLEETnX-uPtBXm1KEr_2zQ6K_0hoGH6JJ0&index=4

What you have is called a triangle soup[1]: you got vertex position (, texture and normal) information couppled with triangle information. What you can do is intersect each triangle from one mesh with another mesh. You can do this either brute-force (by testing all the other triangles each time) or build up a space partitioning data structure to speed up your intersections.
E.g. build an Octree per mesh and iterate over the leaves in one of them: for each of those leaves, test its bounding box against the leaves in the other tree and for each of those collision pairs brute-force test each triangles within either of those pairs against each other (or only test those from mesh A against those in mesh B, if you don't care about self-intersections).
There are libraries for these sorts of algorithms like OpenMesh or Bullet for example. But I only know of one port to Java: JBullet.
EDIT: If you're only interested in approximate collisions you can throw away all information about triangles and build a bounding volume out of your vertices (e.g. an axis aligned box is just the min and the max for all vertex positions, an oriented box is built similarly, but you have to find a good enough orientation first, a sphere is a bit more involved and finally you have a convex mesh, which uses the same sorts of intersection tests as a normal mesh, but is smaller than the original and convex, allowing for some optimisations of the general intersection test).
[1]: there are other kinds of 3D representations that record information about how the triangles are connected. You might imagine finding only two intersecting triangles in mesh A and mesh B and then start searching for intersecting triangles only in the neighbourhood of the initial intersection... these algorithms are much more involved, but for meshes that deform have the advantage, that you don't have to rebuild the space partitioning data structure each time as you have to do with triangle soups.

Trying to achieve dynamic lighting in a tiled 2D isometric environment using Java2D

I am trying write some lighting code for a Java2D isometric game I am writing - I have found a few algorithms I want to try implementing - one of which I found here:
here
The problem is that this sort of algorithm would require some optimal pixel-shading effect that I haven't found a way of achieving via Java2D. Preferably some method via the graphics hardware but if that isn't possible - at least a method of achieving the same effect quickly in software.
If that isn't possible, could someone direct me to a more optimal algorithm with Java2D in mind? I have considered per-tile lighting - however I find the drawPolygon method isn't hardware accelerated and thus performs very slowly.
I want to try and avoid native dependencies or the requirement for elevated permissions in an applet.
Thanks

I did a lot of research since I posted this question - there are tons of alternatives and JavaFX does intend (on a later release) to include its own shader language for those interested. There is also a ofcourse LWJGL that will allow you to load your own shaders onto the GPU.
However, if you're stuck in Java2D (as I am) it is still possible to implement lighting in an isometric game it is just 'awkward' because you cannot perform the light shading on a per-pixel level.
How it Looks:
I have achieved a (highly unpolished - after some polishing I can assure you it will look great) effect for casting shadows, depth sorting the light map, and applying the lighting without experiencing a drop in frame-rate. Here is how it looks:
You'll see in this screen-shot a diffuse light (not shaded in but that step I'd say is relatively easy in contrast to the steps to get there) casting shadows - the areas behind the entities that obstructs the light's passage BUT also in the bounds of the light's maximum fall-out is shaded in as the ambient lighting but in reality this area is passed to the lights rendering routine to factor in the amount of obstruction that has occurred so that the light can apply a prettier gradient (or fading effect of some sort.)
The current implementation of the diffuse lighting is to just simply render obstructed regions the ambient colour and render non-obstructed regions the light's colour - obviously though you'd apply a fading effect as you got further from the light (that part of the implementation I haven't done yet - but as I said it is relatively easy.)
How I did it:
I don't guarantee this is the most optimal method, but for those interested:
Essentially, this effect is achieved by using a lot of Java shape operations - the rendering of the light map is accelerated by using a VolatileImage.
When the light map is being generated, the render routine does the following:
Creates an Area object that contains a Rectangle that covers the
entirety of the screen. This area will contain your ambient
lighting.
It then iterates through the lights asking them what their
light-casting Area would be if there were no obstructions in the way.
It takes this area object and searches the world for Actors\Tiles
that are contained within that area that the light would be cast in.
For every tile that it finds that obstructs view in the light's casting area, it will calculate the difference in the light source's position and the obstruction's
position (essentially creating a vector that points AT the
obstruction from the light source - this is the direction you want to cast your shadow) This pointing vector (in world
space) needs to be translated to screen space.
Once that has been done, a perpendicular to that vector is taken and
normalized. This essentially gives you a line you can travel up or
down on by multiplying it by any given length to travel the given direction in. This vector is
perpendicular to the direction you want to cast your shadow over.
Almost done, you consturct a polygon that consists of four points.
The first two points are at the the base of the screen coordinate of
your obstruction's center point. To get the first point, you want to
travel up your perpendicular vector (calculated in 5) a quantity of
half your tile's height [ this is a relatively accurate
approximation though I think this part of the algorithm is slightly
incorrect - but it has no noticable decay on the visual effect] -
then ofcourse add to that the obstructions origin. To get the
second, you do the same but instead travel down.
The remainder of the two points are calculated exactly the same way -
only these points need to be projected outward in the direction of
your shadow's projection vector calculated in 4. - You can choose any large amount to project it outwards by - just as long as it reaches at least outside of you light's casting area (so if you just want to do it stupidly multiply your shadow projection vector by a factor of 10 and you should be safe)
From this polygon you just constructed, construct an area, and then
invoke the "intersect" method with your light's area as the first
argument - this will assure that your shadows area doesn't reach
outside of the bounds of the area that your light casts over.
Subtract from your light's casting the shadow area you constructed
above. At this point you now have two areas - the area where the
light casts unobstructed, and the area the light casts over
obstructed - if your Actors have a visibility obstruction factor
that you used to determine that a particular actor was obstructing
view - you also have the grade at which it obstructs the view that
you can apply later when you are drawing in the light effect (this will allow you to chose between a darker\brighter shade depending on how much light is being obstructed
Subtract from your ambient light area you constructed in (1) both
the light area, and the obstructed light area so you don't apply
the ambient light to areas where the lighting effect will take over
and render into
Now you need to merge your light map with your depth-buffered world's render routine
Now that you've rendered you're light map and it is contained inside of a volatile image, you need to throw it into your world's render routine and depth-sorting algorithm. Since the back-buffer and the light map are both volatileimages, rendering the light map over the world is relatively optimal.
You need to construct a polygon that is essentially a strip that contains what a vertical strip of your world tiles would be rendered into (look at my screen shot, you'll see an array of thin diagonal lines seperating these strips. These strips are what I am referring). You can than render parts of this light map strip by strip (render it over the strip after you've rendered the last tile in that strip since - obviously - the light map has to be applied over the map). You can use the same image-map just use that strip as a clip for Graphics - you will need to translate that strip polygon down per render of a strip.
Anyway, like I said I don't guarantee this is the most optimal way - but so far it is working fine for me.
The light map is applied p

Collision Detection in libgdx

My question is mostly related to the theory behind it. I make a 2D game for a project and i detect collisions by using the .overlaps method in the Rectangle class and the collisions are handled beautifully. First of all , is that considered to be a continuous or discrete collision technique. As i'm reading the theory i say it is discrete ,however i'm reading in online articles that the major disadvantage of discrete is that it detects collision after it actually happened. So,my question is the following : is it actually discrete and if it is why i see no disadvantages?
Thanks

This is discreet because we only know if two bounding boxes collided after we check if the imaginary/invisible boxes intersected meaning they already overlapped. So by the time you take action (update) due to that collision, the objects are not in the collided position. Worse case, if they are not in relative speed, they can pass through. Think of the classic helicopter game where you dodge obstacles by going up and down. Say you put the velocity of the chopper on x really high, depending on your frame rate which depends on the hardware, you will see different positions of actual collision. For continuous, one object has to be aware of the physics properties of the other objects it may collide with to predict possible collision.
In reality, for 2d games like the helicopter game I mentioned, it really doesn't matter much. You can simulate the result of the collision by doing changes on an object's rotation, velocity, gravity and through some nice animations. If your game objects have abstract shapes, you should use something like box2d. There's a good Intersector class as well.
Also, you can experiment with different bounding box sizes (bounds) of an object rather than creating the bounding box of the object equal to its width and height.

Vertices selection and state of model after rotation

I'm currently writing an application that actually acts as a "cut" tool for 3D meshes. Well, I had some problems with it now which I am clueless on how to solve, since it is my first application.
I have loaded a model from an object file onto the canvas, then on the same canvas, I use the mouse drag event to draw lines to define the cutting point.
Let us say I want to cut a ball into half and I draw the line in the middle. How do I detect the vertices of the ball under the line.
Secondly, if I rotate/translate the ball, would all the the vertices information change?

Think of what you'd do in the real world: You can't cut a ball with a line, you must use a knife (a line has no volume). To cut the ball, you must move the knife through the ball.
So what you're looking after is a plane, not a line. To get such a plane, you must use some 3D math. What you have is the canvas orientation and the "side view" of the plane (which looks like a line).
So the plane you're looking for is perpendicular to the canvas. A simple way to get such a plane is to take the canvas orientation and create a plane which has the same orientation and then rotate the plane around the line by 90°.
After that, you can visit all edges of your model and determine on which side of the plane they are. For this, determine on which side of the plane the end points of the edge are. Use the cross product. If they are on the same side (both results of the cross products will have the same sign), you can ignore the edge. Otherwise, you need to determine the intersection point of the edge and plane. Create new edges and connect them accordingly.
See this page for some background on the math. But you should find some helper methods for all this in your opengl library.
if I rotate / translate the ball, would all the the vertices information change
Of course.

It's not going to be that easy.
I assume the line you are drawing induces a plane which then cuts the sphere.
To do so, you have to calculate the intersecting area of the sphere and the plane.
This is not a trivial task and I suggest using an existing framework for this or if you really want to do this yourself, read about basic intersection problems to get a feeling for this kind of problem. This paper offers a good introduction to various intersection tests.
In general boundary represended volumes, as in your case, are difficult to handle when it comes to more advanced manipulations. Cutting a sphere in half is easy compared to burring a small hole into it. Sometimes it's better to use a volume representation, like tetrahedral meshes or CSG.
Regarding your second question, you shouldn't rotate or translate the sphere, rotate and translate the camera.