physics with d3?

[marc fawzi]

anyone thought of building a D3 layout to support dragging of objects in a physical way?

just curious... for now, I'm using a physics engine but would be nice to consolidate with D3

[Sujay Vennam]

Do you mean a force layout with momentum so that you can "fling" objects? Do you have a specific example of the effect you are trying to achieve?

Re: Momentum: "giving things residual motion when you release them from a drag. This is simply about remembering the velocity of a thing when the user releases it, then applying that velocity to the object every frame and also reducing the velocity every frame by some amount. How you reduce velocity every frame is what you experiment with to get the feel right." (http://stackoverflow.com/a/196209)

Possibly relevant example: http://bl.ocks.org/ZJONSSON/1706523

-s

[Chris Viau]

Another one by Ziggy Jonsson http://zjonsson.github.io/electro/

--
You received this message because you are subscribed to the Google Groups "d3-js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to d3-js+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[marc fawzi]

Sujay

Yes, along the same lines. In fact, I was thinking about the force layout because of all the familiar examples out there... If you consider jQuery.pep.js (Kinetic Drag) then that's what I'm looking for and I suppose I can easily extend as d3.kineticDrag(element).settings({...}) to provide for kinetic drag in a D3 environment, but that's not exactly a "Box2D type "D3 physics layout" ... I never had the time to dig into how a "layout" is implemented in D3, conceptually speaking, but I'm still thinking about that .... If there is a Force layout, and a Pie layout then there should be a Box2D type layout, imo 

Chris

Those seem to follow the mouse' end position and implement collision response but not the type of physics simulation I'm looking for

The initial example that I'm currently handling with jQuery Pep is "kinetic drag"

Marc 

[Ziggy Jonsson]

The d3.force implementation very cleverly allows you to define .on("tick") where you can implement tick-by-tick physical restrictions.

One of the most simplest ones is a collision detection (as applied in the sample shared by Chris above) and original http://bl.ocks.org/mbostock/3231298

Collision can then be extended to newtonian dynamics:  http://bl.ocks.org/zjonsson/1706849   http://bl.ocks.org/zjonsson/1706523

The key to a fast calculation is the d3.quadtree which helps you decide which "neighbors" to process for any given node

It would be interesting to experiment with drag, but currently dragging freezes the velocity of the node being selected (to keep it still)

[Danny Korenblum]

a couple of examples of this for circles and polygons is contained in my new open source Gameprez Developer Kit project at

https://github.com/gameprez/gpdk

which uses perfectly elastic collisions between non-root objects and a velocity Verlet integration algorithm for simulating the physical motions of the objects. In these examples, each collision with the root element (under user control) adds a velocity vector to the non-root object pointing away from the root element along the direction joining the centers of the two colliding objects.

This is only a simple example for debugging purposes but it would be pretty easy to extend the default forces to include gravity/spring/damping forces etc. in order to constrain the objects to stay on the screen.

Although there's no d3.geom.quadtree support yet I made some progress towards this goal last night (e.g. see issue #8 and branch 8_optimized_collision_detection in the repository --- this code is not working yet but I hope to fix it soon).

The quadtree interface has been hard to figure out from the documentation I've seen so far, but I think I understand how the algorithm works so hopefully it won't take me too much longer to fix this.

It might also be possible to integrate these elements with the force layout directly although I haven't explored this option yet myself, I am interested in this approach also - e.g. see issue #6 in the github repository.

This is my first open source project so any input is appreciated as well :)

Incidentally, there's also a test game called DRONEWAR included in the repository which is also available on www.gameprez.com with a $50 weekly cash prize for high scores!

Hope this helps,

Danny
GAMEPREZ Founder

[Marc Fawzi]

Use Bitcoins as rewards?

Will dig into your example ... Thanks!

Are you saying ur working toward a d3.layout.box2d or an isolated implementation for your own game dev needs?

Ziggy

