Render chunks out of view distance as smooth 16^3 cubes

[Winterhome]

Is the chunk there? Yes. Is it loaded? No, it's out of the chunk loading range. Is the chunk at least X% full of blocks? Yes. Take the predominant hull color in that chunk and render the entire chunk as a smooth cube of that hull color. Don't bother trying to load the chunk. Just render its position as a 16x16x16 smooth cube.

Replace that smooth block with actual chunk loading when the chunk loads, not if the chunk fits the criteria for loading. Put that smooth chunk replacement code in with the actual chunk loading, or you'll end up with a lot of invisible ships at close range.

It'd make it a lot easier to do battle when the server stops sending chunk updates, or when you're near a massive titan, or whatever, and it allows you to get a visual idea of whatever other ships are in the area, and makes it easier to try to avoid collisions with invisible/unrenderable ships.

 

[Master_Artificer]

I already fight invisible ships that are not 'cloaked'. This would be very useful to know how close I am to the unloaded enemies and where to shoot. Seems like a no brainier, I like this.

 

[Master_Artificer]

Can I get some other people to upvote this idea? I want a tag over this title stat!

Okay, the "Postponed Indefinitely" is not one that I would want, but that would mean they at least looked at it...

 

[Dire Venom]

What would ships look like at range with this :?
I don't want all my decorative features to never be seen :/
What about ships smaller than 16x16 :? Floating box lol XD
Sounds like nice idea thou

 

[therimmer96]

How would your client know what the predominant colour of the chunk is if the server isn't sending chunk data?

 

[Winterhome]

How would your client know what the predominant colour of the chunk is if the server isn't sending chunk data?

A separate temp file that gets created exactly once when an object is loaded by the server, though this may contribute somewhat to object loading lag. A separate thing from the ship itself - a catalog of each chunk's relative position and its RGB value that gets loaded by the player. As soon as a player enters a sector with an object in it, that chunk RGB data is the first thing sent by the server. If I'm not being stupid, I would assume an XYZ position and an RGB value for each chunk should be all that's needed, or 23 characters per chunk (3 characters per chunk position value, and 3 characters per RGB value, all separated by commas), assuming the information regarding what object this information is attached to is based on the temp file name. 10,000 chunks using a ###,###,###,###,###,### setup in the temp file would amount to somewhere in the neighborhood of 224kb total, which pales in comparison to the sheer quantity of information one would need to send a client per chunk if it were all based on block types.

One could simplify it further, though, by assigning it as ###,###,###,## - where the last numbers are simply a color ID, which should work just fine as long as we have a limited number of colors to choose from. Doing it that way would cut it down to a 140ish kilobyte file for 10,000 chunks, I think.

Of course, I'm making a lot of assumptions here, but I don't see why it wouldn't work to attach a tempfile to each object.

What would ships look like at range with this :?
I don't want all my decorative features to never be seen :/
What about ships smaller than 16x16 :? Floating box lol XD
Sounds like nice idea thou

Beats the hell out of it being totally invisible :p
Decorative features can be seen if the person's computer is powerful enough to handle the chunk loading. Otherwise, though, it's best to let the big, strong server box handle the heavy lifting (it does anyway whether or not you ask it to, so whatever)

A sufficiently small ship wouldn't have a high enough block count within that 16^3 chunk to be rendered in the first place, so they'd probably be invisible anyway. If it's that small, then it's not of sufficient significance to worry about dealing with with anything other than turrets.

 

[Megacrafter127]

or 23 characters per chunk (3 characters per chunk position value, and 3 characters per RGB value, all separated by commas)

using characters to transmit non-string info is really inefficient. you would need 3 characters to display all values a single byte can assume, assuming decimal format. 2 characters in case of hexadecimal format. It is WAY easier to just send the byte instead of 3 1-byte characters.

 

[Winterhome]

using characters to transmit non-string info is really inefficient. you would need 3 characters to display all values a single byte can assume, assuming decimal format. 2 characters in case of hexadecimal format. It is WAY easier to just send the byte instead of 3 1-byte characters.

That would work too. Honestly, I don't know how that all works, I was just throwing numbers together based on the one format I'm vaguely familiar with.

 

