Develop Reference

three.js lookAt() : how to point some local axis which *isn't* the positive Z axis towards another object

I'm creating an app where a person (right now I'm using a cone-shape) is standing on some surface (right now I'm using a cylinder laid lengthwise) and I'd like their feet to orient toward some point (right now it's the center of the cylinder).
(edit: I just realized that my Z axis in this photo is pointing in the wrong direction; it should be pointing towards the camera, but the question remains unchanged.)
Here is a version of the code similar to what I'm trying to accomplish. https://codepen.io/liamcorbett/pen/YMWayJ (Use arrow keys to move the cone)
//...
person = CreatePerson();
person.mesh.up = new THREE.Vector3(0, 0, 1);
//
// ...
//
function updateObj(obj, aboutObj=false){
let mesh = obj.mesh;
if (aboutObj) {
mesh.lookAt(
aboutObj.mesh.position.x,
aboutObj.mesh.position.y,
mesh.position.z)
};
}
//
// ...
//
function animate() {
// ...
updateObj(person);
// ...
}
The code above gives me something similar to what I'm looking for, but the issue is that lookAt() seems to always point the local Positive Z-axis in some direction, and I'd much prefer that it point the local Negative Y-axis instead.
I'd prefer to not change the x,y,z axes of the model itself, as I feel that's going to be a pain to deal with when I'm applying other logic to the person object.
Is there a way to change which axis lookAt() uses? Or am I going to have to roll my own lookAt() function? Thanks ~

Is there a way to change which axis lookAt() uses?
No, the default local forward vector for 3D objects (excluding cameras) is (0, 0, 1). Unlike other engines, three.js does not allow to configure the forward vector, only the up vector. But this is not really helpful in your case.
You can try to transform the geometry in order to achieve a similar effect.
If you don't want to do this for some reasons and you still want to use Object3D.lookAt(), you have to compute a different target vector (so not the cylinder's center).

Even if the forward vector of the lookAt method can't be changed (as #Mugen87 said), you can still adjust the local rotation afterwards by knowing in advance the difference between the forward Z axis used, and the axis you consider your mesh to be "upward" (ex: a person standing up on the Y axis).
Basically, in your case, just add this line after the lookAt method :
mesh.rotateOnAxis( new THREE.Vector3(1,0,0), Math.PI * -0.5 );
And the cone will look up :)

THREE .JS raycasting performance

I am trying to find the closest distance from a point to large, complex Mesh along a plane in a direction range:
for (var zDown in verticalDistances) {
var myIntersect = {};
for (var theta = Math.PI / 2 - 0.5; theta < Math.PI / 2 + 0.5; theta += 0.3) {
var rayDirection = new THREE.Vector3(
Math.cos(theta),
Math.sin(theta),
0
).transformDirection(object.matrixWorld);
// console.log(rayDirection);
_raycaster.set(verticalDistances[zDown].minFacePoint, rayDirection, 0, 50);
// console.time('raycast: ');
var intersect = _raycaster.intersectObject(planeBufferMesh);
// console.timeEnd('raycast: '); // this is huge!!! ~ 2,300 ms
// console.log(_raycaster);
// console.log(intersect);
if (intersect.length == 0) continue;
if ((!('distance' in myIntersect)) || myIntersect.distance > intersect[0].distance) {
myIntersect.distance = intersect[0].distance;
myIntersect.point = intersect[0].point.clone();
}
}
// do stuff
}
I get great results with mouse hover on the same surface but when performing this loop the raycasting is taking over 2 seconds per cast. The only thing i can think of is that the BackSide of the DoubleSide Material is a ton slower?
Also i notice as I space out my verticalDistances[zDown].minFacePoint to be farther apart raycast starts to speed up up (500ms /cast). So as the distance between verticalDistances[i].minFacePoint and verticalDistances[i+1].minFacePoint increases, the raycaster performs faster.
I would go the route of using octree but the mouse hover event works extremely well on the exact same planeBuffer. Is this a side of Material issue,. that could be solved by loading 2 FrontSide meshes pointing in opposite directions?
Thank You!!!!
EDIT: it is not a front back issue. I ran my raycast down the front and back side of the plane buffer geometry with the same spot result. Live example coming.
EDIT 2: working example here. Performance is little better than Original case but still too slow. I need to move the cylinder in real time. I can optimize a bit by finding certain things, but mouse hover is instant. When you look at the console time the first two(500ms) are the results i am getting for all results.
EDIT 3: added a mouse hover event, that performs the same as the other raycasters. I am not getting results in my working code that i get in this sample though. The results I get for all raycast are the same as i get for the first 1 or 2 in the sample around 500ms. If i could get it down to 200ms i can target the items i am looking for and do way less raycasting. I am completely open to suggestions on better methods. Is octree the way to go?
raycast: : 467.27001953125ms
raycast: : 443.830810546875ms
EDIT 4: #pailhead Here is my plan.
1. find closest grid vertex to point on the plane. I can do a scan of vertex in x/y direction then calculate the min distance.
2. once i have that closest vertex i know that my closest point has to be on a face containing that vertex. So i will find all faces with that vertex using the object.mesh.index.array and calculate the plane to point of each face. Seems like a ray cast should be a little bit smarter than a full scan when intersecting a mesh and at least cull points based on max distance? #WestLangley any suggestions?
EDIT 5:
#pailhead thank you for the help. Its appreciated. I have really simplified my example(<200 lines with tons more comments); Is raycaster checking every face? Much quicker to pick out the faces within the set raycasting range specified in the constructor and do a face to point calc. There is no way this should be looping over every face to raycast. I'm going to write my own PlaneBufferGeometry raycast function tonight, after taking a peak at the source code and checking octree. I would think if we have a range in the raycaster constructor, pull out plane buffer vertices within that range ignoring z. Then just raycast those or do a point to plane calculation. I guess i could just create a "mini" surface from that bounding circle and then raycast against it. But the fact that the max distance(manual uses "far") doesn't effect the speed of the raycaster makes me wonder how much it is optimized for planeBuffer geometries. FYI your 300k loop is ~3ms on jsfiddle.
EDIT 6: Looks like all meshes are treated the same in the raycast function. That means it wont smart hunt out the area for a plane Buffer Geometry. Looking at mesh.js lines 266 we loop over the entire index array. I guess for a regular mesh you dont know what faces are where because its a TIN, but a planeBuffer could really use a bounding box/sphere rule, because your x/y are known order positions and only the Z are unknown. Last edit, Answer will be next

