LOD, Clipping plane, Draw distance and stuff


Hi everybody,
seems that periodically someone raises this issue, now it’s my turn I guess.

In two lines: Let’s say I have a domain with multiple cities/worlds, I don’t want to see a city/world while I’m in another. is there a way to manually control the draw distance in a domain?

Here I read that

The LOD is framerate based.

But what if I want to control which content a user is downloading? I want to avoid not only that the user sees (regardless the framerate) but even downloads a content from another city/world. Is it possible?

I found this in the docs. Is it the correct path to follow? Or does the fog help?

I’m reading something here and there and there (the occlude everything outside is very interesting imho) but I can’t find a concrete answer.

Are there any news on these topics?


To make a good job for that, It would require “visibility” zone entities… But this is not existing. It would be fun to be able to have many very large scene horizontally without see the other in the sky. you can’t do that only by draw distance.

For what I have experienced the size of the object seems to also have an impact… if it’s big, even if it is far, it will be render.

Random Picture Thread

There’s other very good reason to have visibilty zones.
It would improve the framerate and unload the GPU.

In the past we could see creations from for away you not want or need to see. But the did hit my GPU.

Vibility zones ir draw distance. both are needed. would make high fidelity mabye more usable on more systems to.


Yes, visibility zone is the straightforward solution that includes all the features above.
Do you know if someone is working on it or there is a workaround to achieve it?


I’m affraid that it’s only in my imagination. It’s maybe a very unperformant concept too, a dev could tell us how possible it could be.


@pacepiro Agree that is a good idea, we aren’t working on it yet. What sort of content/experience are you wanting to create? It could be helpful for us to ponder.


Basically we have more than one experience on our domain, for example Quantum city and Venice city, different experiences that don’t have to be directly connected - I don’t want to see/load Venice while I’m in Quantum.

Moreover Quantum city is particularly heavy so we are working on a new landing point and we want it to be extremely light and fast to load in order to welcome our guests without waiting loading times if they don’t have a fast internet connection.

Last but not least, we are planning to add other buildings on Quantum city, but it is already too heavy, so it would be nice to have a quick way to manage which building each user sees/loads while walking or flying.


Imagine the advantages. Be able to host a significant number of experience on a same server without interference. This would put HF in a very interesting position face to some competitors. (ex: Sansar with it’s 3 free experiences)
This might also mean more domain name sold for HF. (As we can plug one for each different area.


This morning, I woke up with this in mind:

Use case no1:
The user has created 2 different worlds on his domain. He wants to have them fully compartmentalized. Meaning that you can’t see the other one from the any of those 2 worlds.

Use Case no2:
The user created a room with many detailed object (lot of polygons). This rooms is in a city. He would like to not render the content of the room while he’s outside of it (walking in the street). But from that room, He would like to be able to still see the city by the window.

It could be also this:
The user have built a large city with a landscape all around. Since the city is large, he wants to hide a part of the content from a distant area of this city. But where he’s in that specific area, he still want to be able to see the landscape.

I guess that usecase 1 is relatively simple, and just that on would be already a plus value.

The second one is definitely more tricky (I’ve imagined many way to do it , not always performant or easy to use). But it would be very interesting for scene with a higher detail level. (Maybe a solution for “Earth”)


Here’s a concept for a flexible visibility zone system.

It would require a “visibilityType” property on the Visibility Zone.
With 2 possible values:

  • View only entities in this zone (Default value)
  • View all entities tagged for this zone and the not tagged entities that are in this zone

It would require a new property on the entities: “visibilityZones
that could have those values:

  • Null (Default)
  • A list of Zone’s EntityID

Such configuration would give all the flexibility to make optimized domain.
Instead to be limited by the number of polygons that a graphical card can handle,
this would allow large installation totalizing many time that limit.
Because the creator would be able to control what need to be visible from each area.
This, In addition to be able to host many different scenes on a same domain.

Here’s some illustrations of this concept:






This is incredibly cool and accurate. Thank you for sharing.
I think that the first step - Visibility Type on Visibility Zone with just the Default value - is the very first thing to do and could be very useful itself.


I really love the idea. It would make the load on the client much lower in many cases. As example when you in some basement. You not need to render anything outside it. And so there’s other idea i tempted to start making when the time is ready for it. But then this zone type woul be very usefull to !


actually this is very similar to my recent question Lag and amount of models in a domain and octree optimization question where I asked if I can put TB of data without impacting the performances of clients.
A developer answered me that this was already happening with the octree internal algorithms, but reading this thread seems disavow this good news.

What I understood is that even if we see the other scenes in distance they are quite optimized and not impacting the performances when you are in one scene.
Reading here it seems that we must wait for a new kind of zones arriving.

How does all this match?


I know your post from view days ago.

With zonrs you could block everything around at close didtance. The octree is using some sort of draw dustance and nit render small items based on that. I think with the octree you will keep see bugger items much longer. With o zone you can make a theater and not render everything out side. Thunk octree still would do that ?

That is how i see it.


So… I even don’t understand if this new visibility zones are in the agenda for a not so distant 0.70 release or are still considered a “nice to have” that will never be done?:confounded:


They said that they will explore the idea. No commitment has been expressed so far. Better not wait after this.


Pretty sure it’s on this pile of other important things the need to add and fix.