yet another idea for making digging ground videogame and keeping it at 60 frames

Load the terrain that is far away.Place the picture of the terrain on four vertex plane that a camera in the scene sees.Combine the movement of the enemies that are behind the plane with what is on the plane.

Use video texture Or another method to show the picture.Then end the faraway terrain.Dynamically load the planes that show the faraway terrain in front of the player.Add the terrain back when you pass the plane.The terrain that is most closes to the player stays in the scene until he moves away from it.

Like in the block easy demo.Have the ground spawn underneath the enemies and end behind them.

Have you heard of the key enter and its line breaking abilities?

Or bullets points? Logical order of thought?

You shouldn’t write everything in one big blob, please edit your first post.

No i have not heard of that concept?What does it mean?

Some videogames show faraway terrain as pictures.Do some voxel videogames do that?

Okay this seems sensible.

Its a simple lod.

I have also thought about photographing a chunk from 6+ different angles and creating a flat representation of it for far objects.
Basically low poly placeholder.
I think I even pm you at one moment with this.

Some games use this for example for NPC. I think I saw it in Dead rising 3.
Building and mountains in openworld games seem to use something similar also.

Problem is, it has to be distant. Enough distant that you won’t bother rendering npc already…

It doesn’t really help you with the digging part also, because simply if the hole is enough close to you it has to be rendered the standard method which brings you back to square one.

Part 2

Found finally a picture of a midway lod:

This is what octree voxel games get for free.
(and before certain people wrong ideas, octrees are not good for this type of games and need no discussion here)

You just get the average of each 8 cube ‘cube’ and represent it as only 1 cube.
From distance you cant tell the difference.

Not the far down part of the whole.Just the part of the whole that is close up.The far away part of the hole can be a picture.

I want the planes close enough to keep the draw calls low enough to keep the framerate at sixty.And then allow enemies to be seen on the planes with faraway ground.

I think it would look nice.
A player really needs is to see is where he is going.It provides that. I think it would playable and enjoyable.Along with
digging it would be prefect.

My idea is lot more easy than yours impliment.I believe it gets results.

That is a bad idea.
I will make people sick.

You shouldn’t do that do terrain that close to the player.
You can not place the enemies on the plane while keeping good perspective.
The planes would warp and rotate when the player moves which would make you sick.
You wont have proper depth perception.
You would have to refresh it very often for them to even make sense.
etc etc

But I guess your answer will still be ‘I think that it will 60fps because pineaple’

I really do not care about good perspective.The planes are not parented to the player.They are dynamically added in front of the player.
I do not need proper depth perception.It would be neccesary to see where you are going.which the plane would do. I would refresh the plane for the enemies not the picture.I am simplying the process.

You do not get sick from a painting do you?

Tell me why the framrate would drop below sixty with that?

No I don’t. They make great models.
Glitchy field of view where I would want to make sense what is where is wearing down on my eyes.
Then there would be popping, and thus perspective change, which is bad.

I wouldn’t know either why updating/redrawing almost full viewport resolution images would not work well in realtime.
Seems kinda fruity to me :spin:

The portal videogames do it.Don’t they not?

Why do they only allow one tiny portal? check mate.

(only 2 videotextures in an in house engine and snapshots+multiple canvasses+voxel targets+higher resulution+blender’s slow ass api DONT compare
Also the two other portal cameras were rendering a really simple scene,
you would render voxels -> the opposite.
)

So there is no way to do it and have good framerate.

This is great if you do it for the distant chunks, that don’t need updating.

If instead of a camera videotexture you draw the image thats even better.
Drawing a bunch of 128by128 pixel textures is what my pixel meshing demo does twice every frame.

So you can render/draw them once and then keep them as distant objects dont change that much.

Now if you would also do the cube averaging i showed you would have a solid approach for mid to distant chunks.

I haven’t yet found the time yet to test those approaches, but thats what I would want to see done.

I would say its 1/5 of the solution.
Rest is meshing and data structures.

I would like to see that when you have time to impliment it.

This is a sky-box

This is a method to dynamically render the texture of a sky-box.

Be aware this operation is expensive. Many games render the sky-box beforehand and just load them when when needed.

Objects behind the sky-box are not visible (because sky-box blocks the view). The purpose of a sky-box is to hide the fact that the view is limited by “projecting” something else than an empty screen. The sky-box should be the most far away (visible) object.

Therefore objects behind the sky-box do not even need to be present (for render).

This method would make the sky-box way too close. You will not be able to keep the illusion if a 3D Scene. That is the reason why skyboxes typically surround the camera with a constant distance.

The idea of a skybox is that movement of the camera is hardly noticeable. This means when the camera moves through a village, the perspective to the surrounding mountains does not change that much that you as viewer will notice the difference.
This is different when moving fast and far e.g. via airplanes, cars. In such cases a fixed sky-box will not work very well.

You can change the sky-box when moving. But there are two major problems:
A) a switch can be noticeable (when there are too much changes to the perspective)
B) a switch can be expensive (when you want to render the textures)

There are ways to come around that issues:

A)

  • have a finer granularity of sky-boxes
  • distract the player when changing the sky-box (e.g. switch when the camera is in a tunnel)
  • dynamical interpolate sky-boxes (e.g. via transparency fading or texture mixing).
    B)
  • (as mentioned) pre-rendered sky-boxes
  • ? (when you find a method for fast render, you most-likely do not need the sky-box anymore :wink: )