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

[Guichaguri]

It's true, the sky light is a bit blue at night time, but not block light.
I think this explains why.
I don't think we are doing wrong, if we are, photoshop is wrong too

Using same radius in both gradients (#0000FF and #00FF00)

[CptSpaceToaster]

At this point, monitor color-calibration should also me taken into account.

[UndeadZeratul]

You should be able to detect if the player's computer is running f.lux and adjust color according to their currently set color temperature settings based on the time of day they're playing. /s

[TheMDev]

@Guichaguri I know you were planning on continuing development for the mod. I am looking into continuing development for the mod. Would you be willing to share some the changes you made to mod? Did you end up updating it to 1.8? If I do end up continuing the development you would be given credit to as well.

[CptSpaceToaster]

@MDW01 Go for it! I don't think anyone here will try and stop you. The only news I've heard is another GL Light implementation from Elucent... so if you want to pick up the torch and work on a change down in the lighting engine, you're more than welcome!

And as always: good luck, have fun! Feel free to drop a line and ask some questions

[Guichaguri]

@MDW01 I actually was working on 1.9. The only thing I had was the dynamic colored light code, because I was trying to figure out a better way to register the block light color without having to mess up the brightness value, like CptsModdingLight was doing.

The easiest way to implement it is probably through a fragment shader, but that would break shaders mod. If you want to make both of them work, you'll probably want to use regular (obsolete) OpenGL, which I got working pretty well for the dynamic lights

Email me ( guichaguri@gmail.com ) so we can talk about the mod, and I can send you the code I was working on.

[DarkShadow44]

@CptSpaceToaster I'm working on a few fixes for this project. Do you still accept pull requests, or is a fork in order?

[CptSpaceToaster]

@DarkShadow44 Feel free to do whatever you want. I can attempt to review stuff if you want to go the route of PR'ing it... however I'm not setup to distribute the mod easily... I could rescue all of the accounts and whatnot... but I think forking it to make your own would enable you to publish updates and versions in a more efficient manner instead of trying to go through me.

In addition, I'm not sure what version you're targeting... but if it's NOT for 1.8, then a rewrite using this project as light inspiration is probably all you can really do. (Feel free to steal all of the glowstone assets, etc)

And as always: good luck, have fun! Feel free to drop a line and ask some questions

[DarkShadow44]

@CptSpaceToaster Thanks for your response!
I guess a fork would be best then - even though I don't know how long I'll work on it. Probably just fixing the worst rendering issues, so it's usable for my modpack. Anyways, thanks for providing the source like this!

I'm still on 1.7.10, and that's the version I patched. I currently don't the intention of trying to get it into a newer version, since I won't be using that.

Side question, not sure if you can answer that: The project contains some dummy net/minecraft/ classes for the project to compile against the modified minecraft classes. When running from eclipse, I always have to delete bin/net/minecraft, otherwise those dummy classes get loaded. Is that normal, or how did you work with that?

[CptSpaceToaster]

IIRC those dummy classes were ASM targets to copy bulk portions of bytecode into minecraft source... the class name had to match so that the ASM transformers could literally lift out the bytecode and cram it in minecraft's source. I don't remember how I got things to play nicely with the vanilla classes present in a decompiled environment... I wonder if I was relying on the SRG namespace being present instead?

[DarkShadow44]

AFAIK the dummy classes are just used so java doesn't complain during compilation. At least they are not needed, or rather, must not exist during runtime for me. Anyways, it's just a minor issue, I'm glad I got it to work at all.

Also, for anyone interested, I opened a fork at https://github.com/DarkShadow44/CptsModdingLight