The wonders of converting 3do mods to s3o

[Beherith]

How did you do the conversion between them? Am I doing it rong?

[smoth]

I didn't convert, I just made a new s3o. I don't convert my old 3dos I just set the model to the new s3o.

[Beherith]

So if its using the same script, would you mind sending me the 3do and the s3o so I could see what my conversion script is doing wrong?

[smoth]

Iirc you have acess to the grts svn. Try the rgm79(g), that one should be an easy test for you

[Beherith]

Thanks for the help, now 3do to s3o conversion works just right. I did run into something very strange in the process:

I couldn't, for the life of me figure out why my s3os crashed upspring if I had models with tristrips. I tried both strips and fans, both crashed upspring (correct vertice orders were verified with a manual .obj conversion).
Oddly, spring loaded these s3os, but didn't render them properly, see picture. It did, however, seem to render pentagons right, it failed on quads and hexagons.

This is highly non optimal, and may result in us pushing many times the triangles required; since piece shares primitive size to all primitives in piece, any piece with a single more than 4 sided face will be split into individual triangles by upspring.





Notice how the fourth point of quads is placed into the piece origin (0,0,0).


The engine's 3do loading code handles this correctly, because each primitive has its own vertexcount, while s3o uses a shared vertexcount per piece.

Code: Select all

	for (ps = o3->prims.begin(); ps != o3->prims.end(); ps++) {
		C3DOTextureHandler::UnitTexture* tex = ps->texture;

		if (ps->numVertex == 4) {
			va->AddVertexTN(o3->vertices[ps->vertices[0]].pos, tex->xstart, tex->ystart, ps->normals[0]);
			va->AddVertexTN(o3->vertices[ps->vertices[1]].pos, tex->xend,   tex->ystart, ps->normals[1]);
			va->AddVertexTN(o3->vertices[ps->vertices[2]].pos, tex->xend,   tex->yend,   ps->normals[2]);
			va->AddVertexTN(o3->vertices[ps->vertices[3]].pos, tex->xstart, tex->yend,   ps->normals[3]);
		} else if (ps->numVertex == 3) {
			va2->AddVertexTN(o3->vertices[ps->vertices[0]].pos, tex->xstart, tex->ystart, ps->normals[0]);
			va2->AddVertexTN(o3->vertices[ps->vertices[1]].pos, tex->xend,   tex->ystart, ps->normals[1]);
			va2->AddVertexTN(o3->vertices[ps->vertices[2]].pos, tex->xend,   tex->yend,   ps->normals[2]);
		} else {
			glNormal3f(ps->normal.x, ps->normal.y, ps->normal.z);
			glBegin(GL_TRIANGLE_FAN);
			glTexCoord2f(tex->xstart, tex->ystart);

			for (std::vector<int>::const_iterator fi = ps->vertices.begin(); fi != ps->vertices.end(); fi++) {
				const float3& t = o3->vertices[(*fi)].pos;

				glNormalf3(ps->normal);
				glVertex3f(t.x, t.y, t.z);
			}
			glEnd();
		}
	}

The engine's s3o code: (I only have a guess as to what is wrong with it)

Code: Select all

	for (int a = 0; a < fp->vertexTableSize; ++a) {
		int vertexDrawIdx = swabdword(*(int*) &buf[vertexTableOffset]);

		piece->vertexDrawOrder.push_back(vertexDrawIdx);
		vertexTableOffset += sizeof(int);

		// -1 == 0xFFFFFFFF (U)
		if (vertexDrawIdx == -1 && a != fp->vertexTableSize - 1) {
			// for triangle strips
			piece->vertexDrawOrder.push_back(vertexDrawIdx);

			vertexDrawIdx = swabdword(*(int*) &buf[vertexTableOffset]);
			piece->vertexDrawOrder.push_back(vertexDrawIdx);
		}
	}

Thank you for your attention. For anyone wishing to test this, i have attached the commander object to the bug report on mantis.

[Kloot]

