does terraform=client side?

[Nefilim offline]

You go Bytor!!! Go get em!

[Zear offline]

If terrains are too big, how about just sending the <mapname>_heightfield.cs and <mapname>_texture.cs info, and applying it to an existing terrain on the clientside? This data is relatively puny and (while you couldn't touch up the terrain) it would allow a nearly endless variety of terrains.

[Bytor offline]

This confuses me a bit Zear, what files are required in order to make a custom terrain? If the heighfield is all that's needed to shape the terrain, what's in the .ter file?

Can you use an existing .ter file but still modify the peaks and valleys by just changing the heightfield, and still have it be server-side? How about the textures? I think there is a map on my site that uses an existing terrain, but with lava texturing instead of lush, or whatever the original was.

[Zear offline]

When you save the terrain in the editor, the contents of the heightfield and texture files are integrated. Those two files are intended for during terrain creation only. But if you save those files and not the terrain, the changes are reapplied when it is loaded.

Now I have not tried loading those files on the client while connected to a server, but I suspect they will be ignored by the client. On top of that, the changes may not reproduce exactly. But I think they may be plenty close for govt work.

If those files can be loaded and used by a client connected to a server, then we could write a simple client side script that would allow a server to pass that info to the client during map load. If the client ignores them, we just need to have Dynamix alter the client to allow it. No real danger that I can see.

That make sense? The server has the unmodified terrain and the two files. When a client joins it loads the unmodified terrain and then the server passes the changes to the client where they are applied and the two systems maps should match.

Even the randomly generated terrains should be close enough if the seed is the same (and it is in those files). I think it would work with very little overhead. Think of doing a diff, like RTPatch...

[Bytor offline]

[t-b0n3 offline]

Those files control the fractal seeds and things necessary to create a landscape, and how to apply texturing to them. Since these should generate the same on whatever machine they are run from, they should work... that is, if there was support for them...

Of course, you couldn't make any fine adjustments (Raise one part of land, or lower another), but for mappers who want to make really outrageous terain, it technically could make it Server Side...

At least, that's *my* limited understanding of the whole thing....

[Zear offline]

t-b0n3:

You are right, there would not be any fine tuning allowed. You could do what you want in the heightfield and texture editors, but you would still have to leave the terraformer alone except for making or closing holes.

However, you can do a lot of very cool terrain work with just that, even some very subtle stuf - you just have to regen the fractal terrain a lot of times to get what you want. But it is possible to make some very nice landforms with rather detailed texturing.

Bytor:

The heightfield and texture files are not needed if the terrain is saved. They are intended for during development only, to allow you to fine tune.

Think of the contents of those files as terraforming and texturing macros. They allow you to specify (for instance) that all terrain at an angle greater than 45 degrees will have a rock/ice texture instead of a snow texture. Then the engine applies that globally to the map.

I think the minor differences in the way different machines might render the results are small enough that they won't matter. And I think this would be an excellent compromise between dl'ing the actual terrain and cs-only maps.

[Bytor offline]

So, I could make a map using the Katabatic terrain for example, but supply custom heightfields and texture mappings, and it would still be server side?

[t-b0n3 offline]

Not currently... T2 doesn't have that support, but technically, they could add it....

[Zear offline]

Right. We would need the server to send the 'macros' in those files to the client, where they would be applied (take a second or two to do that). All we need is for Dynamix to at least allow the client to make the function calls and have them stick. The server already can I think. Then we could write a script to do the transfer. But it'd be better if they put the transfer in for us... mebbe rename the files w/ a different extension and if those files exist for the map, sent to client and apply...

[Zear offline]

Or (requiring a bit more work) they could just send a pseudo-dem. The terrain does after all consist of a 256x256 array of 1-byte height values. That's only 64k (less if compressed for transfer, which could be done at map-making time. possibly as little as half the size on average, and mebbe more, depending on the data, just like compressing any other data). Not too bad for even a modem user - like 10-15 seconds at a guess. Then send the texturing macros (since the texturing is only for looks anyway...) and voila! You just sent the terrain.

I can't imagine what they are doing that requires a 1/2 meg for the terrain file. When you import a png as a heightfield it only takes a second or two (and that includes load time and interpreting the png as a 'dem') and the terrain is structurally ready. The only thing I can figure is that they are saving rather detailed texture info - and that is so not important. After all, when was the last time you looked at a terrain and said 'That texture there is off a couple pixels'? Texturing is important, but presice placment is not. Any error introduced by different machines applying the macro would be negligible for looks and irrellavant for play...

The more I think about it, the more I think the bottleneck is a business decision, and not technological. Fer heaven's sake, it really isn't that much data that needs to be sent in a lossless fashion...

Mebbe we're just barking up the wrong concrete tree.

[Bytor offline]

Perhaps the ter file is large because of the texture meshing. I remember that was something they worked on quite a bit during the early stages of the beta. Maybe the algorithm that handles the meshing of textures where two different textures meet generates a lot of detail, and that detail is stored in the ter file.

I have no idea, just a guess. For all I know the texture meshing is done in real time by the game engine.

[Got Haggis? offline]

I was reading the T2 ingame forums today, regarding autodownloading of maps. Someone posted an email they got from Dave regarding this issue.....he said that they didn't have time to include it in the general release of t2, and wanted to include it in the expansion pack, but now it doesn't look like they will have time for that either.

So yes, it does look like it is more of a business decision

[MrPink offline]

Why couldn't they just implement a redirect download as is the case with UT maps? Client is redirected to another server to d/l the map then continues into the game server once the map is completely d/led and installed.

[Reaper ~BC~ offline]

It sounds now like it won't ever be done.
At least they could create a bunch of terrains, and bundle them with the expansion. It wouldn't take that long to generate 20 or more terrains for us to use. What do ya think?