[therimmer96]

A separate temp file that gets created exactly once when an object is loaded by the server, though this may contribute somewhat to object loading lag.

This is what the game already does, except with the entire ship data. when you first load a ship, a copy gets saved to client-database, and local access is fast enough with such small files that it wouldn't really make a difference.

Quite often, when you meet a ship in combat, its the first time you meet that entity, meaning thats where the lag comes from. this would not solve that issue.

 

[Winterhome]

Quite often, when you meet a ship in combat, its the first time you meet that entity, meaning thats where the lag comes from. this would not solve that issue.

It isn't about lag. It's about view distances and servers outright not sending chunk information after, for some bizarre reason, attempting to reload them after combat has started.

I have seen ships that were previously loaded outright disappear mid-combat numerous times. The idea of having a default fallback LOD that is loaded by a system separate from the "normal" chunk loading system is meant to prevent ships from becoming totally invisible under any circumstances whatsoever, be they server error or insufficiently powerful hardware on the client's end to render the enemy ships.

 

[GRHayes]

Is the chunk there? Yes. Is it loaded? No, it's out of the chunk loading range. Is the chunk at least X% full of blocks? Yes. Take the predominant hull color in that chunk and render the entire chunk as a smooth cube of that hull color. Don't bother trying to load the chunk. Just render its position as a 16x16x16 smooth cube.

Replace that smooth block with actual chunk loading when the chunk loads, not if the chunk fits the criteria for loading. Put that smooth chunk replacement code in with the actual chunk loading, or you'll end up with a lot of invisible ships at close range.

It'd make it a lot easier to do battle when the server stops sending chunk updates, or when you're near a massive titan, or whatever, and it allows you to get a visual idea of whatever other ships are in the area, and makes it easier to try to avoid collisions with invisible/unrenderable ships.

Probably a better idea would be for them to store an exterior mess of the original craft that is reduced poly by combining edges. This could be made during the save process relatively easy. It would also be far easier on the graphics engine to display at a distance.
Considering you can't necessarily see detail as to what block is or isn't broken.

In fact I would suggest they do the same to home bases and stuff that doesn't really change much or have the risk of being shot destroyed with any ease.

They could be doing something similar to what I am saying already. No telling without them saying something.
Just because a game is voxel based game doesn't mean it is rendered the same by each engine. Which means we are kind of shooting blind making a suggestion of this kind.

 

[Winterhome]

Which means we are kind of shooting blind making a suggestion of this kind.

Shooting blind is also the reason for the suggestion

 

[GRHayes]

Shooting blind is also the reason for the suggestion

My biggest issue when it comes to this is when you get close to the edge of a sector the ships crossing it pops back and forth as if they are warping around. The problem has to do with the way they scale for rendering and their transformation.

All in all they done pretty fantastic but I think that could be improved some. If they went to a 9 block sector to a local space rendering system that would clear up that type of issue.

 

[therimmer96]

sure, ships disappearing is a pain, but tjis would not help. the game already is storing a local cache. adding a second would not do anything. i would rather the time be spent fixing the bug than implementing a semi fix that wouldn't really help.

 

[Winterhome]

sure, ships disappearing is a pain, but tjis would not help. the game already is storing a local cache. adding a second would not do anything. i would rather the time be spent fixing the bug than implementing a semi fix that wouldn't really help.

It's not just the disappearing. You're forgetting that not everybody is able to run around with their chunk render settings set to 20,000.

 

[jayman38]

Even if these low-LOD chunk blocks were always painted white to simulate starlight glinting off, it would still help. In non-combat situations, players would be motivated by curiosity to go check out these featureless bits, to see what features they could find up close.

 

[Master_Artificer]

It would even work well if it just resulted in grey boxes, instead of colors. Any chunk of the ship with a ship core is dark grey like standard armor, and any docked entities to it are light grey around the chunk with a ship core inside of it, like basic hull.

And each chunk would be a single visual square, vastly simplified.

I can never set my view distance beyond 2k, and often need to bring it down to 1k when fighting to keep framerate above 3-4.


I think this is a good idea, it doesnt need to be implemented soon (tm), but I think it is a good thing to have before beta.