oh cool, missed the 3d printer chat, i did a bit of 3d printing of robots during my phd (have a flashforge creator these days)
@meow: since you’re doing single objects I’m guessing you haven’t done any stress testing on geom? happen to have seen any? i tend to do coevolutionary simulations with multi-component/mesh bodies, which is why i stick to brevis for the simulations (and stl writing even), but have been working switching over to geom for high-quality renders
@kephale: What kind of stress testing?
I've looked at brevis a little bit but haven't actually used it.
large numbers of objects being rendered at a time
with dynamics
When I worked on my generative code I did some performance optimizations using criterium, and would have liked to have improved performance even more in order to sustain 60 fps for visualizing simulations.
Then I switched to focusing on creating files for 3d printing, so I haven't been too concerned about performance.
hmmm, i’ll have to poke at your repos, i could use some 3d l-systems, as i need some trees for my simulations (a version of brevis was used for simulating electron microscopy, which can be used for simulating photosynthesis)
in a lot of ways brevis is no where near as pretty as geom from an idiomatic standpoint, but it has been more optimized for simulation than anything else i’ve run into
Once I have the foundation in place I plan to apply the l-systems approach to the generation and manipulation of polyhedra and other complex shapes. So then performance will be an issue again.
oh i saw ion at one point…
ion ergo has the l-system code
although my focus was really on supporting all possible variations of l-systems, more than strictly performance
I wanted to make it very easy to create the rules
yeah, i see that, it looks quite pleasant to write the lsystems
also have examples here: https://github.com/decomplect/ion/tree/master/examples/ion/ergo
My cellular automata code is also optimized to a degree, but doesn't perform as well as a one-off optimized solution as again my focus was on making it easy to define the rules in order to take these things into new directions, rather than just making yet-another-brians-brain run really fast.
Although it does irk me that I haven't gotten as much performance out of these as I would like.
I haven't really gotten into multi-agent simulations, but I understand the concern about performance there.
@kephale I'm curious to see what you are rendering to stl files and how you are applying simulations to geometry.
@meow: it was initially tetrahedral-based l-systems in python 5/6 years ago, then hand-designed robot parts in solidworks and simulations of basic geometries that abstracted the components (i.e. not modeling screws/screw holes, etc). now the STLs are coming from multicellular simulations that are calibrated from microscopy data, and more often, meshes taken directly from the microscopy data itself
@kephale: very interesting stuff indeed :simple_smile:
do you have a geom+ion repo up?
I used python for quite a while - switched to clojure about 6 months ago
yeah, i was c++->(flirt with clojure)->python->clojure after lee spector convinced me and havent looked back
the initial flirt lost because it was in early clojure days when linking to processing was a huge mess and it was the only reasonable way to get graphics
but i’m seriously excited about a lsystems library, as i really would enjoy adding photosynthetic trees to simulations
i’d be curious how you map from the result of applying a l-system onto a mesh
I haven't yet applied any kind of generative processing to geometry.
When I was trying to decide where to go with my efforts I initially was going to do the turtle graphics thing but decided it had been done before.
So had so many 2d graphics approaches. And while I'm really interested in agents and other forms of simulations, I wanted something "visual" and "concrete" and was interested in 3d printing.
So I looked into it and found OpenSCAD and scad-clj and toyed with them.
And while they are great, I want to really push the limits so I decided to focus more on the polygon meshes.
So I started using http://thi.ng geom several days ago, but I also want to color the polygon faces for full-color printing and STL files can't do color so I had to read the specs on X3D so I could add that option. Just finished that a day or two ago.
Now I can work on adding mesh operators, such as those defined by Conway https://en.wikipedia.org/wiki/Conway_polyhedron_notation
Those will be part of the "grammar" for any l-system or automata.
Figuring out http://thi.ng in enough detail to know whether or not it will support where I want to go has been challenging, but I'd rather not have to write my own mesh library.
Right now all this CAD stuff is in this repo: https://github.com/pkobrien/cad
So one thing that I'm picturing is an l-system the generates a string of commands that are mapped to mesh operators that operate on a seed polygon, just like an l-system can be mapped to turtle graphics operations.
I'm also thinking about how polygons can be manipulated like cells in cellular automata, where the polygons attributes (like color, for example) can be determined by the state of neighboring polygons.
And all of this should be able to be creatively combined to form creatures, sculptures, tree-like structures, whatever. And printable in full color by 3D printers. Or rendered as part of a virtual reality scene.
@kephale: I'm spending a lot of time on creating a foundation that will support a wide range of possibilities with as few limits as possible.
@kephale: You should also look at Karsten's Morphogen system for an example of a generative approach to mesh ops.
yeah i’ve checked it out a bit, stuff like greg hornby's 3d printable lsystem robots and stuff came from my phd lab. i am definitely still digesting the geom-based packages at the moment. for cad based ops, as you note, morphogen does seem to have a good set of operators, and i’m hoping it can be the programmatic replacement to solidworks stuff
just currently somewhat caught in the middle of a few different systems that have been around longer than geom, some even being in c++ (though I have clojure wrappers and such)
but i’m dying to see more speed tests, because i need real time simulations to be able to convince people to switch to a full clojure stack
I never used solidworks, and haven't done any CAD stuff in ages, but it was actually Autocad circa 1985 or so that got me into computers.
nice!
CAD is datavis
:simple_smile:
the combination of needing to get real time simulations of meshes, brought me to @eggsyntax and @georgek ’s CLJS mathbox interface for doing 3d plotting
which seems like a decent enough way to get to meshes, and provide a web frontend to hide the clojure from folks who might be initially afraid
@meow: have you done much with the geom CLJS code?
What I don't want to have to do is any kind of mouse manipulating. I want to generate everything pragmatically. Hence my interest in http://thi.ng and generating X3D files without using any other tool, like Meshlab or a CAD system that can't be fully automated.
yeah, although there is the meshlab server interface, so that might work, but i get what you’re saying (and am certainly on-board with that approach)
ahh, yeah input devices are kind of necessary for my ends
on the other hand, and possibly of interest to you, most of my mesh stuff involves images->meshes
which i’ve been doing in clojure (given that images are a pretty practical way to do CAs)
do you mean have I done much with the cljs version of the http://thi.ng geom code? If so, no. I've only focused on the regular clj code so far.
I am interested in images->meshes
ah yes, thats what I mean, i was just wondering how usable it is from a CLJS standpoint, i mean it does have the viz package for plotting too
these are always 3D images these days, so there isn’t any 2D->3D projection type of thing going on
~8gb images are pretty efficient to process (as compared to C++ code), so it should be plausible to handle pretty decent CA spaces
I spent some time getting up to speed on cljs and the various reactive tools and was going to dive into om next but then when I got into the 3d printing I kind of gave up on the idea of trying to put a front-end onto any of the stuff I'm working on and just focus on using it myself to drive the output of files that can be uploaded to services like Shapeways. At least for now. And its kind of nice to not have the kinds of concerns that you are facing. :simple_smile:
mmm, i can survive without CLJS at the moment, but yeah the multi-agent + input interfaces are extra problems
i’m just kind of dancing around whether it is worth it to dive into geom for an immersion over the december holidays
it seems like a cure-all for any sort of visualization in clj/s
While I'm not using http://thi.ng with cljs, it does have full support for it. And the morphogen front-end is a cljs app using maybe reagent or one of the react-based libraries.
And Karsten definitely knows a thing or two about cljs, react, core.async, etc.
Have you looked at the app that uses morphogen?
no? i’ve only read through the repo at this point
It isn't going to answer your question about performance because the app basically lets someone pick a seed shape and then morph it using the various operators.
it might hint at performance by splitting the faces a ton though!
But it does show that cljs support is there.
Yeah, and there might be examples in the morphogen repo as well. Or you could hit up Karsten on twitter and see what he has to say.
I like his approach. A mesh is just a bunch of clojure data structures, like vectors and maps.
mmm yes, its about time for that
And everything uses protocols and defrecords.
So the operations are just functions going against data.
mmph, yes, i can appreciate that, i had issues with that in brevis when scaling up, but maybe the protocols/defrecords resolves that
it led to tainting it with tons of java
but @meow thanks much! lots of food for thought, but now I think i do need to get some into my belly
np
ttyl
I suspect you'll face the same issue you have with brevis. While defrecords provide some performance improvements, they aren't a magic solution. I had the same struggle with optimizing ergo.
But I'm far from an expert when it comes to optimizing clojure.