Random WIP 2006-2011 - Page 402

Random WIP 2006-2011

Share and discuss visual creations and creation practices like texturing, modelling and musing on the meaning of life.

Moderators: MR.D, Moderators

User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: Random WIP

Post by FLOZi »

knorke wrote: Also what happend to the egg robots from last page?
http://kencumpian.deviantart.com/gallery/

Have been some more updates here. Also he last visited the forums yesterday (Monday).

There's some nice close-ups of the Pillager tank, judging from the layout (idler and drive on the same level and in contact with ground, segmented treads) looks like the treads are of true-animated-link type (ala Spring Tanks) rather than hide/show pieces (ala Nanoblobs), hide/show texture changes (ala S44) or texture scrolling shader.
User avatar
KenC
Posts: 6
Joined: 02 Jul 2011, 00:15

Re: Random WIP

Post by KenC »

FLOZi wrote: There's some nice close-ups of the Pillager tank, judging from the layout (idler and drive on the same level and in contact with ground, segmented treads) looks like the treads are of true-animated-link type (ala Spring Tanks) rather than hide/show pieces (ala Nanoblobs), hide/show texture changes (ala S44) or texture scrolling shader.
Sadly, the treads are shortcutted, but in this case they rotate and then replay with a "Move/Rotate now" command. Much like this:
Attachments
Treadnique.gif
(6.37 KiB) Downloaded 2 times
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Random WIP

Post by knorke »

Not much of a big difference imo, it is basically not noticeable ingame.
There are some more ways to ie save piececount or get smoother animation but in the end I like the "fully rotating" track pieces because you can easily do a "damaged track" by just hiding a few pieces.
With those other technics it would be obvious that the "hole" left by the blown track element does not travel 360┬░
User avatar
KenC
Posts: 6
Joined: 02 Jul 2011, 00:15

Re: Random WIP

Post by KenC »

knorke wrote:Not much of a big difference imo, it is basically not noticeable ingame.
There are some more ways to ie save piececount or get smoother animation but in the end I like the "fully rotating" track pieces because you can easily do a "damaged track" by just hiding a few pieces.
With those other technics it would be obvious that the "hole" left by the blown track element does not travel 360┬░
As soon as I implemented an experimental battle damage system, I knew I had to redo the treads if I wanted to have damaged tracks. I'll have to look into it down the line when I work on generated death animations and actual wreckage...for right now everything just sorta goes "pop". It's hard to ignore when tanks are so prone to taking damage:
Attachments
TanksExplode.gif
TanksExplode.gif (2.83 MiB) Viewed 2553 times
User avatar
Wombat
Posts: 3379
Joined: 15 Dec 2008, 15:53

Re: Random WIP

Post by Wombat »

