Spring RTS Engine

We argued with smoth about trees being ugly or not in one topic and one idea arised:

Spring generated(default) trees could, at least have some randomized size and height(And if im not wrong, also rotation) variance algorithms. You can do this kind of stuff manually with custom features with tdf.

Spring default trees looks all the same, in size, and therefore highlights the ugliness...

trees are ugly unless you have graphics and most importantly shadows up to full, in which case they look quite ok. they would look much much better if they swayed dynamically to the same wind deciding wind-gen direction and income, but different sizes would be a good first step

I don't see any reason why to continue the work on the distinction of units, features & trees. IMO everything should be unified for simplicity and flexibility.

I 100% agree with you, jK. I really wish it was all the same stuff, just different tags. There's very little about Features that's even slightly necessary atm, other than the shadowmaps working properly for them, but not for Units.

Aren't features more efficient than gaia units?

jK wrote:-> LOD system for features is currently not doable, only if you use gaia units, which will increase the cpu overhead dramatically.

FLOZi wrote:Aren't features more efficient than gaia units?

yes they are esp since last version.

FLOZi wrote:Aren't features more efficient than gaia units?

jK wrote:-> LOD system for features is currently not doable, only if you use gaia units, which will increase the cpu overhead dramatically.

unification != the same

unification -> universal :

• including or covering all or a whole collectively or distributively without limit or exception; especially : available equitably to all members of a society <universal health coverage>
• adapted or adjustable to meet varied requirements (as of use, shape, or size) <a universal gear cutter> <a universal remote control>

Means: features should not become units, neither should units become features, instead both should give their advantages in one pool, so both can select and profit of those.

So atm there are 4 separate model renderers: units, features, trees and projectiles.
This doesn't make any sense at all and it makes it nearly impossible to include new features, debugging, etc.
Instead there should be just one renderer for all of those types - yeah, even tress should be just _models_.
Also features and units could share optimizations, so an energy-storage is more feature-like than unit-like. And atm trees get some special optimizations feature don't get etc.

So atm there are 4 separate model renderers: units, features, trees and projectiles.
This doesn't make any sense at all and it makes it nearly impossible to include new features, debugging, etc.
Instead there should be just one renderer for all of those types - yeah, even tress should be should be just _models_.
Also features and units could share optimizations, so an energy-storage is more feature-like than unit-like. And atm trees got some special optimizations feature don't get etc.

I agree with all of that.

Trees as models? Hell yes. I don't have all the models for a complete deciduous "set", I will work on that. I have all sorts of pines.

And it would be nicer than hell to have these behavioral states be settable via Lua, btw. Then I can create a Unit, do some "animation" during the first frame of its existence to randomize Piece positions, then declare it's a Tree (obviously, part of that requires that Piece coordinates / rotations be saved in a static location at that point, so it will preserve them without having to do any further computation). Then we could have our cake and eat it, too.

That would be fricking awesome.

I also agree. There are some issues to work out of course. We would need a unit generator that replaces trees with similar looking units to maintain compatibility with old maps.

Ah, now I see what you mean.

zerver wrote:I also agree. There are some issues to work out of course. We would need a unit generator that replaces trees with similar looking units to maintain compatibility with old maps.

umm that is REALLY easy.

Just either define the trees as some (custom?) internal model format (with custom renderer?) and assign this as models to the tree units, or stuff some replacement tree models in springcontent.sdz

Either way getting rid of the separation would be good, but indeed first (probably) the unit code would need to get the functionality that is unique to features now (burning, geo smoke, not updating if there's nothing to update, and probably some more things). And some measurements of the performance change would be good too. (The units lists in CQuadField would suddenly contain a lot more objects; although possibly here the separation could be kept in some way, if combining units and features appears to be problematic.)

Features already use unit rendering code AFAIK so that part shouldn't be hard to combine even more I'd say.

Rotation is the most important thing in making trees look less uniform. Though the spring default ones do have a degree of preshading IIRC so it may look like they are lit from different directions.

As a workaround to give your features rotation, create units, rotate them, and then kill them, making the feature the corpse. Corpses inherit rotation.

Spring defaults aren't preshaded. They just are not borked, shadowmap-wise. And Feature rotation's fixed in Buildbot Spring. I'm doing what you're suggesting as a workaround for now, though