Player shadow rendering problem in TLK 1.4
by Phoenix Online Studios · in Torque Game Engine · 03/21/2006 (9:16 am) · 13 replies
I hope this one is easy to fix...
All our character models are equipped with collision meshes (because we need to be able to detect mouse clicks on them) but this causes the shadows cast by them to be cast from the (invisible) collision meshes instead of from the visible models. While it's nice with some form of shadow, it would be awesome if we can have collision meshes but still the detailed shadows of our characters, rather than the kind of "blob" we get right now... I don't know if this is just a matter of exporting settings or setting up the character datablock incorrectly, or if it would actually require some engine modification to work. Anyone knows how to fix this?
All our character models are equipped with collision meshes (because we need to be able to detect mouse clicks on them) but this causes the shadows cast by them to be cast from the (invisible) collision meshes instead of from the visible models. While it's nice with some form of shadow, it would be awesome if we can have collision meshes but still the detailed shadows of our characters, rather than the kind of "blob" we get right now... I don't know if this is just a matter of exporting settings or setting up the character datablock incorrectly, or if it would actually require some engine modification to work. Anyone knows how to fix this?
#2
I'm at GDC this week, so I can't easily check code.
Do I understand correctly that the dynamic shadow (the one also visible in stock TGE) uses the collision meshes if they're available?
I know thats the the effect you're going for, but it is neat and I can see other applications for this (hmmm...).
Anyway, I can't check anything until I get back, but I wanted to get a little more info.
-John
03/21/2006 (11:06 am)
Hi guys,I'm at GDC this week, so I can't easily check code.
Do I understand correctly that the dynamic shadow (the one also visible in stock TGE) uses the collision meshes if they're available?
I know thats the the effect you're going for, but it is neat and I can see other applications for this (hmmm...).
Anyway, I can't check anything until I get back, but I wanted to get a little more info.
-John
#3
Just my 2 cents.
03/21/2006 (12:58 pm)
Maybe you can use an invisible and very simple DTS, mounted at the players, for detecting the clicks... This way you would also get the default detailed shadows for them.Just my 2 cents.
#5
As I said, we need the player shadows to act as if there was no collision mesh on the model... Before attempting to modify the build, the plan is to do some tests to see if we can fix it by exporting the models differently. I have no idea if it would make sense, but one thought is that maybe giving a lower detail level to the collision mesh should work. The plan is to try that and see what happens in any case.
03/22/2006 (2:35 pm)
Yes, the dynamic shadow uses the collision mesh, not the player mesh. I'd have to check to be 100% sure but I think this happens regardless if you're using stock Torque or any of the Lighting Pack versions...As I said, we need the player shadows to act as if there was no collision mesh on the model... Before attempting to modify the build, the plan is to do some tests to see if we can fix it by exporting the models differently. I have no idea if it would make sense, but one thought is that maybe giving a lower detail level to the collision mesh should work. The plan is to try that and see what happens in any case.
#6
IIRCC, I have never applied a collision mesh during player model creation... I think it uses the bounding box as its collision... That in turn is divided up into sections for hit detection in various areas by %.
So, I guess im saying, why did you apply a collision mesh to your player? Removing it would solve your problem.
03/23/2006 (8:10 am)
I didn't think you needed a Collision mesh for the player... as its class has a form of collision zones type thingy.IIRCC, I have never applied a collision mesh during player model creation... I think it uses the bounding box as its collision... That in turn is divided up into sections for hit detection in various areas by %.
So, I guess im saying, why did you apply a collision mesh to your player? Removing it would solve your problem.
#7
03/25/2006 (12:43 pm)
Well, we're developing a mouse-controlled game, and we need somewhat detailed detection of clicks on aiplayers. A bounding box is not good enough because it includes too much space outside of the character models. The click detection we have actually works only on the part of the collision mesh attached to the character model that is inside the bounding box. It cannot detect clicks directly on regular meshes.
#8
I know it will endup concave and "invalid" but it will still work for colision, you will just have holes in with colision dosnt work.
Your other option may be to use LOScolision (its for caculation is projectiles hit somthing)... i dont beleave that the TLK see that type of colision box (dont quote me)... so it may do just what you want. I havent worked with this much.
03/25/2006 (1:34 pm)
Well, then i go back to my origional sugestion. Make your colision box directly from the players mesh.I know it will endup concave and "invalid" but it will still work for colision, you will just have holes in with colision dosnt work.
Your other option may be to use LOScolision (its for caculation is projectiles hit somthing)... i dont beleave that the TLK see that type of colision box (dont quote me)... so it may do just what you want. I havent worked with this much.
#9
It's weird because the collision boxes don't seem to be used for the shadow of other ShapeBase objects like vehicles.
-John
03/27/2006 (8:25 am)
Did you get a chance to see if this happens in stock TGE and TLK?It's weird because the collision boxes don't seem to be used for the shadow of other ShapeBase objects like vehicles.
-John
#10
Non-convex collision meshes are not an option because the mouse picking ray code doesn't work with them. :(
05/02/2006 (9:11 am)
We did some new testing the other day... What happens with TLK 1.4 (we have not touched the rendering code) when a character has no collision mesh is that a dynamic shadow (i.e. moving along with the animations) is cast, but when a collision mesh is exported along with the character, the shadow is the shadow of the collision mesh. The collision mesh is animated along with the character and so is that shadow as well.Non-convex collision meshes are not an option because the mouse picking ray code doesn't work with them. :(
#12
The mouse picking ray calculations need the collision meshes to be convex and interestingly work only for the portions of the collision meshes that at any given time are inside the collision box. If you click outside the collision box, the player object is obviously ignored as a potential object for the picking ray to collide with, even if the pose of the player actually makes him go outside the collision box.
I guess collision meshes weren't originally intended to be used together with players, so the shadow rendering code doesn't distinguish them from regular meshes, somehow chosing them in favor of the visible mesh.
05/05/2006 (8:55 am)
Just to clarify, the collision box (you see its boundaries highlighted when you select the player in the mission editor) is not to be confused with the collision meshes that we have attached to our players. The collision box, which is what player collisions against terrain, other collision meshes etc. is calculated against, does not cause any shadows. It is the collision meshes we attach to players, just like you would to regular .dts shapes, that override the shadows that would otherwise use the visible player mesh.The mouse picking ray calculations need the collision meshes to be convex and interestingly work only for the portions of the collision meshes that at any given time are inside the collision box. If you click outside the collision box, the player object is obviously ignored as a potential object for the picking ray to collide with, even if the pose of the player actually makes him go outside the collision box.
I guess collision meshes weren't originally intended to be used together with players, so the shadow rendering code doesn't distinguish them from regular meshes, somehow chosing them in favor of the visible mesh.
#13
What's preventing me from testing right now is that I don't have a player model with collision meshes, can you send over a player that is showing this problem (it doesn't need to be the same player, just a player DTS that has the problem and its datablock definition, basically enough to get it running in a test environment here)?
05/05/2006 (11:43 am)
What doesn't make sense is that the Player class uses the ShapeBase renderShadow method (it doesn't override this method), so the shadow code is the same and the behavior should be the same.What's preventing me from testing right now is that I don't have a player model with collision meshes, can you send over a player that is showing this problem (it doesn't need to be the same player, just a player DTS that has the problem and its datablock definition, basically enough to get it running in a test environment here)?
Torque Owner AllynMcelrath
Solution #1: Created your colision "box" from a copy of your players mesh.
Solution #2: i dont know...