From The Depths - Forum

Full Version: Rendering faces of "solid" blocks pressed against other solid blocks? plsnomore
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
FTD doesn't seem to have any sort of notable surface culling. Leads to far, far more lag than necessary when looking at anything with a large number of blocks.

If something with a solid, non-complex shape that is ordinarily flush with other surfaces like its own - like the bottom/back of wedges, all sides of cubes/beams, etc. is pressed against another similar object, then the surfaces between them really shouldn't be visible.

Unless there's some sort of magic like that already ingame - but I somehow doubt that's how it works.


I feel it would be very, very beneficial to the game for it to feel and act more like blocks glued together rather than individual 3D objects glued together on a grid layout, including how they're rendered.
This is a good idea but only outside combat. Combat is laggy enough, scratching a ship's side by 1 block and seeing its juicy insides, just before another armour gets rendered in would be odd. If this wont happen its fair game.

Hopefully wont happen for turrets, I am learning to tetris and I need to go inside blocks to see what they are often
Maybe it could be a setting? Like, either you enable it when you want, or it enables depending on the framerate, or something. That way you could still see the faces while building, but they won't render when you're fighting six bulwarks with your own battleships while a kingstead is getting deleted.
i dont think this would help much because what happens when the top layer of your side armour gets killed then the game has to now handle 1 the explosion and calculation which blocks are destroyed but 2 it now has to calculate which blocks it needs to render again causing probably a larger lag spike than if everything was pre rendered besides once its loaded in the texture are handled by your GPU im pretty sure only very high poly counts can even cause a little lag, look at buildings they have no physics effecting them so they can be huge before they lag, its physics that causes most of the issues not how many blocks are rendered in but how many blocks must be included in the physics calculations like when you auto scrap in designer and it lags for 2 minutes as each block is calculated as ragdoll..
FTD only lags because of CPU problems, rendering everything only has a slight effect on framerate, while physics; ACCs, missiles, and other multiblock systems cause almost all of the lag.

I'm not sure this would improve anything but framerate on very low end computers while making building a few times harder. Sad
(2016-05-01, 04:30 PM)chp2001 Wrote: [ -> ]FTD only lags because of CPU problems, rendering everything only has a slight effect on framerate, while physics; ACCs, missiles, and other multiblock systems cause almost all of the lag.

I'm not sure this would improve anything but framerate on very low end computers while making building a few times harder. Sad

Im not sure if you are right. Nick recently said this:

(2016-05-10, 02:08 PM)Nick Smart Wrote: [ -> ](...)
FtD is using bugger all physics engine now as there is no raycasting, no colliders, and only one rigidbody object per vehicle. It literally uses about as much physics engine as 6 tennis balls bouncing around.
(...)
(2016-05-10, 02:08 PM)Nick Smart Wrote: [ -> ](...)
The biggest win would be in the reduction of render times. Notice the frame rate increase when you move the camera so that your vehicle is no longer "in shot" ? That's where the FPS is going. Perhaps U5 helps with that but the initial tests of U5 from whenever it was I first tried it did not change frame rate significantly.
I have some plans for level of detail systems and Khaz is working to reduce the number of verts, and we will make new blocks like 4m long exhausts and 4m long particle pipes etc to reduce vertex count.

(2016-05-10, 02:22 PM)Nick Smart Wrote: [ -> ](...)
Rendering is not JUST about the GPU. The meshes need to be sent to the GPU by the CPU for rendering.