Working on Terrain Manager class...

#1 Thought I'd update this thread with the current results. (questions above still apply! haven't gotten to those areas yet)

I took the plunge and unlinked the TerrainBlock from the SceneObject hierarchy. It turned out to be not so bad.. :)

The collision stuff has been a nightmare, it took a good 2 hours to track down where the engine was getting the TerrainBlock pointer instead of the TerrainManager pointer. It turns out that when you call buildConvex(), it stores a pointer to the TerrainBlock in the convex structure. *sigh*

So what's the status?

It works! I have two separate TerrainBlocks rendering, and can switch the collision detection between them.

Up next:
- Make collision work on both terrains at the same time. (need to figgure out how the TerrainConvex works and why it won't allow two blocks at the same time)
- Make raycasting not wrap.
- Adjust the coordinates so terrains are 'next to' each other instead of 'on top of' each other.

I'll post a screenshot this evening, although it doesn't look like much right now. How do I enter 'fly mode' in game? It would be a lot faster than having to walk to the edge of the world :)

--Bryan

#2 You can get to "fly mode" by hitting Alt C. Nice to hear you are making such great progress!. I believe someone else on the forum found out how to remove terrain wrapping. It didn't work for waterblocks for some reason and I think it didn't remove all invisible collisions. It should be a start though. If I can find the thread I'll post it for you.

#3 Hey Bryan,

Good to see you're making progress with this... brave man :)

I know you've already detached TerrainBlock from the SceneObject tree, but after thinking about it a bit, I think it might be easier overall to leave it as a scene object. That way, terrain blocks can just be declared in the mission as they currently are (you don't need to specify all the terrian info for files, etc, in the TerrainManager). You could just add a field that specifies where in the TerrainManager array the block should fit.

This way, the entire TerrainBlock list would ghost over to the clients, etc, and the block position would just determine the transform position for the terrain object. It should then fit right into the collision database as-is. The only real responsibility for the TerrainManager class would be to stitch up rendering for the terrain. If the TerrainManager class is set to ghost always, and it exists in the mission before all the terrain blocks, then the terrains on the server or client onAdd can simply check for the existance of the terrain manager object (which on the server could be marked by name, and on the client could be passed the ghost id in the ghosting process). If there's no TerrainManager object, then the terrain just renders as it currently does - infinitely repeating, and adds itself to the contianer with a huge BB.

#4 David,

Thanks for the fly-mode key :) And I did see the thread on stopping the wrapping collision, but I don't recall it having any code. I'll take a look at it again.

Mark,

Thanks for responding. I came to a similar conclusion when I was trying to figgure out how to load multiple terrain files, right now I'm just specifying "terrianFile1" and "terrainFile2" in the TerrainManager block. I'll probably add back the SceneObject attribute and use your suggestion to get everyone talking to one-another.

As for collision... if each TerrainBlock is a SceneObject, and their bounding box is strictly around the TerrainBlock, will the collision work as-is? (still have to fix rayCasting, I assume)

It 'feels' like the TerrainConvex needs to be modified. I'm calling buildConvex() for both terrains, but only one would collide properly. I'm still lost in the collision code... :(

Rendering is the easy part, I can definitely clean up the render code a lot and fix it up for larger terrains, but that'll be a second pass.

--Bryan

#5 Hmmm... actually, the buildConvex function as well as the castRayI function would have to be modified so that they don't wrap around.

The reason the terrain convexes might only be returning the list from the last block could be the call to sTerrainConvexList.collectGarbage() at the top of the TerrainBlock::buildConvex funtion. Looks like that code was set up to only handle a single terrain block collision. Probably would work to have it just not do that in the case of a multi-block collision. I'm not sure though... Tim was the one who did all the convex collision stuff.

#6 Mark,

While I still have your attention.. Are the coordinates in start & end sent to the castRay() function ALWAYS within the bounds of the SceneObject box?

ie: If you perform a scene castRay from the top of a mountain across several terrain blocks to someone on a distant slope.. will the castRay() of the TerrainBlock be called multiple times, each with a separate chord? Or just one call with the super-long ray?

Thanks,
--Bryan

#7 I promised a screenshot.. this one's not too bad:

EDIT: Removed pic.
www.fractalscape.org/TorqueTerrain

On the right is Stronghold, and on the left is WaterWorld.

--Bryan

#8 Nice Bryan,

I am standing in the sidelines watching your progress as the terrain was something I was going to tackle in the near future.

Good Luck.

p.s. Interesting web-site you have.

#9 Melv,

Thanks, although I must say your fluid rendering is way beyond my abilities :) Bravo!

I just got collision working on both terrains. So it looks like an alpha-testable version should be coming along next week..

Next Up:
- DataBlocks like Mark was suggesting
- Clean up the mess & document the manager

--Bryan

#10 Naw,

The stuff I did on fluid rendering hasn't been exactly rocket science. I've simply exposed existing functionality and hopefully guided it in the right direction.

Although alot of people certainly appreciate it, and I appreciate their support greatly, personally I don't think I've done anything 'serious' yet.

I'm working on stuff now that is certainly my own and hopefully will blow peoples' socks off, being useful is always a bonus as well! :)

Keep up the good work.

#11 Update...

I'm now adding support for NxM grids of terrain, and repeating the NxM grid infinitely. This should give a baseline implementation which also falls back to single terrain tiling (NxM = 1x1) for the default case.

