Spring RTS Engine

Lookie!!!

Snowy Trees !!

I just gotta do the upspring trick...

and until someone TEACHES me how to do the damn alpha channel trick, you still get to flip the map and add an alpha.. urgh...

me and forboding BOTH can't figure that out...



I'll finish the tyranid chimney soon.. its the only one left of those capaliary towers...

but yeah, though I have no transparencies to work with... grumble... what do you guys think?? it shouldn't be TOOOOO bad on resources... they are between 40-150 faces each... the groups of trees being the more obviously.... I figure as long as they aren't used all over the place insane.... they should look good on a map or two..

Very cool, the best that can be done without transparencies.

Use far more poly, there's no problem in it at all. Todays videocards can render far higher poly count, with no drop in FPS at all. Caydr proved that there isn't even a reasonable limit to it. Go ahead, make some beatifull trees

E: Needless to say, these trees are actually quite awesome. Well done!

I'd have to echo BvDorp... you could probably use 200 tris per tree without any real problems, even with a big forest. Try making them as a pair of hex-rings capped by points (a grand total of 36 tris) with a single hex-ring (12 more tris) for the trunk, then apply welding... if you go up to a 12-ring for the leafy bits, you can get a lot of roundness out've Spring, after welding, and that's still just 72 tris per tree.

Then do your uv projections on it while it's still very generic, and you're in great shape. You could very easily do one nice-looking tree skin on a 128/128, or a three-tree group with three very unique skins on a 256/256. Just bring back your very simplistic tree, once the projection is done, and *then* manipulate the polygons to create uniqueness. Why do the uvmapping the hard way, when you can just do a simple cylindrical projection and be done with it?

If this sounds confusing, let me know, and I'll do an example. After I'm done with the thing I'm doing for AATA, so bear with me- I have a very limited time-budget this weekend.

If I recall, the current autogenerated trees are actually using up more polys than those snowy trees, and they're chronicly overused

AF wrote:If I recall, the current autogenerated trees are actually using up more polys than those snowy trees, and they're chronicly overused

Yeah you could probably get away with smoothing it a bit and still have it less than the stock ones.

Argh wrote:I'd have to echo BvDorp... you could probably use 200 tris per tree without any real problems, even with a big forest. Try making them as a pair of hex-rings capped by points (a grand total of 36 tris) with a single hex-ring (12 more tris) for the trunk, then apply welding... if you go up to a 12-ring for the leafy bits, you can get a lot of roundness out've Spring, after welding, and that's still just 72 tris per tree.

Nope, it won't work out like you think. We tried forests of trees and frankly that is not going to work with higher poly count. I know what you are saying but features are like stage hands... they help but should remain out of the spotlight and not drawing attention. If they are too high they will consume resources.

this ran at ~20fs These are also LOW LOW poly objects. Features should not eat up resources.... at least not too much because we want to save those resources for the units and other things. dispite caydrs arguement feature poly counts matter.

Are you sure that wasnt just the framerate going down because you where looking side on? On my machine looking sideways puts the framerate down laods features or no features, it's even worse with shadows turned on....

yep.. but you know what... I am tired of trying to tell you people crap..

I keep telling people shit and then get replies questioning it which waistes my time as I type detailed paragraphs.

Short answer form(because pictures do not tell enough): Deci tried making a forest using my palm trees and yeah, they ATE frames... they were within the limits argh was talking about...and there wasn't even a battle happening.

I agree with smoth 100%. I really like that aftershock map by aGorm, but I can't really play it because all the features completely destroy my frame rate.

setting up texturing and transforms also costs something. Rendering 1000 10-poly objects will be a lot slower than rendering 1 10000-poly object. Furthermore, spring uses display lists to render static features, which are fast in theory, but in reality I have a feeling the driver doesn't optimize with them.

Trees have LOD for a reason
So yes I agree with smoth and argh.
The discussion about high/low poly is based on units that are being transformed and displayed anyway. If that is the case, then adding some extra polygons doesn't change a lot.

summarize:
more polygons have a small impact
more objects has a much larger impact on FPS.

I didn't actually test this though, but I'm quite sure I'm right about it.

smoth wrote:

Argh wrote:I'd have to echo BvDorp... you could probably use 200 tris per tree without any real problems, even with a big forest. Try making them as a pair of hex-rings capped by points (a grand total of 36 tris) with a single hex-ring (12 more tris) for the trunk, then apply welding... if you go up to a 12-ring for the leafy bits, you can get a lot of roundness out've Spring, after welding, and that's still just 72 tris per tree.

Nope, it won't work out like you think. We tried forests of trees and frankly that is not going to work with higher poly count. I know what you are saying but features are like stage hands... they help but should remain out of the spotlight and not drawing attention. If they are too high they will consume resources.

this ran at ~20fs These are also LOW LOW poly objects. Features should not eat up resources.... at least not too much because we want to save those resources for the units and other things. dispite caydrs arguement feature poly counts matter.

Wow... For once I agree with Smoth

AF wrote:Are you sure that wasnt just the framerate going down because you where looking side on? On my machine looking sideways puts the framerate down laods features or no features, it's even worse with shadows turned on....

I loled...

After shock runs fine on my machine even with 500 fighters having a dogfight, from a side on view, at a res of 1900x1200, with shadows. My machine, by todays standards, is only only moderate at best. (AMD Athelon 3200XP, 1 GIG ram, 6800 GT 256, SATA drives). I did find much larger dranis on resorses. FOr instance, when I first made the map, i didnt actully bother to check the plams, other than the first one. I didnt realise teh other palms were gropes of palms. The bigest of which was about 5 palms, and hence 5 times the pollies. Running that almost crashed my computer as doon as any hint of tree came into view... but you have to bare in mine that was sevreal thousand trees...After slashing the polycount to about a 1/4 I was left with (on my machine) a totaly playable map. Ran like a dream.

BTW, one thing that does piss me of no end is Geos.... These realy DO eat your framerate. The placement is the biggest problem because ity often puts down 2 or 3 were u ask for 1, but I noticed (after a servere glitche) than if you get about 10 of them around one spot, the frame rate plumets to about 1 frame every 2 seconds... Ofcourse thats a little of topic.

aGorm

Spring's bottleneck is number of objects, not their polycount... a 50 polygon model with 50 different object-pieces will run a shitload slower than a single object-piece model with 4,000 polygons.

The way the engine steps through and processes its objects is really really inefficent at the moment O_O