Project Abandoned/Request permission to Continue?

[Guichaguri]

I know this is not the right place to be asking about this stuff.
This hasn't been updated for a year, and I want to keep the idea alive.
Can I have permission to take the idea, update the mod, recode most of the ASM stuff, reduce dependencies and implement new features? Of course, keeping your name in credits for all of your work.

[heaton84]

I don't know what say I have in the matter these days, but I have
definitely stopped Minecraft development and don't see myself coming back
any time soon.

For what it's worth.

Capn', what say you?

On Mon, Jun 13, 2016 at 5:01 PM, Guichaguri notifications@github.com
wrote:

I know this is not the right place to be asking about this stuff.
This hasn't been updated for a year, and I want to keep the idea alive.
Can I have permission to take the idea, update the mod, recode most of the
ASM stuff, reduce dependencies and implement new features? Of course,
keeping your name in credits for all of your work.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#58, or mute
the thread
https://github.com/notifications/unsubscribe/AGibuId9VRYobAG36AGlyOVsSe0oyrDIks5qLdMtgaJpZM4I0x2U
.

Josh Heaton

[ruyanve]

Cpt sign off a while ago... Someone started to work on the project here: http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/wip-mods/2585070-colored-lights
But I don't know what the status is atm

[Guichaguri]

@ruyanve That one is also inactive for 6 months.

My plan is to recode it to a tweaker instead of a Forge coremod, so it will work with LiteLoader and Forge (and even vanilla) at the same time. (the same thing I've been doing with BetterFps) I also want to make an API using interfaces, so other mods can update without having to remove compatibility or mess with dependencies.
And finally, implement dynamic colored lights.

[CptSpaceToaster]

@Guichaguri You are more than welcome to pick up the idea, and go ahead and run with it! I've always wanted to get back into the swing of things, but time didn't really permit.

Kovu was here from the very beginning, and can be found early on in the forum post, and early implementation. IIRC, he mentioned that he might try to do a couple things himself, but I'm not sure what his approach is doing specifically, other than relying on GL lighting. Don't be afraid to include him in the discussion, but it looks like you would be executing a completely different approach.

If you want to perform another source-replacement using a more up-to-date framework, then you're going to solve a lot of issues that I kept on running into. I might even take a look to see what someone else does with it :)

Good luck, have fun! Feel free to drop a line and ask some questions

[Guichaguri]

@CptSpaceToaster Thank you :)

[Guichaguri]

Strangely enough, making a smooth dynamic light is way easier than colored lights (Only two hooks: World.getCombinedLight and ChunkCache.getCombinedLight)
https://gfycat.com/HonestEsteemedDormouse
I might have to recode the dynamic light to make it work with colored lights, I don't know.
I'll start implementing the colored lights today and we will see

[CptSpaceToaster]

One of the last things I did on the original project involved a conversation with AtomicStryker. We ended up getting both projects to work together, because DL didn't need to mess with the bit-packed lighting values. You might be able to do something similar if you wanted.

[CptSpaceToaster]

@Guichaguri Would you be able to share a link to your current progress, or where you intend to make progress once you get there?

Thanks a ton!

Good luck, and have fun!

[Guichaguri]

Since I'm still experimenting, I will not open the source yet.

https://gfycat.com/NegativeUnfortunateCaiman

The lighting in 1.8+ block rendering is now working. I like this new rendering system because the block/item models have to provide the quads, texture and color, the rendering part is all in vanilla code. So it should work with other mods.

TESR and entity lighting didn't changed from 1.7 to 1.10. But I want to try another solution instead of applying the color in the brightness value, and also try to remove shader dependency.

I redesigned the API:

• IColoredLight: You can implement this class on blocks. (getLightColor)
• ILightEmitter: You can implement this class on entities or particles. (getLightValue, getLightColor)
• IItemLight: You can implement this class on items. It's the same as ILightEmitter, but takes an ItemStack as a parameter.
• ILightTransformer: This is an advanced feature. You have to implement the transformLevel and transformColor methods, and do whatever you want based on the position. Useful for rave lights or custom light types (spot or area lights). The whole dynamic light feature is implemented using this feature.

