Hi, I have been looking into creating a coloured light mod for Minecraft, and the far the best idea I have come up with would be to enlarge the lightmap that minecraft uses to render sky light and block light together.

 

However, to reference a point on the light map Minecraft uses a short coordinate value so light values (0-15) can be mapped directly to the texture.  The problem I am having is when I try to reference a point in a larger lightmap (say 32 by 32 or 4096 by 16) the coordinates simply do not map correctly and ever Google search I have done says shorts (16-bit integers) cannot be uses in the function minecraft uses to set texture coordinates (glTexCoordPointer) but minecraft obviously does use it.  I just don't get it.  I simply want to be able to use a larger lighmap.

 

If anyone want to see what I'm talking about in the minecraft source (MCP or forge), look up the Tessellator object and draw() in it.

 

If anyone has an explanation on how this function works with shorts or a helpful link please post.

Hi

 

Here's a little bit more background information, although it sounds like you might know it already.

 

http://greyminecraftcoder.blogspot.com.au/2013/08/lighting.html

 

The lightmap texture is set up in

EntityRenderer.enableLightmap()

 

The size is 256x256 (since the blocklight and skylight values are multiplied by 16 when they are stored in the "mixed brightness" number), i.e. each of the 16 blocklight x 16 skylight combinations has a 16x16 texels patch which is all the same colour.

 

( float f = 0.00390625F;  --> 1/f = 256,  i.e. the texels are scaled to each be 1/256 wide x 1/256 high)

 

I suspect (but I'm not sure) that the 16x16 texels patches is necessary because the block textures are also 16x16 texels in size.

 

Not sure how all this will help you, but if you figure it out I'm keenly interested...

 

-TGG

 

 

 

 

Thank you a bunch!  I was wondering why the texture coordinates were shifted 4 bits and had not discovered this function.  I'll look into it now and see what I can come up with.

 

Once again thanks a lot, I post again if I'm successful or run into any more problems.

Update:

Changing scaling to 1/4096 in the EntityRenderer.enableLightmap() function allowed me to change the size of the lightmap to 256 by 256 so I can fit both RGB and skylight values... and it worked!  The block light and skylight blended properly and colours also rendered correctly.  Now I have to implement the three block light values throughout the rest of minecraft and fix the ao calculations, but so far so good!

Awesome :-)

 

Good luck with the AO calcs, they did my head in.

 

-TGG

Update:

ITS WORKING

 

Screenshot:

 

Next on the list:

Smooth Lighting

That is absolutely amazing - Mojang should hire you to handle their lighting code!

This looks like it will be an amazing mod! This all done without base edits?

Nope, this pretty much is incompatible with everything right now.

 

I may be able to make it compatible but there are many problems to fix before I get there.

Alright, so I think I've got a good handle on how minecraft does it AO calculations and rendering and there is a problem.

 

When the blending for a block is rendered, each of the four corners of each face are assigned a brightness which is mixed (it is in the form of coordinates that points to somewhere on the lighmap).  So, when the face is rendered, each corner is given a texture coordinate that corresponds to a smooth version of this map:

 

