I used the same paper for the basis of my tree generator.... though they missed a trick in the original paper..... the point cloud should also have an associated direction vector for each cloud point it gives you far more control over the tree,
also the tree is all about the point cloud and it's distribution !
@Eric Chadwick - its done in literally the worst way possible at the moment so it's too slow to grow realtime after a depressingly small number of iterations. I know how to fix it but since it's just reference i'm saving the optimisation for the proper version.
@Klunk yep, i spotted that issue pretty quickly they do allude to it in the blurb but dont really go into what sort of direction makes most sense. i've got them tending upwards for the moment which seems to largely work.
the whole space colonisation thang works very well as a "fractal" system.... twigs->fronds->tree.....as the second trick missed in the paper is the tree/branch/twig its self should work as a point/vector generator.... but that plant modelling paper is a new one to me
I had quite a lot of experience with speedtree (and had some really good results but boy does it throw out a lot of crap....) though space colonization method seems to produce a more "natural" result and less crap the process is not particularly intuitive
rather embarassingly that second algorithm completely stumped me for a long time. then i grew a brain and made it happen
There's plenty of refinement left to do including:
not having gaps where branches should meet,
multiple target points on the trunk (the trunk doesn't contribute at all, they're just converging on a point)
direction biasing
biasing the distribution of points - it makes sense for there to be more towards the outside of the volume (anyone know the right search terms for that sort of thing - the internet is not playing ball)
but.. even the dumb dumb implementation is really fast - as in it's instant with no acceleration structures at all, this is literally just nested loops it gets faster as it goes (because you're effectively removing information) you need far less points to start with
also gif (of me advancing the growth steps manually)
biasing the distribution of points - it makes sense for there to be more towards the outside of the volume (anyone know the right search terms for that sort of thing - the internet is not playing ball)
I implemented "density by map" option for my emitters, I also implement several 3d texture maps... eg 3d volume depth map (also has a helper object) etc. one of the strangest but welcome things I find with this algorithm is no matter how many branches and complicated the tree gets there is never any self intersection
i dont relish the thought of implementing anything like that from scratch - i'd probably have to read documentation and that makes my soul sad.
Given the need to support 'any' closed volume for a canopy I'm inevitably going to end up doing some sort of voxelisation which means it should be fairly straightforward to generate a distance field that I can use as a mask. I dont relish the thought of that either but it's maths(mild headache) rather than openGL docs(car battery clipped to your sensitive bits)
Intersection between branches is possible with the outside in approach I think - that might actually kill the idea. With the original I think it would be impossible
I like how fast outside-in is though so I will persevere for a bit
I maintain a kdtree of the tree node positions as it grows to speed up the find nearest.....then enumerate the kdtree to generate new nodes. In my case the biggest bottle neck is reorganizing the tree into a more suitable state for generating the mesh.
i dont relish the thought of implementing anything like that from scratch
the point generation became so critical to the tree creation process I haddecided thought it best to implement them as max pipeline objects (a rabbit hole to hell that was !! ) Though they do have other uses.... they make for great scatter type stuff and mesh instancing etc it all gets a bit nuts after a while and the face hugger it all gets a bit bonkers
I wanted a break from trees and because I am an idiot I decided to have a go at the overlapping model wave function collapse without reading anyone else's implementation (tbh - I got bored reading the descriptions of the algorithm so I didn't even bother with that)
The overlapping model is the one where you take a source image, slice it up into overlapping tiles and then generate a bigger image by select appropriate neighbours for a placed tile automatically - as opposed to the more common model where tile neighbours are defined ahead of time
This was certainly a mistake but it does appear to be mostly working. It doesn't reliably fill the image but I don't think it's supposed to - i really should read the words... (top image is result, other one is the debug I think filtering the tileset for duplicates will increase the likelyhood of it finishing but I'd rather play video games this afternoon.
Replies
also the tree is all about the point cloud and it's distribution !
@Klunk yep, i spotted that issue pretty quickly
they do allude to it in the blurb but dont really go into what sort of direction makes most sense. i've got them tending upwards for the moment which seems to largely work.
Next i'll try this one
https://www.researchgate.net/publication/266472675_Particle_Systems_for_Plant_Modeling
Which appears to be exactly what I was going to try and work out for myself
then i grew a brain and made it happen
There's plenty of refinement left to do including:
- not having gaps where branches should meet,
- multiple target points on the trunk (the trunk doesn't contribute at all, they're just converging on a point)
- direction biasing
- biasing the distribution of points - it makes sense for there to be more towards the outside of the volume (anyone know the right search terms for that sort of thing - the internet is not playing ball)
but..even the dumb dumb implementation is really fast - as in it's instant with no acceleration structures at all, this is literally just nested loops
it gets faster as it goes (because you're effectively removing information)
you need far less points to start with
also gif (of me advancing the growth steps manually)
I implemented "density by map" option for my emitters, I also implement several 3d texture maps... eg 3d volume depth map (also has a helper object) etc.
one of the strangest but welcome things I find with this algorithm is no matter how many branches and complicated the tree gets there is never any self intersection
Given the need to support 'any' closed volume for a canopy I'm inevitably going to end up doing some sort of voxelisation which means it should be fairly straightforward to generate a distance field that I can use as a mask.
I dont relish the thought of that either but it's maths(mild headache) rather than openGL docs(car battery clipped to your sensitive bits)
Intersection between branches is possible with the outside in approach I think - that might actually kill the idea. With the original I think it would be impossible
I like how fast outside-in is though so I will persevere for a bit
i dont relish the thought of implementing anything like that from scratch
the point generation became so critical to the tree creation process I had decided thought it best to implement them as max pipeline objects (a rabbit hole to hell that was !! )
Though they do have other uses.... they make for great scatter type stuff and mesh instancing etc
it all gets a bit nuts after a while
and the face hugger
it all gets a bit bonkers
The overlapping model is the one where you take a source image, slice it up into overlapping tiles and then generate a bigger image by select appropriate neighbours for a placed tile automatically - as opposed to the more common model where tile neighbours are defined ahead of time
This was certainly a mistake but it does appear to be mostly working.
It doesn't reliably fill the image but I don't think it's supposed to - i really should read the words... (top image is result, other one is the debug
I think filtering the tileset for duplicates will increase the likelyhood of it finishing but I'd rather play video games this afternoon.