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: 6109
Joined: 29 Apr 2005, 01:14

Re: Random WIP

Post by FLOZi » 12 Jul 2011, 04:31

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.
0 x

User avatar
KenC
Posts: 6
Joined: 02 Jul 2011, 00:15

Re: Random WIP

Post by KenC » 12 Jul 2011, 10:11

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
0 x

User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Random WIP

Post by knorke » 12 Jul 2011, 10:37

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┬░
0 x

User avatar
KenC
Posts: 6
Joined: 02 Jul 2011, 00:15

Re: Random WIP

Post by KenC » 12 Jul 2011, 11:51

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 1611 times
0 x

User avatar
Wombat
Posts: 3379
Joined: 15 Dec 2008, 15:53

Re: Random WIP

Post by Wombat » 12 Jul 2011, 11:54

i demand that .sdz >:( !
0 x

User avatar
Beherith
Moderator
Posts: 4934
Joined: 26 Oct 2007, 16:21

Re: Random WIP

Post by Beherith » 12 Jul 2011, 13:49

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?
0 x

User avatar
rattle
Damned Developer
Posts: 8278
Joined: 01 Jun 2006, 13:15

Re: Random WIP

Post by rattle » 12 Jul 2011, 15:37

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
0 x

User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Random WIP

Post by knorke » 12 Jul 2011, 20:33

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
0 x

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

Re: Random WIP

Post by KaiserJ » 12 Jul 2011, 21:03

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)
0 x

User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Random WIP

Post by knorke » 12 Jul 2011, 22:06

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 ?
0 x

User avatar
smoth
Posts: 22300
Joined: 13 Jan 2005, 00:46

Re: Random WIP

Post by smoth » 12 Jul 2011, 22:09

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?
0 x

User avatar
yuritch
Spring 1944 Developer
Posts: 1018
Joined: 11 Oct 2005, 07:18

Re: Random WIP

Post by yuritch » 12 Jul 2011, 22:15

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.
0 x

User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Random WIP

Post by knorke » 12 Jul 2011, 22:28

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
0 x

User avatar
KenC
Posts: 6
Joined: 02 Jul 2011, 00:15

Re: Random WIP

Post by KenC » 13 Jul 2011, 03:59

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.
0 x

User avatar
smoth
Posts: 22300
Joined: 13 Jan 2005, 00:46

Re: Random WIP

Post by smoth » 13 Jul 2011, 04:06

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..
0 x

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

Re: Random WIP

Post by FLOZi » 13 Jul 2011, 04:12

<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>
0 x

User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Random WIP

Post by knorke » 13 Jul 2011, 09:22

*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
0 x

User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: Random WIP

Post by jK » 13 Jul 2011, 09:50

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.
0 x

User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14605
Joined: 17 Nov 2005, 02:43

Re: Random WIP

Post by Forboding Angel » 13 Jul 2011, 10:09

60 pieces??? O_O The evo tanks are generally like 3 - 5 pieces. Wow.
0 x

User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10238
Joined: 24 Jan 2006, 21:12

Re: Random WIP

Post by PicassoCT » 13 Jul 2011, 10:24

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
0 x

Locked

Return to “Art & Modelling”