T3D Camera collision with the Terrain
by JezPop · in Torque Game Engine · 04/26/2010 (11:14 am) · 6 replies
Can someone please tell me how i can get the flymode/overhead or any other camera to collide with the terrain in T3D!!
I have scoured the forums but everything seems to be tucked away in the private forums - seemingly indicating that changes to the code are necessary to acheive this oO.
The camera operations are the fundamental operations necessary in evaluation of this product. Since the documentation is still a WIP, the forums should at least expose some basic information to aid the evaluation process.
I note the TSStatic camera has the option to add a collision mesh to it in the world editor, can this be acheived with the stock camera? If so, how?
I am so far enjoying the evaluation process but this issue is seriously affecting productivity and hence my intended requirement analysis report.
So any info on this matter would be greatly appreciated.
I have scoured the forums but everything seems to be tucked away in the private forums - seemingly indicating that changes to the code are necessary to acheive this oO.
The camera operations are the fundamental operations necessary in evaluation of this product. Since the documentation is still a WIP, the forums should at least expose some basic information to aid the evaluation process.
I note the TSStatic camera has the option to add a collision mesh to it in the world editor, can this be acheived with the stock camera? If so, how?
I am so far enjoying the evaluation process but this issue is seriously affecting productivity and hence my intended requirement analysis report.
So any info on this matter would be greatly appreciated.
About the author
#2
I also understand the gravity of having access to engines code, but it seems at the moment that this product is rather like being given a car with a good engine but no steering wheel !
The script should by rights be able to access and change the basic functions needed for games developement, yet it seems that this cannot be done with the most basic of objects - ie the camera. It seems it was in one flavour of the engine once (the script reference has onCollision and castray functions and i dont know if this is obsolete or not now) and i know its possible to create a timer in script instead of using the objects onTick event, which i am guessing is the equivalent of Direct X's onFramemove/onFrameRender events and then to throw the castray oncollision methods into the timer.
So i am at a place now of whether or not to recommend a corporate licence to my clients, and so far i am 50/50. If the basics stay in the engine for further releases this will always affect version control and portability issues, from the snippets of code in the forums i can see that the engine has gone through substantial rewrites instead of using the OO methodology of re-use code, and this has obviously had an impact on the script aswell as the documentation and support.
With all that said i can't get away from the fact that this is a robust, fully accessible and fully editable engine that has a full range of products, tools and genre kits already very well established.
I have time to wait to evaluate the next release so i think that is what i should do.
04/27/2010 (5:58 am)
Thank you Ivan, i understand the various techniques of collision, and in the script reference there are such methods as onCollision() and castRay. So at some point it was actually accessible via script.I also understand the gravity of having access to engines code, but it seems at the moment that this product is rather like being given a car with a good engine but no steering wheel !
The script should by rights be able to access and change the basic functions needed for games developement, yet it seems that this cannot be done with the most basic of objects - ie the camera. It seems it was in one flavour of the engine once (the script reference has onCollision and castray functions and i dont know if this is obsolete or not now) and i know its possible to create a timer in script instead of using the objects onTick event, which i am guessing is the equivalent of Direct X's onFramemove/onFrameRender events and then to throw the castray oncollision methods into the timer.
So i am at a place now of whether or not to recommend a corporate licence to my clients, and so far i am 50/50. If the basics stay in the engine for further releases this will always affect version control and portability issues, from the snippets of code in the forums i can see that the engine has gone through substantial rewrites instead of using the OO methodology of re-use code, and this has obviously had an impact on the script aswell as the documentation and support.
With all that said i can't get away from the fact that this is a robust, fully accessible and fully editable engine that has a full range of products, tools and genre kits already very well established.
I have time to wait to evaluate the next release so i think that is what i should do.
#3
04/27/2010 (6:45 am)
Sorry to be unhelpful, but what's with all the T3D threads in the TGE forum?
#4
1) I put this thread here because its where the discussion of oldy worldy source code is and the discussion of its portability to other versions.
2) If TGE(A) is the standard base that T3D has come from i want to be able to view some source at least to evaluate the comparison of render methods and object/world transform methods with those of other engines, this is not possible in the T3D forums, and although its quite obvious that mostly all of these methods have changed over time, the basis of them hasn't and therefore gives me an evaluation starting point.
3)I didn't want my thread to be gobbled up in the private forums that i currently do not have access to.
If you think that maybe this would be more useful in the T3D public thread, or the TGEA thread then i will happily move it, and like the engines camera be under the terrain and not seen or replied to by anybody with any more useful facts than you need to buy it first.
EDIT: Sorry i didn't intend this comment to sound as harsh as it does! I understand the need for the private forum but it seems that the very basics of evaluation needs are being left out of the public forums.
04/27/2010 (10:15 am)
Not unhelpful at all:1) I put this thread here because its where the discussion of oldy worldy source code is and the discussion of its portability to other versions.
2) If TGE(A) is the standard base that T3D has come from i want to be able to view some source at least to evaluate the comparison of render methods and object/world transform methods with those of other engines, this is not possible in the T3D forums, and although its quite obvious that mostly all of these methods have changed over time, the basis of them hasn't and therefore gives me an evaluation starting point.
3)I didn't want my thread to be gobbled up in the private forums that i currently do not have access to.
If you think that maybe this would be more useful in the T3D public thread, or the TGEA thread then i will happily move it, and like the engines camera be under the terrain and not seen or replied to by anybody with any more useful facts than you need to buy it first.
EDIT: Sorry i didn't intend this comment to sound as harsh as it does! I understand the need for the private forum but it seems that the very basics of evaluation needs are being left out of the public forums.
#5
As for the problem at hand-
You could use some analogue to onTick (I'm not sure whether that's a T3D thing; I've only heard it fabled :P) or a repeating schedule to call castRay every fraction of a second and implement camera collision - but that's frankly a hack and a waste of performance.
[There are creative ways to get around it - maybe attach your camera to a FlyingVehicle - but they're less worthy of consideration than just writing your camera logic with schedule and castRay :P.]
04/27/2010 (5:34 pm)
Didn't sound harsh at all! If anything, I should be apologising. I guess it's the instinctive nitpicker in me :P. It's possible you may get more responses in the T3D forum, but I really don't know what the traffic is like there.As for the problem at hand-
Quote:It seems it was in one flavour of the engine once (the script reference has onCollision and castray functions and i dont know if this is obsolete or not now)Those things are still fully implemented and useful, but scripting was never meant to be used for instant-to-instant object logic like collision. Scripts are for event management, primarily - for example, in onCollision you would typically apply damage to a falling object or do some other thing that happens when the object hits another object. However, onCollision isn't called frequently enough to be used for collision response with any sort of accuracy or elegance.
You could use some analogue to onTick (I'm not sure whether that's a T3D thing; I've only heard it fabled :P) or a repeating schedule to call castRay every fraction of a second and implement camera collision - but that's frankly a hack and a waste of performance.
Quote:The script should by rights be able to access and change the basic functions needed for games developement, yet it seems that this cannot be done with the most basic of objects - ie the camera.Torque was, it seems to me, designed as a source product. If you needed a specific type of camera in your game, you could fairly easily do it yourself - but it wasn't really GG's job to create a bunch of different camera types to cover many eventualities (which, in any case, may still not be exactly what you want for your game). Now with the advent of no-source T3D, people are finding limitations in what you can do with scripting.
[There are creative ways to get around it - maybe attach your camera to a FlyingVehicle - but they're less worthy of consideration than just writing your camera logic with schedule and castRay :P.]
#6
I understand the need for a full source base for a game engine, and as you said a no source T3D has limitations. I wouldn't like to see T3D be a scripted only engine i think that would ruin its reliability and its flexibility which at the moment is one of its great strengths.
Its whether or not this approach can fit into the needs of a rapid development environment, will it be easier to change code and methods and all of the code walking that would be involved or to have a greater script base to work from?
I guess that for some of us the requirement would to be to have a more expansive script to code access capability so perhaps it wasn't so limited. However not being totally clear on the architecture involved or the impact on performance that the script could have its impossible for me to comment much further on how this could be acheived :)
Anyway thanks for taking the time to read and reply to my ramblings, even if it is in the wrong forum. :P
04/27/2010 (11:59 pm)
Thanks for the reply Daniel. :)I understand the need for a full source base for a game engine, and as you said a no source T3D has limitations. I wouldn't like to see T3D be a scripted only engine i think that would ruin its reliability and its flexibility which at the moment is one of its great strengths.
Its whether or not this approach can fit into the needs of a rapid development environment, will it be easier to change code and methods and all of the code walking that would be involved or to have a greater script base to work from?
I guess that for some of us the requirement would to be to have a more expansive script to code access capability so perhaps it wasn't so limited. However not being totally clear on the architecture involved or the impact on performance that the script could have its impossible for me to comment much further on how this could be acheived :)
Anyway thanks for taking the time to read and reply to my ramblings, even if it is in the wrong forum. :P
Torque Owner Ivan Mandzhukov
Liman3D
The first one is so create a logic for constraining the terrain.
Ray-casting is commonly used.
The second one is to implement an AABB collision ,based on a velocity vector.
You are right - you need the source code.