T3D camera/terrain collsion
by JezPop · in Torque 3D Beginner · 04/27/2010 (11:10 am) · 4 replies
So Ok this a repeat post from the TGE forum (where i have been able to evaluate the base capabilities of the foundation of T3D) under advice i have been directed here so that i may get a more informative response.....
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 the intended productivity and hence my intended requirement analysis report.
So any info on this matter would be greatly appreciated.
::
replies have so far directed me to the fact that i need source code access, i believe this to be a shorfall in the engine since basic game objects such as the camera should be accessible via the torque script, and source code access should only be needed for this standard object if you wanted something else other than the stock fly/overhead/orbit modes that are employed in every game on the market.
So much of the engine has been rewritten instead of using OO methodology that there is no legacy support, hence the question of future releases and portability. Whats wrong with inheriting the stock camera and employing helper methods instead of changing the method names themselves?
Suffice to say there are problems with the internal and external exposure of the engine to the script at this point that cannot allow me to make a concrete decision on whether this is something i could recommend as fit for the pupose of my clients.
Although, don't get me wrong here. From what i have evaluated this engine has all the capabilities and then some of what i would advise as a foundation for game development, i would rate it highly as such. Although I cannot rate it at the same degree for what can be accomplished through the script for basic objects, that in other engines are accomplished easily.
I'm still sitting on the fence on this one..............
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 the intended productivity and hence my intended requirement analysis report.
So any info on this matter would be greatly appreciated.
::
replies have so far directed me to the fact that i need source code access, i believe this to be a shorfall in the engine since basic game objects such as the camera should be accessible via the torque script, and source code access should only be needed for this standard object if you wanted something else other than the stock fly/overhead/orbit modes that are employed in every game on the market.
So much of the engine has been rewritten instead of using OO methodology that there is no legacy support, hence the question of future releases and portability. Whats wrong with inheriting the stock camera and employing helper methods instead of changing the method names themselves?
Suffice to say there are problems with the internal and external exposure of the engine to the script at this point that cannot allow me to make a concrete decision on whether this is something i could recommend as fit for the pupose of my clients.
Although, don't get me wrong here. From what i have evaluated this engine has all the capabilities and then some of what i would advise as a foundation for game development, i would rate it highly as such. Although I cannot rate it at the same degree for what can be accomplished through the script for basic objects, that in other engines are accomplished easily.
I'm still sitting on the fence on this one..............
About the author
#2
As you point out, having the source access will bring you miles further, or just a good script reference (anybody have a link?). There has been a lot of talk lately by the GG folks of exposing more to script, and although useful, you can definitely over-do the exposure as script can be many times slower than a native c++ routine.
Also, if you have the source, exposing nearly any aspect of the engine is trivial.
05/03/2010 (9:44 am)
I'm sure you could write a function using a raycast to detect and prevent collision. Look for the script function containerRayCast(...) and it's uses. It would not be the best solution, by far, but could be made to work for the purposes of evaluation.As you point out, having the source access will bring you miles further, or just a good script reference (anybody have a link?). There has been a lot of talk lately by the GG folks of exposing more to script, and although useful, you can definitely over-do the exposure as script can be many times slower than a native c++ routine.
Also, if you have the source, exposing nearly any aspect of the engine is trivial.
#3
05/04/2010 (6:28 am)
Quote:There has been a lot of talk lately by the GG folks of exposing more to script, and although useful, you can definitely over-do the exposure as script can be many times slower than a native c++ routine.Exposure isn't all that's necessary - ideally we'd just be able to script far more with existing procedures - for example, the ability to turn camera collision on and off with a flag. Scripting doesn't need to take over more of the responsibility for game logic, it just needs to be able to change more meaningful and diverse things (if you don't have source access to get in there and do that yourself).
#4
...and i agree, the camera is pretty fundamental and the ability to enable/disable collision detection on the fly is something that should be available through the script using those existing procedures. I don't think i have yet seen a game which needs the camera to dissappear into the terrain in such a way o0..
05/04/2010 (4:55 pm)
Thanks for the bump Daniel :)...and i agree, the camera is pretty fundamental and the ability to enable/disable collision detection on the fly is something that should be available through the script using those existing procedures. I don't think i have yet seen a game which needs the camera to dissappear into the terrain in such a way o0..
Torque Owner Daniel Buckmaster
T3D Steering Committee