I am doing a very simple implementation of plotting polygons in Leaflet.js using d3.js
I am following this: http://bost.ocks.org/mike/leaflet/
Polygons are plotted correctly, but when zooming in/out most of them are not visualized (even if in DOM I can see these hidden polygons)
You can check http://bl.ocks.org/pere/7370413
Any ideas?
The bounds were being calculated outside of the reset function so it was using the original zoom (I think this might be a small error in Mikes Bl.ock, although experience has taught me this is rarely the case). Because the bounds were calculated outside of reset it was using the original zooms bounds and hence you saw the polygons drift. Also, this stops the polygons being "cut-off" (which occurs in Mike's Bl.ock).
Anyway I bumped your Bl.ock to here. There are some other minor changes as well.
Hope this helps.
Related
I've been trying to render silhouettes on CAD models with webgl. The closest i got to the desired result was with fwidth and a dot between the normal and the eye vector. I found it difficult to control the width though.
I saw another web based viewer and it's capable of doing something like this:
I started digging through the shaders, and the most i could figure out is that this is analytical - an actual line entity is drawn and that the width is achieved by rendering a quad instead of default webgl lines. There is a bunch of logic in the shader and my best guess is that the vertex positions are simply updated on every render.
This is a procedural model, so i guess that for cones and cylinders, two lines can always be allocated, silhouette points computed, and the lines updated.
If that is the case, would it be a good idea to try and do something like this in the shader (maybe it's already happening and i didn't understand it). I can see a cylinder being written to attributes or uniforms and the points computed.
Is there an approach like this already documented somewhere?
edit 8/15/17
I have not found any papers or documented techniques about this. But it got a couple of votes.
Given that i do have information about cylinders and cones, my idea is to sample the normal of that parametric surface from the vertex, push the surface out by some factor that would cover some amount of pixels in screen space, stencil it, and draw a thick line thus clipping it with the actual shape of the surface.
The traditional shader-based method is Gooch shading. The original paper is here:
http://artis.imag.fr/~Cyril.Soler/DEA/NonPhotoRealisticRendering/Papers/p447-gooch.pdf
The old fashing OpenGL technique from Jeff Lander
I'm using d3 v4 to draw a collapsible tree - see here
I'm setting the translateable world using translateExtent but when you zoom in or out, the translateable world doesn't adjust. You can see in my example (lines 479-514) I've attempted to fix this by multiplying by the scale or dividing by scale where appropriate but that hasn't worked. (The ideal is that when you move at any point there is always one 'card' visible - it works at 1x zoom).
Another complication is that the top node of the tree needs to be centralised in the browser, so everything is offset relative to that.
I've seen a few other mentions that translateExtent doesn't work with zooming in or out but wondered if anyone had managed to get it to work?
I am learning d3js and trying to incorporate zooming/panning features on a graph, however on the initial zoom event it jumps to a random spot and zooms in. After that, the zooming and panning work as expected. Why is the initial event moving the starting point and adjusting the scale oddly?
Code and example here: bl.ocks.org/dbaileychess/7570631
This is because the zoom behaviour is attached to a different element than the one you're zooming. It determines the position of the mouse cursor relative to its own position and passes that information to the callback. If you're zooming a different element, the relative coordinates are no longer correct.
To fix, add the offset between the elements that the zoom behaviour is attached to and the elements you're zooming to the translation. This question has come up a number of times already, see e.g. here.
I am trying to create a simple example with three.js. I have a bunch of triangles making up a volume. It seems triangles are incorrectly ordered -- or rendered in weird order. Here is the example you can see:
http://urlmin.com/qlp
just rotate the view around and see the view flickering.
The behavior is same with canvas or webgl renderer.
Please note that I am not using lights. Each triangle is colored slightly differently.
I must be missing something really simple. Let me know you think. Thanks!
JSFiddle here http://jsfiddle.net/aR8wr/
Your camera NEAR plane is very small and FAR plane very big. This results in less precision in rendering, floating point errors, and thus, flickering. Setting those variables to for example 0.01 and 1000 gets rid of the flickering.
It still looks weird from some angles. I'm not exactly sure what causes it, but it might help if you divide your model into smaller triangles. Alternatively, you can use WebGLRenderer, where it works perfectly as long as you set more sensible values to NEAR and FAR.
Having fun with D3 geo orthographic projection to build an interactive globe, based on all the great examples I found.
You can see my simple mockup at http://bl.ocks.org/patricksurry/5721459
I want the user to manipulate the globe like a trackball (http://www.opengl.org/wiki/Trackball). I started with one of Mike's examples (http://mbostock.github.io/d3/talk/20111018/azimuthal.html), and improved slightly to use canvas coordinates and express the mouse locations in 'trackball coordinates' (i.e. rotation around canvas horizontal and vertical axes) so that a fixed mouse movement gives more rotation near the edges of the globe (and works outside the globe if you use the hyberbolic extension explained above), rather than Mike's one:one correspondence.
It works nicely when the globe starts at an unrotated position (north pole vertical), but when the globe is already rotated (manipulate the example so the north pole is facing out of the page) then the trackball controls become non-intuitive because you can't simply express a change in trackball coordinates as a delta in the d3.geo.rotate lat/lon coordinates. D3's 3-axis rotation involves applying a longitude rotation (spin around north pole), then a latitude rotation (spin around a horizontal axis in the canvas plane), and then a 'yaw' rotation (spin around an axis perpendicular to the plane) - see http://bl.ocks.org/mbostock/4282586.
I guess what I need is a method for composing my two rotation matrices (the one currently in the projection, with a new one to rotate the trackball slightly), but I can't see a way to do that in D3, other than digging into the source (https://github.com/mbostock/d3/blob/master/src/geo/rotation.js) and trying to do the math to define the rotation matrix. The code looks elegant but comment-free and I'm not sure I can correctly decipher the closures with the orthographic projection instance.
On the last point, if someone knows the rotation matrix form of d3.geo.projection that would probably solve my problem too.
Any ideas?
There is an alternative solution to patricksurry's answer, by using quaternion representations, as inspired by Jason Davies. I, too, thought D3 would've already supported this composition natively! And hoped Jason Davies posted his code...
Took sometime to figure out the math. A demo is uploaded here, with an attempt to explain the math too. http://bl.ocks.org/ivyywang/7c94cb5a3accd9913263
With my limited math knowledge, I think, one of the advantages quaternion over Euler is the ability to compound multiple rotations over and over, without worrying about coordinate references. So it would always work, no matter where your north pole faces, and no matter how many rotations you'll have. (Someone please correct me, if I got this wrong).
I decided that solving for the combined rotation matrix might not be so hard. I got http://sagemath.org to do most of the hard work, so that I could express the composition of the original projection rotate() orientation plus a trackball rotation as a single equivalent rotate().
This gives much more natural behavior regardless of the orientation of the globe.
I updated the mockup so that it has the improved version - see http://bl.ocks.org/patricksurry/5721459
The sources are at http://bl.ocks.org/patricksurry/5721459 which include an explanation of the math - cool that you can use proper greek letters in javascript for almost readable math sourcecode!
It would still be good if D3 supported composition of rotate operations natively (or maybe it does already?!)