ChangeLevel & Alternative way to do terrain

[Jaguar_jwg]

Terrain
I used a large heightmap, and cut it up into 64x64 parts.
I then use GenSurf to create a .MAP file of each (512 surface brushes).
Next I open the .MAP files one by one in RF and fit them together, so that I have my large terrain.
I have six of these maps so far, and they compile and run fine. In about 30 seconds it’s compiled, and it runs fine (30-60 fps). To accomplish this I use an EnvironmentSetup entity, and enable UseFarClipPlane, (I have to say, that’s an amazingly brilliant feature in RF).

However, I’m concerned that using a larger area of terrain may affect the frame rate, especially on slower pcs. So, Is there another simpler way to use terrain in RF?

Change Level
I tested the ChangeLevel entity, and it worked. I know what I have to do to return to the previous level, but what do I need to do in order to return to the previous level, and find it as I left it. I believe I would have to save the level, but I am not sure. Appreciate any help.

[Jay]

The problem is not going to be the engine, but the level editor and its level compiler. The more brushes you have, the longer it will compile. Using actors can be a workaround, but it is not simpler (more work), because you have to cut the models into pieces which then act as seperate actors themselves. Otherwise performance is bad, because collision on staticmeshes is not that fast. But the upside of actors is that you can optimize them in your modelling program, cutting away lots of unused polys.

btw, how can a 64x64 bitmap produce only 512 surface brushes??? That's really low for that. Normally a 16x16 bitmap produces this amount of surface brushes...

You could however try to seperate the collision from the rendering: You export as map and as some other format (if this is possible) that a modelling program can read. Then you could import it into the level editor, and then you flag all the brushes as 'Clip' brushes. This way they are not rendered, but provide the needed collision. While on the other side you do the rendering with the divided model of the terrain, used as actors. This is the fastest way to use terrains (the best speed from the engine) i know of, but it also requires the most work.

[Jaguar_jwg]

Could you go through that a bit slower, especially the last paragraph? Do I cut the model into pieces in a modeler, and then export each part, and make them actors? How small should I cut them?

OK
Export as .map or some other format that a modeling program can use. (I follow you so far)
Import it into the level editor. (The only import option I see in the level editor is 3dt. Do you mean I should convert the file back to a .map file and then open it in the editor?)
Flag all the brushes as ‘Clip’ brushes. (cool)
Do the rendering with the divided model of the terrain. (got ya)
I really want to try this, but I just need to understand those few questions I raised above.

Another thing, If the terrain has a steep slope at an angle of 85 degrees, would my player walk up it, or collide with it? Thanks

Oh! By the way, I used a heightmap 64x64 to create my brushes in gensurf with division of 16x16. I am not sure if it got smaller.

[Jay]

oh. i am sorry i wasn't that clear. But i will answer that questions now:

yes you cut it into pieces in your modeller. Divide it into 'sections' like you can imagine the countries on the world map (like you have 'The Swamp', 'The Hills', 'Mountainrange1', 'Mountainrange2' etc). This way the actors that are not seen are not rendered at all, giving you speed.
Then you export them seperately as actors and then get them all into RF as StaticMeshes. The predefined settings are good, but you might set UseFillColor to true, because this disables the Lighting which just causes problems on such big actors like terrains. Also it is faster.

I meant you export as both *.map and the format that a modelling program can use. But it is important that both exported files contain the same terrain model - or at least they should be almost the same in shape. Then you open the *.map file in the level editor and the other file in the modelling program where you then can cut the model into pieces. A good polycount for a 'piece' is about 800-1500 (from my expierience)

Try NemsTerrainGenerator (i hope it still exists, i haven't used it a while) because it can export to both *.map and *.dxf if i remember correctly.

[Jaguar_jwg]

Thanks. I'll study this some more and see if I can get it worked out.
How about the question on change level? Can you help me with that.

[Jaguar_jwg]

Thanks, Nems works fine.
I can perhaps get your suggestions work. The problem I am having though is exporting the terrain as a map file. It didn’t come out right, but I believe this is because the poly count was too high.
However, I realize that it doesn’t make a difference to the speed of the game as you said. It’s just the compilation. So I guess I can live with that for now. Cutting up models is more work than I want right now.

There is one thing I have a problem with, which I really would like to get sorted out on terrain.
I don’t want my player to climb slopes at angles of between 50 and 90 degrees. What’s the best method of preventing this, while allowing him to be able to jump down these slopes?

[Jay]

it doesn't make a clear difference, but it does. With actors you don't have lightmaps, which cuts down the polycount (everytime a new lightmap begins a new polygon starts), but because of that, you don't have the best lighting (or you bake it into the textures). However, the speed impat only becomes clear if you divide the model into parts like i said (you can save that for the final version, it's much work), and lower the polycount of the actor a bit to the point where it isn't noticed (milkshape has the directx mesh tools that can do that, any other poly reducer may also work, if you have lot's of flat space it really can make a difference!) because it clips the polygones that are not seen before they even have to be clipped by the driver.

With your other problem, in the EnvironmentSetup entity there are the entries SlideSlope and SlideSpeed:

SlideSlope - ranges from 0 - 1, defining the sliding angle from which on you will slide down the mountains. 1 is flat and 0 is 90 degrees (0 and 1 don't really make sense). I am not sure about your value, i think you have to try out.
SlideSpeed - the speed with which you will slide down. when you set it high enough, the player won't be able to climb the big montains.

[Jaguar_jwg]

I really would like to try this out. Only if it was as easy for me as it sounds. I tried - I exported the map as a 3ds, and tried using 3dsMax to go to work on it. But all those chunks..., and selecting polys of some go all the way from the bottom to the peak..., How do I cut these up to begin with...? If only it was as easy for me as it sounds... I really would like to try it.

Thanks for the info on the slopes.

[Jaguar_jwg]

I didn't get the slopes to work. I changed the slide parameters, but nothing happened.

[Voltare]

i like his original idea.......and i use nem's.....

[Jaguar_jwg]

I mean, my character still walks up mountains.

[Voltare]

is there not a way in which you could place an invisible bursh where you wanted them to stop at?I haven't done any terrain stuff in Rf for a good long while, but I seem to remember something like that......

[Jaguar_jwg]

Thats another alternative, but I wanted to avoid that, since I would have to place too many brushes, based on the shape of each mountain.

Back to clipping the terrain and using actors to render. I got my actor and my terrain, but I get an error when I use StaticMesh to get my actor in RF. What am I not doing right?

[Voltare]

i think you have to use staticentityproxy......

[Jay]

that cannot be it. The StaticMesh is working right.
maybe you just typed the filename wrong??? Look in the RealityFactory.log for more infos. The actor has to be in the media\actors\ folder in the rf folder.