Strange Collision effect
by Will O-Reagan · in Torque X 2D · 06/15/2007 (11:21 pm) · 8 replies
I'm expereincing a really odd collision circumstance. Basically, I have a group of two barrels, and a few buildings on either side of the barrels. All objects have the object type "structure". I have my character, who I am testing to march between the two buildings, and hopefully be intercepted by the "barrel/structure" objects. It seemed to work ok at first, but consistantly, since I just noticed it today, I'm experiencing the following behavior.
If I approach the barrels from "North" I get a perfectly good Collision.
If I approach the barrels from "South" my character walks through like nothing is there.
Its 100% reproducable, I can make a video if you like. It doesn't depend on velocity, or anything like that, its just a strange one way street effect.
If I approach the barrels from "North" I get a perfectly good Collision.
If I approach the barrels from "South" my character walks through like nothing is there.
Its 100% reproducable, I can make a video if you like. It doesn't depend on velocity, or anything like that, its just a strange one way street effect.
About the author
I have a degree in dramatic art, and literature, from UC Santa Barbara. I've worked for a few studios, also at Animax Ent in 2008, and some smaller studios. Currently studying Computer Science at CSU Channel Islands.
#2
06/16/2007 (12:10 pm)
Ok, I sent my collision effect/bug - entire project to both your emails.
#3
06/18/2007 (8:30 pm)
I'm seeing the same effect when moving up and down. It's a little hard to follow exactly what's going on, but part of the problem seems to be that the colliding object is mounted. The collisions should be processed on the object that's mounted to (the object whos velocity is being modified). Also, you'll probably want to use Clamp response, rather than Bounce, for things like characters and walls. Let me know if this makes sense in context or if I'm just misinterpreting the code.
#4
06/19/2007 (10:23 pm)
Thanks Thomas, this does make sense. I think you are pretty much on target for the mounting collision thing. The character isnt actually mounted to the object, but I think its creating the same basic effect. The character gets it's velocity from the "platform", and the platform in turn updates its position relative to the character. I thought having a aura type object to guide the character around would be useful, but in fact, in situations such as this it doesn't seem that great and in fact its really less intuitive and useful then it should be. I'm going to write some more clever code, as that was written quite a few months ago when i didn't really know anything. Unfortunately, I'm trying to also port the game to the 360 now, and low and behold it doesn't deploy properly. I get a blank screen before I have even loaded up the first world. At first I thought it was image sizes, but since resizing the images, it still doesn't deploy. Since the game is targeting the 360 as it's platform, I really want to see how it reacts inside the console. I guess its going to be a few weeks on the drawing board before i figure this whole scenario out... Maybe the next TorqueX build will help. Luckly I havn't quit my day job yet.
#5
A great number of video cards won't accept textures larger than 2048. Many won't accept textures larger than 1024. Many also won't accept textures that aren't exact powers of 2 in each dimension (256x1024, for example). This is a limitation of all hardware-accelerated 3D apps (such as games ;). I think you're well within your limit for the XBox as far as texture size, but I wanted to warn you in case you wanted to reach a reasonably broad range of PC players.
One thing to keep in mind is the resolution of the game on-screen. If you have more texels in your source image than there are pixels on the region of the screen it's drawn in, you're not actually gaining any detail. In fact, in many cases you can lose detail. For example, if the size your image is rendering at is between mip levels of the source texture (i.e. the graphics card has to sample from two different-sized versions of your source image which can result in a blurry effect on certain hardware). The opposite effect is if the texture isn't mip mapped and you downsample you get a nasty glittery effect when you move or rotate it certain ways.
An easy solution is to scale down source art in your painting app (photoshop or gimp or whatever) to the approximate pixel size you want it to be on-screen (or a power of 2 greater than that size.. within reason). That ensures that you have a chance to clean up your art at that res so as not to leave any guess-work to different graphics cards that may or may not agree on what the image should look like. It also ensures that you're not wasting any GPU memory, which is always a good thing to strive for.
06/20/2007 (3:05 am)
Oh yea, I meant to mention the image size thing, but forgot. I actually had to resize one of the images for it to even run on my machine (the size of the title background was causing an exception - would be a crash in a binary build). A great number of video cards won't accept textures larger than 2048. Many won't accept textures larger than 1024. Many also won't accept textures that aren't exact powers of 2 in each dimension (256x1024, for example). This is a limitation of all hardware-accelerated 3D apps (such as games ;). I think you're well within your limit for the XBox as far as texture size, but I wanted to warn you in case you wanted to reach a reasonably broad range of PC players.
One thing to keep in mind is the resolution of the game on-screen. If you have more texels in your source image than there are pixels on the region of the screen it's drawn in, you're not actually gaining any detail. In fact, in many cases you can lose detail. For example, if the size your image is rendering at is between mip levels of the source texture (i.e. the graphics card has to sample from two different-sized versions of your source image which can result in a blurry effect on certain hardware). The opposite effect is if the texture isn't mip mapped and you downsample you get a nasty glittery effect when you move or rotate it certain ways.
An easy solution is to scale down source art in your painting app (photoshop or gimp or whatever) to the approximate pixel size you want it to be on-screen (or a power of 2 greater than that size.. within reason). That ensures that you have a chance to clean up your art at that res so as not to leave any guess-work to different graphics cards that may or may not agree on what the image should look like. It also ensures that you're not wasting any GPU memory, which is always a good thing to strive for.
#6
I am shooting for the 360 though, hopefully those extra calculations and anti-aliasing and graphics doo-hookies they put in the system will clean up some of my garbage... ;)
06/21/2007 (9:50 pm)
Thanks for the suggestions Thomas, we non-artists need all the help we can get. I am shooting for the 360 though, hopefully those extra calculations and anti-aliasing and graphics doo-hookies they put in the system will clean up some of my garbage... ;)
#7
06/30/2007 (10:12 am)
I think it was process collions at rest.. the barrels are getting collisions now thanks thomas. I also resized all my images, and low and behold my project ports to the 360 (yay!). Thanks for your help!
#8
Good luck, Will. Post back if you have any more issues.
07/02/2007 (5:08 pm)
Great! I'm glad this is working. This one had me particularly concerned.Good luck, Will. Post back if you have any more issues.
Torque Owner Thomas Buscaglia