Not really. I'm just saying that it's feasible. It's ALREADY possible in game to constantly place torches in front of you on the ground while you're running, and it doesn't cause the game any performance issues. And if you're playing Survival Multiplayer, the player running behind you can take the torches off after you place the next one.
It's not a guess, it's simple facts.
I even suggested a way it could do it, by creating a new invisible block that doesn't block movement (similar to how Reeds, torches, ladders, all don't block movement) but generates light (torches generate light) and have that block get automatically placed and removed by player movement (rather than right clicking). The game has to keep track of a player's X and Y and Z positions anyway, so it'd just have something that checks whenever a player moves out of some space and places a new pseudotorch at the new space, and removes the one at the old space. It wouldn't be interactable (you'd sight through it, like you can with stairs or ladders from the side) and it wouldn't destroy blocks already there (so if you walked in front of a ladder, or through reeds, the light would temporarily go out).
Then if your torch runs out or you stop holding it, it would just remove the pseudotorch in your space.
It'd have some small weird cases (such as having your torch go out if you stand in front of a ladder) but it would still be feasible... and I'm sure it could be managed to work even in those cases, somehow.
I don't think it's impossible, it just wouldn't be particularly elegant or easy to implement. I also think it would make the game rather easy...
I don't think it'll happen, not without decimating FPS.
Look at that square sun; it sets, yes? When it sets, light is recalculated like mad. The game lags.
The lag would happen all the time while you carried the torch/portable light, I think.
Rollback Post to RevisionRollBack
Ha! I don't even know the meaning of the word, "Illiterate!"
the diff between constantly placing a torch in front and deleting the 1 behind and having it done automatically for you...?
why would this lag us more than we already are lagging?
i always thought that a way to make this work is to have it when the player runs with whatever item gives you moving light that the game places a invisible torch every 2 blocks, then after the player is 2 two away it automatically deletes its self. sure it may not be super smooth but its the same as placing a torch, which doesnt affect lag.
but what do i know
I like this idea. It's simple and could use the same thing that renders the blocks in the beginning. Then when it deletes, use the unrender for when you walk away from the block. I'm guessing notch could take that *above* code and copy the code and edit it for a special exception for these invisible torch blocks.
We are talking about modifying a few hundred vertex values per frame.. on computers that can perform a billion calculations per second.. spare me the naive performance-rant.
Clearly the issue is that currently, light sources are only allowed on integer positions, and that having a light follow the player while pegging the source to the nearest integer position doesnt make for a smooth lighting experience (from an animation-perspective) ..
Probably the rendering engine he is using only allows access to the fixed function pipeline, and in that case the fixed-function feature that could have easily handled a lighting-sphere around the player is already being used (for fog.)
Probably the rendering engine he is using only allows access to the fixed function pipeline, and in that case the fixed-function feature that could have easily handled a lighting-sphere around the player is already being used (for fog.)
Block lighting has nothing to do with the rendering engine. 16 different levels of brightness are stored within block data, and the rendering engine just looks at the brightness level when texturing blocks.
To be honest, the issue about lag seems untrue. Like others have pointed out, the current lighting model is fast enough to update while you are placing torches on the ground/walls as you move. It would be merely adapting the lighting engine to allow virtual light sources, which shouldn't be too complicated to do (if it isn't that way already!). By virtual I mean a light-emitting entity does not have to occupy the same memory space as the block information, so you don't have issues like a light source inside a doorway/water.
It would be virtually the same thing as spawning an invisible torch and moving it to another position when your character fully steps into a new block. No smooth transitions, just snapping the moving light source to the game grid. This looks very reasonable to me.
Now this is something I can agree with: that it could look and feel very bad. But I'm not convinced it would be THAT bad. I'd love to see a test run.
But what I'd really like to know is where and when has Notch made these statements about moving lights, and what did he say exactly. Maybe what he said was "I tried it, but it didn't look smooth enough, and that's impossible in the current engine." I'd be willing to accept that.
If anyone can point me to a direct source so I can quote him, that'd be a great addition to the fact-checking thread.
That would be awesome, walking around in the dark, and then... Shoof...BOOM. A meteor rockets downward into the ground! Then you rush to check out the meteorite landing site, and grab some rare ore. :biggrin.gif:
Probably the rendering engine he is using only allows access to the fixed function pipeline, and in that case the fixed-function feature that could have easily handled a lighting-sphere around the player is already being used (for fog.)
Block lighting has nothing to do with the rendering engine. 16 different levels of brightness are stored within block data, and the rendering engine just looks at the brightness level when texturing blocks.
Excuse me sir, thats block-lighting-by-torch. That is not block-lighting-by-a-dynamic-object.
You are essentially trying to argue that a feature that doesnt exist isn't done by the rendering engine. Well, DUH. Of course it isn't. It doesnt exist.
The player-as-a-light-source could have been done with the fixed function pipeline for free, at the expense of not having fog. Its the way the old DirectX 8 games such as the original Half-Life did its flashlight, in spite of not having a programmable pipeline. It didn't even require the use of pixel or vertex shaders, although can still be emulated with them. The fixed-function pipeline has a fog stage, and the fog stage is nothing more than interpolating between vertex colors and a defined color (for example, BLACK for emulating a local light source, WHITE for emulating fog) based on its distance from the camera.
The regular vertex lighting that already exists in the game could continue to be accomplished in the same way as now, but making sure to use the emissive color fields instead of the diffuse color fields (if the lighting is all precalculated, there is no reason to use diffuse vertex colors anyways)
It's not a guess, it's simple facts.
I even suggested a way it could do it, by creating a new invisible block that doesn't block movement (similar to how Reeds, torches, ladders, all don't block movement) but generates light (torches generate light) and have that block get automatically placed and removed by player movement (rather than right clicking). The game has to keep track of a player's X and Y and Z positions anyway, so it'd just have something that checks whenever a player moves out of some space and places a new pseudotorch at the new space, and removes the one at the old space. It wouldn't be interactable (you'd sight through it, like you can with stairs or ladders from the side) and it wouldn't destroy blocks already there (so if you walked in front of a ladder, or through reeds, the light would temporarily go out).
Then if your torch runs out or you stop holding it, it would just remove the pseudotorch in your space.
It'd have some small weird cases (such as having your torch go out if you stand in front of a ladder) but it would still be feasible... and I'm sure it could be managed to work even in those cases, somehow.
I don't think it's impossible, it just wouldn't be particularly elegant or easy to implement. I also think it would make the game rather easy...
I don't think it'll happen, not without decimating FPS.
Look at that square sun; it sets, yes? When it sets, light is recalculated like mad. The game lags.
The lag would happen all the time while you carried the torch/portable light, I think.
why would this lag us more than we already are lagging?
[SSSS]
I like this idea. It's simple and could use the same thing that renders the blocks in the beginning. Then when it deletes, use the unrender for when you walk away from the block. I'm guessing notch could take that *above* code and copy the code and edit it for a special exception for these invisible torch blocks.
Clearly the issue is that currently, light sources are only allowed on integer positions, and that having a light follow the player while pegging the source to the nearest integer position doesnt make for a smooth lighting experience (from an animation-perspective) ..
Probably the rendering engine he is using only allows access to the fixed function pipeline, and in that case the fixed-function feature that could have easily handled a lighting-sphere around the player is already being used (for fog.)
Block lighting has nothing to do with the rendering engine. 16 different levels of brightness are stored within block data, and the rendering engine just looks at the brightness level when texturing blocks.
It would be virtually the same thing as spawning an invisible torch and moving it to another position when your character fully steps into a new block. No smooth transitions, just snapping the moving light source to the game grid. This looks very reasonable to me.
Now this is something I can agree with: that it could look and feel very bad. But I'm not convinced it would be THAT bad. I'd love to see a test run.
But what I'd really like to know is where and when has Notch made these statements about moving lights, and what did he say exactly. Maybe what he said was "I tried it, but it didn't look smooth enough, and that's impossible in the current engine." I'd be willing to accept that.
If anyone can point me to a direct source so I can quote him, that'd be a great addition to the fact-checking thread.
MINECRAFT FACTS: BIG LIST OF WHAT NOTCH HAS ACTUALLY SAID ABOUT THE PLANNED FEATURES OF MINECRAFT
Seeing as how you can spam torches with little to no effect on performance, I don't see why it would be impossible to make a moving lightsource.
That would be awesome, walking around in the dark, and then... Shoof...BOOM. A meteor rockets downward into the ground! Then you rush to check out the meteorite landing site, and grab some rare ore. :biggrin.gif:
http://getsatisfaction.com/mojang/topic ... onal_books
I hope to get a lot of support for this!
MINECRAFT FACTS: BIG LIST OF WHAT NOTCH HAS ACTUALLY SAID ABOUT THE PLANNED FEATURES OF MINECRAFT
Excuse me sir, thats block-lighting-by-torch. That is not block-lighting-by-a-dynamic-object.
You are essentially trying to argue that a feature that doesnt exist isn't done by the rendering engine. Well, DUH. Of course it isn't. It doesnt exist.
The player-as-a-light-source could have been done with the fixed function pipeline for free, at the expense of not having fog. Its the way the old DirectX 8 games such as the original Half-Life did its flashlight, in spite of not having a programmable pipeline. It didn't even require the use of pixel or vertex shaders, although can still be emulated with them. The fixed-function pipeline has a fog stage, and the fog stage is nothing more than interpolating between vertex colors and a defined color (for example, BLACK for emulating a local light source, WHITE for emulating fog) based on its distance from the camera.
The regular vertex lighting that already exists in the game could continue to be accomplished in the same way as now, but making sure to use the emissive color fields instead of the diffuse color fields (if the lighting is all precalculated, there is no reason to use diffuse vertex colors anyways)