Quest for Higher End Graphics Support

[Inocudom]

Colored light rays are not impossible because they can't be achieved in Irrlicht; they are impossible because the developers simply do not like doing them.

Now, concerning Blender's game engine, three questions must be asked:
How does it perform compared to Irrlicht (RAM usage, CPU usage, GPU usage, frame rate?)
How would it affect the maximum size of Minetest worlds?
How would sound be dealt with?

[shaneroach]

Colored light rays are not impossible because they can't be achieved in Irrlicht; they are impossible because the developers simply do not like doing them.

That's cool. Getting some money in the hands of devs is one of the perpetual issues with open source, and another reason I sort of liked the idea of somehow getting procedurally generated terrain to Blender. They seem to have hacked together a business model of sorts that at least keeps the core group in cash.

Pay has always had this odd motivational effect on pretty much all modes of work known to man. =)

[shaneroach]

You may want to see 'build a world's graphics - it uses the Irrlicht engine.

A lot of that is indeed very pretty.

https://www.buildaworld.net/

That the one you're talking about? Wow it even has physics for the terrain and buildings. That's downright awesome.

[Calinou]

You may want to see 'build a world's graphics - it uses the Irrlicht engine.

A lot of that is indeed very pretty.

https://www.buildaworld.net/

That the one you're talking about? Wow it even has physics for the terrain and buildings. That's downright awesome.

How about Terasology? While programmed in Java (your opinion may vary), it's free/libre and readily available. Unlike Minetest, it runs poorly on slower machines, like many of the graphically advanced games today which lack fallbacks such as fixed-function rendering.

[Jordach]

You may want to see 'build a world's graphics - it uses the Irrlicht engine.

A lot of that is indeed very pretty.

https://www.buildaworld.net/

That the one you're talking about? Wow it even has physics for the terrain and buildings. That's downright awesome.

How about Terasology? While programmed in Java (your opinion may vary), it's free/libre and readily available. Unlike Minetest, it runs poorly on slower machines, like many of the graphically advanced games today which lack fallbacks such as fixed-function rendering.

My machine is fast and gets bad fps there. With MC + SEUS 10.1 Ultra; I get about ~30 fps non fullscreen and ~15 at 1080p.

[Calinou]

My machine is fast and gets bad fps there. With MC + SEUS 10.1 Ultra; I get about ~30 fps non fullscreen and ~15 at 1080p.

Tweak the settings, highest settings will always be slow.

Even the lowest settings look rather good, as long as you use a good view distance.

[Inocudom]

But terasology has a very limited height range (it is like Minecrafts.)

[rubenwardy]

But terasology has a very limited height range (it is like Minecrafts.)

this thread is about graphics, not about comparing game play.

[Inocudom]

But terasology has a very limited height range (it is like Minecrafts.)

this thread is about graphics, not about comparing game play.

But Calinou brought up Terasology, so I thought I would mention that.

Quake 3 Arena and Half Life have colored lightrays in them, but those weren't voxel games. I guess one of the issues is that lighting colors would have to be stored in the map database, which could result in a noticeably larger file size in the end, even with leveldb and redis. But suppose lighting nodes had set colors. What then?

[Jordach]

But terasology has a very limited height range (it is like Minecrafts.)

this thread is about graphics, not about comparing game play.

But Calinou brought up Terasology, so I thought I would mention that.

Quake 3 Arena and Half Life have colored lightrays in them, but those weren't voxel games. I guess one of the issues is that lighting colors would have to be stored in the map database, which could result in a noticeably larger file size in the end, even with leveldb and redis. But suppose lighting nodes had set colors. What then?

Or use nodemeta to store the colour value of the lighting, it's THREE BYTES OF INFO, not MEGABYTES.

[Inocudom]

But some people might interpret those three bytes being for every single node, thus they might think that a map of 2GB will become 8GB. Surely, such an increase in map size would not happen.

[Calinou]

But terasology has a very limited height range (it is like Minecrafts.)

this thread is about graphics, not about comparing game play.

But Calinou brought up Terasology, so I thought I would mention that.

Quake 3 Arena and Half Life have colored lightrays in them, but those weren't voxel games. I guess one of the issues is that lighting colors would have to be stored in the map database, which could result in a noticeably larger file size in the end, even with leveldb and redis. But suppose lighting nodes had set colors. What then?

Quake 3 Arena, Half-Life, Team Fortress 2, Sauerbraten… use pre-computed lightmap textures (thus, the lights are not volumetric in any way, even though models adapt in a fake way their colour and shading to the environment, which means they generally look out of place). They take hours to generate in large maps.

Coloured lighting would multiply by 3 the storage needs of light, but also the computing needs of light, except if you find a way to optimize things when no colours are present in a block.

[Inocudom]

But some people might interpret those three bytes being for every single node, thus they might think that a map of 2GB will become 8GB. Surely, such an increase in map size would not happen.

So this statement would basically be true?

[Jordach]

But some people might interpret those three bytes being for every single node, thus they might think that a map of 2GB will become 8GB. Surely, such an increase in map size would not happen.

Wrong, you can quite simply store them as special nodemeta, allowing custom colours on the fly. (Disco balls anyone?)

This means that non lighting nodes can easily produce the same space, while the new lighting nodes use their node storage.

[Inocudom]

But some people might interpret those three bytes being for every single node, thus they might think that a map of 2GB will become 8GB. Surely, such an increase in map size would not happen.

Wrong, you can quite simply store them as special nodemeta, allowing custom colours on the fly. (Disco balls anyone?)

This means that non lighting nodes can easily produce the same space, while the new lighting nodes use their node storage.

That is one steel gate out of the path, but others exist, as Calinou made quite clear.