@haze said:
Yeah, that's really awesome. So many options...i can spend hours playing with it :s. Great job.
Can you increase a bit the grid range(20 max instead of 10) to test big forest.
No shader problems and performances are quite satisfying.
The wind is much nicer ^^.
I love to play with it <3. Thanks for this amazing tool Paul.
Thanks!
I can increase the grid range easily, of course. As it stands, 100 trees is already a lot, though, for many different configurations. I have one tree that takes performance down to about 20 FPS with a full grid and shadows and even only looking at a quarter of the grid seems to take triangles up near a couple million. I fear that allowing it to go up to 400 trees (20x20) would make the program crash a lot.
Stability has been my primary concern since you can spend a long time tweaking the parameters of a particular tree… and it would suck to lose that to a crash. A more ‘crashy’ program means I’d have to spend a lot of time doing boring things like quick saves and autosaves, etc…
The feature is really meant to let you see how well the tree works in a setting where you have a lot of them. ie: will you have to have multiple seeds or will just one instance rotated and scaled work. For example, I created one tree config that had such distinctive branch structure that you could easily see it repeated over and over.
So I feel like the grid satisfies its current intent without sacrificing flexibility. Perhaps I could make it a separate config or command line option for the folks who are willing to take the risk.
I can increase the grid range easily, of course. As it stands, 100 trees is already a lot, though, for many different configurations. I have one tree that takes performance down to about 20 FPS with a full grid and shadows and even only looking at a quarter of the grid seems to take triangles up near a couple million. I fear that allowing it to go up to 400 trees (20x20) would make the program crash a lot.
Stability has been my primary concern since you can spend a long time tweaking the parameters of a particular tree… and it would suck to lose that to a crash. A more ‘crashy’ program means I’d have to spend a lot of time doing boring things like quick saves and autosaves, etc…
The feature is really meant to let you see how well the tree works in a setting where you have a lot of them. ie: will you have to have multiple seeds or will just one instance rotated and scaled work. For example, I created one tree config that had such distinctive branch structure that you could easily see it repeated over and over.
So I feel like the grid satisfies its current intent without sacrificing flexibility. Perhaps I could make it a separate config or command line option for the folks who are willing to take the risk.
With correct LOD config you can have much more trees, when i look with my cam a bit y offset, i see the edge of the forest, so i want impostors after 400 meters to fill that hole ;)…beautiful screenshots.
But you’re right. it’s enough sufficient for the final release. i was just curious ^^. Stability and crashes is a fairly good argument to let it as it is x).
@haze said:
With correct LOD config you can have much more trees, when i look with my cam a bit y offset, i see the edge of the forest, so i want impostors after 400 meters to fill that hole ;)....beautiful screenshots.
Yeah, screenshots are why I’ve almost increased it myself like 50 times now. Would be nice to have the option of upping it just for that. Like as a command line option or something.
@pspeed said:
Turbulence agitates the branch tips at a higher frequency than the rest of the tree so the leaf quads do get agitated. It's hard to agitate the leaves within the quad without some animation. From that it's hard to guess how fast to agitate, too.
See, really, I’ve dressed up and polished this pig about as far as it will go, I guess. It’s not at all an accurate representation of wind since normally oscillation only happens when the wind isn’t moving the tree. I try clever ways to simulate this by having the branch intensity delay the tree motion just a bit… makes it look like the branches rock back and forth after a big wind. Mostly, I fake a lot of stuff together and fake a little more and it becomes random enough to be semi-believable… and it’s relatively cheap. (2 sine lookups per vertex does make my old-school brain shudder a bit but it seems not to draw down the frame rate at all.)
A more proper solution involves not only determining wind strength but the slope of the change in wind so that the tree can oscillate or not based on whether the wind is backing off. There are a few ways to do this. Also, the tree itself needs to be treated as bones of an animation so that each joint gets rotated properly. This would also allow the down wind section of the tree to have more turbulence than the leading side and support the lateral torsion separately.
So, my fear on leaf agitation is that if I add it then it will look less natural by being a more incorrect thing. That being said, it wouldn’t be the first time that some acceptable trick eventually occurs to me.
What you’ve created with SimArboreal is really amazing. I’ve spent quite a bit of time this year animating grass and trees in glsl so I realize how tricky it can be. I’ve spent a handful of hours combing through your code and am in the middle of refactoring my game to use SimArboreal. The lack of wind was a big concern so the addition of wind in SimArboreal is a big deal to me. Thanks again for all of your excellent work (especially your well documented shaders)!
@JoeMama said:
What you've created with SimArboreal is really amazing. I've spent quite a bit of time this year animating grass and trees in glsl so I realize how tricky it can be. I've spent a handful of hours combing through your code and am in the middle of refactoring my game to use SimArboreal. The lack of wind was a big concern so the addition of wind in SimArboreal is a big deal to me. Thanks again for all of your excellent work (especially your well documented shaders)!
Thanks for the kind words. Shader documentation is a survival skill. Keeps me from blowing my brains out if I have to go fix something 2 years from now.
I’ve tested the latest build… really impressive! Are you planning to make a tool to paint trees on the terrain? I know @jayfella was working on something similar to this to integrate into the editor but I don’t think it was finished in the end unless I missed it.
@monkeychops said:
I've tested the latest build... really impressive! Are you planning to make a tool to paint trees on the terrain? I know @jayfella was working on something similar to this to integrate into the editor but I don't think it was finished in the end unless I missed it.
I have no direct plans to do anything like that. Doesn’t mean someone else won’t do it, though.
I’ll try not to derail the thread, but I kind of stopped adding more and more to the terrain generator I made because it kind of gets to the point where I’m making an out-of-the-box game - just insert storyline. Whilst I believe that game engines should come with certain things (such as a charactercontrol, a terrain generator, physics, etc…) at the end of the day you will more than likely re-write most of these areas yourself to suit your own needs, and remove the bloat you don’t use.
@jayfella said:
I'll try not to derail the thread, but I kind of stopped adding more and more to the terrain generator I made because it kind of gets to the point where I'm making an out-of-the-box game - just insert storyline. Whilst I believe that game engines should come with certain things (such as a charactercontrol, a terrain generator, physics, etc..) at the end of the day you will more than likely re-write most of these areas yourself to suit your own needs, and remove the bloat you don't use.
Yep, definitely. One of the reasons I opted for generative layers and stuff is partly because the data is self-contained and it therefore should make a decent enough example on how to plug in some other data source. The procedural versions are actually quite a bit more complicated, in fact. A tree layer that pulled entities from an ES, for example, would be stupid-simple.
…how the trees got into that layer is a completely separate issue. But either way, how the trees are stored, etc. is very game specific at that point. My personal choice to use an ES would tend to be counter to a lot of other popular approaches.
I’ve read the various articles before. Seems like most of them use geometry shaders to do the fins at runtime.
I have no immediate plans to implement anything like this as it gets pretty complicated and doesn’t address my immediate needs. That being said, it is something I think about. In fact, technically the same approach I use for the flat-poly level of detail would render camera facing fins also. Then it’s just a matter of dealing properly with the bump maps.
Saying that, I would recommend having a go with crazybump to make awesome normal maps though - some of the stuff that program can output you would swear is geometry
yeah, i also know about the GeometryShader thingy is quite annoying, seems like procedural content “require” it, even if we can do the same in CPU…
What exactly the author of the article above mentioned is “linear height map tracing for relief mapping” for Normal mapping we need. (look like alien tech for me also)
What i really want is to increase the visual quality of the subject if I can… The good thing is if the LOD system is inplaced, expensive computing for high detailed tree can be decreased a lot. Now i’m travelling around your code and also do experiments about relief mapping a bit, what I found so far:
Hooks for extra Procedural geometry fins, for geometry leaves, for tree holes … can be in SkinnedTreeMeshGenerator, which is naturally should be there (and fit my convention for XXXGenerator). The question is if the library are open for extentions in someway, such as this Generator example.
Fins shader can be just a bark texture along the tree’s trunk, looking good enough… The mentioned article spend quite a long time to explain how to make relief mapping, which in turn only look fancy if multisampling, alpha to coverage and transparent are configured correctly (mean a lot of works) … So I prefer not to take the path.
Yeah, there are some parts of the code that could probably be opened up a bit. Also, the TreeBuilderReference in the editor that does all the work of putting the LOD together… is doing too much work. A bit more of that should be pushed over to the library side… though at least right now that part is 100% flexible. (because anyone trying to duplicate it would have to write their own, lol)
One more thing I find out can be optimized a lot more is the leaves layers , which exactly is the fragment shader of the leaves. If I just show the trunks, the FPS are good even the grid quite big, when leaves turn on and they are small, also no framerate dropping. Stall only happen when the leaves billboard are quite big…
Should LOD affect also to the leaves at shader level? For example: no alpha blending, force a switch to lower mipmap texture (it’s still a bunch of leaves anyway)… will immediately cut out quite a lot of performance cost.
@atomix said:
One more thing I find out can be optimized a lot more is the leaves layers , which exactly is the fragment shader of the leaves. If I just show the trunks, the FPS are good even the grid quite big, when leaves turn on and they are small, also no framerate dropping. Stall only happen when the leaves billboard are quite big...
Should LOD affect also to the leaves at shader level? For example: no alpha blending, force a switch to lower mipmap texture (it’s still a bunch of leaves anyway)… will immediately cut out quite a lot of performance cost.
But from what you described, the performance hit is when you are close… when you’d want to be showing full quality anyway. So I’m not sure I understand.
The fragment shader is essential Lighting.j3md’s fragment shader. It needs per fragment lighting to give the “round” effect from the splayed normals. Otherwise the leaves look like a bunch of cardboard cutouts.
This is a very cool project and your way of coding looks very neat and well structured! Definitely will use this in the (near) future when I have the time!
One thing I was wondering about after playing with the demo, and I realize that it is because of the way those leave billboards are made and the way it is meant to be, but when you rotate around a tree you can see that those leaves rotate and follow the camera in order to always face it, which can look a bit weird if you stand close to the tree :P.
Do you know of any technique in which that could be solved? Maybe you can make a few textures for leaves from different angles, and switch between those when reaching certain angles? Guess that won’t do it as you have so many angles to take care of and probably get a very visible switch anyways
@reveance said:
This is a very cool project and your way of coding looks very neat and well structured! Definitely will use this in the (near) future when I have the time!
One thing I was wondering about after playing with the demo, and I realize that it is because of the way those leave billboards are made and the way it is meant to be, but when you rotate around a tree you can see that those leaves rotate and follow the camera in order to always face it, which can look a bit weird if you stand close to the tree :P.
Do you know of any technique in which that could be solved? Maybe you can make a few textures for leaves from different angles, and switch between those when reaching certain angles? Guess that won’t do it as you have so many angles to take care of and probably get a very visible switch anyways
There are no good solutions. This one is optimal for what I felt 90% of ground-walking cases would be. It’s rare that you would strafe around a tree much so you wouldn’t notice it. Obviously, hovering around is different… and walking under the tree and looking directly up is strange, too.
The “many polygons” approach has different issues as you’ve noted. You either have to fade out the edge-on leaves and/or use so many of them as to hide it. Arranging them can also be tricky so that self-shadows don’t show up strangely.
Edit: and note, one of the reasons leaf generation is a separate step based on the output of the branch generation is to let users who want to code something better simply use their own leaf generation. It means having to do a lot more work in code (versus just using the .j3o) but all of the parts are there. You just end up copying some sections of what TreeBuilderReference is doing in the editor source.
@pspeed said:
There are no good solutions. This one is optimal for what I felt 90% of ground-walking cases would be. It's rare that you would strafe around a tree much so you wouldn't notice it. Obviously, hovering around is different... and walking under the tree and looking directly up is strange, too.
The “many polygons” approach has different issues as you’ve noted. You either have to fade out the edge-on leaves and/or use so many of them as to hide it. Arranging them can also be tricky so that self-shadows don’t show up strangely.
Edit: and note, one of the reasons leaf generation is a separate step based on the output of the branch generation is to let users who want to code something better simply use their own leaf generation. It means having to do a lot more work in code (versus just using the .j3o) but all of the parts are there. You just end up copying some sections of what TreeBuilderReference is doing in the editor source.
Alright, yeah I thought it’d be a tricky problem…and probably irrelevant for most because it’s not really obvious until you start running circles under the tree while looking up…and who does that :facepalm:? But good to know that you can just replace that part…well structured it is
One question: Is it possible to rotate the trees, so that they have a different up-vector, e.g. when having a “little planet” with trees?
Or will one of the solutions (e.g. the billboards for the branches) not work for such a scenario?
EDIT: I will check this later … it would bee needed for certain camera types too (e.g. when you can fly with loopings and roll movements).
