Torch in hand, gradle

[manu3d]

I just noticed that the torch in the player's hand doesn't light up the environment anymore. The problem seems to be related to what is done in the lightGeometryStencilPass, and in particular the WorldRendererLwjgl.renderWorld() lines:

DefaultRenderingProcess.getInstance().beginRenderLightGeometryStencilPass();
...
DefaultRenderingProcess.getInstance().endRenderLightGeometryStencilPass();

Or am I perhaps missing a setting somewhere? Commenting out the stencil pass (and patching appropriately the following lightGeometryPass) solves the problem, although I don't know what other problems it introduces. I.e. right now I'm not even sure what the stencil pass does in the first place. The picture doesn't seem to change if it's disabled, unless I go very close to an object with the torch, by which point I get something related to the issue [deleted user] has been mentioning recently, albeit without the pixel-scale artifacts he has shown.

I tried to go back into the git log to see if I could find a commit where the torch in hand still worked but I immediately stumbled upon errors seemingly due to libraries having changed. Should I run gradle idea or gradle cleanIdea idea whenever I go back in time a lot? How does this work?

 

[Cervator]

Yeah this is definitely something that changed in the relative past, appearing differently in some contexts like noted on https://github.com/MovingBlocks/Terasology/issues/1486 - if the effect I see is related maybe the light isn't correctly dispersing, just showing as a very bright but limited pattern on very close walls at your exact block level?

Usually the easiest way to find exactly when something changed is going through the builds in Jenkins since it is just one download plus a quick test run. You can either jump back in the dev builds until you find it, or start with the stables to narrow it down. I've got like a hundred builds locally for easy access to historic search

Then if you want to see it in code check out a specific commit and yeah run gradlew cleanIdea idea. And delete the config file and saves of course.

 

[manu3d]

1) Where can I meet this fellow, mr Jenkins? I only heard him by name but never had to deal with him.
2) Good to know about having to run gradlew when going back in time. I guess I'm starting to see the pattern of errors that require running gradlew. I wish there was a way to make this more explicit though. I.e. a warning after git pull or after checking out a specific, old commit.

 

[Cervator]

Mr. Jenkins hangs out at:

http://jenkins.terasology.org/job/Terasology - then you can pick a specific build number, then go to Build Artifacts, then "build" then "distributions" and there's the zip

http://jenkins.terasology.org/job/TerasologyStable holds the stable builds in the same fashion

Yeah I'd like a better way to catch Gradle being in a "dirty" state, so to say. I'm not sure how though. Have pretty much just gotten used to "When in doubt, gradlew" - which can take a while with 50+ source modules

 

[manu3d]

Thanks Cervator, I will now have a chat with Mr Jenkins. Hopefully he'll spill the beans.

 

[manu3d]

I've been talking to Mr Jenkins. He's cooperating, somewhat reluctantly. For example, he didn't want to provide the wereabouts of stable 31's zip, as they aren't in build/distributions. It turns out I didn't need that particular distribution though, so, no big deal.

Speaking of gradle, how about an hybrid, semi-manual approach?

Let's say that when some libraries are changed, the current gradle-related configuration is manually labeled with a simple, progressive, version number (if it hasn't one already), this number being stored somewhere in a commit. Then, at least those using something like git's bash shell could have an alias that redirects a command such as "git pull" to a script preceding the actual git pull command. The script would check for the local version number against the one coming with the pull. If the local number is lower than the one coming with the pull, the script might run gradle or at least warn the developer that he should.

It's not that easy, isn't it?

 

[Cervator]

Some of the older builds died in a fire when our server exploded

I've got some even older ones in a local backup, from way long ago. Hanging on to them for nostalgia and maybe for when we have a plain web server way of serving old builds for the fun of it.

On Gradle - I think we may be able to improve it in IntelliJ by adopting its new project file format. That's the main obstacle for allowing the "Import via Gradle" project option, which gets your IDE set up in a sort of "live" mapping to Gradle, where some/all changes might be applied automatically without having to rerun Gradle manually. In effect that's what we are doing currently - the project files are generated instead of linked, so we have to regenerate to catch updates.

I'm not sure how the situation is with Eclipse.

Running from command line via Gradle tasks is fine since there you run through the whole Gradle workflow no matter what you do.

It will indeed likely take a bit of time to convert to IntelliJ's new format, as by currently importing you lose all our customizations like Git setup, run configs, etc. That needs to be redone somehow.

 

[manu3d]

Exploded.... like literally? How many city blocks did it flatten?

Anyway, I thought it wasn't going to be as easy as I put it...

 

[Cervator]

Hehe, well I'm not sure what caused not one but two HD failures but I like to imagine there was at least melting involved.

 

[Florian]

I created a github issue about torches in hands. Is that the same issue you had?

https://github.com/MovingBlocks/Terasology/issues/1527

 

[manu3d]

I think it's related and possibly the same. Good to have a commit where it all started. I'll investigate the matter further. Are you still having the issue? Because the last PR of mine that went through should have at least temporarily solved the problem.

 

[manu3d]

Digging this thread from the grave to let everybody know that I have been looking into the related code and the code the more than I year ago I commented out (it was causing problem to the held-in-hand torches).

The code under scrutiny is in org.terasology.rendering.dag.nodes, in classes LightGeometryNode and DirectionalLightsNode. It turns out the code in these two nodes is probably worth -three- nodes AND is currently highly interdependent: the nodes -must- be processed in strict sequence as OpenGL state changes in one are relied upon in the next. Obviously this is a no-no and will be taken care of as I migrate the nodes to the new renderer's architecture.

It appears @begla was using a fancy optimization technique called "Light Volumes", using the stencil buffer to avoid some light calculations for fragments (pixels) not influenced by lights. This allows for large numbers of point lights (in the hundreds at least - need to test it) without impacting performance much. The two nodes will therefore eventually become the three LightVolumesStencilNode, LightVolumeLightingNode and MainLightNode.

Simply un-commenting the disabled code turns off the held-in-hand torch for currently unknown reasons. Also, I need to find a way to visualize the light volumes to be sure they are positioned correctly AND display the content of the stencil buffer to make sure the appropriate thing is written to it.

So, finally, I'm on this case.

Tagging @tdgunes, @indianajohn and @Josharias as they might be interested about this.

Ciao!

 

[manu3d]

Further on this topic and with a big help from @Anthodeus I made a bit of a discovery. The line:

for (EntityRef entity : entityManager.getEntitiesWith(LightComponent.class, LocationComponent.class)) {

does not return all the visible torches because the placed one are blocks, not entities. I mean, silly me thinking they'd be entities. Of course they are blocks, what was I thinking.

Anyway, the question for @begla or perhaps @Immortius is: was the Light Volumes optimization technique intended to exclude placed torches? Are placed torches lighting up the landscape purely through the light propagation system and they wouldn't be able to take advantage of Light Volumes anyway?