I want to make an interactive globe 3D and I found this site that seems to be perfect to what I want, but I'm have some problems with the code.
1- I downloaded the source code but he don't open in my browser, it stop in the loading...
2- Are There best way to map the click on countries? The current code is using segments but if I want to click on some little country I will have to increase the amount of segments and this make some performance problems to some computers or cellphones.
Related
I'm looking to implement a video editing feature like that of featured here https://clideo.com/video-editor.
I'm planning to use Vue 3 with a Laravel backend, but is there an ideal framework to use for a web application like this, or should I just try to reverse engineer/hack my way to a working implementation?
Sorry if this is the wrong place to ask, I just haven't been able to find an answer.
Thanks
Video editor consist of two important parts
1)A Timeline that represents sequence.
2)A Output window to show output of timeline.
-Clideo uses div and html elements positioning to generate timeline but a better alternative is to use Canvas and draw a timeline on it just like in veed.io
-For video output again you have to use canvas and webGL to draw each and every frame one by one.
you wont be able to edit video on backend and send edited multimedia for each change user makes you need to find a way to do in on client using webcodec.
For the choice of framework if you are having canvas and webGL do all the rendering of timeline and output then it dosent matters you will spend more time with drawing functions.
Almost every video editor has a timeline. But only in some of it (https://wave.video/tools/video-marketing/promo-video-maker) is divided into several ranges. An additional advantage will be the grid on the line. You can also easily manage layers and frames.
I have a SVG generated map for the game I am developing. I have no problems with the game being open-source and it uses open web technologies such as HTML and SVG. No problems there.
But at the same time I want the players not to be able to see or reverse engineer a map of the whole world (to retain true exploration). For now I generate map using a seed that is secret and not version controlled. So even though the algorithm is known curious players can use open-sourced code to generate "game-like worlds" but not that exact one. This solves the "global" problem.
But since SVG is rendered on a page as a single Voronoi diagram all the data (I don't mind the coordinates of points) would be extractable. Data like resources, land types, biomes, climate etc. could be fetched from SVG to gain an upper hand in finding good locations for settlements.
Any idea how to prevent that? Players have limited vision so I thought about either:
not rendering the whole Voronoi diagram at all (just the visible part), but that could be potentially tricky to do (maybe, haven't looked into it yet),
inserting the resource/land tile data into SVG graph only to visible locations
I can see the benefits of both approaches and if done correctly it could even boost the performance (not rendering the whole thing/rendering with less data) and lead to bigger worlds without impacting performance.
Any other ideas/programming/architectural approaches to help with the issue?
(I am using Vue.js, d3.js, svg-pan-zoom and Laravel backend just in case it helps.)
The ideas that you gave are perfect, but for implementing them, you need to make hard work, and spend much time.
I have a suggestion. Is will work for most of the users. Maybe some users will "hack" it. But I believe it will work for 95% of the times.
You can create a very big rectangle, from the top left point 0,0 until the right bottom point. The rectangle will be white, and it will be over all other shapes.
This way if someone will download the SVG, we will see nothing. Just a big white rectangle.
In you game HTML, you can add a CSS selector, to hide this rectangle.
If you following this method, most of the users (who don't have a photo editing software) will not be able to see the map.
Users who knows how to inspect elements in HTML may see the map. But I believe that most of them who will see a white box, will not believe that there is something behind.
I think that this is a simple temporary approach that you can do, before doing other more defensive ways.
I'm working on a website which mixes html and WebGL/canvas. We're using WebGL/canvas to draw a graph with many elements, which proved to be too slow if drawn using html or svg.
The problem is that not our whole page is made in WebGL/canvas. The browser remembers the zoom from the html part of the website where zooming is fine, and then applies it to the part which uses WebGL, making the raster graph there blurry and too large for the window.
This is a major setback and a huge blow to the user experience. The worst part is that the browser won't even let me READ the zoom value so that I could AT LEAST notify the user about the issue, or even adjust the drawing based on the zoom.
Has anyone else run into this problem? How did you solve it?
I am trying to build a network graph (like a network for brain) to display millions of nodes. I would like to know to what extent I can push the d3 js to in terms of adding more network nodes on one graph?
Like for example, http://linkedjazz.org/network/ and http://fatiherikli.github.io/programming-language-network/#foundation:Cappuccino
I am not that familiar with d3.js (though I am a JS dev), I just want to know if d3.js is the right tool to build a massive network visualization (one million nodes +) before I start looking at some other tools.
My requirements are simply: build a interactive web based network visualization that can scale
Doing a little searching myself, I found the following D3 Performance Test.
Be Careful, I locked up a few of my browser tabs trying to push this to the limit.
Some further searching led me to a possible solution where you can pre-render the d3.js charts server side, but I'm not sure this will help depending on your level of interaction desired.
That can be found here.
"Scaling" is not really an abstract question, it's all about how much you want to do and what kind of hardware you have available. You've defined one variable: "millions of nodes". So, the next question is what kind of hardware will this run on? If the answer is "anything that hits my website", the answer is "no, it will not scale". Not with d3 and probably not with anything. Low cost smartphones will not handle millions of nodes. If the answer is "high end workstations" the answer is "maybe".
The only way to know for sure is to take the lowest-end hardware profile you plan to support and test it. Can you guarantee users have access to a 64GB 16 core workstation? An 8GB 2 core laptop? Whatever it is, load up a page with whatever the maximum number of nodes is and sketch in something to simulate the demands of the type of interaction you want and see if it works.
How much d3 scales is very dependent on how you go about using it.
If you use d3 to render lots of svg elements, browsers will start to have performance issues in the upper thousands of elements. You can render up to about 100k elements before the browser crashes, but at that point user interaction is basically useless.
It is possible, however, to render lots and lots of lines or circles with a canvas. In canvas, everything is rendered in a single image file. Rather than creating a new element for each node or line, you draw a line in the image file for it. The downside of this is that animation is a bit more difficult, since you can't move elements in a canvas, only draw on top of a canvas or redraw the whole thing. This isn't impossible, but would be computationally expensive with a million nodes.
Since canvas doesn't have nodes, if you want to use the enter/exit/update paradigm with it, you have to put placeholder elements in the DOM. Here's a good example of how to do that: DOM-to-canvas with D3.
Since the memory costs of canvas don't scale with the number of nodes, it makes for a very scalable solution for large visualizations, but workarounds are required to get it to be interactive.
Are there any JavaScript libraries out there that allow you to create heatmaps using in-browser graphic rendering features such as <canvas> or SVG?
I know about HeatMapAPI.com, but their heat maps are generated on the server side. I think that in the era of <canvas> element we don't need that anymore!
If there is nothing like this yet, are there any volunteers to participate in creating such a tool?
I created a demo including a real-time heatmap with the <canvas> element and javascript. I also added the documented code next to the heatmap sample. The heatmap generation process is based on an alpha map in the canvas element which depends on the users mouse movement.
You can take a look at my demo right here:
http://www.patrick-wied.at/static/heatmap/
I created a hit map with the help of Google Visualization API [http://code.google.com/apis/visualization/documentation/]. It uses SVG & VML, and also cross browser compatible. Hope it'll help.
I have some js/canvas/web worker code here though there's plenty of work that could be done with it. It's also pushed online at http://heatmapthing.heroku.com/. Your browser needs to support web workers for this.
Please send pull requests if you improve it. The pseudo-gaussian smoothing is slooooooooow as hell right now.
I also gave it a try, but without doing the Gaussian smoothing my self, I let canvas do that for me. Basically I draw a radial gradient for every point in gray scale and then colorize this gray scale image (see "Creating Heat Maps with .NET 2.0 (C#)" for a detailed explanation, my implementation differs a bit).
The result looks like this:
(source: bitbucket.org)
The rendering time isn't that bad on Chrome/Chromium. I think the most time consuming part is the colorizing, because I am looping over every pixel.
You can find the code here: http://trac.openlayers.org/browser/sandbox/camptocamp/canvas/openlayers/lib/heatmap-js/heatmap.js
I played with heatmap a few years ago. See http://www.urbigene.com/treemapphp/, the algorithm came from here: http://www.cs.umd.edu/hcil/treemap-history/
Heatcanvas looks quite good. It also has a leaflet extension to run on top of openstreetmaps
https://github.com/sunng87/heatcanvas
It runs quite well on few points (< 200) or so, but gets a bit slow on many thousands of points. I think it might also recalculate more often than necessary after pan and zoom, and I had some problems with changing the heatmap on the fly (replacing heatmap with another using javascript), guess I need to experiment a bit more with it, or contact the author