(pic from this very helpful blog post http://greyminecraftcoder.blogspot.ca/2013/08/lighting.html, thanks Ghost!)

 

So, when I try to do this with my enlarged lighmap (which is pretty much 256 of these lighmaps tacked together) the texture coordinates cover a very large area of the map and end up looking like this:

 

 

Not quite sure how to solve this, I tried setting the colour of the blocks but that was really finicky and not a good solution.  I am going to look into using multiple light textures and layer them to get good blending.

 

If anyone has any suggestions feel free to post 'em!  I'll post again if I have anything worth mentioning.

Hi

 

Wow that looks pretty impressive even if it wasn't the effect you were looking for!!

 

Looks like a tricky problem.  I think the issue is that you're trying to interpolate across four dimensions (R,G,B, skylight) in something that's only represented in two dimensions.

 

I'm not  familiar with OpenGL at all, but your idea of multitexturing with a total of three lightmaps (R * skylight, G * skylight, B * skylight) sounds like a good idea to try.  I also notice that textures can have up to four dimensions which might be another way to get the GFX card to do linear interpolation across four dimensions for you.  Don't ask me how because I'm just guessing!

 

Interesting challenge...

 

-TGG

 

I think of blending the colours into the 16/16 lightmap right before a block corner has is brightness set. You'll need to calculate the colours first then. Don't know if that makes sense with the Minecraft lighting engine.

@TGG

Your 4D interpolation sounds like the best solution out of the two, except it will probable take the most to implement so I've tried the other way and I think it could work.  However I am also extremely new to OpenGL and am having lots of trouble trying to mix the texture with glTexEnvi calls, the solution's probably obvious to someone who knows what their doing. 

 

I've been able to make vanilla lighting work with the two lightmaps (skylight and blocklight, both 1x16 textures) but text stops rendering properly and colours don't work correctly (eg. grass colour, AO, and block shading).  I'll keep looking for a solution.  Any help would me most welcome!

 

EDIT: I took a quick look into it and 4D textures are not supported like I would have hoped and I think they're currently beyond me.

 

@GotoLink

I don't know if I exactly understand what you're suggesting, but Minecraft generates the lighmap once at the beginning of each frame and uses it to render the whole frame.  Changing it for each vertex would probably be incredibly laggy and yield unexpected results.  Thanks for the suggestion though.

 

 

Should I start a new topic to ask for help with the OpenGL problem?  Or just ask here?

Just a guess - since I have ~0 clue of opengl, since it worked without smooth textures, maybe its because of interpolation?

If my math is right you make a 4096 big texture, maybe something else is scaling it down with bilinear filter or something?

 

@ailmanki

You're right, the funky colours were because of interpolation.  So now instead of one 256*256 (or 16*4096) texture, I'm trying to use four 1*16 textures.  I'm having trouble getting the blending to work.

This is a very interesting project!

Awesome stuff mate

 

I'm sure you can just use this thread to ask about the gl stuff as well, its related and besides I'm sure this thread will be an interesting read for others diving into this kind of thing

@Mazetar

Thanks for the interest!  I'll go ahead and post some more stuff then.

 

Since in MC 1.7 their adding official support for shaders, I think they will be a better solution than screwing around with  the glTexEnv stuff (that feature was deprecated in OpenGL 1.3 I think and was added in 1999, almost 15 years old!).  So if anyone has any advice for using shaders for multi-textureing, don't be afraid to post!

 

I have had a look into it and I think it wont be too difficult, a very simple fragment shader will do the trick I think.  I'll just have to figure out how to sample the textures properly.

If the project is finished, can you upload some screenshots and maybe make API of it, so other mods can use it too.

 

BTW, your project looks amazing!

Hi again, just wanted to mention that was able to get a shader working where the glTexEnv failed with vanilla light.  So what that means is I made the lighting system use two lightmaps instead of one (skylight and blocklight) and combine them via a shader, and this worked with smooth lighting perfectly.  So that's a nice step forward. 

 

However, using the shader at only one step of rendering caused a lot of other things to render wrong (like held blocks and items).  This problem will probably be fixed when I finish going through everywhere in the code where the Tessallator.setBrightness member is accessed.

 

Also the first little test I made was made using vanilla MCP, no forge, and I'd like to make this forge compatible with an API and not break anything and forge has a few more things that need to be made compatible to work with this.  This will probably take quite a bit of time and tons of debugging to get it to work properly.  AND Minecraft 1.7 will add official support for shaders with will require a rewrite of the mod, which will probably take a good bit less time than the first.  All in all, don't hold your breath for a final version, it's going to take some time I think.

 

Also, any suggestions how you think the API should be layed out are welcome.

 

Tiedye

I would suggest that for held items, that the light value just be grayscale lighting (i.e. like vanilla).  I don't think its really worth the overhead of trying to do calculated lighting on inventory items and ItemEntity objects.

Also, any suggestions how you think the API should be layed out are welcome.

 

If it would be possible, I'm sure being able to change the light colour based on metadata would be very useful, as many mods have coloured lamps now

 

Either way, an API for this would be great! Best of luck!

@Draco18s

I think when it comes down to it, not Including the coloured lighting may be more of a pain that including it due to fact that the default lightmap is being completely replaced, and since its being done with shaders the overhead should be essentially zero.

 

@luisc99

Thanks for the suggestion!  I'll be sure to do my best to add that, seems like an excellent idea.

 

One last thing, the 1.7 per-release just got released (Yay) so I'll be aiming to release this mod for that instead, so don't expect anything before 1.7.

@Draco18s

I think when it comes down to it, not Including the coloured lighting may be more of a pain that including it due to fact that the default lightmap is being completely replaced, and since its being done with shaders the overhead should be essentially zero.

 

Point.

Another little update.

 

Note that I've been pretty busy with school stuff so that's why I've made so little progress, but here's a screenshot.

 

 

Smooth lighting!  Its using the multi-lightmap with shaders idea and its working pretty well.  Do note however this is just a modification my original test that I used to make the not-smooth-lighting screenshot from before, so extremely incomplete (note black block in hand), and has no semblance of an API.  Just thought I'd post something so you know I haven't given it up.

That looks even impressiver than without smooth lightning.