Re: The difficulties of converting 3do mods to s3o
Posted: 02 Nov 2010, 13:34
How did you do the conversion between them? Am I doing it rong?
Spring RTS Engine
Open Source Realtime Strategy Game Engine
https://springrts.com/phpbb/
The wonders of converting 3do mods to s3o
Page 2 of 3
Re: The difficulties of converting 3do mods to s3o
Posted: 02 Nov 2010, 14:26
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.
Re: The difficulties of converting 3do mods to s3o
Posted: 02 Nov 2010, 16:07
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?
Re: The difficulties of converting 3do mods to s3o
Posted: 02 Nov 2010, 19:22
Iirc you have acess to the grts svn. Try the rgm79(g), that one should be an easy test for you
Re: The difficulties of converting 3do mods to s3o
Posted: 09 Nov 2010, 10:31
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.
The engine's s3o code: (I only have a guess as to what is wrong with it)
Thank you for your attention. For anyone wishing to test this, i have attached the commander object to the bug report on mantis.
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();
}
}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);
}
}
Re: The difficulties of converting 3do mods to s3o
Posted: 09 Nov 2010, 14:45
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.
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.
Re: The difficulties of converting 3do mods to s3o
Posted: 09 Nov 2010, 15:25
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!
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!
Re: The difficulties of converting 3do mods to s3o
Posted: 09 Nov 2010, 17:11
http://www.opengl.org/registry/specs/NV ... estart.txtKloot wrote:An easier solution is to store and draw each strip separately
It's supported by both gfx vendors since it is in OpenGL3.
Re: The difficulties of converting 3do mods to s3o
Posted: 09 Nov 2010, 18:34
Hmm nice, that saves a few lines.
By the way, your armcom model seems to use strips very inefficiently, which will not give you any speed advantage over plain triangles:
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
Strips please, with -1 terminators.Beherith wrote: Would you like tri strips or tri fans? Both with the proper -1 strip terminators in the vertex index array?
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
Re: The difficulties of converting 3do mods to s3o
Posted: 09 Nov 2010, 19:06
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?
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?
Re: The difficulties of converting 3do mods to s3o
Posted: 21 Nov 2010, 13:13
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
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
Re: The difficulties of converting 3do mods to s3o
Posted: 22 Nov 2010, 13:22
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.
So progress on bump maps and proper specular maps is going along just fine:
Performance cost is negligible so far.
Re: The difficulties of converting 3do mods to s3o
Posted: 22 Nov 2010, 14:14
CrazyBump costs 99$ / 300$ (non-commercial / commercial)!Beherith wrote:I found a wonderful little program called CrazyBump, its the smartest and best looking bump map creator I have ever seen!
I prefer ShaderMap, it costs only 20$ and has even more functionality from what I know.
Re: The difficulties of converting 3do mods to s3o
Posted: 22 Nov 2010, 14:23
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)
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)
Re: The difficulties of converting 3do mods to s3o
Posted: 22 Nov 2010, 18:57
Okay, the stamped/brushed tin runway is hilarious.
Re: The difficulties of converting 3do mods to s3o
Posted: 22 Nov 2010, 19:08
Regular asphalt would melt under the awesome jet power of the peeper.
Re: The difficulties of converting 3do mods to s3o
Posted: 22 Nov 2010, 20:17
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.
The guys on the forum I found out about it were saying they thought it was better than CrazyBump, and it's free.
Re: The difficulties of converting 3do mods to s3o
Posted: 23 Nov 2010, 00:01
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.
Re: The difficulties of converting 3do mods to s3o
Posted: 23 Nov 2010, 05:22
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, ...).Beherith wrote: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)
Re: The difficulties of converting 3do mods to s3o
Posted: 23 Nov 2010, 05:32
Write an awesome animated track shader and I'll buy you a beer 