I've been studying this:
https://github.com/mikechambers/ExamplesByMesh/blob/master/JavaScript/QuadTree/src/QuadTree.js
and I believe I understand the general idea about quad trees, although I do have two questions about how they work, and the implementation above:
Wouldnt you have to rebuild the entire tree every several ms? In Javascript wouldnt this be extremely slow to do?
If I have something like this: http://davzy.com/screenshots/skitched-20120318-180324.png, then its easy enough to find the other dots in the same quad but I have a rectangle that hits 3 different quads, is there a way I can make it display as a child of all 3 of those quads?
On 144 of the above example it says this Node.prototype._classConstructor = Node;, I'm just curious what's going on. I thought prototype was a way to define a function or variable for future use within a class, so I'm not sure what this line does.
1. Wouldnt you have to rebuild the entire tree every several ms? In Javascript wouldnt this be extremely slow to do?
I suppose that depends on what you're using it for; but yes, the author's collision-detection example in his blog post about his QuadTree implementation will clear the tree and repopulate it roughly 24 times per second (so, about once per 40 ms). You can judge for yourself whether that's "extremely slow"; on my machine it looks quite smooth. (And even if not, I would expect the rebuilding of the QuadTree to actually be cheaper/faster than the redrawing of all of the circles on the canvas.)
2. […] I have a rectangle that hits 3 different quads, is there a way I can make it display as a child of all 3 of those quads?
I'm not sure what you mean by "display", but: if you call the constructor with the pointQuad parameter set to false, then items are two-dimensional (i.e., they have width and height in addition to x and y), and every item will be a child of the smallest quad that it fits completely inside. In your example, since the rectangle crosses the vertical midline of the canvas, it will be a direct child of the root quad.
3. On 144 of the above example it says this Node.prototype._classConstructor = Node;, I'm just curious what's going on. […]
The Node "class" has a "subclass" named BoundsNode (used when the items are two-dimensional), and BoundsNode.prototype._classConstructor is set to BoundsNode (which overrides the inherited Node.prototype._classConstructor). This allows Node's subdivide method to write new this._classConstructor(...) in order to construct a new BoundsNode if this is a BoundsNode, and a new plain Node if this is a plain Node.
Related
I grew up using JQuery and have been following a programming pattern which one could say is "React-like", but not using React. I would like to know how my graphics performance is doing so well, nonetheless.
As an example, in my front-end, I have a table that displays some "state" (in React terms). However, this "state" for me is just kept in global variables. I have an update_table() function which is the central place where updates to the table happen. It takes the "state" and renders the table with it. The first thing it does is call $("#table").empty() to get a clean start and then fills in the rows with the "state" information.
I have some dynamically changing data (the "state") every 2-3 seconds on the server side which I poll using Ajax and once I get the data/"state", I just call update_table().
This is the perfect problem for solving with React, I know. However, after implementing this simple solution with JQuery, I see that it works just fine (I'm not populating a huge table here; I have a max of 20 rows and 5 columns).
I expected to see flickering because of the $("#table").empty() call followed by adding rows one-by-one inside the update_table() function. However, the browser (chrome/safari) somehow seems to be doing a very good job of updating only that elements that have actually changed (Almost as if the browser has an implementation of Virtual DOM/diffing, like React!)
I guess your question is why you can have such a good graphics performance without React.
What you see as a "good graphics performance" really is a matter of definition or, worse, opinion.
The classic Netscape processing cycle (which all modern browsers inherit) has basically four main stages. Here is the full-blown Gecko engine description.
As long as you manipulate the DOM, you're in the "DOM update" stage and no rendering is performed AT ALL. Only when your code yields, the next stage starts. Because of the DOM changes the sizes or positions of some elements may have changed, too. So this stage recomputes the layout. After this stage, the next is rendering, where the pixels are redrawn.
This means that if your code changes a very large number elements in the DOM, they are all still rendered together, and not in an incremental fashion. So, the empty() call does not render if you repopulate the table immediately after.
Now, when you see the pixels of an element like "13872", the rendering stage may render those at the exact same position with the exact same colors. You don't have any change in pixel color, and thus there is no flickering you could see.
That said, your graphics performance is excellent -- yes. But how did you measure it? You just looked at it and decided that it's perfect. Now, visually it really may be very very good. Because all you need is avoid the layout stage from sizing/positioning something differently.
But actual performance is not measured with the lazy eyes of us humans (there are many usability studies in that field, let's say that one frame at 60 Hz takes 16.6 ms, so it is enough to render in less than that). It is measured with an actual metric (updates per second or whatever). Consider that on older machines with older browsers and slower graphics cards your "excellent" performance may look shameful. How do you know it is still good on an old Toshiba tablet with 64 MB graphics memory?
And what about scaling? If you have 100x the elements you have now, are you sure it will scale well? What if some data takes more (or less) space and changes the whole layout? All of these edge conditions may not be covered by your simple approach.
A library like React takes into account those cases you may not have encountered yet, and offers a uniform pattern to approach them.
So if you are happy with your solution you don't need React. I often avoid jQuery because ES5/ES6 is already pretty good these days and I can just jot down 3-4 lines of code using document.getElementById() and such. But I realize that on larger projects or complex cases jQuery is the perfect tool.
Look at React like that: a tool that is useful when you realize you need it, and cumbersome when you think you can do without. It's all up to you :)
When you have something like this:
$("#table").empty()
.html("... new content of the table ... ");
then the following happens:
.empty() removes content and marks rendering tree / layout as invalid.
.html() adds new content and marks rendering tree / layout as invalid.
mark as invalid among other things calls InvalidateRect() (on Windows) that causes the window to receive WM_PAINT event at some point in future.
By handling WM_PAINT the browser will calculate layout and render all the result.
Therefore multiple change requests will be collapsed into single window painting operation.
Context :
I'm working on a pretty simple THREE.JS project, and it is, I believe, optimized in a pretty good way.
I'm using a WebGLRenderer to display lot's of Bode plot extracted from an audio signal every 50ms. This is pretty cool, but obviously, the more Bode I display, the more laggy it is. In addition, Bodes are moving at constant speed, letting new ones some space to be displayed.
I'm now at a point where I implemented every "basic" optimization I found on Internet, and I managed to get a 30 fps constantly at about 10.000.000 lines displayed, with such a bad computer (nVidia GT 210 and Core i3 2100...).
Note also i'm not using any lights,reflections... Only basic lines =)
As it is a working project, i'm not allowed to show some screenshots/code, sorry ...
Current implementation :
I'm using an array to store all my Bodes, which are each displayed via a THREE.Line.
FYI, actually 2000 THREE.Line are used.
When a Bode has been displayed and moved for 40s, it is then deleted and the THREE.Line is re-used with another one. Note that to move these, I'm modifying THREE.Line.position property.
Note also that I already disabled my scene and object matrix autoUpdate, as I'm doing it manually. (Thx for pointing that Volune).
My Question :
Do the THREE.Line.position modification induces some heavy
calculations the renderer has already done ? Or is three.js aware that my object did not change and
avoid these ?
In other words, I'd like to know if rendering/updating the same object which was just translated is heavier in the rendering process than just leaving it alone, without updating his matrix etc...
Is there any sort of low-level optimization, either in ThreeJS about rendering the same objects many times ? Is this optimization cancelled when I move my object ?
If so, I've in mind an other way to do this : using only two big Mesh, which are folowing each other, but this induces merging/deleting parts of their geometries each frames... Might it be better ?
Thanks in advance.
I found in the sources (here and here) that the meshes matrices are updated each frame no matter the position changed or not.
This means that the position modification does not induce heavy calculation itself. This also means that a lot of matrices are updated and a lot of uniforms are sent to the GC each frame.
I would suggest trying your idea with one or two big meshes. This should reduce javascript computations internal to THREE.js, and the only big communications with the GC will be relative to the big buffers.
Also note that there exists a WebGL function bufferSubData (MSDN documentation) to update parts of a buffer, but it seems not yet usable in THREE.js
I will describe my problem using the attached image :
The green block is the starting position of my game entity. Next I'd like to move it to the position marked by the orange square. But at the same time, I assume that levitation is not possible or/& this block is a wall. In either case going there is not possible. So I need to figure out a way of finding the first available place (as close to the orange square as possible) for my entity to move (in this case it would be either the top of the grey column or point two rows beneath the orange square).
I have a 2d array describing the grid, where 1 is a wall and 0 is empty space.
data = [
[1,1,1,1,...],
[1,0,0,0,0,...],
[1,0,0,...],
...
]
I was thinking about solution in this way (where for example I can check at 1. if beneath my cell is floor and end the algo, or continue if not to cell 2.) but I can't think of a way of doing this efficiently (and easily).
Does anyone has any ideas how to tackle this ? I'm not really sure what algo should I ask google for :)
You are looking for Q-learning algorithms. This is a form of reinforcement learning. Here's one http://en.wikipedia.org/wiki/SARSA
Basically you run the simulation between source and destination multiple times and each time it gets close and closer to discovering the goal.
I think you can use Cellular Automata for your case, if it is worth the trouble. It is not AI per se, easy to implement and you can replace A* as well as the final position finding problem using one logic.
Consider the eight neighbourhood cells around the game entity. Each cell can be free or blocked (0 or 1). There will be 2^8 combinations of the neighbourhood, but you may or may not have to use that many rules for the CA.
Try looking into this: http://www.cs.sun.ac.za/rw711/2012term1/documents/CABehringPathPlanning.pdf
they implemented CA for path planning in robotics, you can tweak it to suit your need.
The advantage is, with proper rule set, your CA will terminate only when the game entity has reached the appropriate position around the goal (closest to the goal and not levitating).
You can also implement multiple rule sets on the system, thereby making it more robust.
I want to create some randomly flying objects in a Unity 3D game. You can imagine them like fireflies. Now there're some tasks to do with them, include:
They usually fly randomly (of course).
They can fly away or fly back in some conditions.
I have to write some Javascript to do these things, but I don't know how to do. Can you help me? Thank you very much!
EDIT: I think I'll need these functions:
function Fly()
{
//control the gameObject to fly randomly
}
function FlyAway()
{
}
function FlyBack()
{
}
I would suggest that you look at the canvas tag, but then it will not work on IE as I don't know if 3D effects will work on excanvas well.
This gives you a drawable surface to do your graphics.
You will probably need to write your own primitive functions for the graphics, but it is very doable.
EDIT: You will need to use object oriented javascript for each of your fireflies, which will help you to move each of them each frame.
If you show your attempt at drawing graphics you can get more help.
As much as I hate condoning the use of Flash, this really sounds like a Flash job.
However, if you insist on using JavaScript, I'd thumb through some Chrome Experiments for 3D examples (w/canvas): http://www.chromeexperiments.com/
I've done an abstraction library that may help here:
DP_PanelManager
The library makes moving objects pretty simple - at the bottom of the page there's an example called "Useless Animation" - it's basically a checkerboard where each square randomly moves, changes size and changes opacity.
Something like that with fewer panels and a little math to do smoother travel (something like this should be easy enough to modify) should get you close.
The component also has simplified functions for collision detection and distance between panels (with bearing - the function will tell you how far apart two panels are AND in which direction they lay).
Hopes this gives you a headstart.
My approach would be
randomly create a x/y equation (may be from a given set, if you don't know how to 100% randomize this).
Decide, randomly if you go by the x or by the y.
decide the number of steps you take on the axis you chose in step 2.
move your element according to the x/y you get from the equation in step 1.
When you finished to move all the steps (number of steps is given in step 3), go back to step 1. In a loop.
I'm building an application on top of canvas, it consists of a simple DOM that gets redrawn on every mouse move (yes, it is necessary), for performance issues not every part part gets redrawn only what is needed.
The app is working well but I'd like to add the zoom feature, the way I see it, it can be done in three different ways:
1 - Every DOM element gets recalculated (position and size) every time a user zooms in or out - it might have issues with precision and its not a very good abstraction
2 - The canvas has a resolution property (i.e. when the user zooms out resolution might change from 1 to .75) - there will be a need to make the calculations on every redraw
3 - Use the built in translate() and scale() methods - possibly the most elegant and fastest solution, however it is not intuitive at all, it might be difficult to understand how it is being done latter on by me or someone else (these methods work on the full canvas, first you would translate and scale on the canvas and afterwards everything you draw gets 'magicly' translated and scaled)
Which one is best or are there other possibilities I'm not thinking of?
I would use the builtin translate()/scale() methods. If you're worried about the performance and quality of any of these methods, you should try to do it in a way that you can swap it out for another of the options to compare, if the results end up giving you any concern.