hd lighting abilities?

[jordan4ibanez]

i was reading about irrlicht and i noticed that it is capable of lighting in hd...could this mean that there could be dynamic torch light? or dynamic TEXTURED (coloured) torch light? or how about orange glow at sun down? or blue darkness early in the morning? THAT would be amazing!

[neko259]

celeron55 is afraid of making the game too slow on old computers if the dynamic lighting would be enabled. Mayba this can be done optionally?

[Jordach]

And beat MC hands down.

[jordan4ibanez]

thats the thing!! my friend is running minecraft on a p4 2.6 ghz with
like 512 gb of ram and nvidia 5200 fx (128mb vram) on half settings!
this game is 1/10th the weight of minecraft! all this stuff will be
possible if we have settings to enable and dissable some of the
bulkier features on minetest after their developed!

[Hackeridze]

like 512 gb of ram

O_O

[Staffs]

like 512 gb of ram

O_O

I think he meant MB

[cisoun]

Would be interesting! I've got also an old Dell P4 1.8Ghz 512Mb with Nvidia Geforce 5600FX, that would be cool if it works on it!


Edit: Or we could just use the Doom 3 engine? Ok I'm out... ->[]

[sdzen]

if I had the amount of ram he has 512 gb I would consider looking outside to remember what the sun looks like

[jordan4ibanez]

if I had the amount of ram he has 512 gb I would consider looking outside to remember what the sun looks like

i meant mb

[sdzen]

I know I was Just Teaseing

[Teravisor]

If you implement dynamic lighting correctly, you can't lose anything. you might only win.
Old machines turn it off and get static lighting like the one right now
Not-so-old do dynamic lighting themselves and ignore(ideally not even receive? - meaning less bandwidth usage) lighting bits.

Though getting yourself into making correct dynamic lighting might be just time-consuming.

[neko259]

Yes, dynamic lightning must be implemented. Also we must have an ability for entities to emit light.

[Nemo08]

Yes, dynamic lightning must be implemented. Also we must have an ability for entities to emit light.

+100500!

[sdzen]

+∞

[MrThebuilder3]

Yes, dynamic lightning must be implemented. Also we must have an ability for entities to emit light.

+inf

[RAPHAEL]

+

Actually wouldn't bother me one way or the other if it was implemented. However I would be interested in MORE lighting. AKA a higher light max.

[celeron55]

The problem with hardware lighting is that you cannot use the voxel lighting and hardware lighting simultaneously without shaders, and nobody is willing to or capable of creating such a system. Including me,

[neko259]

The problem with hardware lighting is that you cannot use the voxel lighting and hardware lighting simultaneously without shaders, and nobody is willing to or capable of creating such a system. Including me,

You mean shaders support isn't implemented in irrlicht? Or you don't want the game to bound users or old computers? But this also slows the game on modern hardware and wastes its features that aren't used.

[jordan4ibanez]

i have taken this on my own to rewrite the lighting to accommodate hd/dynamic/textured lighting with help from members of the irrlicht community. wish me luck.

[neko259]

i have taken this on my own to rewrite the lighting to accommodate hd/dynamic/textured lighting with help from members of the irrlicht community. wish me luck.

I wish you luck!

[jordan4ibanez]

thank you..this could take me weeks or months

[neko259]

Mesa driver supports opengl3 now, so we can use modern graphics features even on computers with old graphics cards. Of course they will be emulated by CPU.

[wokste]

The day / night system currently gives problems. I think we should have fluent transitions. Here is a suggestion for implementation:

Code: Select all

u8 MapNode::getLight(u8 bankLevel, INodeDefManager *nodemgr) const
{
    // Select the brightest of [light source, propagated light]
    const ContentFeatures &f = nodemgr->get(*this);
    if(f.param_type == CPT_LIGHT)
    {
        return (
            (param1 & 0x0f) * (16 - bankLevel) +
            (param1>>4)&0x0f * (bankLevel)
        )>>4;
    }
    if(f.light_source > light)
        return f.light_source;
    return 0;
}

bankLevel must be an uint8 between 0 and 16. 16 means day, 0 means night. I suggest a sin-like curve for the float.

A word on efficiency. I do not know what the if statements do, but if statements and type conversions are relatively expensive for a computer. To further improve speed, this can be changed in a macro. (to avoid a function call). This will look somewhat like:

Code: Select all

#define getLight(block,bankLevel) (((block).param1 & 0x0f) * (16 - (bankLevel)) + ((block).param1>>4)&0x0f * (bankLevel))>>4)

Note: This code is neighter compiled nor tested

[kahrl]

The day / night system currently gives problems. I think we should have fluent transitions. Here is a suggestion for implementation:

Code: Select all

u8 MapNode::getLight(u8 bankLevel, INodeDefManager *nodemgr) const
{
    [snip]
}

bankLevel must be an uint8 between 0 and 16. 16 means day, 0 means night. I suggest a sin-like curve for the float.

That's what getLightBlend() is for.

A word on efficiency. I do not know what the if statements do, but if statements and type conversions are relatively expensive for a computer. To further improve speed, this can be changed in a macro. (to avoid a function call). This will look somewhat like:

Code: Select all

#define getLight(block,bankLevel) (((block).param1 & 0x0f) * (16 - (bankLevel)) + ((block).param1>>4)&0x0f * (bankLevel))>>4)

Umm, you know that a function that is defined inside class {} is inline?


BTW, the actual reason that the day-night transition is not smooth is that time_to_daynight_ratio (from utility.h) returns only three discrete values (350 at night, 750 at sunset and sunrise, 1000 during the day). I started changing that in my shaders_v2 branch (be sure to set enable_shaders=0 in minetest.conf if you want to try it). However, the patches force a lot more mesh updates when the daynight ratio is changing.

[wokste]

Thanks for the reply, appearantly I didn't understand the code as well as I thought. Your explanation helps a lot. I also like to hear that someone is already working on it.

Umm, you know that a function that is defined inside class {} is inline?

I didn't know that. Thanks again.