I got that about the motion after collision but the force layout has a special implementation of newtonian dynamics so I can understand the limitation with respect to drag (because its needed for the functioning of the layout)

Sent from my iPhone

--

[dannyko...@gmail.com]

Thanks, see the circletest and polygontest "games" for the simple physics examples.

Currently I'm only working on this for our own HTML5 game development needs but open to tighter d3 integration e.g. Via d3 layouts as well. I have only dug into d3 far enough to achieve what you see here and my understanding of d3 layouts is still too incomplete so that's the best answer I can give you right now. That's also why I labeled this issue as a "question" in the "issues" section of the repository.

I dig the bitcoins suggestion! Will think about this :)

Appreciate it,

Danny

---

From: Marc Fawzi <marc....@gmail.com>

Sender: d3...@googlegroups.com

Date: Tue, 30 Apr 2013 10:56:11 -0700

To: d3...@googlegroups.com<d3...@googlegroups.com>

ReplyTo: d3...@googlegroups.com

Cc: d3...@googlegroups.com<d3...@googlegroups.com>

Subject: Re: physics with d3?

--
You received this message because you are subscribed to a topic in the Google Groups "d3-js" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/d3-js/K6G6m97d7r4/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to d3-js+un...@googlegroups.com.

[Danny Korenblum]

just pushed some bug fixes to the repository on github for the circletest and polygontest games caused by merging updates from other branches that i didn't test for. looks like i need to add an issue to create unit tests!

sorry about that, all code seems to be working now.

--
You received this message because you are subscribed to a topic in the Google Groups "d3-js" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/d3-js/K6G6m97d7r4/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to d3-js+un...@googlegroups.com.

[Danny Korenblum]

the dev branch on the gpdk now uses a single "global" quadtree accessible to all game elements, instead of each element doing a simple loop over its own neighbor list, for faster and more memory efficient collision detection, hopefully making it much more scalable to larger number of elements.

On Tue, Apr 30, 2013 at 10:56 AM, Marc Fawzi <marc....@gmail.com> wrote:

--
You received this message because you are subscribed to a topic in the Google Groups "d3-js" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/d3-js/K6G6m97d7r4/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to d3-js+un...@googlegroups.com.

[Danny Korenblum]

forgot to mention that velocity exchange for polygon-polygon collisions is handled along a normal vector for the polygon having the intersecting edge with a unit normal vector with the larger dot product against the line joining them for simplicity and to define a "normal" direction for a vertex-edge collision

[Danny Korenblum]

quick update - refactored the physics engine to move the list of elements bound to the physics engine into the Collision module, and created an Integration module to allow a global timer updating all elements per quadtree update, providing better control of computational resources compared to the previous "quick and dirty" solution of running each element on its own timer (using the d3 timer queue).

profiling on chrome shows about a factor of 10x less processing time for collision detections using the dronewar test game, with >40% idle time, indicating better optimization and scalability and therefore more extra room for more complicated graphics / effects and other features.

renamed the simulation element methods to be more self explanatory. any suggestions for more challenging test games are welcome! right now i'm leaning towards a star controll II - style "melee" game, requiring a "auto camera zoom" feature to keep game elements "on screen" as their pairwise distance fluctuates....

https://github.com/gameprez/gpdk

you can play the latest version of the "dronewar" test game on the www.gameprez.com beta test site, as well as compete for highscores to win a $50 cash prize as well!

of course the physics engine can be used separately from the game elements on other data structures as well. the new Integration module makes it easy to run multiple simulations in parallel by assigning each simulation's elements to a specific "tick" discrete timestep update function.

we're working on a tutorial for the kit as well.

To unsubscribe from this group and stop receiving emails from it, send an email to d3-js+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to a topic in the Google Groups "d3-js" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/d3-js/K6G6m97d7r4/unsubscribe?hl=en.

To unsubscribe from this group and all its topics, send an email to d3-js+unsubscribe@googlegroups.com.

[marc fawzi]

Hey Danny

