@mikera: Saw your twitter reply. Gonna take a look at clisk.
@mikera: Would love to chat about this with you. Also interested in how to improve mesh performance. You've worked a lot on matrices and such. I want to really push the limits on mesh subdivision modeling and could really use your expertise.
Sure.... a lot of performance stuff depends on representation though
The reason that core.matrix+vectorz-clj is 10-20x faster than core.matrix+clojure vectors is by using unboxed primitives with Java arrays rather than the much more heavyweight approach of boxed numbers in persistent vectors
Upshot is: you'll probably need to look at alternative representations if you really want max performance
Right. And I'd rather not reinvent the wheel there as I don't really have the experience or expertise to do so.
Have you looked at how the gmesh is represented in http://thi.ng?
Pretty simple use of clojure sets and vectors and a Vec3 type.
Am curious to know if something similar could be constructed using core.matrix+vectorz-clj?
@mikera: I'm adding clisk to my cad code so I can play with it more based on your example. Thank you for making it so easy. :simple_smile:
I guess what I'm really asking is can you recommend an alternative representation for polygon meshes that would support the type of manipulations I'm doing?
Well - I'd probably take a look at using something like a dense Nx3 matrix to represent a large set of points. Would be backed by a single Java array, so very fast for memory access, cache line efficiency etc.
If you want to translate / transform points in bulk that is probably going to be the most efficient representation
Yeah, the catmull-clark smoothing function is a good example as it creates new vertices/faces/edges and "moves" previous ones.
I also want to do more generative creation of meshes way beyond the simple stuff that I've been doing with platonic solids as seeds.
I want to make use of the L-system and cellular automata code I worked on prior to this.
Makes sense. Basically you want arbitrary transformations on point clouds etc.?
And the ability to turn these into solids etc?
And creation.
Yup makes sense
Yes, I like the idea that they can be 3d printed in real life - so the mesh needs to be watertight, etc.
But I also want to create immersive worlds of these things for VR.
You'll need to do quite a bit of index tracking too then
Since a lot of vertices will be shared
Yes.
I guess some of this depends on how much you are willing to put up with mutability
If you look at the gmesh in http://thi.ng it uses a "winged edge data structure" like the Wings3D modeling software. But that's just an overly fancy way of saying that it has some indexes to keep track of its data. There are faces, vertices and edges and everything else is an index.
Yup that is a good way of doing things
It also mirrors how a lot of the operations will actually go to the GPU
I just used (op/colorize-clisk clisk/vnoise)
on the latest shape I was playing around with. Cool. Got a new toy to play with. Thanks! :simple_smile:
Cool, enjoy! If you want interesting textures check out tweegeemee on twitter
Nearly all of these work as 3D textures
Cursive can't resolve your namespace trickery, sadly. 😞
The only issue I see it that you will need to subdivide a lot if you want the finer details of the textures to show, since we are still only doing per-face colouring
Haha
Yes that is a bit of an evil hack....
Yeah, I follow that tweegeemee bot - cool stuff.
I plan to add per-vertex coloring at some point. Won't be hard to do - just have so many things on my todo list.
And I'm still surprised how much I can achieve with just simple coloring of the face.
So I'm still playing around with lowpoly and per-face coloring as interesting limitations.
@mikera: What is your interest in all of this? Where are you trying to go with your work? And are you interested in any collaboration?
It's more of a fun sideline for me (my main work is around data science / machine learning). happy to collaborate though where I have time.
I also have an interest in game programming, so I'm interested in tools that may help this
What I like about this is that its just a bunch of polygons - they can be used for 2d/3d rendering, printing, VR, games, etc.
So I have an interest in all of that.
What I want to do is create the building blocks that make it easy to create/manipulate/distort polygon meshes in an artistic/inventive way for use in a wide variety of applications.
So if I wanted a high-performance "dense Nx3 matrix" as you recommended, where would be the best place to start? Is there anything similar that you could point me to?
Well the raw data structures are already there in vectorz-clj
something like
(use 'clojure.core.matrix)
(def points (new-array :vectorz [100 3]))
Then you can do something like
(defn translate! [pts dx] (add! pts dx))
And other similar bulk operations for scaling etc.
For subdivision etc. you'd need to track indices and "join" extra points onto the array as needed
In http://thi.ng the main function is add-face
which updates all the indexes as each face is added.
Everything is immutable so any mesh op creates a new mesh.
Immutable is nice.... I think that's definitely the best way to go for the overall API
A face is a vector of points in counter-clockwise order.
You probably want mutability for some of the internal calculation however, that would be my guess
If performance is an important concern, that is :simple_smile:
That's what I haven't really done with Clojure.
I've only been working with clojure for 7 months now.
And haven't done any Java - mostly Python.
Some js, and lots of other languages before Python, but mostly OO stuff.
I will look at vectorz-clj and do some experimenting.
Mutability isn't very idiomatic in Clojure for sure
But it is sometimes justified if you really need the best performance
in core.matrix the API prefers immutable operation like (add a b)
But there are mutable vesions for people who need them, like (add! a b) which mutates a
Sweet. I will definitely check it out.
Gonna be away for a while soon but will look at this later today or tomorrow.