FYI: for max speed, you could use math. There is no need to use ray casting. https://brilliant.org/wiki/3d-coordinate-geometry-equation-of-a-plane/

The biggest issue resolved is filtering out faces of planeBufferGeometry based on vertex index. With a planeBufferGeometry you can find a bounding sphere or rectangle that will give you the faces you need to check. they are ordered in x/y in the index array so that filters out many of the faces. I did an indexOf the bottom left position and lastIndexOf the top right corner position in the index array. RAYCASTING CHECKS EVERY FACE
I also gave up on finding the distance from each face of the object and instead used vertical path down the center of the object. This decreased the ray castings needed.
Lastly I did my own face walk through and used the traingle.closestPointToPoint() function on each face.
Ended up getting around 10ms per point to surface calculation(single raycast) and around 100 ms per object (10 vertical slices) to surface. I was seeing 2.5 seconds per raycast and 25+ seconds per object prior to optimization.

How to create 2D physics blob similar to the "Sushi Cat Game" using javascript physics engine?

I am trying to create HTML5 game that similar to Sushi Cat game. I followed a similar tutorial from Emanuele Feronato's blog post and then came up with the structure like the picture A in this image, where the gray orbits are allowed to penetrate each other, and the red lines are distantConstraint.
But the problem is when the blob fell from a high place (or hitting corner), it becomes like in picture B.
I tried to use spring, different constraint force, smaller orbits, but they are not working properly.
My questions:
What is the solution for this? Or where can I find the solution on the web?
Is there any other js physics engine that has a specific feature to do this task?

Remove the symmetry
Just add some additional constraints to the points. The current symmetry of the shape means that round and folded in half are both valid and relaxed configurations.
Radial constraints.
Using one of the lines from the center to the outside as a referance, give each spoke an offset angle from that line.
Then each outside point will be moved as follows.
Get angle of ref line.
var ang = Math.atan2(refLine.p2.y - refLine.p1.y, refLine.p2.x - refLine.p1.x);
Then for each line move the end point towards its desired relative angle position.
// line is a spoke line with a property angle that is the angle from the
// reference line
var x = refLine.p1.x; // get center point
var y = refLine.p2.y;
// get position relative to ref ang
line.x = Math.cos(line.angle + ang) * line.length + x;
line.y = Math.sin(line.angle + ang) * line.length + y;
Do that for each spoked line and apply it after you apply the line length constraints.
In referance to the image you gave the line from center to 12 o'clock is the reference line then the other spoked lines will have angles restrained as follows.
1 o'clock is 30deg from ref
2 o'clock is 60
3 is 90 so on to 6 at 180deg
And the other direction
11 o'clock is -30deg from ref
10 o'clock is -60 and so on
You will be able to ignore the 6 o'clock line incase giving it a constraint makes the object want to roll to the right.
Only one
This now means that there is only one solution to the possible states rather than the many that you had.

The reason why the blob folds into itself, is because gravity will squish the blob points and the distance joints will find a new valid configuration. The job of the distance joint is just to maintain a given distance between two points, and it doesn't really do anything to prevent the self-folding.
An alternative approach is using Prismatic Joints (also called "slider joints"). With prismatic joints, the outer blob circles would slide along an axis radially from the center of the blob. To make the blob springy, you could add some kind of springs between the blob center and the circles. If the blob still self-folds, you could add limits to the prismatic joints, so the circles can only slide a certain distance.
This video demonstrates prismatic joints in a similar fashion, using the RUBE physics editor (using box2d under the hood).
A similar scene was made using p2.js physics engine, read more here. (direct link to demo). The part of the code that constructs the Prismatic Joints in the p2.js demo is:
// Constrain the capsule body to the center body.
// A prismatic constraint lets it move radially from the center body along one axis
var prismatic = new p2.PrismaticConstraint(wheelBody, body, {
localAnchorA : [0, 0],
localAnchorB : [0, 0],
localAxisA : [Math.cos(angle), Math.sin(angle)],
disableRotationalLock: true, // Let the capsule rotate around its own axis
collideConnected: true
});
In JavaScript, there are several ports of Box2D available which have the Prismatic Joint. p2.js has PrismaticConstraint.

