Tech Artist - What are you working on: FOREVER Edition!

Eric Chadwick

I look forward to animated GIFs of the growth!

Klunk

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 !

poopipe

@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.

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  

Klunk

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
 

malcolm

Wow, the tree stuff is looking great. I found using speedTree pretty challenging, hopefully these solutions are easier.

Klunk

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

poopipe

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:

1. not having gaps where branches should meet,
2. multiple target points on the trunk (the trunk doesn't contribute at all, they're just converging on a point)
3. direction biasing
4. 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)

Klunk

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 

poopipe

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

Klunk

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 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

poopipe

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. 

Klunk

uniform distribution across a non-planar quad.....


most of versions online suggested splitting it across the 2 tri's but in the above case would produce a hard edge   first generate a biased unit quad distribution the bias is computed from the ratio of the top and bottom edge you then do four polynomial interpolations to fit the the polygon surface. I'll post it up once it's cleaned up   bugs are ironed out
which enables me to loft a "flat" and uniform random points around a spline....

It was one of those... "lofting a volumetric cylinder of points was easy peasy how tough would a planarish loft be"

poopipe

did you just invent some sort of irregular tessellation thingy? 

triangulate it, I want to see what happens

Klunk

unfortunately I disabled the convert to mesh code now I can't find it any way heres the planar (z=0.0) unit point  to quad code....

//********************************************************************************************
// where quad is defined as....

//	c----d
//	|    |
//	|    |
//	|    |
//	b----a

inline void UnitPoint2Quad(const Point3& unit, const Point3& a, const Point3& b, const Point3& c, const Point3& d, Point3& p)
{
	float u1mx = 1.0f - unit.x;
	float u1my = 1.0f - unit.y;

// some inlining 
// p = a * (1 - u.x) * u.y

	p.x = a.x * u1mx * unit.y;
	p.y = a.y * u1mx * unit.y;
	p.z = a.z * u1mx * unit.y;

// p += b * (1 - u.x) * (1 - u.y)

	p.x += b.x * u1mx * u1my;
	p.y += b.y * u1mx * u1my;
	p.z += b.z * u1mx * u1my;

// p += c * u.x * (1 - u.y)

	p.x += c.x * unit.x * u1my;
	p.y += c.y * unit.x * u1my;
	p.z += c.z * unit.x * u1my;

// p += d * u.x * u.y

	p.x += d.x * unit.x * unit.y;
	p.y += d.y * unit.x * unit.y;
	p.z += d.z * unit.x * unit.y;
}

it's max and c but should be pretty easy to understand. If any one's interested I can post the random biased code snippet too

Muzzoid

I've been modifying the renderer of the flax engine.

Not totally finished, but i rewrote how bloom in the engine works.

Klunk

some tree auto LOD

it's a rather basic "keep mod n" and junctions at the moment... planning to add weighting based on most deviation.

Klunk

had a late night epiphany... resulting in a new way to generate point normals..... 

using a top angle and a bottom angle (with adjustable distance between)...
need to change the gizmo colour when it passed 90 to show it's "inverted"

Klunk

had a sleepless night and wondered whether, after this thread, I could convert the edge rendering tool to generate the normal directly. Turns out I can


obviously the UI will need some tweaking and there are some seam issues that could be improved and I haven't tried anything more complicated than the cube All I can say is tangent space normal maps what a ball ache long live object space   !
will post it up when it's in and acceptable state 
seems i've got work to do....

thought I could get away without actually having to compute the tangents (you don't if your uv are correctly aligned ) Oh well time to roll out the Lengyels

pi3c3

Hah! That's really useful. Honestly I don't know why we never thought about this. 

Lengyels?

Klunk

IIRC he wrote one of the original routines for generating tangent space vectors
seems like he knows a thing or two


almost a chamfer

poopipe

i genuinely sat down with the intention of having another crack at the trees 
but...
i wrote a shit game engine that runs in the terminal and a shit game to run on it instead 
(who knew there was a bong glyph ?)

poopipe

Klunk said:

I'm pretty confident you can't make the seam perfect (at least in terms of generating a texture) cos its a sampling/filtering artefact.
 

poopipe

apparently it works on windows with no changes at all which is nice. 
(there's no bong cos I don't have the right fonts installed)



I wasn't seeing that flickering on ghostty  - I think I need to add double-buffering 

i call this game "shit flappy bird"
I'm trying really hard to not get sidetracked and render a spinning cube btw

Klunk

mini rant something I'm working on put me on collision course with Collada ! dear god it's effing awful.... who ever created it didn't know anything about 3d models and didn't know anything about xml absolute dogs dinner of a format.  Think they looked @ obj and though yeah we can do worse than that .
Interleaved face indexing who the fuck does that (oh yeah obj) !!!! And if you have a polygon word of advice the first thing you'll want to know is how many sides it's got! And sometimes you don't want to lose your triangulation or sometimes you want triangles with their edge visibility nope the only option is all tris with all edges visible or polygons and on the fly retriangulation hoping that it comes out the way the creator intended.

poopipe

Is it not structured roughly like fbx? I.e unintuitive but actually fine once you've dragged your balls across all the broken glass. 
I've only ever mucked around with injecting material data into collada and honestly can't remember 

Klunk

decided to bin it it's so appalling

poopipe

a quick scan over the spec suggests its similar to fbx so yeah - ballls + broken glass. plus  you have to argue with someone's idea of xml 

can't imagine why the format hasn't caught on ...