This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-11-30
Channels
- # admin-announcements (13)
- # announcements (2)
- # avi (1)
- # aws (10)
- # beginners (427)
- # boot (3)
- # cider (4)
- # clara (26)
- # cljs-dev (21)
- # cljsrn (24)
- # clojure (205)
- # clojure-dev (32)
- # clojure-india (26)
- # clojure-japan (1)
- # clojure-russia (256)
- # clojurescript (41)
- # clojurex (1)
- # cursive (38)
- # datavis (99)
- # datomic (15)
- # emacs (19)
- # events (2)
- # funcool (5)
- # immutant (45)
- # ldnclj (3)
- # om (60)
- # omnext (4)
- # onyx (383)
- # overtone (7)
- # parinfer (1)
- # re-frame (3)
- # reagent (7)
- # ring (1)
- # testing (5)
Just had to post that intermediate image before switching back to cell simulations, the bunny is just the seed mesh to be deformed. If you squint you can see tiny extrusions along the path of the swarm, but need to do some tweaking to improve the mesh-mesh collision code.
@kephale: How are you handling meshes in brevis? Do you have a lot of Java code for that? Have you looked at how http://thi.ng geom handles meshes? Just curious how they compare. I'm having to extend the http://thi.ng mesh quite a bit to do what I want.
Meshes aren’t super clean, but that is getting refactored a bit with some upcoming work from the image stuff. Yes, it is heavy on Java, but what I’ve been doing for that is actually subclassing Clojure maps, so you still get all those perks. I haven’t done that for meshes yet, since the only functionality they have really needed was load, render, and collide.
I’ve skimmed the gmesh code a bit from http://thi.ng, but i havent taken the full serious pass yet
i cobbled together a prototype for outputting a brevis scene to http://thi.ng luxor
i guess i’m most likely to add conversions to/from http://thi.ng meshes, and maybe try to match function names where that can still be done
I'm adding these operators that take a mesh and create a new mesh using information about vertices, edges and faces from the original mesh. And some of the operations are funky like replacing a vertex with an n-gon face. So I'm having to build additional data structures and maps so that I can do these manipulations. Like this:
(defn vertex-edges
"Returns a vector of edges for a vertex."
[mesh vertex]
(let [dataset ((:vertices mesh) vertex)
xf (map (fn [datamap] [(:next datamap) (:prev datamap)]))
np-map (into {} xf dataset)
start (first (sort (keys np-map)))
verts (reduce (fn [acc _]
(conj acc (np-map (last acc))))
[start] (range (dec (count np-map))))
edges (map (fn [e-vert] [vertex e-vert]) verts)]
edges))
Because the new face needs to be in the right vertex order so that the normal points outward maintaining the integrity of the mesh.
So I'm having to really dig into the mesh code to see what kind of helper functions already exist.
And when they don't I have to figure out how to get what I need out of how the mesh info is stored internally.
So I'm just taking a stab at all this and at some point I'll go back and clean it all up.
The lack of documentation, docstrings, variable names that I understand, etc. is making it a challenge.
just thinking through a way to maximize the ability to reuse your code in brevis, where they might not quite be pure maps
Plus the use of protocols defined in separate namespaces and such means that a lot of times Cursive F4 (to move to the source definition) puts me on the protocol definition, not the implementation, which tells me nothing worthwhile.
I have a couple of meshes (foo and bar) that I keep around to inspect in the REPL, which helps a lot.
i.e. (:vertices mesh) ends up being equivalent to a (.getVertices mesh) call, which I believe would be sliiightly faster
mmm, brevis meshes are already java classes, which is the only reason i’d do something that obscure
mmm brevis was originally pure clojure, using penumbra to get graphics, but (and if it turns out to not be true i’d be all the happier) moving all rendering to java gave a significant performance boost, which made it easier to move meshes to java
honestly there are some discussions about moving the rendering to native code even, with clojure on top
and just to add, the hope is to not force java on anyone (its an awful thing to do to a person), so using brevis only involves clojure code
yeah, there is a student helping out who is poking around at the webgl side of things
You're probably aware of this, but just in case: Three.js (which is what MathBox is built on) provides a pretty cool higher-level abstraction over webgl.
it was penumbra, then it got migrated to pure LWJGL, i’m working with some J3D/JOGL people, and will probably move it over to that in december
I'm essentially not either, since I'm working with a further abstraction over that abstraction 😉
http://thi.ng is certainly providing webgl as well, which keeps me on the fence about what to do next
but the difference in ease between using http://thi.ng, relative to actually extending it, is prohibitive at the moment
Making steady progress on open-sourcing cljs-mathbox, by the way. Currently struggling a bit with getting it working properly with {:optimizations :advanced} & getting the externs file right.
This seems to have stalled but for a while Kovas was working on Gamma https://github.com/kovasb/gamma
I'm on vacation, so I'm only putting in about half-time on it, but I'm getting there 😉
I have done nothing with webgl and http://thi.ng so not sure what that is like.
Mathbox looks so cool and if we could do that kind of stuff in clojure that would be awesome.
and fwiw, a lot of my image work stays really close to java, so i’m probably more open to tossing in java than i should be
yeah, my first plan for @eggsyntax and @georgek ’s mathbox cljs interface is to try hooking it up to a brevis world running on a cluster for visualizing ecological dynamics
I'm totally agnostic on the rendering side of things. I just really needed a mesh construct that I could manipulate and keep valid.
mmm, i’ve been thinking that the smart thing to do would be to setup http://thi.ng meshes to behave like first-class physical objects in brevis
allowing all existing http://thi.ng mesh code to work as usual, but then you can toss it into a simulation where the mesh can be deformed by other objects, and other sorts of physical simulation
I think Karsten has a little bit of physics code somewhere in http://thi.ng. Wonder if that would be useful.
so translating existing vertices along some vector in response to a collision, for example?
then the other stuff that i’m currently doing in c++ involves actually simulating membrane tensions across the mesh
the main thing under consideration is making http://thi.ng meshes interchangable with brevis meshes within a brevis simulation
Yeah, that's a fairly different set of issues than my work, where I'm adding/removing vertices/faces according to various rules that come out of nowhere, rather than any laws of physics.
it would be amusing to be able to say you’ve rolled them to test whether they are biased ; P
And a mesh is really just a minimal data structure that keeps track of vertices, edges, and faces so that their normals are valid. Then its combined with a bunch of functions defined by protocols.
it would be quite fun to take these meshes you’ve been making, inscribe some numbers, and test for bias
hey @georgek @eggsyntax. just coming back online after holidays and thought i'd say hi!
glad to see #C0F0V8DT5 is going strong
@pleasetrythisathome: welcome! Yeah, things are off to a flying start
love the http://thi.ng stuff above
I spent a lot of time with toxic.libs when I was using processing a lot years back
have always been a big fan of Karsten's work
@pleasetrythisathome: Thanks! I'm having a lot of fun with it.
Here's a low poly thing with lots of color blending to make it more interesting https://pbs.twimg.com/media/CVCECZBUkAEq227.png:large