From: Manuel A. F. M. <ma...@us...> - 2005-02-26 04:04:10
|
S=E1b, 2005-02-26 =E0s 11:40 +0000, Yuri Vilmanis escreveu: > On Tue, 22 Feb 2005 08:03 pm, Manuel A. Fernandez Montecelo wrote: > > 1- I'm making tests, and takes about 15 minutes in a pentium IV to > > render a row of 4 squares of terrain, made out of 4 square heightmaps= of > > 33 pixels; to a scale of 128 units each one, (people in CS recommend = to > > take the units in CS as meters, so I'll take it as a equivalence), > > 512x128 total. previously I made a test with square heightmaps, 512 > > pixels of side; 16 such sectors being each one 4096 units of side: a = big > > square of 16 kilometers of side, comparable to the size of our first > > island-continent Feld (maybe a bit bigger, somebody out there -resqua= d?- > > talked about 25x15 kilometers or so). this takes hours, say 2 or 3, t= o > > render in my computer. >=20 > Ouch. That sounds nasty. Bug the Crystalspace developers, I dont think = that's=20 > a reasonable performance... I already did :) explained below.. > When you say render, I take it you dont mean render as in rendering... = umm,=20 > better way to put that... as in displaying the result to the screen? Is= this=20 > 'rendering' the process of loading the file and creating the 'terrain' = object=20 > in CS? Does CS do any subdivision or interpolation when it does this (e= g =20 > making the terrain smoother, or creting low-detail versions for far vie= ws)?=20 > Any of these could potentially produce results like you describe... actually the rendering of the terrain with that plugin it's quite fast, say, seconds even for big terrains. the problem it's just with collision detection, instead of using the heightmap to get it it uses some kind of costly computations, that's what cause all the delay, this is only needed for the first time. so with inaccurate info about collision detection you're suddenly standing some distance above the ground, or getting inside of elevations and seeing the terrain from below.. the method to calculate the collision detection it uses another kind of vertex so it's independent of the resolution of the heightmap for terrain, but it takes minutes (say, 2 or 3) with resolution of 256 (I think it's a matrix of 256^2 points), and about an hour with 512, with 300mb of ram or so. I didn't even think in test it with more than this =3D) and CS developers said that wasn't easy to fix and there are no plans to do it at the moment. > > so the map (or union of divided maps) for the whole Feld, PNG format, > > has only about 400 kb. and if this takes a lot to render initially (e= ven > > minutes in the simpler case) and sometimes has problems with FPS in t= he > > empty map, having a lot of resolution like you propose would make it > > unusable. >=20 > Fair enough as stated... but remember that the 3rd person view will pro= bably=20 > be a lot closer to the ground than whet you're probably seeing. The sta= ted=20 > resolution (and I assume you mean 2038 pixels on a side for a square of= 16km=20 > on a side) will make each polygon about 8 meters on a side... this mean= s that=20 > each flat square of terrain will be big enough to stand 100 characters = on, if=20 > they bunch up a bit ... thats a pretty low detail to arbitrarily impose= on=20 > the gameplay (then again, look at Mechwarrior 3 - but that was a M$ pro= duct,=20 > after all ;) - I suggest you need more detail than that, even if it doe= s mean=20 > smaller view distance. At the very least, talk to the people who are wo= rking=20 > on gameplay / look&feel and see if they're OK with terrain polygons tha= t big. I was mainly making tests to see the different performances and trying to figure out how we can get something working, so all this were examples. Jorrit, the CS creator and developer of Planeshift, thinks that I'm a bit crazy proposing such huge maps of (8km)^2 (not only for performance, but he also thinks that is a huge world in general and we should begin with something smaller), if it's divided into sectors a suitable size (a good size seems to be 1km) you can have the surrounding sectors loaded and unload all the rest so it would probably be usable and could make maps with 1 square per meter or so. but this has the problem of the gaps and strange lights in the edges (see in example [1] ), we don't know if we can use this at all, and even in the best case could have those kind of flaws until fixed. [1] the use of the same texture for all the maps is a bug that they're trying to fix now, but there's still a problem with that plane of light and the light lines in the edges: http://www.once.net.nz/wiki/moin.cgi/WikiSandBox?action=3DAttachFile&do=3D= view&target=3Dmaterialmap-problem.png=20 > The size of Feld has been discussed at length before, both in mailing l= ists=20 > and IRC - I'm not sure about newer discussions on IRC, but the older on= es=20 > concluded that the size of the original map from the website was realis= tic=20 > for what was wanted from the gameplay itself.=20 > Feld (which is an island, not an 'island/continent') was planed at arou= nd=20 > 300kmx500km. If its going to be shrunk by a factor of 100 in area, I th= ink=20 > thats something which should be a major topic of discussion on the mail= ing=20 > list, as it radiacally changes the whole direction of the project (bigg= ish=20 > world -> tiny world). I don't think that there are any MMORPG out there with such a huge size, and that's the smaller island! some considerations: - 300x500 km =3D 150000km, that's more than the double size of Ireland (without North Ireland, 70), with 4 million of people (again without North Ireland). - Planeshift has more than 100 MB of compressed artwork, the area with the bigger archive (almost 20 mb) is the initial square, 1'6km of side, and most of the areas are corridors or the inside of buildings. - on the other hand, it can take about half an hour to cross a place of 8 km running, without obstacles. it will take a lot of time to explore such a tiny world, not even talk about designing it, all the design in the wiki is clearly insufficient to fill it, and most of the villages and cities are not really designed and does only have vague descriptions. making a grid with a separation of 1km, you have 64 sectors to fill with villages, lakes, ruins, etc; it would take about 2 minutes to go from one to another. in example the current map in the server has only 500m of side, it takes 50 secs to cross it (70 diagonal) with double speed than normal (I tweaked it to be able to move quickly and see the different things in the map), you can make some tests trying to see what's inside all the houses and see if you get bored running from one side to another, at least I do, the one that I'm proposing would be 256 times bigger. and again, that's the smaller island in our world. but most importantly, there are memory and computation constraints that I talked about, so we'll have to either wait for somebody to implement something better or to stick with these for a while. so if you don't want this system please tell me, I spent some weeks trying to make a decently implementable proposal, and didn't finished yet, so I could at least save some time. > > in addition, the maps could be even downloaded initially with the bin= ary > > package, as we are doing now, so network bandwith it's not a problem > > with this system. >=20 > Certainly doable for Feld, but Feld is a small place... the once world = is much=20 > larger. You can either plan ahead now, make changes to the software lat= er, go=20 > with low resolution, or decide on a smaller world. I'm not saying one i= s=20 > neccesarily the right choice - I think the choice needs to be made by t= he=20 > whole team. well, I have no problem with discussing feasible ways to implement our world, but then first the whole team (or those who want such a huge world) has to test it and view how it works, and make another implementable proposal. it's just talking about desired sizes and not thinking about how to implement it and fill it up doesn't make sense for me :) > Thanks. I probably didn't correctly understand the gaps problem - I sus= pect=20 > the CS terrain component has something to do with it. Put the code in C= VS and=20 > I'll look at it myself - and maybe take a look at why its taking such a= =20 > ridiculous time to load... there's no code, you can just play with it modifying the parameters of the world file and replacing the heightmap of CS/data/terrainf/. the main values with impact in performance are these: - <lodvalue name=3D"block resolution">8</lodvalue>: defaults to 16 in tha= t map I think, with values higher than 32-64 it uses all the CPU with walktest and makes jerky movement, and doesn't have really a very noticeable impact. - <lodvalue name=3D"cd resolution">64</lodvalue>: this is about the collision detection, with values higher than 256 the results are not good and increases a lot the time and memory to generate the map for the 1st time, no penalization after that. > Hope to hear more people joining the discussion on this too... >=20 > cya all, > Yuri greetings :) --=20 Manuel A. Fernandez Montecelo <ma...@us...> |