Triangle strip indices order?
by Chris Calef · in Torque 3D Professional · 11/24/2010 (3:00 pm) · 41 replies
Hi, just a random question after bashing my head against the problem for most of the day yesterday... I'm writing an FBX exporter for dts models, and have (mostly) succeeded at exporting the skeleton and animation frames, but when I came to the meshes, in particular triangle strip meshes (I haven't tried all triangles yet) I found that I really have no idea how the indices work.
I thought I did, and my solution starts to look like it should be working, but it isn't:
What I'm doing is starting with the first three indices, making a triangle out of them, and then for each new one, making a triangle out of it plus the last two. I'm going in the same order every time. My problem looks like possibly the winding order is not supposed to be the same every time... but I'm not sure that's it, because on closer examination it also looks like it's trying to make triangles between verts that shouldn't be part of the same triangle at all (i.e. edges going across the middle inside the barrel).
This makes me wonder if there is another list somewhere or more information stored somewhere, that should be telling me how these indices actually are supposed to go together to form triangles?
Of course, now that I've publicly admitted confusion on the matter, I'll probably solve the problem in the next ten minutes, but in case that doesn't happen I'd be wildly grateful if anyone here could help me figure this out.
Cheers!
Chris
I thought I did, and my solution starts to look like it should be working, but it isn't:
What I'm doing is starting with the first three indices, making a triangle out of them, and then for each new one, making a triangle out of it plus the last two. I'm going in the same order every time. My problem looks like possibly the winding order is not supposed to be the same every time... but I'm not sure that's it, because on closer examination it also looks like it's trying to make triangles between verts that shouldn't be part of the same triangle at all (i.e. edges going across the middle inside the barrel).
This makes me wonder if there is another list somewhere or more information stored somewhere, that should be telling me how these indices actually are supposed to go together to form triangles?
Of course, now that I've publicly admitted confusion on the matter, I'll probably solve the problem in the next ten minutes, but in case that doesn't happen I'd be wildly grateful if anyone here could help me figure this out.
Cheers!
Chris
About the author
#2
Edit: No, that's stupid.. sorry. All you need to do is for the second triangle, you reverse the last two vertices of the first triangle I think.
11/24/2010 (4:04 pm)
Chris, instead of doing it in the order you describe (1-2-3-4) see if listing the vertices in the 1-2-4-3 order solves the problem. It should have the same winding for both triangles that way.Edit: No, that's stupid.. sorry. All you need to do is for the second triangle, you reverse the last two vertices of the first triangle I think.
#3
11/24/2010 (4:22 pm)
And... yup! Case resolved. In case anyone ever has the same problem: triangle strips in Torque at least are wound alternately.
#4
Thanks for the reply!
11/24/2010 (4:25 pm)
Ha ha, beat me by a minute Konrad! You're right, it goes opposite for the second triangle - what I'm doing is: for k=2 to indices.size, check k%2 and in one case run (k-2, k-1, k), other case run (k, k-1, k-2).Thanks for the reply!
#5
11/24/2010 (4:28 pm)
No problem, glad to see you got it working! :) The exporter sounds really nice. I wonder how hard an importer would be to make.. :)
#6
Finding FBX quite a pleasure to work with actually - big learning curve, but lots and _lots_ of useful functions in the API. I think we may be leaning Ecstasy pretty hard this way in the near future...
11/24/2010 (4:36 pm)
Oh, I don't think it will be that much harder... don't worry, Jon is already all over me about it, haven't even got the exporter working yet ;-) but I'm sure it will happen too. Finding FBX quite a pleasure to work with actually - big learning curve, but lots and _lots_ of useful functions in the API. I think we may be leaning Ecstasy pretty hard this way in the near future...
#7
Sounds like a really good way to make it available to a larger audience.
11/24/2010 (5:05 pm)
Quote:
I think we may be leaning Ecstasy pretty hard this way in the near future...
Sounds like a really good way to make it available to a larger audience.
#8
11/24/2010 (5:10 pm)
Yeah, at least exporting to FBX has been part of the plan for a long time... but when I saw how much work it can do (like import/export from collada) I started thinking I should use it more internally as well. It's going to get a whole rollout with just FBX functions on it pretty soon.
#9
I've gone through hell working on models, placing nodes, scaling, LODing, adding collision meshes and calculating lighting for a second uv only to realize later that they needed something tweaked, and it's just hell to go through that pipeline sometimes (alas, part of which are our own tools, and these are the ones that are giving most headaches, but we can't afford to license maya or max at this time, so we use Milkshape - which has a terrible support for dae). But if FBX (which turned out to be what collada always wanted to be) could be used things would become significantly simpler.
Perhaps you should consider releasing this as a separate addon to the engine(s) as well. Everyone needs this. :)
11/24/2010 (5:44 pm)
That is awesome! Are you planning to support a second (or multiple) UV maps? To put it better - are you looking to support the features in the latest DTS version, or rather those that are available through dae import? I've gone through hell working on models, placing nodes, scaling, LODing, adding collision meshes and calculating lighting for a second uv only to realize later that they needed something tweaked, and it's just hell to go through that pipeline sometimes (alas, part of which are our own tools, and these are the ones that are giving most headaches, but we can't afford to license maya or max at this time, so we use Milkshape - which has a terrible support for dae). But if FBX (which turned out to be what collada always wanted to be) could be used things would become significantly simpler.
Perhaps you should consider releasing this as a separate addon to the engine(s) as well. Everyone needs this. :)
#10
11/24/2010 (6:57 pm)
Well, damn, back up against a linker error I narrowly dodged a couple of days ago... seems like a naming collision or something, between fbx and something else already linked to my build. Odd, since it's called kFbxClassId, doesn't seem likely to collide with anything native to anyone else... have to test it against stock T3D build I guess.
#11
[€]nevermind, jon told me...
11/24/2010 (9:30 pm)
hey chris, outta curiosity, what maps that in the background ?[€]nevermind, jon told me...
#12
Here are some visuals:
11/26/2010 (8:22 pm)
Well, the battle continues, thought I'd post a couple screenies of current status so nobody thinks I'm slacking over the holiday... I narrowly sidestepped the linker error again (gulp!) and then finally got my material created and attached to my mesh, with all associated layer elements, etc., but am now having a tvert meltdown - it seems like they should just work (scale of 0.0 to 1.0, right?) but while they appear to be close, it seems like I'm indexing them wrong or something. Here are some visuals:
#14
11/26/2010 (10:42 pm)
Congrats! Awesome!
#15
Now, on to weighted skeletons...
Incidentally, can you tell me more about how people use the secondary UV maps in Torque? Is that how you're doing your cliff pack / Sahara stuff?
I'm a little confused, because I'm finding data in the tvert2 field of my VertexData array, even on simple shapes like the barrel and the box above, which I would assume would have no use for multiple maps. Not sure if it's just irrelevant garbage or if it actually means something.
11/26/2010 (11:22 pm)
Thanks Konrad! Now, on to weighted skeletons...
Incidentally, can you tell me more about how people use the secondary UV maps in Torque? Is that how you're doing your cliff pack / Sahara stuff?
I'm a little confused, because I'm finding data in the tvert2 field of my VertexData array, even on simple shapes like the barrel and the box above, which I would assume would have no use for multiple maps. Not sure if it's just irrelevant garbage or if it actually means something.
#16
Besides supporting a second UV map, you might also want to pull in vertex color information, as that is used with forest shapes to control wind motion.
I don't think I have the tools needed to create an FBX that is good enough to test with, but if there's anything I can help you with, please let me know.
Also, that backdrop level looks amazing!
11/26/2010 (11:34 pm)
We use the second UV map for tone maps made with pureLight. There are actually other uses in Torque 3D for a second UV map, but I can't recall which texture maps make use of it. Sahara is a texture projection and works on the shader level, so it uses the UV map that the diffuse map uses (that is, the first).Besides supporting a second UV map, you might also want to pull in vertex color information, as that is used with forest shapes to control wind motion.
I don't think I have the tools needed to create an FBX that is good enough to test with, but if there's anything I can help you with, please let me know.
Also, that backdrop level looks amazing!
#17
I don't know what's going on with the tvert2 values on the models I'm playing with here - they both have tvert2 numbers, both fairly reasonable looking numbers, not float garbage, but they go in a range from around -1.0 to 1.0 (actually slightly outside that range, oddly, to +/-1.02 or so) instead of 0.0 to 1.0. Ignoring them for now, but... wtf??
Good to know about vert colors being used in Torque, though, easy to find where to put them in FBX.
Re: the backdrop level, heh heh, can't claim credit for that - it's actually a demo map for a certain Engine Which Shall Not Be Named In These Forums... but which does happen to import FBX natively. ;-)
11/27/2010 (12:12 am)
Hmm, thanks for the info. I don't know what's going on with the tvert2 values on the models I'm playing with here - they both have tvert2 numbers, both fairly reasonable looking numbers, not float garbage, but they go in a range from around -1.0 to 1.0 (actually slightly outside that range, oddly, to +/-1.02 or so) instead of 0.0 to 1.0. Ignoring them for now, but... wtf??
Good to know about vert colors being used in Torque, though, easy to find where to put them in FBX.
Re: the backdrop level, heh heh, can't claim credit for that - it's actually a demo map for a certain Engine Which Shall Not Be Named In These Forums... but which does happen to import FBX natively. ;-)
#18
Oh well.. it still looks really nice.
Not China Town nice of course, but still very nice. From this angle. I don't know about the others.
:)
11/27/2010 (12:25 am)
Quote:it's actually a demo map for a certain Engine Which Shall Not Be Named In These Forums... but which does happen to import FBX natively. ;-)
Oh well.. it still looks really nice.
Not China Town nice of course, but still very nice. From this angle. I don't know about the others.
:)
#19
So we're getting something beyond revision 139 Real Soon Now™? Babies have been "released" in shorter time!
11/27/2010 (12:47 am)
You'll know those light & sound symbols from a minute with the engine in question ;)So we're getting something beyond revision 139 Real Soon Now™? Babies have been "released" in shorter time!
#20
Things are actually so different now that I'm considering starting a new repo, to avoid stomping on people's existing work - if they've been able to get any serious work done with the rev. 139 version. In any event, expect a major announcement soon, and thanks for your patience!!
11/27/2010 (1:53 am)
@Ronny: Yes, progress is coming, sorry for the long wait! Although to be fair, this "baby" pretty much had to change "mothers" twice since last April, in addition to rewriting its underlying DNA on the fly... hope you like it!Things are actually so different now that I'm considering starting a new repo, to avoid stomping on people's existing work - if they've been able to get any serious work done with the rev. 139 version. In any event, expect a major announcement soon, and thanks for your patience!!
Associate Chris Calef
BrokeAss Games
Still, I'm doubling my tris... will try alternating next.