Don’t you need to realize them first?
Yeah, and I tried that. Didn’t do anything.
Though given that my knowledge of geo nodes is spotty at best, chances are good that I might not be doing something right.
That’s weird… Realizing instances on your file destroys the uv map…
Apparently, attributes are not preserved through realization? What good is instancing anything then? I don’t know if it’s a bug, or if it’s simply not implemented yet.
Yup, and there doesn’t seem to be a way to capture UV maps as an attribute yet either, so there’s no way to define or preserve it.
It’s infuriating. Geo nodes are good for so much, except for the one thing I most want from it.
Even if you could capture it, it would not work on realized instances. Instances don’t store any attributes.(except location, rotation, and scale.)
It seems, when you use the realize instances node, it only realizes the vertex positions.
Hold on. I might’ve found something promising. Click to 9:40.
If you can make it so that the node tree can expose the position of the realized geometry, you might be able to project the texture onto the generated objects.
We’ll, I’ve managed to get a texture on there, but I still can’t transfer the UVs, so the results are pretty sloppy.
I thought if I could capture some info from the source instance, and somehow apply that info to all the instances individually, I could use it as a base for a texture projection.
I managed to preserve the UV data after realise instance in EEVEE using the sculpt vertes color trick.
BillboardTree - 1.zip (1.6 MB)
Too bad this won’t be possible in the official release 
2 Likes
Looks like it’s already been nixed. I loaded it up, and all I get is a blank alphas. : \
I don’t get why this is such an issue. Why delete the UVs on realized instances? On top of that, why is it so difficult to capture the UV data? It’s all just vectors.
I’m starting to think that normal transferred billboard trees in Blender are my personal white whale.
The UVs are not actually deleted. They are just stored as a separate attribute. Blender currently doesn’t have the capability of classifying attributes as UVs, vertex groups, etc. In cycles this wouldn’t be a problem where you can use the “Attribute” node to access the UV data by name. Attribute rendering will probably be implemented for EEVEE soon (without the SVC trickery)
Have you enabled SVC in the experimental features?
2 Likes
Have now! It works! 
Quick, totally off the wall question here. When I expose transform vectors in the modifier tab, is there I way I can hide certain axes from being displayed?
For example, I have Rotate XYZ exposed to randomly rotate the individual leaf cards, but I only need one axis shown. Can I hide X and Y?
Okay, I think I’ve finally done something I’m kinda happy with.
Take everything that’s been stated above, ignoring anything to do with transferring normal shading, take some of Skuax’s rounded hemispheres, make them into little spheres without a top or bottom, then scatter those. You get a nice little stylized tree that looks clean, since the camera track prevents you from having to look at janky flat edges, gives the trees a better sense of fullness, and still catches the light at extreme angles.
I also added a new input entry on the modifier that spreads the leaves away from their starting position.
Dunno why I didn’t think of this before.
BillboardTree_Final.zip (1.6 MB)
9 Likes
Combine XYZ?
Maybe the random value should be set to vector. Right now all the leaves move towards the +XYZ direction
I use a Separate XYZ between the Random Value and Rotate Euler node, then changed it’s entry to a float value. Now, you just have one value for Z.
Now, Scale I want to keep as a min/max value, since I want them all to scale up and down evenly across axes. Now for Translate, I should use a similar setup as I did for Rotate, combining X and Y while excluding Z, then set the entry value to a single float.
edit: wow, that was easy. I love how much more intuitive fields are compared to the old attribute setup. It makes it so that even maff dum people like me can adjust things without spending hours futzing around with vaguely defined values.
BillboardTree_Final_Final.zip (862.4 KB)
1 Like
Yeah, that is a bit more intuitive. I’ve now switched it.
1 Like
Nice! 
So all you have to do is transfer the normal attribute, and assign it an output? I’m assuming that, by default, it transfers shading from the base mesh from the source geometry, and that if you wanted to use a 3rd source, you’d just bring in another mesh through Object Info, and attach it to the Target?
edit: I went in and duplicated your node setup on my tree, and all that achieved was giving me a blank tree. I’m obviously missing some big step here…
Good work, bear in mind that these card trees are not Cycles friendly, good for Eevee though.
I still haven’t managed to get the billboards to work by reconstructing them. As far as I can tell, there aren’t any real differences between his node tree, and mine. I’m probably going to stick to my workaround, since realizing the instances even on that single tree gives me a huge hit to viewport performance. Throwing a few dozen into a scene would probably be nigh unworkable.
But yeah, they don’t look too grand when rendered in Cycles. The spheres look a tiny bit better than the flat cards, but it loses some of its blended softness that make them look so, er, tree-ish.
2 Likes