TCP Project - Terrain - Discussion
by Phil Carlisle · in Torque Game Engine · 02/14/2002 (3:30 pm) · 16 replies
Open discussion thread concerning terrain project.
Please contact David Myers to help out on this project.
Please contact David Myers to help out on this project.
About the author
Recent Threads
#2
What are the objectives of the Terrain Project?
Who all is currently working on this project?
I know personally I've played with the terrain code to little avail beyond "stretching" the terrain. I know I'd like to see the map area expanded, and be able to punch smaller holes in the terrain, but my experience terrain engines is all but non-existant. Could anyone offer any insight into the algorithms used for Torque's terrain generation?
03/13/2002 (3:46 am)
TCP - Terrain Discussion:What are the objectives of the Terrain Project?
Who all is currently working on this project?
I know personally I've played with the terrain code to little avail beyond "stretching" the terrain. I know I'd like to see the map area expanded, and be able to punch smaller holes in the terrain, but my experience terrain engines is all but non-existant. Could anyone offer any insight into the algorithms used for Torque's terrain generation?
#3
> Who all is currently working on this project?
Not that many people... David Myers from 21-6 was supposed to be heading up the Terrain TCP but he's stated he's too busy with Myr to head anything up... I dont know of anyone else who's gotten any results with terrain mods
> What are the objectives of the Terrain Project?
There are several different objects for the terrain as I see it, leading to four different terrain 'modes':
- Infinitely Repeated, Single Heightmap (what we have now)
- Non-repeated, single heightmap (for example, having an island map and not being able to swim out and find another island exactly the same farther out)
- Multiple Heightmaps, non-repeated (support for multiple 256x256 terrains put together seemlessly, preferrably with background loading, etc)
- Multiple Heightmaps, repeated - same as above just looping back around...
Adding support for this stuff, however, isn't the hard part... you have to consider how everything is handled by the engine. If you say a tree is at location 423.12,591.29,20.56 you would have to handle it within a certain reference frame... if there's a world origin (0.0,0.0,0.0) and everything extends from there, you should be fine... however if objects are managed in relation to the center of a given terrain block, coordinates would have to be fiddled with - things would just get weird... there's also added issues of editing the terrain (the current terrain editor is set up to only edit a single terrain block), recalculating the shadows is also done for a single block and tiled like the terrain is (which leads to rogue shadows when people have managed to stop the terrain from tiling infinitely)
It's just a huge undertaking, and unfortunately I haven't seen a whole lot of requests lately for people asking about the terrain which is a shame... so I never bothered starting hacking away at the code and looking for something a bit more glamourous to work on... but I'd be willing to do some work on it if there's people out there who still want big terrains *shrugs*
--noh
03/13/2002 (7:59 pm)
I too was looking at working on core terrain stuff, and while I'm still interested in it, the scope of what needs to be changed seems like too much for just me in my spare time...> Who all is currently working on this project?
Not that many people... David Myers from 21-6 was supposed to be heading up the Terrain TCP but he's stated he's too busy with Myr to head anything up... I dont know of anyone else who's gotten any results with terrain mods
> What are the objectives of the Terrain Project?
There are several different objects for the terrain as I see it, leading to four different terrain 'modes':
- Infinitely Repeated, Single Heightmap (what we have now)
- Non-repeated, single heightmap (for example, having an island map and not being able to swim out and find another island exactly the same farther out)
- Multiple Heightmaps, non-repeated (support for multiple 256x256 terrains put together seemlessly, preferrably with background loading, etc)
- Multiple Heightmaps, repeated - same as above just looping back around...
Adding support for this stuff, however, isn't the hard part... you have to consider how everything is handled by the engine. If you say a tree is at location 423.12,591.29,20.56 you would have to handle it within a certain reference frame... if there's a world origin (0.0,0.0,0.0) and everything extends from there, you should be fine... however if objects are managed in relation to the center of a given terrain block, coordinates would have to be fiddled with - things would just get weird... there's also added issues of editing the terrain (the current terrain editor is set up to only edit a single terrain block), recalculating the shadows is also done for a single block and tiled like the terrain is (which leads to rogue shadows when people have managed to stop the terrain from tiling infinitely)
It's just a huge undertaking, and unfortunately I haven't seen a whole lot of requests lately for people asking about the terrain which is a shame... so I never bothered starting hacking away at the code and looking for something a bit more glamourous to work on... but I'd be willing to do some work on it if there's people out there who still want big terrains *shrugs*
--noh
#4
You can also set the terrain's x, y, z position.
The only problem I'm having now is the Terrain::castRay function. It hits the phantom terrain. I've tried everything I know of to fix it.
There are some editor issues since the editors look for a specific terrain block named "Terrain." It would be better to add a terrain block selector to the editor gui, kind of like the terrain editor's attachTerrain function.
Right now I'm editing terrain with a hack. Every time I want to change a terrain block, I rename it to "Terrain." It works, but it would be nice to have something better.
So, if anyone is willing to help with the castRay problem, I'll post everything I've done.
03/13/2002 (11:45 pm)
I've got islands working. The terrain stops repeating, and you can't collide with phantom tiles.You can also set the terrain's x, y, z position.
The only problem I'm having now is the Terrain::castRay function. It hits the phantom terrain. I've tried everything I know of to fix it.
There are some editor issues since the editors look for a specific terrain block named "Terrain." It would be better to add a terrain block selector to the editor gui, kind of like the terrain editor's attachTerrain function.
Right now I'm editing terrain with a hack. Every time I want to change a terrain block, I rename it to "Terrain." It works, but it would be nice to have something better.
So, if anyone is willing to help with the castRay problem, I'll post everything I've done.
#5
I've read that some people were interested in larger terrains. I'm not really concerned with the size of the terrain, as much as how small of a section of terrain I can manipulate and how much of the terrain is rendered.
One of our area builders has voiced a desire to have more precision with the placement of buildings and the ability to put smaller holes in the terrain. I've notice looking at the mesh view that in order to decrease the size of the squares that can be referenced I exponentially increase the number of polys that the terrain uses, and terrain that is out of view is still rendered. I figure if I reduce the size of the squares then culling must be added to save poly's.
Chris Evans << If you are willing to share what you've accomplished so far I'd be happy to help you out. I haven't really studied the Terrain yet. I'm about to complete the project I am currently working on, and will be able to start working on Terrain, although I've got a whole list of lighting bugs being added to my todo list as I type...
03/19/2002 (1:38 pm)
nohbdy << Thank you for the feedback concerning different type of terrains. I was more interested in what the terrain project was trying to accomplish. I've read that some people were interested in larger terrains. I'm not really concerned with the size of the terrain, as much as how small of a section of terrain I can manipulate and how much of the terrain is rendered.
One of our area builders has voiced a desire to have more precision with the placement of buildings and the ability to put smaller holes in the terrain. I've notice looking at the mesh view that in order to decrease the size of the squares that can be referenced I exponentially increase the number of polys that the terrain uses, and terrain that is out of view is still rendered. I figure if I reduce the size of the squares then culling must be added to save poly's.
Chris Evans << If you are willing to share what you've accomplished so far I'd be happy to help you out. I haven't really studied the Terrain yet. I'm about to complete the project I am currently working on, and will be able to start working on Terrain, although I've got a whole list of lighting bugs being added to my todo list as I type...
#6
Anyway, I believe the terrain uses a grid type algorithm for vis culling. It'd be possible to increase the number of squares in the grid which would decrease the number of polys sent to the card that don't get rendered, but that would also increase the time it takes to determine visibility...
It would also be possible to increase/decrease the amount of tessellation in the terrain, but right now I believe everything is tessellated the same, or at least there's no easy way to specify an area be tessellated more than any other area.
As for having better control over building placement, I don't really know anything about that...
Anyway if you want small squares, you can reduce the amount of tesselation to compensate... Then the only thing you have to worry about is the extra time it takes to determine visibility... which may or may not even matter... depends on the bottleneck, really... and the exact algorithm that's used... I haven't really looked at it closely enough to tell you exactly how it works
Anyway... thats just what I think is true... dont take my word for it :) As for the Terrain core project - I really don't see anyone taking an active interest so unfortunately any changes you need to be done to the terrain will probably need to be done by you and your team, at least for now... oh well
-nohbdy
03/21/2002 (8:08 am)
Well to be honest, there's a lot of things that could be done... and there hasn't been anyone to step forward and say what really needs to be done. And from the looks of this forum there's not a whole lot of people that are interested in actually messing with the terrain right now. Not to mention the fact that different games have extremely different requirements for terrain.Anyway, I believe the terrain uses a grid type algorithm for vis culling. It'd be possible to increase the number of squares in the grid which would decrease the number of polys sent to the card that don't get rendered, but that would also increase the time it takes to determine visibility...
It would also be possible to increase/decrease the amount of tessellation in the terrain, but right now I believe everything is tessellated the same, or at least there's no easy way to specify an area be tessellated more than any other area.
As for having better control over building placement, I don't really know anything about that...
Anyway if you want small squares, you can reduce the amount of tesselation to compensate... Then the only thing you have to worry about is the extra time it takes to determine visibility... which may or may not even matter... depends on the bottleneck, really... and the exact algorithm that's used... I haven't really looked at it closely enough to tell you exactly how it works
Anyway... thats just what I think is true... dont take my word for it :) As for the Terrain core project - I really don't see anyone taking an active interest so unfortunately any changes you need to be done to the terrain will probably need to be done by you and your team, at least for now... oh well
-nohbdy
#7
Once I feel Torque is stable and properly functioning in its current basic state, then I will be more interested in exploring other options. For example, I would like to explore a paging system to bring in new terrains as you reach the boundaries of the current one. I would also like to have more local control of particular terrain squares; sort of an override on the general tesselation system at particular locations. And not just for the geometry, but also for the texturing (i.e., an override to allow fine detail texturing at particular spots but not necessarily everywhere.
BTW, in reference to the post above about more accuracy in interior placements, Torque can be very accurate. The world transform, scale, and rotation settings in the editor can be changed for very precise positioning. However, being able to change the size of the empty squares (which is another example of local override control) would greatly enhance the level designers work process.
But as I began saying, I'm most interested in understanding how Torque works and making Torque perform optimally in its current state. that doesn't mean I'm not dreaming about future possibilities :)
03/21/2002 (9:57 am)
I think there are a lot of ppl interested in the terrain for various purposes. Being relatively new to TGE, I'm still studying the terrain (and other areas of the engine) primarily to see what is working and what's not. Right now myself and several others are working on getting the terrain lighting working properly...this will be shared when done. Once I feel Torque is stable and properly functioning in its current basic state, then I will be more interested in exploring other options. For example, I would like to explore a paging system to bring in new terrains as you reach the boundaries of the current one. I would also like to have more local control of particular terrain squares; sort of an override on the general tesselation system at particular locations. And not just for the geometry, but also for the texturing (i.e., an override to allow fine detail texturing at particular spots but not necessarily everywhere.
BTW, in reference to the post above about more accuracy in interior placements, Torque can be very accurate. The world transform, scale, and rotation settings in the editor can be changed for very precise positioning. However, being able to change the size of the empty squares (which is another example of local override control) would greatly enhance the level designers work process.
But as I began saying, I'm most interested in understanding how Torque works and making Torque perform optimally in its current state. that doesn't mean I'm not dreaming about future possibilities :)
#8
If you're not going to be the one spearheading the effort to allow for resizing different portions of the terrain then tell him to figure it out himself or stop complaining!
You can use a .dif file to emulate terrain (in fact, it'd make it look more realistic with a cropping of rock or uneven terrain) and "seal off" the opening to look like a smaller hole is cut.
I'm not too enthusiastic about messing with terrain rendering or water rendering solely because my computer doesn't render them correctly to begin with. I am upgrading soon, so I might be able to work with it a bit.
03/21/2002 (10:21 am)
Make your level designer think outside the box...If you're not going to be the one spearheading the effort to allow for resizing different portions of the terrain then tell him to figure it out himself or stop complaining!
You can use a .dif file to emulate terrain (in fact, it'd make it look more realistic with a cropping of rock or uneven terrain) and "seal off" the opening to look like a smaller hole is cut.
I'm not too enthusiastic about messing with terrain rendering or water rendering solely because my computer doesn't render them correctly to begin with. I am upgrading soon, so I might be able to work with it a bit.
#9
IMHO the TCP is about looking to the future--and if the program and tools can be improved to enhance the level designers experience, and everyone agrees those improvements have high enough priority, then perhaps that becomes one of the TCP missions. If not, then it becomes the indy's sole mission.
03/21/2002 (10:50 am)
I don't think the TCP section is the place to tell level designers to "think outside the box". That would be in other forum areas where folks have to make do with what they have. IMHO the TCP is about looking to the future--and if the program and tools can be improved to enhance the level designers experience, and everyone agrees those improvements have high enough priority, then perhaps that becomes one of the TCP missions. If not, then it becomes the indy's sole mission.
#10
The reason I said what I said about not many people being interesting in messing with the terrain was simply because I haven't seen anything come of it.
The Torque Core Project, as I see it, is here so the community can work together to improve the engine. The keyword here being the community - the community is what will make (or break) GarageGames in the long run. If you and several others are working on getting something to work, and plan on releasing the work which would potentially be integrated back into the engine, why not release what you've already done already? There aren't many benefits that I see, for you or the community, to wait "until its done". Correct me if I'm wrong.
Maybe I'm just being a bit too idealistic or have been smoking the open-source 'peace-pipe' a little too much lately, but when I first read about the TCP forums I figured it was going to be a place where the more experienced Torque users could work together to improve upon the core parts of the engine - making it better for everyone. It's disappointing to find out that they haven't become anything like that. The only forums that have posts in them are Collision, UI, AI and this one. UI and Collision havent had posts in a month now, AI has a lot of posts, but it isn't exactly what I'd call a collaboration... and this forum's turning into my personal rant forum (j/k) :)
Anyway... the point I'm trying to make is share the wealth... unless there's a good reason not to, as in it's for a game and the feature is so super special that you think only YOUR game should have it. Whether it's terrain code or AI code or anything that could even remotely be the beginnings of something that could be re-integrated into the engine.. post it and let people know what you're doing... Otherwise you end up with duplicated work, incompatibilities, or buggy crap.. the more active these core projects become, the more people will learn about the engine and the more people will be motivated to make it better...
Oh well, I've typed enough... Just something I felt needed to be said... This doesn't have anything to do with you personally it's just a feeling I get from all the (or should I say 'both the') TCP threads.
-noh
03/21/2002 (1:03 pm)
"I think there are a lot of ppl interested in the terrain for various purposes. Being relatively new to TGE, I'm still studying the terrain (and other areas of the engine) primarily to see what is working and what's not. Right now myself and several others are working on getting the terrain lighting working properly...this will be shared when done."The reason I said what I said about not many people being interesting in messing with the terrain was simply because I haven't seen anything come of it.
The Torque Core Project, as I see it, is here so the community can work together to improve the engine. The keyword here being the community - the community is what will make (or break) GarageGames in the long run. If you and several others are working on getting something to work, and plan on releasing the work which would potentially be integrated back into the engine, why not release what you've already done already? There aren't many benefits that I see, for you or the community, to wait "until its done". Correct me if I'm wrong.
Maybe I'm just being a bit too idealistic or have been smoking the open-source 'peace-pipe' a little too much lately, but when I first read about the TCP forums I figured it was going to be a place where the more experienced Torque users could work together to improve upon the core parts of the engine - making it better for everyone. It's disappointing to find out that they haven't become anything like that. The only forums that have posts in them are Collision, UI, AI and this one. UI and Collision havent had posts in a month now, AI has a lot of posts, but it isn't exactly what I'd call a collaboration... and this forum's turning into my personal rant forum (j/k) :)
Anyway... the point I'm trying to make is share the wealth... unless there's a good reason not to, as in it's for a game and the feature is so super special that you think only YOUR game should have it. Whether it's terrain code or AI code or anything that could even remotely be the beginnings of something that could be re-integrated into the engine.. post it and let people know what you're doing... Otherwise you end up with duplicated work, incompatibilities, or buggy crap.. the more active these core projects become, the more people will learn about the engine and the more people will be motivated to make it better...
Oh well, I've typed enough... Just something I felt needed to be said... This doesn't have anything to do with you personally it's just a feeling I get from all the (or should I say 'both the') TCP threads.
-noh
#11
Give some ideas or resources, or live with it.
Just stating the problem won't make their level designers happy, so an alternative must be used.
I know I will not be worrying about terrain details, and don't really want to work on this part of the engine. Since I'm not going to want to put work in, but need work out... I'll have to make do with what I have.
Yeah, the ideal situation would be to bend the box to fix the shape but when we currently aren't bending the box or don't really want to bend it ourselves we're going to have to reform to fit to the box.
03/21/2002 (1:27 pm)
No... my point was:Give some ideas or resources, or live with it.
Just stating the problem won't make their level designers happy, so an alternative must be used.
I know I will not be worrying about terrain details, and don't really want to work on this part of the engine. Since I'm not going to want to put work in, but need work out... I'll have to make do with what I have.
Yeah, the ideal situation would be to bend the box to fix the shape but when we currently aren't bending the box or don't really want to bend it ourselves we're going to have to reform to fit to the box.
#12
I post regularly on fixes to the current engine; both for questions and solutions. The terrain lighting/shading issue that needs fixing is just my current mindbender and I will definitely be sharing it in the regular forums. I just didn't think that was the purpose of these TCP forums. Maybe I'm off-base on this. Give me your thoughts.
03/21/2002 (1:46 pm)
@nohbdyI post regularly on fixes to the current engine; both for questions and solutions. The terrain lighting/shading issue that needs fixing is just my current mindbender and I will definitely be sharing it in the regular forums. I just didn't think that was the purpose of these TCP forums. Maybe I'm off-base on this. Give me your thoughts.
#13
"Basically, the point of TCP is to organise otherwise seperate groups of people interested in a certain feature into organised units.
The idea is that these units SHOULD help give a better quality of addition, serve to speed up development and hopefully provide some internal QA"
My thoughts are that small things little mods aren't Torque Core Project stuff. Small 'fixes', hacks, cool little additions, new GUI controls... they all belong in the regular forums... If someone wants to use them in their projects, great... they're not things that everyone will need or even want
If you have a real bug fix for a problem that effects everyone... there's a Torque Core Project for Bugfixes that nobody's even touched yet... assuming it's a bug that's part of the core code.. something that effects everyone... then it belongs there..
When you start getting into the 'hot and heavy' stuff like Terrain modifications then it should fall under the umbrella of the Torque Core Project. Maybe I'm completely over-estimating how much code would actually need to be changed for your lighting fix since I'm not 100% sure what you're refering too :) But either way, a terrain fix like that would be useful to everyone. If it gets fixed, it should get tested thouroughly, and eventually merged into the official source tree. Click on the "Features" link on your left under Torque Engine Info... TCP should be about giving the community the chance to make everything listed there even better than it is now, whether it be terrain lighting or terrain streaming.
I know it shouldn't really matter whether or not it gets posted here or in the regular forums... but if these forums get used for stuff that should be in the regular forums, or the regular forums get used for stuff that should be in the TCP forums... what's the point in having all these extra forums? Not to mention all the extra stuff that gets posted in the forums that isn't related at all to any hard engine code...
It's possible you're right and I'm completely wrong about TCP... hell, in my opinion the original posts about how TCP is supposed to 'work' seem very counterproductive... proposing ideas... setting up a forum per proposal... a lot of administrative overhead that in my opinion is completely worthless. Just a forum for each one of the things listed on the "Features" page would be adequate (plus ones for other things that should be added to the engine that aren't there like AI... and the catch-all 'Other' forum)
Anyway, them's my thoughts... whether or not that's really how TCP works or what these forums are for I have absolutely no idea... I just think thats the way it SHOULD work ;)
-noh
This stupid thing refuses to post... grr...
03/21/2002 (8:11 pm)
To quote from Phil's post in the Torque Core Project::Getting Started::The purpose of TCP thread:"Basically, the point of TCP is to organise otherwise seperate groups of people interested in a certain feature into organised units.
The idea is that these units SHOULD help give a better quality of addition, serve to speed up development and hopefully provide some internal QA"
My thoughts are that small things little mods aren't Torque Core Project stuff. Small 'fixes', hacks, cool little additions, new GUI controls... they all belong in the regular forums... If someone wants to use them in their projects, great... they're not things that everyone will need or even want
If you have a real bug fix for a problem that effects everyone... there's a Torque Core Project for Bugfixes that nobody's even touched yet... assuming it's a bug that's part of the core code.. something that effects everyone... then it belongs there..
When you start getting into the 'hot and heavy' stuff like Terrain modifications then it should fall under the umbrella of the Torque Core Project. Maybe I'm completely over-estimating how much code would actually need to be changed for your lighting fix since I'm not 100% sure what you're refering too :) But either way, a terrain fix like that would be useful to everyone. If it gets fixed, it should get tested thouroughly, and eventually merged into the official source tree. Click on the "Features" link on your left under Torque Engine Info... TCP should be about giving the community the chance to make everything listed there even better than it is now, whether it be terrain lighting or terrain streaming.
I know it shouldn't really matter whether or not it gets posted here or in the regular forums... but if these forums get used for stuff that should be in the regular forums, or the regular forums get used for stuff that should be in the TCP forums... what's the point in having all these extra forums? Not to mention all the extra stuff that gets posted in the forums that isn't related at all to any hard engine code...
It's possible you're right and I'm completely wrong about TCP... hell, in my opinion the original posts about how TCP is supposed to 'work' seem very counterproductive... proposing ideas... setting up a forum per proposal... a lot of administrative overhead that in my opinion is completely worthless. Just a forum for each one of the things listed on the "Features" page would be adequate (plus ones for other things that should be added to the engine that aren't there like AI... and the catch-all 'Other' forum)
Anyway, them's my thoughts... whether or not that's really how TCP works or what these forums are for I have absolutely no idea... I just think thats the way it SHOULD work ;)
-noh
This stupid thing refuses to post... grr...
#14
Terrain is one of these things. Its going to need a group of people, working in conjunction (not against each other) to fix it.
Unfortunately, it looks like we are in a sticky situation with this. There are very few people who have the main key skills:
1) Knowledge of the problem area
2) Knowledge of the torque implementation
3) Skills to alter the solution
I think if we can get 1 or 2 key players in on any given project, then others WILL join and help out.
But someone (other than me) has to step up for these things to get underway. Its clear there are enough people who WANT change, but not enough to actually DO the change.
I know i tend to be idealistic, but I'd hoped that some guys like Melv May or whoever would jump up and take over one of the projects.
As it is, I'm taking on the AI project, mainly because its my chosen field of research for the next 2 years, and also, because I know a guy who's already worked a LOT on the subject and is happy for me to port and extend his work.
Maybe once we get the AI stuff in. People will understand the TCP idea more. The AI will not solely be me, but I'll get a good skeleton setup for others to add meat to the bones.
Phil.
03/30/2002 (6:13 am)
nohbdy: your absolutely right. The idea of the TCP is to optimize the amount of work done by people by essentially not getting them to do ALL the same things at the same time. If people discuss the problems (in the discussion forum) then declare thier intentions. I hoped it would lead to a few people ganging together to chew on a large scale issue.Terrain is one of these things. Its going to need a group of people, working in conjunction (not against each other) to fix it.
Unfortunately, it looks like we are in a sticky situation with this. There are very few people who have the main key skills:
1) Knowledge of the problem area
2) Knowledge of the torque implementation
3) Skills to alter the solution
I think if we can get 1 or 2 key players in on any given project, then others WILL join and help out.
But someone (other than me) has to step up for these things to get underway. Its clear there are enough people who WANT change, but not enough to actually DO the change.
I know i tend to be idealistic, but I'd hoped that some guys like Melv May or whoever would jump up and take over one of the projects.
As it is, I'm taking on the AI project, mainly because its my chosen field of research for the next 2 years, and also, because I know a guy who's already worked a LOT on the subject and is happy for me to port and extend his work.
Maybe once we get the AI stuff in. People will understand the TCP idea more. The AI will not solely be me, but I'll get a good skeleton setup for others to add meat to the bones.
Phil.
#15
So far I've read:
1) Expand mission area.
2) Punch smaller holes.
3) Modes of operation (repeat/non-repeat), single/many terrain blocks.
4) Fix terrain editor for multiple terrains
5) Fix lightmaps for multiple terrains
The TerrainManager thread:
www.garagegames.com/index.php?sec=mg&mod=forums&page=result.thread&qt=4474
I have a pretty solid handle on the terrain engine in the areas of rendering, tessellation, and API. Still missing in-depth knowledge of visibility, collision, lighting and water.
Melv has said he will fix the WaterBlocks, and I'm about to go work on the lightmap code.
Project status:
#1 - Done.
#2 - I know how this can be done easily, but no clue how to expose this functionality to scripting.
#3 - Support exists, but it isn't exposed to scripting.
#4 - TBD
#5 - TBD
--Bryan
04/14/2002 (1:17 pm)
It looks like I've kinda taken the first steps here with the TerrainManager. So I figgure this is a good place to track features that people want from Torque's terrain engine.So far I've read:
1) Expand mission area.
2) Punch smaller holes.
3) Modes of operation (repeat/non-repeat), single/many terrain blocks.
4) Fix terrain editor for multiple terrains
5) Fix lightmaps for multiple terrains
The TerrainManager thread:
www.garagegames.com/index.php?sec=mg&mod=forums&page=result.thread&qt=4474
I have a pretty solid handle on the terrain engine in the areas of rendering, tessellation, and API. Still missing in-depth knowledge of visibility, collision, lighting and water.
Melv has said he will fix the WaterBlocks, and I'm about to go work on the lightmap code.
Project status:
#1 - Done.
#2 - I know how this can be done easily, but no clue how to expose this functionality to scripting.
#3 - Support exists, but it isn't exposed to scripting.
#4 - TBD
#5 - TBD
--Bryan
#16
It would be like cookie-cutting holes into the terrain. It might not be the best solution, but it's probably the easiest.
There was a thread a LONG time ago explaining how to do this, but it didn't work for me. It would stop the collision in random areas, and different areas for the client and server. For the server the player could collide with a certain block, but for the client the player would fall through that same block. It caused the player to fall and warp back up over and over again.
I'll see if I can find the thread...
*Edit: Here it is...
garagegames.com/index.php?sec=mg&mod=forums&page=result.thread&qt=1695
When I posted my reply to that thread I thought his code would just empty the tile like it normally does. I didn't realize what it was supposed to do until later.
*Edit: I just tried it again, it still doesn't work. Now that I think about it, I'm not sure if this method even WILL work. It only calculates whether or not to show the terrain in an interior while someone is looking at it, right? So, if you were staring at the sky and running around, wouldn't you be able to collide with that section of terrain since it's not calculating whether or not to show it?
Maybe I'm wrong, probably am :) I'll go look at that section of the code since I don't have anything better to do.
04/14/2002 (1:51 pm)
You can set whether or not to render the terrain inside interiors. If you use that code, you can probably stop the collision inside interiors.It would be like cookie-cutting holes into the terrain. It might not be the best solution, but it's probably the easiest.
There was a thread a LONG time ago explaining how to do this, but it didn't work for me. It would stop the collision in random areas, and different areas for the client and server. For the server the player could collide with a certain block, but for the client the player would fall through that same block. It caused the player to fall and warp back up over and over again.
I'll see if I can find the thread...
*Edit: Here it is...
garagegames.com/index.php?sec=mg&mod=forums&page=result.thread&qt=1695
When I posted my reply to that thread I thought his code would just empty the tile like it normally does. I didn't realize what it was supposed to do until later.
*Edit: I just tried it again, it still doesn't work. Now that I think about it, I'm not sure if this method even WILL work. It only calculates whether or not to show the terrain in an interior while someone is looking at it, right? So, if you were staring at the sky and running around, wouldn't you be able to collide with that section of terrain since it's not calculating whether or not to show it?
Maybe I'm wrong, probably am :) I'll go look at that section of the code since I don't have anything better to do.
Torque 3D Owner Marco Meier
Slickware Games
Anyone done this?