Python S3O module and optimizer

[FLOZi]

I should stop googling stuff and read my book on Assessment for Learning.

wrt tristripping:

http://shiny-dynamics.blogspot.com/2010 ... r-osg.html

http://home.comcast.net/~tom_forsyth/pa ... e_opt.html

[Beherith]

I tried it with the version available at the time of posting, and the code didnt save the texture names in the optimized s3o

It was 24 bytes smaller than upspring optimized, with no change in frate rate at 500 units. The unit had 2.5k tris.

[Muon]

Didn't save the texture names? Huh? What version of Python are you using? Could you give me a hex dump of the header or send the S3O to me?

[Beherith]

2.6.4

[Muon]

Is that the original or the optimized? If it's the optimized, I can read the texture paths just fine.

[Beherith]

Its the original

[Muon]

Huh, it works fine on mine (Windows, Python 2.7), albeit, with a size change of 0 bytes. Did you get the latest latest latest version? Also, was the size change on the borked one +24 bytes or -24 bytes? At least try reinstalling Python or update to 2.7.

[Beherith]

-24 bytes

[Muon]

Yeees, and get the latest version. If it's still borked, upgrade to Python 2.7. Please let me know whether to declare 2.6 off-limits

[Muon]

UPDATE: added the blessed vertex cache optimizer.

Good news: my optimizer reduces the ACMR of your meshes from an average of 3.0 (yes, you read that correctly, every vertex incurs a cache miss) to between ~0.8 and ~1.2.

Bad news: except on certain meshes, the performance change is minimal (+2 to +5 FPS on the average model) even with these heavy optimizations (again, Sandy Bridge graphics, so it might be more important with more bling and an actual GPU), so all of this doesn't mean too much until Spring's renderer is fixed.

[Beherith]

Cool beans, I tested it again, and this time it worked fine. I have yet to performance test the results, but will do so once I get back to main pc.

[FLOZi]

edit: i am a moron

[Beherith]

So 500 BAR core t2 jammers (ones by mr bob, 2.5k tris each) are 21 FPS with upspring optimized models, and 25 fps with your vertex cache optimized ones. Excellent work! Especially considering its so easy to use, every modder should try it.

[KingRaptor]

When run on the Zero-K models, this tool appears to have flipped empty pieces along the Z-axis on a few models. I do not know if there is a common pattern.

Most obvious on Krow (unitname corcrw - turrets aim in the opposite direction to target) and Dante (unitname dante - missiles fire backwards; flamethrower FX is backwards).

Do you happen to know what the cause might be?

[yuritch]

Same happened to S44 models - tracers fly backwards after optimizing. Not sure if it affected all empty pieces or not though.

[Beherith]

How does one even flip an empty piece along z axis? The only info stored in s3o is the offset position, not the offset angle.

[FLOZi]

They often aren't empty but 2 or 4 vertices, and vertex order defines direction.

[Kloot]

One does not.

However, many models have "pseudo-empty" pieces (with only one or two vertices) that are used as effect-emission points, and their direction is determined by the order in which the vertices are specified. Such pieces should not be touched by the optimizer.

[Beherith]

Cool, I didnt know any of this. How exactly is this emission vector defined?

Is it take two vertices, and the vector drawn by vert1->vert2 will be the emission direction?

What methods do you use to create such pieces?

[smoth]

However, many models have "pseudo-empty" pieces (with only one or two vertices) that are used as effect-emission points, and their direction is determined by the order in which the vertices are specified. Such pieces should not be touched by the optimizer.

I do this, thanks for looking out for this.