Mark's suggestion works perfectly, so you can now specify TerrainBlocks like normal in the mission file. I'll add an interface later to define where these blocks exist in the NxM grid.

Works with rendering and castRay, but not collision (it's late, I'm going to bed).

Lighting only works for main terrain, and editor is completely untested, but I'm pleased with it so far. :)

More to come..
--Bryan

#12 Well done Bryan.

Keep going man ... you're on a roll!

#13 Alright, here it is. TerrainManager class (alpha version).

If anyone has the time to test this class more in-depth, please let me know. I have only enough time to add features and make sure they work on a once-through.

Up next:
- Fix rendering around edges.
- Finalize datablock interface (expose NxM matrix coordinates, and eliminate TerrainBlock 'position' var).
- Any feature requests?

Hope you like it!
--Bryan

www.fractalscape.org/TorqueTerrain
www.fractalscape.org/TorqueTerrainManager.zip

#14 woot! Way to go Bryan...

Some more thoughts about the TerrainManager: lighting.

Right now the lightmap for the terrain wraps, with the texel centers in the lightmap corresponding to the vertices in the terrain mesh (for a 256x256 lightmap, it can go up from there). So basically if you have a 256x256 terrain block and a 256x256 lightmap, the 0,0 coordinate in the lmap corresponds to the 0,0 grid position and same for the 255x255. However, for this to work without seams across different terrain blocks, you'll probably want the lightmap texture to stretch from 0,0 to 256,256 (257 verts for 256 texels). You could either do this by manually filtering a 257x257 texture for the lighting - probably the easiest - or you could change the terrain lighter to properly generate a non-wrapping 256x256 texture. Then you just have to make sure that the texel rows/columns between terrain blocks match perfectly.

Does this make sense?

Another thing... large water volumes... maybe you and Melv can hook up to get the liquids properly coexisting with the TerrainManager - so we can have huge oceans, etc. That would be sweet :)

#15 I think I follow you on the lightmap. However, the terrain already has seams at texture borders, do you think the lightmap seam will be any worse? Un-wrapping the lightmap is on my to-do list.

If I go for removing seams, I'll probably do it for the terrain textures too (ala www.fractalscape.org/TextureSeams).

It feels like the tougher problem will be to get proper shadowing *across* terrain boundaries. ie: Tall mountain at edge of one terrain casts shadow across boundary to the plains on the other side.

I've not delved into the WaterBlock class yet, it seems to be getting confused with the TerrainManager. Once it is fixed, large water volumes should be pretty easy. :)

--Bryan

#16 Bryan,

From Monday onwards I will help you with any issues relating to the WaterBlock class.

Melv.

#17 Melv,

That would be great, it appears to be creating waterblocks under all the terrain (regardless of visibility). Probably some function I forgot to subclass in TerrainManager that the WaterBlock is expecting..?


Also, Build 2 is available (same file name) which fixes:
- Funky polygons at terrain corners.
- Mesh cracks along terrain boundaries.
- Datablock attributes for exposing the NxM terrain size.

Next Up:
- Fix lightmaps..?
- Fix rayCast across terrain border.

--Bryan

#18 Downloaded the latest Head version. Then extracted your latest changes over it. Added the TerrainManager.h and .cc files to my project in the terrains section of the Demo. When I compile I get the following errors.

terrRender2.cc
C:\torque\engine\terrain\terrRender2.cc(47) : error C2039: 'MaterialGroups' : is not a member of 'TerrainBlock'
../engine\terrain/terrData.h(90) : see declaration of 'TerrainBlock'
C:\torque\engine\terrain\terrRender2.cc(47) : error C2065: 'MaterialGroups' : undeclared identifier
C:\torque\engine\terrain\terrRender2.cc(47) : error C2057: expected constant expression
C:\torque\engine\terrain\terrRender2.cc(47) : error C2466: cannot allocate an array of constant size 0
C:\torque\engine\terrain\terrRender2.cc(48) : error C2039: 'MaterialGroups' : is not a member of 'TerrainBlock'
../engine\terrain/terrData.h(90) : see declaration of 'TerrainBlock'
C:\torque\engine\terrain\terrRender2.cc(48) : error C2057: expected constant expression
C:\torque\engine\terrain\terrRender2.cc(48) : error C2466: cannot allocate an array of constant size 0
C:\torque\engine\terrain\terrRender2.cc(327) : error C2039: 'MaterialGroups' : is not a member of 'TerrainBlock'
../engine\terrain/terrData.h(90) : see declaration of 'TerrainBlock'
C:\torque\engine\terrain\terrRender2.cc(377) : error C2039: 'BlockShift' : is not a member of 'TerrainBlock'
../engine\terrain/terrData.h(90) : see declaration of 'TerrainBlock'
C:\torque\engine\terrain\terrRender2.cc(377) : error C2065: 'BlockShift' : undeclared identifier
C:\torque\engine\terrain\terrRender2.cc(509) : error C2039: 'MaterialGroups' : is not a member of 'TerrainBlock'
../engine\terrain/terrData.h(90) : see declaration of 'TerrainBlock'

#19 David,

Sorry! Forgot to add that to the docs. Just delete TerrRender2.cc from your project.

I'll #if it out in the next build.

--Bryan

#20 Bryan,

My home PC decided to die this weekend and so I'm going to have to spend my time reinstalling it! Fortunately, I've got a laptop so I can at least get to the forums.

It looks like it's going to be a few days before I'm back online again and can help you with the waterblocks.

Darn it.