It sounds like you've been doing a lot of work to enable D3 as a light gaming platform. If that's a correct assessment, I'd think it's quite an achievement but many of us got into D3 because of the huge number of tantalizing examples Mike had put out, and so in order for anything to get traction I think you need to supply a page with a number of example (the more the better) of high quality with commented code, and I think if those examples perform well then many people will be all over it. The key is examples, not just framework code/capability because that is theoretical to those who can't commit the time to dig into it, which is probably most people here :)

Keep it going and let us know when you have a decent number of examples

Cheers

Marc

To unsubscribe from this group and stop receiving emails from it, send an email to d3-js+un...@googlegroups.com.

[Danny Korenblum]

i agree, that's the plan we're following as well! thanks for the input, will wait on updating this list again until we have more examples ready. my main purpose was to let you know that the code had changed significantly so if you had looked at it earlier and seen something confusing, it might make more sense now.

any suggestions for examples you may have are welcome as well!

To unsubscribe from this group and all its topics, send an email to d3-js+un...@googlegroups.com.

[marc fawzi]

nope, we just like to look at candy, for the most part!

;)

[Danny Korenblum]

Hey Marc,

Here's the current version of a physics example I've been working on to demonstrate how the GPDK can be used to add a "physics layer" to visualizations:

http://entsphere.com/d3/rainflow/

this example shows a matrix map of the earth's surface with colors indicating elevation.

This global elevation dataset is included with Matlab and is available by running "Load topo" i think. Their doc page references National Geophysical Data Center, NOAA US Department of Commerce under data announcement 88-MGG-02.

The additional physics layer provided by the GPDK allows rainflow on the surface of the Earth to be simulated using spheres rolling downhill. I parametrized the forcefield using a numerical gradient of the elevation data, since force can be defined as the gradient of a scalar potential energy function.

This scalar potential is provided by the 180-by-360 element elevation matrix using bilinear interpolation to support floating point precision. There is also a friction force in addition to the gravitational force due to the potential energy of the Earth's surface.

Hitting a key or clicking a mouse button will drop a single circle onto the surface, holding down a key will create a "flow" of "water drops". Drops disappear after 10 seconds.

This example shows how physics layers generated by the GPDK can provide additional interactivity for visualizations not limited to video games, potentially improving learning experience while engaging users and researchers alike to gain additional insights from their data via physics-based interactions.

In the future I'd like to add additional features for this example such as zooming, axis labels, colorbar, and onscreen instructions for users.

Any input is appreciated!

Thanks,

Danny

GAMEPREZ Founder

[Danny Korenblum]

Forgot to mention, this example is also now part of the gameprez/gpdk github repo as well as part of the "test" directory:

https://github.com/gameprez/gpdk/tree/master/test/rainflow

[marc fawzi]

at first glance the behavior of rain drops seems not be distinctly different than several similar examples I've seen that use the D3's force layout.... 

[Danny Korenblum]

thanks for checking it out! i haven't seen anything similar with d3 force layout examples i've looked at yet.

one thing i noticed is that the perfectly elastic collisions between circles seems to prevent them from "packing" statically into the trenches/basins and coming to a complete standstill, as one would expect for say marbles filling a bowl. i'm going to try using inelastic collisions to see if that helps!

[Danny Korenblum]

To reduce the lack of settling problem I increased the coefficient of friction and added 30% damping for collisions between Drops i.e. partially inelastic instead of perfecty elastic collisions; the link and repo have been updated so you can hit "refresh" to load the current version.

I can see how this example might be doable with the d3.force layout since I'm not using polygon-polygon collisions here, but this would require the user to provide a gradient vector function which is included in the gpdk physics engine. 

This was the simplest example of something new I could think of but I'll keep working on more examples to illustrate some of the more advanced capabilities including polygon-polygon collisions and more complex forcefields.

On Sun, May 26, 2013 at 11:45 AM, marc fawzi <marc....@gmail.com> wrote: