The LOD terrain system thread


#1

So I posted this in the HiFi Gitter the other day but got no reply.

Hey everyone - Got a question - Is there a dedicated terrain system for Hi fidelity? or do we use FBX files for terrain? If we use FBX files I would like to suggest using a terrain system with a LOD system this could save allot of draw calls per frame. My 2 cents.

From what I understand - HiFi currently uses a 3D model (.FBX) based terrain system opposed to an dedicated Terrain system with LOD Support. I read that HiFi used a voxel based terrain system at one point but has since removed them due to performance issues. I really think that a terrain with LOD support would benefit HiFi.

Here is why I think that -

Performance - I think that we can squeeze out allot more performance the HiFi Interface/Client. From what I have been reading / watching - performance is key in a VR environment. With the current system we are rendering a dense .FBX mesh every frame. With an Terrain System with LOD Support we would still be rendering that every frame but only the dense bits would be around the users.

Here is the pros and cons of each method.
LOD Based terrain - Pros

  • Can be set to constantly adjust its poly size based on distance from the camera. Video
  • Easier Terrain Creation - Create a height map (.RAW or .r16) and responsible textures for the terrain and plug them in to the Simulation.
  • Allot more detailed terrain in less time and with less work involved.
  • Collision can be generated by the engine.

LOD Based terrain - Cons

  • Limited terrain textures due to performance. However we can use one texture or a series of textures the entire terrain.

FBX Terrain - Pros

  • We can do flying Islands and other non planar based terrain.
  • Can be very fast however only if broken up into smaller chunks from what I have read.

FBX Terrain - Cons

  • Terrain need to be UVW unwrapped for textures.
  • Used V-HACD for the terrain - Takes a while to compile the terrain.

Anyway this is an continuation of that conversation and hopefully we can get a few more people involved this time around.


#2

There did use to be a lod system in place. The original Ron avatar had a series of lod models so it must be do able . A it’s a process that we have all neatly avoided ever since as the Blender avatar work flow was so annoying that lod models were a step too far.


#3

So LODs for Avatars were in place was there anything for terrain though?

Thank you for the reply btw.


#4

looking at the fst file that came with ron it has this bit of code with it

name=ron_standing
filename = ron_standing/ron_standing.fbx
texdir = ron_standing/textures
lod = ron_standing/ron_standing_lod40.fbx = 10
lod = ron_standing/ron_standing_lod60.fbx = 20
lod = ron_standing/ron_standing_lod80.fbx = 40

maybe no use but who knows


#5

What @Judas mentions applies also for any entity models (this means terrain, objects, etc) as long as the model references an fst file instead of FBX.

Basically the FST (Faceshift Transformation File…) handles the bundling of models and their LOD. You can generate these files by packing your models in the model packager in Hifi

These are the result from my experiments:
lod = < model > = < weight >

The higher the “weight”, So basically the higher the weight, the more the model is to be used if FPS targets are not met.

If the FPS target it not met, the largest lowest LOD (file size), smallest (world scale) object, and the most distant objects (world position) will not be shown in world. There is some scale to it, but I havent digged into it as much: But basically if there is no LOD model setup, the model will cardboard or be not rendered if fps is not reached…

But I think most of the terrain stuff should probably be handled by Polyvoxels, since those are automatically downscaled by distance. Otherwise the terrain might look abit too “grid” y if splitting it up.


#6

I just had a play with this and got nowhere.

I made a cube a monkey head and a teapot as fbx models
named them lodtest1,2,3
uploaded them with the uploader which created the fst and packaged them
i edited the fst script and added in the lods as in the head example giving me
"name = lodtest1
type = entity
scale = 1
filename = lodtest1/lodtest1.fbx
texdir = lodtest1/textures
lod = lodtest1/lodtest1.fbx = 10
lod = lodtest1/lodtest2.fbx = 50
lod = lodtest1/lodtest3.fbx = 60
joint = jointNeck = Neck
joint = jointEyeLeft = LeftEye
joint = jointHead = Head
joint = jointEyeRight = RightEye
jointIndex = Cube = 0"
loaded it in world and it remains the cube at every distance upto it vanishing from sight
i tried messing with the lod settings and the fps setting in settings but no joy
has anyone got this working?

https://dl.dropboxusercontent.com/u/10483952/lodtest/lodtest1.fst


#7

50 and 60 seem a bit high, for me it has worked with 10, 15, 20.
Unless they recently broke it.


#8

What do the numbers equate to? fps or distance? has been messing with the numbers blindly to get it to do anything.
Do u have a working example?
How do u have fps and lods set?
Beer


#9

We’re doing and planning work that will address some of the LOD issues across all meshes, not just ones targeted for terrain. Hopefully in the future, rather than sitting in an empty world while waiting for a huge terrain model to download, the server will be able to stream information to the client, with a focus first on lower LOD information and mesh data that is localized to where the avatar is actually located, before streaming higher detail versions or portions of the mesh that are further away.

Until the day we’re all running uncapped gigabit fiber connections to our homes, any metaverse solution that wants to address large scale areas will need to have some mechanism to do this, so hopefully we’ll be able to come up with a good model that can be re-used and turned into something like a standard protocol for partial geometry transmission.

As you can imagine, it’s a huge task both in terms of design and implementation, so it’s not going to be something we can release relatively soon.

However I am interested in additional types of terrain detail. For instance, I would love to see entity types that could allow you to specify a lat/long location and have it source the rendered data from publicly available sources like LANDSAT data, or Open Street Maps in order to realistically render the content. Maybe it will be a hack day project.


#10

Hey thanks for the information on what HiFi is doing.

Totally understandable that you cannot release it anytime soon.


#11

I am looking at implementing my own primitive LOD in the following way:

The entire terrain (several km diameter) as a very low-poly mesh (say about 100m resolution).
Patches of 10m+ resolution as discrete smaller meshes laid over the top.

Anywhere near-by should use the higher poly mesh, while further away parts, the high-poly meshes will be distance-culled, leaving the low-poly underlying mesh (which I am hoping would survive distance-culling by virtue that the view point is still in its vast bounding box).

It also lets me define the general shape of my world, then focus on detail terrain in small bits as I need to / feel like it!


#12

Is there any documentation on the terrain system?


#13

There is no in-world terrain “system” but if you create a model in blender, you can perform edge split / extrude / .obj export and it should work for you.

((i can feel the cringe of a few users as i type that))

:smiley:


#14

And as of the latest beta interface app, you can set the collision type to “static mesh” which means you can walk on that ‘terrain’. Mind the vertices though. Over a million and it goes phantom.