We Keep Coding

How to rotate an object along a circular path?

I'm trying to realize a bicycle that moves along a circular path, using webGL programming language. My problem is related to the rotation of the bicycle itself that does not rotate on itself during its circular movement, but it remains with its initial angle, although the object is correctly translated in a circular fashion along the track.
In order to provide circular movements to the bicycle, I'm using the cosine and sine functions and each time varying the angle. The axes that I have to take into consideration are the x-axis and z-axis while the y-axis is fixed.
Any suggestions?

If I understood you correctly, what you want is essentially to orient the bicycle so that it faces its direction of motion?
That is usually done by calculating the model (bicycle)'s modelToWorld matrix. Your matrix lib probably have a .lookAt function and you should use that to calculate the modelToWorld matrix.
You should be able to calculate the bike's forward direction. If its moving around in a circle then it is normalize(cross(normalize(bikePos-circleCenter), UP_VECTOR)).

How to detect collision in not easily polygon divided body

Say we are coding something in Javascript and we have a body, say an apple, and want to detect collision of a rock being thrown at it: it's easy because we can simply consider the apple as a circle.
But how about we have, for example, a "very complex" fractal? Then there is no polygon similar to it and we also cannot break it into smaller polygons without a herculean amount of effort. Is there any way to detect perfect collision in this case, as opposed to making something that "kind" of works, like considering the fractal a polygon (not perfect because there will be collision detected even in blank spaces)?

You can use a physics editor
https://www.codeandweb.com/physicseditor
It'll work with most game engines. You'll have to figure how to make it work in JS.
Here's an tutorial from the site using typescript - related to JS
http://www.gamefromscratch.com/post/2014/11/27/Adventures-in-Phaser-with-TypeScript-Physics-using-P2-Physics-Engine.aspx

