Game Development Community

dev|Pro Game Development Curriculum

Merry Christmas, Community - Poly Soup

by Kyle Carter · 12/24/2006 (5:03 pm) · 143 comments

Wow - almost three months since my last .plan. I guess I should write these things more often. What have I been up to? Nothing that's quite ready to be talked about in depth, but in brief: developing ways for us to do more releases at a higher quality and with bigger feature sets.

And probably some smaller stuff that I'll be posting about in coming months, too. :)

Speaking of smaller stuff, I took a few days about a month ago and extended 3space and TSStatic in TSE to support more flexible collision scenarios. Or to speak more directly, polysoup collision. I've collaborated on this with Tom Spilman, who spent some time debugging it, integrating it into a project, and cleaning it up a bit, and the end result is a polysoup implementation that seems fairly usable.

So, here's a screenshot of an orc on a concave donut:

farm1.static.flickr.com/85/272842689_bb8f17c445_m.jpg

Now, some caveats: this is just the result of a few day's hacking, not an official announcement of GG support for polysoup in Torque. So while it's pretty easy to integrate, you do have to have some coding knowledge to use it.

It's also not bullet proof. We use OpCode, so it's pretty fast & efficient, but if you expect to drop ten orc models into a level and not have a performance hit when you run a buggy into them, you'll have to think again. But if you want to build a building in DTS, and don't go overboard in your model complexity, you should do just fine.

Finally, it collides against ALL the meshes in your model, including invisible ones. So if you want a model to work for polysoup you probably want to kill all your Col-1 meshes & so forth for proper results. Adding some sort of filtering rule wouldn't be hard but it was unclear the best way to do that so we left it a bit braindead.

You can get this at its page on TDN, if you're a TSE owner. Remember, you're on your own using it!

I figure I can't very well give you hearty Christmas cheer this holiday, so I may as well post up something nice and useful. :)
#101
10/21/2007 (11:12 am)
@Bobby: I asked this same question above on (Sep 29, 2007 at 23:03) and I got some good answers, also above. You'll need to manually merge the polysoup code in, things have changed in TGEA.

@Eikon Games: I had this same problem and applied the little patch kindly supplied above by Joti Carroll (Jul 31, 2007 at 02:04). Now my players are colliding reasonably well.

You guys would both save yourselves a lot of time by reading all the posts before posting--you'd already be merrily polysouping along instead of reading my snarky comment.
#102
10/21/2007 (11:20 am)
@Lee

You are absolutely right. But (tries to get out of hole) I *did* think I'd read through all the comments. However, I must have missed that one :o(

Implemented that patch and works a treat. Thank you - without your 'snarky comment' I'd still be scratching my head!
#103
10/21/2007 (7:51 pm)
I did read it, and I knew that is the answer but i don't know how to do that. I see the differences between the files but understanding what it goes to is a different matter, could you not post the changes necessary or send me the files, I would be most grateful. I have never had trouble getting anything Torque related to build I'm not sure what I've done wrong, I used Win merge...maybe ill try again...
#104
10/22/2007 (3:57 pm)
@Eikon: I've gotten far, far too much help around here to be snarky for long :-)

@Bobby: Man, I just barely understand what I did with that, and I really have no business distributing it, I think, even if it does seem to work. Just use winmerge to get a diff between the files distributed in the polysoup resource and stock TGEA, and move the stuff that's in the polysoup resource into the TGEA versions. Feel free to email me if you have more trouble, and I'll send you what I've got.
#105
10/23/2007 (9:36 am)
Thanks I'm going to try it again, do you think their might be some sort of problem from the Atlas2 bump-mapping resource i added? other than that it was stock TGEA...Thanks ill send you an Email to let you know from here on out:)
#106
12/17/2007 (10:18 pm)
Thanks for the great resource! I am not a strong VC++ user and I was hoping for a little help. I am using this with TGE 1.5.2 and Visual Studio 2005. The Opcode solution is in my solution browser and I have experimented with adding the opcode and opcode/Release folders in the linker as well as adding Opcode.dll as a Refrence in the Torque Demo Properties, I continue to get this error starting:

13>------ Build started: Project: Torque Demo, Configuration: Release Win32 ------
13>Compiling...
13>tsSortedMesh.cc
13>..\engine\ts\tsSortedMesh.cc(57) : error C2065: 'tDiffuse' : undeclared identifier
13>..\engine\ts\tsSortedMesh.cc(57) : error C3861: 'getUVs': identifier not found

I have uploaded the buildLog here: www.soulsandsocks.com/BuildLog.htm

If anyways had any suggestions for me, I am all ears!

Thanks,