i demand that .sdz >:( !
User avatar
Beherith
Posts: 5145
Joined: 26 Oct 2007, 16:21

Re: Random WIP

Post by Beherith »

Just note that individual tread pieces get expensive very fast wrt performance. Unless you plan on having less than a hundred on screen at once, I would recommend against adding 40 tread pieces per tank.

Poly count is not nearly even a bottleneck in spring compared to piece count.

Absolutely love your stuff, KenC!

How did you decide on the spring engine?
User avatar
rattle
Damned Developer
Posts: 8278
Joined: 01 Jun 2006, 13:15

Re: Random WIP

Post by rattle »

KenC: duplicated treads which have their UVs moved along a tread texture is a little more efficient
that's what it looks like : http://i111.photobucket.com/albums/n131 ... lahxq9.gif

I think I was bored enough to try this once...
http://springrts.com/phpbb/viewtopic.ph ... ck#p238339
Shit took a lot of time in wings due to lack of tools that do this for you.


Are you gonna add normal maps? Because everything's smooth shaded
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Random WIP

Post by knorke »

Beherith wrote:Just note that individual tread pieces get expensive very fast wrt performance. Unless you plan on having less than a hundred on screen at once, I would recommend against adding 40 tread pieces per tank.
I think he already has 40 pieces per tank, just moves them in a different way?

Say you have 40 track pieces per tank plus say 20 pieces for body, turret,gun,wheels etc that makes 60 pieces. Still only about 3x the piece count of a xta commander or random gundam mech.

xta rocko: 12 pieces
xta commander: 20 pieces
random gundam mechs: 20-25 pieces
spring tanks: small tank: 50 pieces, big tank: 61 pieces
(counting empty and unused pieces)

Every piece does have an impact but I dont think a unit with 20 pieces uses twice the cpu as a unit with 10 pieces. Piece movement/translation/whatever is only one part of what makes a unit use cpu.

Unit count matters alot too. And how those units are used.
For example in *A you might have 300 unit per player but how many of those are really in the game?
As in the player actually plays with them.
1/3 of units is a fighter patrol, 1/3 are windfarms, mex, nanos,..
So 2/3 of units is stuff that you never really touch beside building them on repeat or by dragging lines with shift held down.

If you can reduce that and it frees up resources for some fun effects then do it.

Image
lol micro
User avatar
KaiserJ
Community Representative
Posts: 3113
Joined: 08 Sep 2008, 22:59

Re: Random WIP

Post by KaiserJ »

how would a performance comparison be to something like two units that are cubes vs one unit that is two moving cubes

two units i assume would be more costly... but roughly what's the relation in tangible numeric terms? (if anyone wants to take a shot in the dark)
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Random WIP

Post by knorke »

More pieces just means some more calculating of some 3d coordinates which is fairly fast I suppose? Plus maybe running some more Lua script/animation stuff if the pieces are moving. Like checking if a WaitForMove has finished or something. Not stuff that I could see being very slow but I have no idea really.
Possible shadows play a role too?
Using one hitboxes per piece rather then per unit is probally expensive but you hardly need that.

I wanted to do some tests by making a benchmark widget but then I just spawned tons of units with cheats until I thought thats about as much as there will be per player. Was still playable while the units crumbled each other to pieces, did not care about it beyond that.
People also told me about a piece count limit in the engine.
If there is such limit, it is > 67
Anyway, in the end what matters is the performance of the complete game.

ie in last zeroK lobby poll 25%* selected "do not play more zK: because it runs choppy."
*when i last checked, dunno where to see final result
I dont think that is because of piece or polygon count, those are average.
You could probally have a 500-piece unit if you save on pathfinder, effects etc.

tl;dr
Sadly there are no results on how much spring was tested ever in max ?
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Random WIP

Post by smoth »

20? I thought it was more like 17 for an rgm with machine gun? Rounding up?
Also iirc invisible pieces/hidden pieces are negligible.

What multiplier does poly count add on a per piece basis?
User avatar
yuritch
Spring 1944 Developer
Posts: 1018
Joined: 11 Oct 2005, 07:18

Re: Random WIP

Post by yuritch »

knorke wrote:People also told me about a piece count limit in the
engine.
If there is such limit, it is > 67
If there is a (practically reachable) limit, it's surely higher than 128. I have a unit with more pieces than this, and it works.
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Random WIP

Post by knorke »

smoth wrote:20? I thought it was more like 17 for an rgm with
machine gun? Rounding up?
As said, random mechs.
A rx79plus has 30, a rx78g3 has 22.
Tested with this wudget
Also iirc invisible pieces/hidden pieces are negligible.
I'd say matter because the engine still has to calculate their animation in case a weapon is fired from them, unit gets attached there, effect emited,...
Or just because other pieces are attached to it.
What multiplier does poly count add on a per piece basis?
huh?
yuritch wrote:If there is a (practically reachable) limit, it's surely higher than 128. I have a unit with more pieces than this, and it works.
I guessed so. BaNa teached me a new word for this today: http://en.wikipedia.org/wiki/Cargo_cult_programming
User avatar
KenC
Posts: 6
Joined: 02 Jul 2011, 00:15

Re: Random WIP

Post by KenC »

What multiplier does poly count add on a per piece basis?
huh?
I believe what is being asked is if it matters whether or not a piece has polygons for it to contribute to resource consumption, and if it does, how much it would consume.

For example, the basic infantry I modeled has 72 pieces, but only some of them are actually visible. Even though the pieces are model-less would they still consume as much (in the animation aspect) as a 12 polygon piece?

What about a model-less piece with a piece on it that has 12-polygons?

What about a model-less piece that has a 12-polygon piece on it that is currently hidden?

I think the question could have been asked a little more clearly, but I think it's interesting.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Random WIP

Post by smoth »

I am saying that poly count doesn't matter a lot

however, when we are talking about pieces being updated, the poly count might matter for this calculation.

I have also been told that how deeply nested an object is that it's cost can grow as in..

shoulder-arm-forearm-hand-gun-flare
1-2-4-8-16-32 grow..
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: Random WIP

Post by FLOZi »

<argh-zone>

I would (totally and utterly) guess that most of the piece overhead is because of all the matrix math required to compute their current position and rotation - which has to be done in a synced way. Which would imply that individual polycount of a given piece and its visibility are secondary factors. It depends if we are talking about limits of graphical performance or simtime performance - I suspect the number of pieces impacts the latter.

</argh-zone>
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Random WIP

Post by knorke »

*entering the argh zone*
Image
however, when we are talking about pieces being updated, the poly count might matter for this calculation.
world coordinates of polygons change anyway if the unit is moving in any way. Say you have a unit with 2 arms: left arm is 5 polygons, right arm is 5000 polygons. imo makes no difference which arm you rotate.
I have also been told that how deeply nested an object is that it's cost can grow
It seems common-sense but then I am not sure on that:
Each piece position is based on the piece it is attached to.
You start with the inner most piece and from there go outwards, calculating every piece position only once, no matter what structure they are in.

/edit
http://answers.springlobby.info/questio ... any-pieces
User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Random WIP

Post by jK »

smoth wrote:I am saying that poly count doesn't matter a lot

however, when we are talking about pieces being updated, the poly count might matter for this calculation.

I have also been told that how deeply nested an object is that it's cost can grow as in..

shoulder-arm-forearm-hand-gun-flare
1-2-4-8-16-32 grow..
btw the per piece rendering overhead will be reduced in 0.83 by upto ~4/5
before it was upto ~1.3╬╝s per piece & drawframe, in 0.83 it will const ~0.25╬╝s (with a 3,2GHz & 460GTX-OC)


FLOZi wrote:<argh-zone>...It depends if we are talking about limits of graphical performance or simtime performance - I suspect the number of pieces impacts the latter.</argh-zone>
No, the per-piece attributes (rotation & translation) need to be send to the GPU and this eats a damn lot of bandwidth & CPU time. In numbers this means that the CPU needs nearly as much time for this as the GPU needs to render the whole piece!
In 0.83 Spring will now buffer a per piece matrix and send it (1x glMultMatrix), instead of sending each rotation & translation separate (upto 3x glRotate & 1x glTranslate). see here.
Still it isn't perfect in 0.83 either, the best solution would be to use a VBO to buffer all per piece attributes in the VideoRAM and only changing them when needed. This way the bandwidth overhead would be zero.

KenC wrote:but only some of them are actually visible
Pieces with zero vertices (= empty) and are leaves in the mesh tree, don't cause any overhead (they are skipped). All other pieces cause an overhead as explained above.
Last edited by jK on 13 Jul 2011, 10:13, edited 1 time in total.
User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14673
Joined: 17 Nov 2005, 02:43

Re: Random WIP

Post by Forboding Angel »

60 pieces??? O_O The evo tanks are generally like 3 - 5 pieces. Wow.
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10450
Joined: 24 Jan 2006, 21:12

Re: Random WIP

Post by PicassoCT »

I guess its the damage model that demands this many pieces.. but yeah, i usually have the same ammount as Forb here + Invisible Pieces for ParticleGen
Locked

Return to “Art & Modelling”