If you have coordinates of the polygons, you can make an intersection of subject and clip polygons using Javascript Clipper
The question doesn't provide too much information of the collision objects, but usually anything can be represented as polygon(s) to certain precision.
EDIT:
It should be fast enough for real time rendering (depending of complexity of polygons). If the polygons are complex (many self intersections and/or many points), there are many methods to speedup the intersection detection:
reduce the point count using ClipperLib.JS.Lighten(). It removes the points that have no effect to the outline (eg. duplicate points and points on edge)
get first bounding rectangles of polygons using ClipperLib.JS.BoundsOfPath() or ClipperLib.JS.BoundsOfPaths(). If bounding rectangles are not in collision, there is no need to make intersection operation. This function is very fast, because it just gets min/max of x and y.
If the polygons are static (ie their geometry/pointdata doesn't change during animation), you can lighten and get bounds of paths and add polygons to Clipper before animation starts. Then during each frame, you have to do only minimal effort to get the actual intersections.
EDIT2:
If you are worried about the framerate, you could consider using an experimental floating point (double) Clipper, which is 4.15x faster than IntPoint version and when big integers are needed in IntPoint version, the float version is 8.37x faster than IntPoint version. The final speed is actually a bit higher because IntPoint Clipper needs that coordinates are first scaled up (to integers) and then scaled down (to floats) and this scaling time is not taken into account in the above measurements. However float version is not fully tested and should be used with care in production environments.
The code of experimental float version: http://jsclipper.sourceforge.net/6.1.3.4b_fpoint/clipper_unminified_6.1.3.4b_fpoint.js
Demo: http://jsclipper.sourceforge.net/6.1.3.4b_fpoint/main_demo3.html
Playground: http://jsbin.com/sisefo/1/edit?html,javascript,output
EDIT3:
If you don't have polygon point coordinates of your objects and the objects are bitmaps (eg. png/canvas), you have to first trace the bitmaps eg. using Marching Squares algorithm. One implementation is at
https://github.com/sakri/MarchingSquaresJS.
There you get an array of outline points, but because the array consists of huge amount of unneeded points (eg. straight lines can easily be represented as start and end point), you can reduce the point count using eg. ClipperLib.JS.Lighten() or http://mourner.github.io/simplify-js/.
After these steps you have very light polygonal representations of your bitmap objects, which are fast to run through intersection algorithm.

You can create bitmaps that indicate the area occupied by your objects in pixels. If there is intersection between the bitmaps, then there is a collision.

Vectorize Cubic Bezier for 2D WebGL

I am building a 2D cad-like application in Javascript using WebGL and need to allow users to draw cubic bezier curves. My problem is that, as far as I know, WebGL doesn't have any easy way to draw anything but lines and filled triangles.
What makes it more complicated is that I want 'X' number of pixels per segment, and thus will not be able to just iterate through every 1% along the line.
I imagine that this would go something like:
Calculate the total length of the bezier curve
Divide that number by the segments per pixel
Iterate through the bezier curve by the previous number
This is an extremely high performance situation (hundreds of curves at a time), so I can't afford to use a constant number of segments for every curve.
So, my questions are:
Is there any native way to draw a cubic bezier in WebGL?
If not, can anyone help me with the calculations mentioned above, particularly the total length of a cubic bezier curve?

There's no direct way to tell WebGL to "draw a Curve". Just triangles (and lines).
So I think your general approach (Estimate length, divide for desired smoothness, walk the curve) will be good.
You could use a Vertex Shader to do some of the calculations, though. Depending on your data set, and how much it changes, it might be a win.
In WebGL, the vertex shader takes a list of points as input, and produces a same-sized list of points as output, after some transformation. The list cannot change size, so you'll need to figure out the number of subdivisions up in JS land.
The vertex shader could calculate the curve positions, if you assigned each point an attribute "t" between 0 and 1 for the parametric version of the Bezier. Might be handy.
From wikipedia,
As for Bezier length, if we describe it as (p0, p1, p2, p3) where p0 and p3 are the end points and p1 and p2 are the control points, we can quickly say that the Bezier length is at least dist(p0,p3), and at most dist(p0,p1)+dist(p1,p2)+dist(p2,p3).
Could make a fast-guess based on that.
A more thorough discussion for numerical solution is at https://math.stackexchange.com/questions/338463/length-of-bezier-curve-with-simpsons-rule.
There's no closed form solution.
Possibly of interest, I rendered a little Bezier animation for a blog post

I just wanted to add that clearly, we've been rasterizing Bézier curves for a long time, so in addition to the steve.hollasch.net link (http://steve.hollasch.net/cgindex/curves/cbezarclen.html) I pulled from a linked page in #davidvanbrink's answer, I figured there ought to be other resources for this...obviously WebGL/OpenGL adds another dimensional component into finding the appropriate resolution, but this cannot be something that hasn't been attempted before. I think the following links might prove useful.
http://en.wikipedia.org/wiki/NURBS (Non-uniform rational B-spline)
http://antigrain.com/research/adaptive_bezier/index.html (Adaptive Subdivision of Bezier Curves: An attempt to achieve perfect result in Bezier curve approximation)
http://www.neuroproductions.be/experiments/nurbs/
http://threejs.org/examples/webgl_geometry_nurbs.html

Euler Angles from analog sensor data 9dof

I'm looking to compute euler angles based on analog sensor data in javascript. The sensor data includes gyro, accelerometer, and magnetometer data in 3d. The math is a little over my head, and looking for any help or tips.
Thanks!

It is not clear what you are asking for. Is it sensor fusion that you are trying to implement? Or you already have it and you want to get Euler angles from the orientation (rotation matrix or quaternion)?
I have implemented sensor fusion for Shimmer 2 devices based on this manuscript. I highly recommend it.
Euler angles are evil, don't use them. They mess up the stability of your application and they cannot be used for interpolation.
JavaScript seems a little odd choice for this type of task.

How to use GradientEntry in xfl?

<LinearGradient>
<matrix>
<Matrix a="0.0262451171875" d="0.009765625" tx="218.45" ty="83"/>
</matrix>
<GradientEntry color="#E63426" ratio="0.00392156862745098"/>
<GradientEntry color="#CA271E" ratio="0.36078431372549"/>
<GradientEntry color="#B31D19" ratio="0.749019607843137"/>
<GradientEntry color="#AB1917" ratio="1"/>
</LinearGradient>
This is the relevant part of the xfl file that is needed fill a shape with colors using gradientEntry.
The matrix values above are suppose to somehow help me get the start and end coordinates
for the gradient. Does anyone know how to extract the start and end coordinates. I did a similar thing not long ago using EaselJS Matrix 2D class with the decompose function to decide scaling, rotation, skewing and translation (displacement).
What im trying to do is to draw an xfl picture in HTML 5 with canvas.
Im a bit new at programming so maybe my question is not so well formulated! Sorry about that.

I have been looking into this for a good while, but I haven't figured it out entirely yet.
It's a typical transformation matrix found a lot in the XFL files, but what it transforms exactly is unknown to me. I do know that if you pull [0,0] through the transformation matrix and consider the local transformation space of the layer (ie, subtract the transformation point), you get the center of the gradient.
If I transform [0,1], [1,0] or [1,1], however, the results barely differ from [0,0] because the values in the transformation matrix are always extremely small. It does seem that [1,0] at least points in the right direction, though. If I put [1000,0] in it, I get about 1/2 of the entire length of the gradient.
So just based on sight, I would say that the gradient would run from [-1000,0] to [1000,0]. But that's just an empirical estimation. If anyone's got a better estimation, or perhaps a reason why they did it this way, I'd love to know it.