There is still a class that let you set the block/entity/particle/item light without using the interfaces.
And you also don't need the interfaces to set the light. The Block, Entity, Particle, Item class implement the interfaces, so if you can just override the methods and it will work.

[octarine-noise]

Great work so far, I'm liking this a lot! I also have some questions:

How are the colors applied (or will be applied in your preferred solution) to the vertices? I'm trying to gauge how difficult it would be to support colored lights in a custom block renderer.
Will the color values simply modulate AmbientOcclusionFace.vertexColorMultiplier?
Is it all business as usual in Java-land and the colors applied by a shader program?

Would it be possible to get some kind of transform curve / tone mapping going? I found that I didn't like the linear additive color mixing in @CptSpaceToaster 's mod very much, as the "physical" and psychological brightnesses didn't match.
Blue, in particular, was very easily dominated by the other 2 main colors even at high brightness, and didn't have a strong effect on the apparent color of blocks.
Green on the other hand was very bright and prominent even at low brightness.

[Guichaguri]

@octarine-noise
The colors are applied just before VertexBuffer.putPosition in BlockModelRenderer.renderQuadsFlat and BlockModelRenderer.renderQuadsSmooth. I use VertexBuffer.putColorMultiplier, it multiplies the color already set, so no need to worry about conflicts

The color mixing is what I'm willing to change. I think it's better to finish the hooks before start discussing about the formula, but I see what you are saying:

(I also messed up something in the render, you can see horizontal lines)

[CptSpaceToaster]

@octarine-noise: Your points are valid. I would like to remind everyone here that the default light map for moonlight will actually tint objects blue. If you test things at nighttime out in the open, you'll likely see that a Blue Lamp is "not as bright" as the other lights, because Minecraft is already tinting objects blue-ish/purple-ish to begin with, and washing it out.

This does make some sense when you think about the moon coming into play, as a Blue Lamp and the moon light ought to wash each other out because the moon is a blue light source. Heading into a cave to remove the effects of the moon light makes things look a little more balanced, and I'd be interested in hearing what you have to say about the balance when moonlight doesn't come into play.

This is a bit touchy to "fix" because the blue tint can't easily be removed from the ticking sky light map without changing how things look normally, but the results leave us with the problem: Blue (and Red a bit) don't appear to be as significant when compared to a Green light. If you change the balance, by capping/limiting green lights from becoming as vivid, then you might solve the color difference while outside, but create a different problem while indoors.

I could be wrong here, but I was always of a similar opinion anyways as far as @Guichaguri is concerned. Get stuff working first, get picky about colors later.

[octarine-noise]

Completely agree with that philosophy, I just thought I'd put it out there, in case it impacts design decisions. It's never too early to think too much ahead :)

I didn't know about the blue tint of the moon. That explains a lot, but it's not the whole story, because you can see this underground too, just a little less pronounced. Our eyes are just not as sensitive to blue and red as to green.

The solution to this depends a lot on the implementation of the new lighting system. If the RGB channels still go 0..15 and are calculated per-block like vanilla light is, then a 16^4 sized LUT (red/green/blue/sky) might be the way to go. Might even load the color balance data from resource packs, as it is certainly a large component of the visual mood.

[CptSpaceToaster]

Based on this comment and the changes in 1.8, I think it's getting easier to color light sent to the rendering engine, however the questions remain

1. Are we doing it wrong?
   and
2. Is blue harder to see, or is it being washed out by an existing tint?

I totally understand that Blue is harder to see in most cases, and that Blue lights in CLC didn't look as bright as Green.

I'm not convinced that the solution is to punish green (and maybe red a bit). There are a number of things at play here, and I think the default color map is already biased towards blue, making blue lights appear less intense. It's very noticeable at night out in the open (where a screenshot of a pure white block will show up as some sort of light blue. Depending on how far in a cave the player is, moonlight can still make things blue. Removing green's intensity doesn't feel like a good solution, because it addresses a symptom, rather than a problem from my standpoint.

Also note, torches currently emit "more red/yellow" and are far from a neutral white source.

Here's an album of a pure white texture (custom texture pack, with pure white quarts) and color values.
http://imgur.com/a/P87Bx