Animated Trees

[Wijitmaker]

Did you guys know that there was an actor made years ago for testing? Check this out if you have time:

binaries/data/mods/public/art/actors/flora/trees/pine_animated.xml (hopefully it still works)

See what kind of performance issues you might have if you load a map up with these actors as a comparison (probably poorer?). This test tree was also made to animate a fall on "death" (they should actually fall when first attacked).

I like myconid's method a lot better though, no animating required and I'm guessing better performance

[Pureon]

Did you guys know that there was an actor made years ago for testing? Check this out if you have time:

Yep I saw that when I first started working on animations for 0 A.D.

[twin]

Good animation. Do you think to move the smoke in the same direction to the wind? I think that it will more realistic.

[Shield Bearer]

How feasible do you think adding falling trunks would be? And making the tree wobble when being chopped?

[myconid]

lol, now you're just showing off! Amazing.

Just having a bit of fun.

Very nice! Might it be advantageous to introduce a slight bit of randomness? Perhaps in the phase?

After the video I thought to use the object coordinates as an offset of the phase to make "waves" of wind passing through the terrain. Didn't quite work out the way I wanted, but it did make it look random! Right now I'm using three cosines per vertex... maybe kind of inefficient, so I'll need to find a way to approximate it...

Did you guys know that there was an actor made years ago for testing?

Yeah, I came across it while changing the tree actors.

Good animation. Do you think to move the smoke in the same direction to the wind? I think that it will more realistic.

It's possible. The particle emitter could share the wind information with the tree shader, though the two are different effects.

How feasible do you think adding falling trunks would be? And making the tree wobble when being chopped?

That's a job for the animators, I think. Adding a physics engine would take a lot longer than 25 minutes!

[FeXoR]

Great thing in general, even better for 25 min

That's a job for the animators, I think. Adding a physics engine would take a lot longer than 25 minutes!

Hehe ^^

[zoot]

Could more of the skeletal animations be moved to the GPU? Apparently it has been a concern in the past that they are too CPU-intensive.

[myconid]

Could more of the skeletal animations be moved to the GPU? Apparently it has been a concern in the past that they are too CPU-intensive.

Check the config for the "GPU skinning" option. Apparently it's disabled because it's slower, though I haven't tested it.

[zoot]

I see

[k776]

Very nice work.

I notice the shadows flicker as the trees move though. Are shadows done on the CPU or GPU?

If they're on the CPU, it'd be nice to move them to GPU rendered. Should be faster right?

[zoot]

Very nice work.

I notice the shadows flicker as the trees move though. Are shadows done on the CPU or GPU?

If they're on the CPU, it'd be nice to move them to GPU rendered. Should be faster right?

I've noticed that flickering on other shadows too. I assume its a bug. See the shadows at 0:12 in this video:

Edited June 15, 2012 by zoot

[myconid]

Very nice work.

I notice the shadows flicker as the trees move though. Are shadows done on the CPU or GPU?

If they're on the CPU, it'd be nice to move them to GPU rendered. Should be faster right?

Shadows are already done on the GPU. The flickering/pixellation is a limitation of what current shadowmapping technology can do (you'll notice similar artifacts in AAA games as well).

There are some alternative techniques to mitigate the problem, such as cascaded shadowmaps, though in my view their results aren't good enough for their memory/performance cost.

There may also be some techniques to prevent the flickering under some circumstances, such as during rotations. I don't know much about them offhand, but they should be worth looking into.

[zoot]

What about shadow volumes? My choice source of objective information, Wikipedia, says this technique is slow when the shadows are large, but that doesn't really seem to be the case here.

[myconid]

What about shadow volumes? My choice source of objective information, Wikipedia, says this technique is slow when the shadows are large, but that doesn't really seem to be the case here.

I think shadow volumes could become the industry's favourite in the upcoming generations of GPUs (geometry shaders! ), though for the moment shadowmaps are a safer bet for us. Besides, it'll be much easier to get decent results out of what we've already got than if we start from scratch.

It's true that the shadowmap implementation we have needs some debugging, especially the GLSL version (it's on my list, but the list keeps getting longer!). If we can stop the flickering during camera rotations, we're good for 0ad part one. For part two, if there'll be moving lights, seasons and stuff like that, there'll need to be a way to fade smoothly between light states to reduce the flickering... so that can wait.

[historic_bruno]

Let's get some of these patches cleaned up, tested, and integrated with the engine I suppose #1493 and #1497 are a good place to start even though they have no visible effects. I think we can get them in A11 if the changes are validated.

Check the config for the "GPU skinning" option. Apparently it's disabled because it's slower, though I haven't tested it.

Indeed, there was a discussion about that here.

[theShadow]

do you think that the tree swaying that mycond implemented could make it in to a11? possible as an effect thats disabled by default, but can be turned on for testing purposes?

[WhiteTreePaladin]

Flickering shadows when rotating the camera has been an issue for a long time.

[edit]

Really like the tree animations! It's a bit more windy than most maps would need, but I guess you can configure that. It really does make the shadows look bad. If that can't be helped, then perhaps tree shadows could be made static, although that's less than ideal.

[wrod]

I know some of you guys are going to hate me for this but maybe animated trees should wait untill the game is almost done because it could make the game slow if u add the effects first without the rest of the game being done

[zoot]

I know some of you guys are going to hate me for this but maybe animated trees should wait untill the game is almost done because it could make the game slow if u add the effects first without the rest of the game being done

Fortunately, development isn't a static process like that. If the trees are perceived as slowing anything down, they can be taken out or put back in at any time.

[myconid]

I know some of you guys are going to hate me for this but maybe animated trees should wait untill the game is almost done because it could make the game slow if u add the effects first without the rest of the game being done

My patches added a way to scale the amount of effects through the game's config file. Setting that value to 0 = no effects, 10 = all effects. Values in between scale the effects up gradually, depending on how the effects registered themselves with the materials manager.

[feneur]

My patches added a way to scale the amount of effects through the game's config file. Setting that value to 0 = no effects, 10 = all effects. Values in between scale the effects up gradually, depending on how the effects registered themselves with the materials manager.

Are effects possible to turn off completely on an individual basis as well?

[wraitii]

Yeah, whatever myconid is adding right now should have an option in the settings as some of it can be fairly GPU/CPU-intensive on low end machines. I suppose it can't be too complicated to code, but I have no idea what the underlying architecture is.

That being said, I really appreciate trees that slowly rock under the wind (and had personaly implemented small bits of pollen going itsy bitsy in the wind at some point in Alpha 9 for coolness), and it's great it's been done .

[myconid]

Are effects possible to turn off completely on an individual basis as well?

Afraid not. That may involve hardcoding stuff and I'd rather avoid that at this point.

[feneur]

Afraid not. That may involve hardcoding stuff and I'd rather avoid that at this point.

Ok, well as long as there is some way to control it, and eventually it would be nice to have the ability to turn things on and off completely. Don't worry about having that option at the moment though

[historic_bruno]

That may involve hardcoding stuff

Sounds good, because it annoys Philip, and every time the config system's ugliness annoys Philip, it increases the chances that he will replace it (He's complained about it for a long time) Though anyone else is free to work on it if they can improve it. It's especially awkward for renderer config as you may have noticed...

As Erik said, it's not essential to have options for everything in the initial version, but I think eventually we will want them IMO numeric values are nicer for things that can't be expressed as distinct features, like quality and detail level of Effect X.