Headless. ViewDistance.

manu3d

Active Member
Contributor
Architecture
A couple of random questions:

1) As I rummage through the renderer, occasionally I need to do changes to the headless section of the codebase, due to the shared interfaces for example. But that makes me wonder: why does headless have things such as a HeadlessRenderer, HeadlessGraphics and it even deals with visual assets such as meshes and shaders? I thought starting Terasology headless was like starting a command-line only server?

2) It kind of bothers me that the ViewDistance enum sets viewing distances in stone. Would it be perhaps useful to have a "custom" choice, the user choosing the numbers? Also, it'd be good if the user could set the number in chunks but gets informed about the resulting distances in meters/blocks. What do you think?
 

Immortius

Lead Software Architect
Contributor
Architecture
GUI
1) My understanding is that some stuff is only there because too much game logic was tied into the (supposedly) rendering related classes, which is part of what you are fixing :). In general there probably needs to be some sort of Headless renderer/graphics class, just to stub that space, but it should do very little.

On the assets though, they do need exist even in a headless server - if an entity has a mesh, then the server needs to be able to "load" it so that it can exist on the entity and be replicated to the remotes. Also, there may be uses for the assets even on the server - collision for instance. Or the server may care about the size of a texture for some logic. Certainly they don't need to be full fledged opengl assets, and often much or all of the actual asset data can be discarded. Other times the assets are very important, like skeletal meshes and animations, since the positions of bones may need to be simulated on the server.

2) I didn't consider there to be much value in allowing micro-adjustments to view distance (100 vs 101 blocks), and there certainly needs to be a maximum cap on view distance that can be requested (since it impacts server memory usage). View distance in chunks would make sense though.
 

manu3d

Active Member
Contributor
Architecture
On point 1:
So the server replicates an entity and sends, among other things, the entity's meshes over the network to each client? I would have thought the client has all the meshes already once it has all the necessary modules required by the server?
I understand the point about assets and collisions though. So the server would load/create some kind of collision proxy (i.e. bounding box or a sphere) out of an asset. I also understand the example of skeletal meshes: I'm thinking ragdoll characters being simulated on the server hence the server requiring bones-related data. All good points. I tend to think to servers mostly providing only position/orientation and game-related data, but it's true there's more a server might need to be authoritative about.

On point 2:
No, I completely agree with you that there is no need for micro-adjustments: there are reasons for a chunk's dimensions to be powers of 2 and it's understandable that the world on screen has to be a multiple of those dimensions. I only thought in terms of setting distances in chunks but telling the user how many meters/blocks their choice corresponds to. So, if a user sets a view distance of 5 x 3 x 5 he would be informed by the GUI he'd be dealing with a visible volume in meters/blocks 160 x 96 x 160. Ok, I won't tackle this soon I guess, but I might write up an issue about it, to have it somewhere.
 
Top