Scene switching and terrain...

[slapin]

Regarding interior/exterior switching I still can't find any solution

[slapin]

Well, PCZSceneManager is too clever for my tiny brain.
So to summarize my constraints:

• I can't unload Terrain as it hits stability.
• Thus I can't unload whole scene to get into interior.
• Can't use portal feature as all I get is million of crashes. And no, I don't know what I'm doing with it and trial + error is not a way around it as I can't have time till end of millenium to understand how it works. Basically I was unable to even run it at all.
• I can switch to another camera. However I can't switch viewport or I get crash but I can create new viewport.
• Need to understand how to switch viewport without crashing. I can render to render target fine, but not on main window. But that is not necessary as
• I can teleport existing camera without problems so I can go with it. All I need to do is black screen magic.
• Because of water I can't place interior rooms low, but I can put them skyhigh. With latest Ogre fixes I can safely teleport, so I can add interior world in the sky,
  so I can load/unload rooms with data there and teleport player/spawn NPCs.
• But I can't "see" exterior from interior so if I need it I will have to duplicate parts of exterior as part of interior.
• Putting interiors high will prevent physics from interfering, so I don't need to disable exterior physics, however that would probably be benefitial.
• I use Jolt Physics now so I guess It should not be critical to disable existing physics bodies, however it would be better to remove all dynamic ones like characters and vehicles and spawn them again as necessary.
• Probably in some cases interiors can be kept in place with removing current building exterior, but that is totally not universal as occasional interference with terrain or ocean will happen. Need to check if that can work. The problem here is the need to disable all exterior colliders and sensors, which are external to Ogre and can't be removed by Ogre and there is no mechanism to get Ogre in control here. Also as scene does not own anything each object will have to be removed manually which will mean manual removal and reload of all the nodes and objects.

[rpgplayerrobin]

Unloading the terrain must be able to be done somehow, otherwise, why was it even created if it cannot be unloaded when you want?
With that logic, all applications using it (with threading enabled in Ogre) would crash on exit?

[slapin]

Unloading the terrain must be able to be done somehow, otherwise, why was it even created if it cannot be unloaded when you want?
With that logic, all applications using it (with threading enabled in Ogre) would crash on exit?

Well, there is no way to stop or wait all threads until they are complete, so there is no reliable way to unload terrain especially hen you have interdependent systems. So just terrain being uncontrollable async is a tip of the iceberg (and trigger of some architecture decisions), as there are layered subsystems on top of terrain.

To me the later becomes more of the problem multiplier. To explain this lets see you have world heightmap you generate your terrain from, i.e. you have terrain definer which is called for each new x, y of terrain slot, then you need to make terrain collider, which you generate from heightfield each time you define the terrain, then you need to place static and dynamic physical objects on terrain for each defined slot, each handled by separate subsystems. Each subsystem depends on terrain chunk being defined and some also depend on terrain collider being generated, i.e. dynamic objects should not fall through ground.
However some systems are more complex and depend on terrain chunk actually being there to ask terrain about exact height at place, and for some systems low precision heightmap query is sufficient. And if terrain is being teared down all these systems need to be teared down too. And each tiny physical object need to be removed from physics and removed in time. That is huge amount of handling. And adding terrain teardown into expression
means complexity explosion, as each system should handle the case of terrain and its dependent systems being teared down at any moment.
And that could be easier if I made one super object which would handle everything terrain-related in proper order, but all my terrain-related systems are written to be independent, so each system will have to handle terrain and dependencies itself. AND I could propagate events for that to handle tearing down of terrain for each system to handle on top of that, but it would make stuff even more complex.
It is very likely I do it all in not optimal way, as they already have to handle object adding and removing from the world, but there are tons of hacks like described above which make the thing complex, i.e. case for terrain removing before any collider generated but character system waits for characters to spawn, and all these edge cases will have to be handled and there is a lot of them.

So using uncontrollably async terrain I added my own complexity on top thinking as I can't unload terrain safely so I won't need to handle this case.
So even if I could handle this somehow isolated for Terrain like adding some handlers for each task case (as I learn things I see it can be done),
I will still have to handle my own added complexity.

So I'd say it is not completely impossible to do, it is just hard, hard work I'd prefer to avoid. And Iearn new things every day, so that might change in the future, but time for it have not come yet with my current self.

So I would say with my current capabilities, time and space it is impossible to make terrain unload and being capable to move on, so I try alternate solutions like scene switching (all attempts failed now) and teleportation (looks promising, but I have uneasy feeling).

What I'm really lacking is an experience in how things are done properly or ability to look at some mature project which I could learn how things are generally done properly for things like this, so I might be seriously wrong with the architectural decisions, as I most of time have to invent some new pair of square wheels.

[sercero]

Hello,

Do you really need to unload the terrain? Is it using that many resources?

I'm suprised because in one of your messages you said that the player should be able to look outside of the building/interior so if you unload the terrain... they will stare at nothingness.

Isn't it possible to maybe decrease the terrain resolution or the textures?

Another thing: have you searched your problem in the forum?

In another time OGRE was used a lot to create games and I think that this issue came up a lot.

Best regards.

[slapin]

Hello,

Do you really need to unload the terrain? Is it using that many resources?

I'm suprised because in one of your messages you said that the player should be able to look outside of the building/interior so if you unload the terrain... they will stare at nothingness.

Isn't it possible to maybe decrease the terrain resolution or the textures?

Another thing: have you searched your problem in the forum?

In another time OGRE was used a lot to create games and I think that this issue came up a lot.

Best regards.

Hi!

It is not consuming too much resources and it is possible to decrease resolutions. I searched the problem on the forum but I guess nobody had issues like I have. I had high hopes for multiple SceneManagers but was unable to make that work (though that was suggested on the forum). I currently aim for camera teleporting and loading interiors into area above highest terrain point. This has physics precision limitations, but I hope I can resolve it. I think sometimes replacing building exterior with interior will work but I did not try to implement it.