Kindly do not double-post to give your own reports more exposure, you're not going to get anything fixed faster.

What's wrong with it is that strips are not linked together the right way (which happens to be a PITA). An easier solution is to store and draw each strip separately (which happens to be sitting in my local repo), and it'll get pushed in due time.

Meanwhile, if you have some other tri-stripped test models, those would be welcome.

[Beherith]

Sorry about double posting, you're right.

Would you like tri strips or tri fans? Both with the proper -1 strip terminators in the vertex index array?

Now that I have s3o parsing and writing 100% complete, I think it wouldn't be hard to write a script that converts the current s3o's to ones with proper tri strips.

Thank you for your attention on this matter!

[jK]

An easier solution is to store and draw each strip separately

http://www.opengl.org/registry/specs/NV ... estart.txt
It's supported by both gfx vendors since it is in OpenGL3.

[Kloot]

Hmm nice, that saves a few lines.

Would you like tri strips or tri fans? Both with the proper -1 strip terminators in the vertex index array?

Strips please, with -1 terminators.

By the way, your armcom model seems to use strips very inefficiently, which will not give you any speed advantage over plain triangles:

Code: Select all

piece: lthigh
    strip: 0 (6 vertices)
    strip: 1 (4 vertices)
    strip: 2 (4 vertices)
    strip: 3 (4 vertices)
    strip: 4 (4 vertices)
    strip: 5 (4 vertices)
    strip: 6 (4 vertices)
piece: rthigh
    strip: 0 (6 vertices)
    strip: 1 (4 vertices)
    strip: 2 (4 vertices)
    strip: 3 (4 vertices)
    strip: 4 (4 vertices)
    strip: 5 (4 vertices)
    strip: 6 (4 vertices)
piece: torso
    strip: 0 (4 vertices) 
    strip: 1 (4 vertices) 
    strip: 2 (4 vertices) 
    strip: 3 (4 vertices) 
    strip: 4 (4 vertices) 
    strip: 5 (5 vertices) 
    strip: 6 (4 vertices) 
    strip: 7 (4 vertices) 
    strip: 8 (4 vertices) 
    strip: 9 (4 vertices) 
    strip: 10 (4 vertices)
    strip: 11 (5 vertices)
    strip: 12 (4 vertices)
    strip: 13 (4 vertices)
    strip: 14 (4 vertices)
    strip: 15 (4 vertices)
    strip: 16 (4 vertices)
    strip: 17 (4 vertices)
    strip: 18 (4 vertices)
    strip: 19 (4 vertices)
    strip: 20 (4 vertices)
    strip: 21 (4 vertices)
    strip: 22 (4 vertices)
    strip: 23 (4 vertices)
    strip: 24 (4 vertices)
    strip: 25 (4 vertices)
    strip: 26 (4 vertices)
    strip: 27 (4 vertices)
piece: biggun
    strip: 0 (4 vertices)
    strip: 1 (4 vertices)
    strip: 2 (4 vertices)
    strip: 3 (4 vertices)
    strip: 4 (4 vertices)
    strip: 5 (4 vertices)
    strip: 6 (4 vertices)
    strip: 7 (4 vertices)
    strip: 8 (4 vertices)
    strip: 9 (4 vertices)
    strip: 10 (4 vertices)
    strip: 11 (4 vertices)
    strip: 12 (4 vertices)
    strip: 13 (4 vertices)
    strip: 14 (4 vertices)
    strip: 15 (4 vertices)
    strip: 16 (6 vertices)
    strip: 17 (4 vertices)
    strip: 18 (4 vertices)
    strip: 19 (4 vertices)
    strip: 20 (4 vertices)
    strip: 21 (4 vertices)
    strip: 22 (4 vertices)
    strip: 23 (4 vertices)
    strip: 24 (4 vertices)
