I've set up a simple demo of UV mapping at http://jsfiddle.net/pB5A9/1/ . It's based on Image manipulation and texture mapping using HTML5 Canvas? .
The algorithm itself works pretty well. There's one issue, though. There appears to be a faint seam between the triangles. I tested this both on Chrome (14.something) and Safari (5.1). It's possible it works correctly in other browsers though I cannot be sure of that.
I'm guessing the issue has something to do with clipping. The thing is I'm not sure how to tweak the coordinates so that the issue disappears. Perhaps it's missing some padding (+1) or something. Ideas are welcome. :)
It has to do with the way different browsers choose to take on anti-aliasing (or not).
It looks good on Chrome 15.
Clipping less should solve your problem. I'd suggest you try expanding your clipping region for each object by 0.5 or 1 pixel and see how it does. (alternatively you could try shifting everything by 0.5 pixels and seeing if the anti-aliasing changes, you might be surprised)
Related
Version and info
THREE.ObjectLoader2: 2.4.1
THREE.LoaderSupport.MeshBuilder: 1.2.1
THREE.LoaderSupport.WorkerSupport: 2.2.0
THREE.WebGLRenderer: 93
THREE.REVISION: 93
The problem
When I raycast an object in my scene, I found that it worked perfectly down to the pixel, until I moved the object. In my program I expload the scene, so I move all the objects, and child objects away from the center of the scene.
To easily visualise the issue instead of raycasting a single point at a mouse click, I opted to raycast the entire screen, this is what I get (Figure 1)
(Figure 1)
The reason for the gaps is because it took to long to raycast every pixel, so instead I raycasted every fourth. The reason for the gap in the middle is because I zoomed away from the original position.
Now, see what happens when I expload the object (Figure 2),
(Figure 2)
As you can see, there is almost a circle. Why is this?
What I've tried
I've tried many things across the internet, and came here when I could find no more.
I've tried a range of different models, some work differently to others, strangely enough. The lamborghini-aventador which was created in Blender works the strangest.
To see if it was a problem with the exploading code, I moved the object to the right. This is where things get interesting (Figure 3).
(Figure 3)
It looks as if my outlining I put on the object (the outlines are an EdgesGeometry) is behind, the actual object is in the middle, and the raycasts are further.
What I speculate
I suspect the issue is to do with scaling. So I tried removing all scaling I did in the code, however I got the same result, unfortunately.
Apologies if this is some noobie mistake, though I do hope it is :)
The code
For those who are adventurous enough to delve into my terrible code base, here it is (the majority of the code is inside demo.js):
github
Testing it
Press G to shoot the raycasts (will freeze for a bit), press X to expload, press S to unexpload. Standard orbit controls.
What I've found
Here are some of the links I have already found and tried on this issue:
https://threejs.org/docs/#api/core/Raycaster
Three.js Raycaster not detecting scene mesh
https://github.com/mrdoob/three.js/issues/1325 (Updating the matrix)
http://barkofthebyte.azurewebsites.net/post/2014/05/05/three-js-projecting-mouse-clicks-to-a-3d-scene-how-to-do-it-and-how-it-works (Followed step by step)
... and many more ...
Any ideas?
I think that your model might not have proper bounding boxes/spheres generated.
The circular shape could result from the rays passing the bounding sphere check of a bounding sphere that is too small.
You mention resizing/processing your geometries in some way... After you do that, try calling geometry.computeBoundingBox() and geometry.computeBoundingSphere() to rebuild boxes and spheres, and see if that helps?
edit: Apparently this problem was due to bounding boxes and spheres not being recomputed...
the fix was to:
scene.traverse( (o)=>if(o.geometry){o.geometry.computeBoundingBox();o.geometry.computeBoundingSphere();} );
I came across a problem today where diagrams I have created are not working in Firefox when created via getPointAtLength. Here is a fiddle showing the problem:
http://jsfiddle.net/xfpDA/9/
Note comments at the top of the javascript.
The relevant part of the SVG path is:
C189.5,423.237,266.965,390.696,266.965,390.696
This works perfectly in Chrome and IE, but Firefox skips right over the curve and just closes the path.
However, a tiny change to the curve is enough to fix the problem:
C189.5,423.236,266.965,390.696,266.965,390.696
^
Why does changing that value by a thousandth make the difference between a pretty curve and a broken SVG?
EDIT: That coordinate is not the only one that can be changed to 'fix' the problem, so it appears that Firefox does not play nicely with high-precision curve values.
Firefox is not able to calculate the length of the curve under some circumstances (e.g. delta=0/0). So the result for that path part is NaN/0/undefined and therefore is not added to the total length and the domain for getPointAtLength is smaller.
I'm combining 3D content with Three.js with HTML and SVG content. The Three.js CSSLoader does a pretty good job synchronizing placement of HTML and SVG content in the 3D world.
But the SVG/HTML coordinate systems are 'left-handed', whereas Three.js coordinate system is 'right-handed'. This basically means that their y-axes are reversed. In SVG/HTML, y/top goes up as you go down the screen, and Three.js uses the more standard mathematical convention of y going down as you go down the screen.
I have to continually convert from one to the other, which is pretty error prone. I know I am not the first to run into this (for example, look here). Has someone come up with a general solution? Here's what I tried:
Do everything in an Object3D with .scale.y = -1. As you may suspect, this turns out to be a disaster. It turns everything inside-out, and don't even try to put your camera in there.
Do everything in an Object3D with .rotate.x = Math.PI. This is more promising, but the z axis is no longer consistent with the HTML concept of z-index. Still, this is what I'm using now.
In HTML, don't use top, use bottom. In SVG, do everything inside a <g transform="scale(1, -1)"> inside a <g transform="translate(0, imageHeight)">. However, I feel this would be more confusing for developers, and the imageHeight has to be kept up to date at all times, which is yet another burden.
Has anyone come up with something better? Perhaps a library to help with this?
I would suggest you to use the SVG Global Transform Attribute, if you post an example of your code, i could edit the answer and post the example here, maybe a JSfiddle.
Basically you will need to add the transformation to your SVG, in your case to change the direction of y-axis, you can do a "scale(1,-1)".
See the W3 documentation with examples in the following link:
http://www.w3.org/TR/SVG/coords.html#SVGGlobalTransformAttribute
The first common use of this attribute:
Most ProjectedCRS have the north direction represented by positive
values of the second axis and conversely SVG has a y-down coordinate
system. That's why, in order to follow the usual way to represent a
map with the north at its top, it is recommended for that kind of
ProjectedCRS to use the ‘svg:transform’ global attribute with a
'scale(1, -1)' value as in the third example below.
They have some examples there too, I hope it solves your problem. :)
I'm trying to implement collision detection for SVG text elements using client side JavaScript. The hit-test should check if any glyph of a text overlaps any glyph of another text element. Since getBBox and getExtentOfChar are anything than accurate I need a custom solution.
My first approach was to get the colour of each coordinate/pixel of an element and do the hit-testing manually, but this does not work because it isn't possible to get the colour of a coordinate. It would require an additional canvas to get pixel colours -> awful workaround.
Now I'm thinking about converting the text or the glyphs to polygons for hit testing. Is it possible? Or has anyone another approach for glyph based hit testing?
Best Regards
You are really entering a world of pain and cross browser problems. I ended up doing custom path-rendering of fonts only to get the total text length reliable and consistent. I don't even want to think about glyph-hitting.
One problem for example is that firefox (at least 3.6) and iirc also some version of opera has some rounding error when scaling so when you scale the parent-element holding the text and scale the text by the inverse of that scale, then the letter-spacing will be slightly different compared to without any scale. (Because each letter must begin on an even number or something like that, problem can be solved by multiplying both the upscale and downscale with like 10000 but that's another story)
The performance impact by using path compared to text is unfortunately quite noticeable. If your canvas does any form of animated panning or zooming you should switch to pure text-elements during the animation and once static, turn on path rendering for accuracy.
Fortunally converting svg-fonts to paths is very easy, it is plaintext and using the exact same format as the path-element. (beware of font-embedding-licenses though! Also keep file size in mind as you cannot use the fonts from the users system, )
As for the pixel-based hit-testing – if you switch to HTML5 Canvas, then this will become possible. Several projects provide easy transition from SVG to Canvas, e.g. fabric.js. See a comparison table here.
As for the polygon-based approach – possible, but difficult. You can convert text or glyphs to polygons (paths) using some tool (Inkscape's text-to-path for instance). And then there'll be calculations. Making a general solution for any text will require a lot of work. However, if the text doesn't change, then drawing your text manually using paths can be a quick and dirty solution.
I've googled and googled about this, and all I can find, including on StackOverflow, is "support was and is broken in most major browsers." Not an actual solution to my problem.
This month's Playboy came with a pair of 3D glasses (red/cyan) to view the eye-popping centerfold. Naturally, I hit the Internets to find every single red/cyan anaglyph I could and look at how awesome they are. Eventually I found some animated GIFs, which led to the idea that maybe I should make some cool HTML5 Canvas thing that lets you put shapes on a scene in 3D.
This is how far I got. Only works well in Google Chrome. In Firefox, the "Elevated Text" should look correct, but not the rectangles.
The way I'm generating the scene is thus: There are layers that each contain a Z-index, and you can place a rectangle or some text on whichever layer you want. The concept is simple. When drawing the object, it draws one [Z-index] pixels to the left in pure red, then it draws one [Z-index] pixels to the right in pure cyan.
In theory, the overlapping parts should subtract to become pure black. In Chrome, this happens for filling rectangles, stroking text, but not for filling text. In Firefox, this only happens for stroking text.
Although the intended effect of globalCompositeOperation="darker" should do exactly what I want, it's obvious that going down this road is going to bring nothing but pain.
Does anyone here have an idea as to how I can get the effect I want without using globalCompositeOperation? I tried messing with the alpha channel on the colors but didn't really like how that came together (they never add up to pure black). I could draw a third black rectangle between the red and cyan ones, but that doesn't solve the problem for text or arbitrary shapes.
I could do the pixel-for-pixel rendering myself in the Javascript, but that just seems like overkill. Any thoughts?
If you still need this, I have written a free context-blender library that lets you perform Photoshop-style blend modes between two canvases. I have not yet added 'darker', but you could either:
Fork the project on GitHub, add your own support for darker (it's pretty easy to see how to add a mode) and then send me a pull request, or
Ply me with promises of upvotes to get it added for you. :) The only hard part (as with many of the blending modes) will be attempting to determine what is correct when blending one or two areas which are <100% opacity.
It seems that the correct mode in Firefox is globalCompositeOperation="difference". Haven't tested in Chrome or IE.
Because "difference" is a mathematical operation, there is no ambiguity in the implementation, unlike the subjective term "darker".
Maybe you would like to use darken instead of darker. darker has been removed from the specification in 2007
It's a bit of a hacky way but it worked for me.
You can invert the entire canvas by doing
ctx.globalCompositeOperation = "difference";
ctx.fillStyle = "white";
ctx.fillRect(0,0,canvas.width,canvas.height);
Then render whatever you want to render using globalCompositeOperation = "lighter". Then invert the entire canvas again and it should give the same results as a "darker" blend mode would.