[opensource-dev] Interested in Terrain Advancement
nexisentertainment at gmail.com
Fri Apr 23 19:55:16 PDT 2010
I'm personally working on Voxel terrain, got most of the opensim
framework down, trying to find a place to upload to the code to though.
Using Minecraft's generation algorithms, with the author's permission.
On Fri, 2010-04-23 at 13:26 -0700, Dzonatas Sol wrote:
> There does seem to be a collective feel that the terrain needs to
> upgraded somehow. Even a Linden suggested maybe a way to override it if
> the builder choses, like with sim sized mega prims.
> My first concern is LOD. The constant changes of LOD on the terrain make
> the appearance the terrain unnatural and unstable. There are times where
> we spend lots of time to get the terrain to look just perfectly aligned
> with other objects nearby. When one decides to walk away 20m, 40m, 60m,
> however, the perfect alignment becomes a prefect fashion statement for a
> drunk bulldozer. The hard work undertaken to detail the alignment of the
> terrain seems like a complete loss.
> As I've used other renders, lets pick on Call of Duty, the terrain is
> pretty stable even at a distance. It has to be. The mere jump of LOD in
> the terrain could mean a way to cheat in Deathmatch sniper rounds. You
> know how snipers love to crawl around the terrain. That kind of
> stableness doesn't happen when the drunk bulldozer decides to
> rearrangement the landscape every frame you move. Call of Duty uses the
> Source Engine, yet this isn't a 'lets all switch over to the Source
> Engine' rant. It is a use-case that shows that even on old steampunk
> video cards there still have the coal to burn up the pixels and display
> a stable landscape. The use-case means, bottomline, it is possible.
> Maybe a baby-step solution is just to have an option to turn-off the LOD
> for the current sim, and maybe nearby sims. The problem here, maybe, is
> that the changes to add vertex limits would be affected by this. It
> might not be all that simple like it was in the past without the vertex
> limits. Therefore, there would need to be separate vertex limits: one
> for the terrain and the rest for objects.
> Here is another use-case with a collada file: Lets say I have a collada
> file that contains a very detailed structure of a volcano (terrain
> only). The volcano is 1km wide. That crosses several 256m sims. There
> are lava tunnels that lead inside.
> The suggested solution was to use a sim sized mega-prim. To do that with
> scuplties would be hard for more than just looks. Sculpties need to
> calculate all the phsyics, yet the collada file could have that already
> detailed and compiled with the file.
> How do we do this with the stock viewer even if we used sculpties? The
> stock viewer doesn't include a "sit on this object here like one sits on
> land now anywhere" option. If we used a mega-prim, it would disabled the
> ability to sit anywhere on the terrain.
> The other idea is to import a terrain, which is an available feature.
> That doesn't allow us to have multiple height maps, like lava tubes. If
> a lava tube crossed a sim to another, there would be a hole in the
> terrain in one sim. There current terrain engine doesn't allow holes.
> Multiple height maps would allow us to have holes in the terrain. The
> physics detail of a scupltie bent to make that hole doesn't preform (and
> I don't mean just frame optimization.. I mean like how a skirt clearly
> either looks good or not when you sit down kind of 'preform'.)
> So, maybe the solution include that baby step.. to allow multiple height
> map layers. A Lava tube could be done with three layers. One for the
> bottom of the tunnel. One for the top. And one for the side of the
> volcano above the tunnel. There would be needed an extra feature with
> the height map to allow empty spaces, to allow where the tunnel opens
> into the side of the volcano.
> So, before we even digress into the advantages of collada refineries, it
> seems the first two baby steps would be to fix LOD and allow an
> arbitrary number of terrain layers.
> I would like to see what others think about this.
> Policies and (un)subscribe information available here:
> Please read the policies before posting to keep unmoderated posting privileges
More information about the opensource-dev