piece: nanolath
    strip: 0 (4 vertices) 
    strip: 1 (4 vertices) 
    strip: 2 (4 vertices) 
    strip: 3 (4 vertices) 
    strip: 4 (4 vertices) 
    strip: 5 (4 vertices) 
    strip: 6 (4 vertices) 
    strip: 7 (4 vertices) 
    strip: 8 (4 vertices) 
    strip: 9 (4 vertices) 
    strip: 10 (6 vertices)
    strip: 11 (4 vertices)
    strip: 12 (4 vertices)
    strip: 13 (4 vertices)
    strip: 14 (4 vertices)
    strip: 15 (4 vertices)
    strip: 16 (4 vertices)
piece: head
    strip: 0 (4 vertices)
    strip: 1 (4 vertices)
    strip: 2 (4 vertices)
    strip: 3 (4 vertices)
    strip: 4 (4 vertices)
    strip: 5 (4 vertices)
    strip: 6 (4 vertices)
    strip: 7 (4 vertices)
    strip: 8 (4 vertices)
    strip: 9 (4 vertices)
    strip: 10 (4 vertices) 
    strip: 11 (4 vertices) 
    strip: 12 (4 vertices) 
    strip: 13 (4 vertices) 
    strip: 14 (4 vertices)
    strip: 15 (5 vertices)

Did you convert every face to its own strip?

Also, the strips themselves don't render correctly (neither with my own fix nor with jK's linked extension which produces identical results):

http://springrts.com/phpbb/download/fil ... ew&id=5132

Disabling culling only partially helps, so I think your script is still bugged (aside from the fact that it doesn't z-invert vertices):

http://springrts.com/phpbb/download/fil ... ew&id=5133

[Beherith]

This is just the generic arm com model, with each primitive converted into a tri strip. I dont think I can do a proper long tri strip without putting in 0 area triangles, since in s3os a vertex contains pos,uv and vnormal in one lump.

Ill look into the bad strips once im back at home again, since I recall them loading fine in wings 3d (obj conversions).

Is a tristrip of 4 vertices much less efficient than 2 triangles for a quad?

[Beherith]

Thanks Kloot! I got the latest build from git, and am gonna try to make tristripping work on my end too.

Here is some show of progress:
http://beherith.eat-peet.net/stuff/radarnormal.swf

Its 100% working, but still needs a bit of work on the looks.
Especially the shadows. I dont do double sided faces atm, and this results in pieces with holes having bad shadows

[Beherith]

I found a wonderful little program called CrazyBump, its the smartest and best looking bump map creator I have ever seen!

So progress on bump maps and proper specular maps is going along just fine:


Performance cost is negligible so far.

[jK]

I found a wonderful little program called CrazyBump, its the smartest and best looking bump map creator I have ever seen!

CrazyBump costs 99$ / 300$ (non-commercial / commercial)!
I prefer ShaderMap, it costs only 20$ and has even more functionality from what I know.

[Beherith]

Wow, thats quite expensive. Im using the 30 day trial atm, will look for other solutions once it expires.

Btw, jK, Im using your shader, and am loving it! Sorry about the newbie question, but does it give more functionality than normals? (because I saw a blue channel in EVOs texture2's)

[Pxtl]

Okay, the stamped/brushed tin runway is hilarious.

[Beherith]

Regular asphalt would melt under the awesome jet power of the peeper.

[FLOZi]

Did you try this out yet Behe? http://springrts.com/phpbb/viewtopic.php?f=9&t=24289

The guys on the forum I found out about it were saying they thought it was better than CrazyBump, and it's free.

[Beherith]

I started off with nDo, but the results were less than satisfactory. Its overly sensitive to noise, can't differentiate between high frequency noise and features. Crazybump has excellent feature detection, much easier to tweak, has batch support, and is way faster.

[jK]

Btw, jK, Im using your shader, and am loving it! Sorry about the newbie question, but does it give more functionality than normals? (because I saw a blue channel in EVOs texture2's)

It's a framework so you can give each unit its own shader if you want to (see S44's flag), so you can do what ever you want with the blue channel (ideas are: separate specular/reflection, detailmapping, ...).

[FLOZi]

Write an awesome animated track shader and I'll buy you a beer