Constant Volume Joint may be what you are looking for. As its name suggests, it tries to maintain the volume it has upon creation despite impulses from outside, much like a water balloon.
Here is a demo.
A working example with Box2dweb can be found here.
If you are interested in creating blobs with the creative application of more standard joints, this article comes to my mind.

Find 'view' co-ordinates in vis.js

I'm working on a modification to vis.js's Graph3d to do a filled line graph, like this:
The hard part - unsurprisingly - is working out the rendering order for the polygons. I think I can do this by checking whether a ray from the viewer to a given line B crosses line A:
In this example, since line A is "in the way" of line B, we should draw line A first. I'll use a snippet of code from How do you detect where two line segments intersect? to check whether the lines cross.
However, I haven't figured how to find the position of the user's view. I kind of assumed this would be the camera object, so wrote a little bit of debug code to draw the camera on the graph:
var camera = this._convert3Dto2D(this.camera.getCameraLocation());
ctx.strokeStyle = Math.random()>0.5 ? 'ff0000' : '00ff00';
ctx.beginPath();
ctx.moveTo(camera.x, camera.y);
ctx.lineTo(camera.x, camera.y+5);
ctx.stroke();
In fact, the camera co-ordinates as measured by this are always at 0,0,0 on the graph (which would be the far top right on the above screengrab). What I need, I think, is effectively the bottom of the screen.
How can I find this? Or is there a better way to achieve what I'm trying to do?

I don't know if this is still an active issue, but FWIW, Graph3D has internal handling of the sort ordering.
All graph points are sorted with respect to the viewpoint, using a representative coordinate called point.bottom. The rendering is then done using this ordering, with the most distant elements drawn first. This works fine as long as none of the elements intersect; in that case, you can expect artefacts.
Basically, all you need to do, is define point.bottom per graph polygon, and Graph3D will then pick it up from there.
If you are still interested in working on this:
This happens in Graph3d.js, method Graph3d.prototype._calcTranslations(). For an example, have a look at how the Grid and Surface graph elements are initialized in Graph3d.prototype._getDataPoints(). The relevant code is:
obj = {};
obj.point = point3d;
obj.trans = undefined;
obj.screen = undefined;
obj.bottom = new Point3d(x, y, this.zRange.min);

Drawing half of a Bezier path in Raphael

Let's say I have a cubic Bezier path as follows (formatted for use with the Raphael path function):
M55 246S55 247 55 248
Just an example. This was taken from my drawing application, where I use the cursor to draw a line when the user holds the mouse button down, kind of like a pencil or marker. I'm using jquery's mousemove event to draw the line between two points every time the user moves the mouse. There is another (the reference point) that is taken before the line is drawn, so that the Bezier curve can be created.
Here's my question: is it possible to make Raphael only draw half of a given path? I'm aware of the getSubpath() function, but if my understanding of Bezier curves is correct, it would be rather difficult to calculate the second argument. The problem with the animate function is that it creates double lines (that is, it creates the curved line that I want, and the boxy line around it which should not be shown, possibly because the mouse is being moved faster than the animation can handle).
Of course, if my approach itself is flawed in some way (or my understanding of the possible solutions), I'd like to hear it. Any help would be appreciated.

It is a bit messy, but maybe this will answer it:
line[line.length] = paper.path(drawPath); //drawPath being the fill line length
//get a subpath, being half the length of your bezier curve
subPath = line[line.length - 1].getSubpath(0, line[line.length - 1].getTotalLength()/2);
//remove the full-length bezier curve
line[line.length - 1].remove();
//Draw your new line
line[line.length - 1] = paper.path(subpath);
Honestly, this this is quite inefficient. But, I can't think of a better way to go about it. You can't just grab the tangent and divide by half, since a bezier curve will be longer the length of a tangent line (as a crow flies). This means that you must process the line via rapheal and then get a subPath of half the length.

The middle point can be calculated, not aware of any functionality in Raphael that will cut the bezier in half for you.
From the looks of those commands, it's standard SVG markup (see the SVG spec to understand it better: http://www.w3.org/TR/SVG/paths.html#PathDataCubicBezierCommands)
M=> MoveTo the absolute position 55,24
S=> Smooth Curve to the absolute 55,247 55,248
Smooth curve can be rewritten as a standard CurveTo or C if you want, S is only the shorthand for it and the curveto / C you can easily calculate the center point.

Splitting a bezier curve in half is just a bit of math, nothing too hard. You might be helped by the path extensions for raphaël, and it should be pretty simple to add a method there to do the splitting.
The "just a bit of math" part could e.g use De Castelau's algorithm for splitting the curve at any given point.