Kyle LeMaster
#107
12/19/2007 (11:14 pm)
@Kyle: I've hesitated to answer since I am a C++ novice myself, but since no one else has....I'm guessing that you've misapplied or left out one of the header files, presumeably tsSortedMesh.h, since tDiffuse was apparently not declared anywhere.
#108
12/26/2007 (9:49 pm)
I spent the past week attempting to hand merge the proper code with 1.0.3. Unfortunately, even though I was able to get it to compile, once in game it would crash or not collide or not even load. I was using WinMerge, but I had trouble with some of the differences in the code.
I did go through this thread and tested out all the fixes, but without success.

Anyway, if anyone has the correctly merged files or a compiled '.exe' for 1.0.3, would it be possible to email them to me? (I hope this isn't breeching forum etiquette...)

Thanks.

P.S. I did find out where that dastardly 'opcode.dll' was (c:\Program Files\Media)! If anyone needs a copy let me know.
#109
12/27/2007 (11:02 am)
@Kerry: You need to build the opcode.dll using the opcode code that comes with the resource. I suspect that is some different opcode.dll you found that is incompatible.

It's a separate build from the opcode/TGEA build.
#110
12/27/2007 (1:50 pm)
While we're talking about it, I'm trying to build polysoup in a TGE1.5 Linux dedicated server build (Fedora Core 4). The first error message I get is:
./game/tsStatic.h:73: error: ISO C++ forbids declaration of TSMesh with no type
#111
12/27/2007 (7:08 pm)
@Lee: Thanks for the reply. The opcode.dll is from the TGEA build. The directory is set to something like '../../../../media'. I didn't want to change it for fear of messing it up. The opcode.dll works (luckily). Today I merged the Polysoup into TGE 1.5.2 and got that working. So I think I'll stick with that until there's an update for TGEA.
And sorry, but I can't help with the Linux stuff. No experience there at all...
#112
12/29/2007 (6:38 pm)
Adding TSMesh.h to the includes at the top of tsStatic.h solved that problem, but building the opcode stuff is kicking my butt. I'm wondering if it's simply a matter of the right compiler options, since ODE uses a nearly identical verison of opcode and it compiles fine.

Currently I'm stuck at:
./opcode/./Ice/IceTypes.h:52: error: __int64 does not name a type

Although there is an error that does not stop compilation before that:
./opcode/OPC_IceHook.h:21:19: error: Math.h: No such file or directory

There is no "math.h" to be found, however.
#113
12/31/2007 (4:42 pm)
I've gotten past the __int64 problem (apparently) by defining it as with "-D _int64 = long long" as a compiler flag. But now it's getting really strange, I'm getting a bunch of syntax type errors from the Ice stuff (what is that stuff anyway?). I thought perhaps it wasn't GCC4 compatible, but the g++32 compatibility compiler gives the same messages. Here's the first one (of many similar):


./opcode/./Ice/IceTypes.h:126: error: expected `)' before * token
#114
01/02/2008 (10:19 pm)
Hi I checked it with

TGE 1.5.0 and
TGEA 1.0.3

both are giving runtime exceptions when I check the polysoup box.

any idea...

can anyone send me the code for TGEA 1.0.3 if i am doing wrong.
#115
01/02/2008 (10:53 pm)
At one time I had that happen, but it worked ok if I turned on the polysoup option directly in the mission file instead of the editor. Sorry, I know that's a stretch....in my current version it works fine.
#116
01/03/2008 (12:16 am)
can u pass the modified TGEA 1.0.3 files.
I can even cross check!!
#117
01/03/2008 (3:16 pm)
Well, I'm not gonna "pass" anything, but I'll send you the files. Contact me via email. See my profile.
(If you'd had your email addy in your profile, you'd have them already!)
#118
01/11/2008 (8:01 pm)
@Lee: Any chance you would email me the files as well? I've been working with the polysoup in TGE, but I would really like to take advantage of the shaders in TGEA 1.0.3. Thanks.

P.S. I downloaded and played your Singularity FPS game. I think the concept is fun and I enjoy the variety of vehicles and power ups. Nice work!
#119
01/11/2008 (8:44 pm)
@Kerry: Thanks, and they should be there now. Y'all feel free to contact me directly for this.

BTW the ICE library is apparently a completely Windows-only deal. I've found a port of it to Linux but it does crazy stuff like ifdef out assembler code and replace it with simple functions. Also a LOT of type definitions needs to be redone in a platform independent way. Although the Opcode lib itself doesn't seem too bad in that regard.

Definitely not a plug-n-play port by any stretch of the imagination. I'm going to feel so dirty renting a Windows server--and even worse potentially telling someone who wants to host my game that that's the only option. :-(
#120
01/11/2008 (9:34 pm)
Quote:BTW the ICE library is apparently a completely Windows-only deal.

This is not accurate. It's pretty straightforward to take the included OPCODE library and get it compiled on the Mac - it doesn't require a lot of changes. Instead of compiling as a linked library [which IIRC this resource is set up to do], try adding it to your project and linking to it statically.

I haven't tried it on Linux myself, but if it compiles on the Mac it should be fine on Linux too.