Spintz wrote:I don't know if Newton can handle it very well. When I last checked with Newton, I was told that it doesn't handle making certain meshes active or inactive, especially large static ones. The time it takes to build the geometry data for a large convex hull, was too much. I looked into the serialize function, and having the geometry data pre-calculates, but the serialize function would take over 10 minutes and still be running, if terrain tile was larger than 512x512. Hopefully it's improved, but if it hasn't, Newton won't be able to handle this.
Spintz is probably more expert in Newton than I am, but while it is truth the Newton engine will have problems building at collision tree for a large 2d terrain, it is also truth that it has a user defined collision, and it is also it is possible to split the mesh into separate tiles each with a static body.
About the convex hulls, I had build 100,000 vertices hull of randomly generated points and it takes less than 3 seconds. For me that is fast enough, actually it is much faster than qhull on the same data set.
Woooah, i thought you guys where exaggerating, hehe. But this is seriously jawdropping. And yeah man it has kind of a supercomputer, but at least workstation feeling. Pretty cool.
dear god that thing is big! i almost wet myself when i saw it. i dl'ed the movie first and watched that. he 60 seconds doesn't do it justice. ntm my computer is a slightly modified emachine with a freakin celeron processor. i should not be getting the 80fps max that i did...
When banks compete, you win.
When ISPs compete, you win.
When electronics retailers compete, you win.
When governments compete...you get drafted.
Note that if you just want to view some existing or generated terrain data with it, you will have to deliver your png in 16-bit greyscale format to Ranger MK2. Just overwrite an existing base texture in the map directory or create a new dir and adapt the batch files.
To get a 16-bit greyscale texture you might want to use a photoshop compatible plugin called
superpng http://www.fnordware.com/superpng/ which is free. Hardly any image processing soft supports it out of the box.
The reason for 16-bit greyscale is obvious if you try to visualize something like the grand canyon. 8-bit just flattens it considerably, no comparison. Every good Terrainmaker software should certainly have the ability to handle 16-bit greyscale properly. It looks just awesome.
I did the Ranger conversion for the Grand Canyon and if somebody is interested i will post the file.
Ooops, forgot to tell that once you have moved your base texture to its place in a map subdirectory you have to delete all the other files in there to enable Ranger to generate new ones. It does it only once. If you start it the second time it will be much faster.
someone still intrested in? spintz?
i just recalled this thing due to some MMORPG stuff.
if its about colition detection. couldn't this problem be solved with a little 2d-tricks? lets say we check the greyscale-value of the highmap+generic detailmaps to get the high and do the same a little left and right from this position to get a normal-orientation... thought checking the color of a texture at a position should be quite fast but i think it is.
other idea would be to splitt check the position (just x/y) (maybe movement ,too) ot the object we want to be collision deteted and then generate just a minimal terrain-piece around from the original data for the colision detection.
loading pre-calculated terrain-pieces should be less effitient than generating a minimum collision environement on the fly.
-both arent best for very fast objekts like artillery-bullets or something like that.
but for a client-side colission detection in a mmorpg it should be good enough.
if the whole thing could be made to work with terrain-puzzles ( like WoW uses) ... well imagine a perfect optimized terrain, consisting thousands of small , loading friendly pieces. put together to a hughe terrain which can load and disload continueosely in a way the user wont notice.
non-jerky non-popping almost-endless no-re-loading flawless terrain...
jeah sounds like garden eden...
actually i just wanted to ask if anyone is still working on this. even if its just for flightsims where you dont need a death accurate colission detection..
well someone still on it?
greetings
thommy E
//edit
i have no real knowledge about this .. but .. shouldn't a vertex shader be able to do all the grafical optimisation? ij yes we wont lose any cpu-power which we can use for a inteligent collision detction.
//edit end
athlon2400xp+,geforce4200ti, 0.2Tb hd+64mb extern, 512mb ram, linux FC5 2.6.16-1.2096, 100%gates-free system
I have read into this algorithm and decided not to implement it. While it looks very nice, it uses tricks to make the terrain look more detailed in areas. It uses "height detailmaps" to make low res terrain look more detailed, and would be hard to work out with collision. It may be nice for a flight sim, where you aren't really close to the ground much, but not for any of my purposes.
