Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Warmist]

So a bit of images first:
Without light adaptation but log light
With light adaptation

So the problem i'm having now is the light adaptation changes the color of light. I'm using an idea i found on one paper that you could just divide by Y component of CIEXYZ color to have semi-working tonemapping. Because as it works now, the light values can (and do) go beyond 1. This makes sense, but we need some way of displaying what that means...

Other problem visible in the second set of images is that bounces are quite stupid. It concentrates the light in middle of cavern.

[Fleeting Frames]

Not only that, but there's the question of where the souther section gets the light when it is disconnected?

As far as the first set of images go, the 2 bounce view feels bit too...naturalized? Sharp? Anyway, feels off to have the colour of soil ramp right next to magma so similar to the colour for the "," in ~ centre of three SE bloodthorn saplings. Comparison next to each other: ▉▉

1 bounce feels better on that front.

I take it the colour of the object light bounces from affects the resultant colour?

Is it too expensive to have the magma underneath the trees in the northern part light them up? It's odd that they're mostly in darkness when things on higher z-level get better lightning even dozen+ tiles away.

[Warmist]

Not only that, but there's the question of where the souther section gets the light when it is disconnected?

As far as the first set of images go, the 2 bounce view feels bit too...naturalized? Sharp? Anyway, feels off to have the colour of soil ramp right next to magma so similar to the colour for the "," in ~ centre of three SE bloodthorn saplings. Comparison next to each other: ▉▉

1 bounce feels better on that front.

I take it the colour of the object light bounces from affects the resultant colour?

Is it too expensive to have the magma underneath the trees in the northern part light them up? It's odd that they're mostly in darkness when things on higher z-level get better lightning even dozen+ tiles away.

Heh... You noticed. The southern part lit because of some bug... The "offscreen" for some reason generates light... Probably something todo with the arrays limits or sth...

And yeah current bouncing just takes the light at the location after first pass and move it into light emitter buffer. Which is not correct to say the least. I need to figure out a diffuse/specular distinction and have colored but not transparent object.

This might need some sort of light directionality. Not sure how to do that simply though...

[Meph]

Bump, because someone brought it up on Reddit once more. We want Rendermax + TWBT

[Warmist]

Bump, because someone brought it up on Reddit once more. We want Rendermax + TWBT

Mostly been overcomplicating everything: current state it does not work, and looks terrible when it does

I'm waiting for mifki to finish his rewrite for twbt integration. I think it will be easier to do then.

[Meph]

Has he even started? ^^

[mifki]

Bump, because someone brought it up on Reddit once more. We want Rendermax + TWBT

Mostly been overcomplicating everything: current state it does not work, and looks terrible when it does

I'm waiting for mifki to finish his rewrite for twbt integration. I think it will be easier to do then.

Hm... What I was going to do is mostly internal stuff related to handling overrides and shouldn't make much difference to you. However, I'm also thinking that eventually, I need to move to shader-based rendering and _that_ maybe will make it easier to add visual effects. Although I don't see how twbt+rendermax can co-exist as two separate plugins anyway. I'd like to have a visual fx framework, where other developers may provide shader code fragments to be included, and have their C++ plugins feed data to them, but I'm not sure it's worth it when there's only rendermax needing this so far.

[Warmist]

Bump, because someone brought it up on Reddit once more. We want Rendermax + TWBT

Mostly been overcomplicating everything: current state it does not work, and looks terrible when it does

I'm waiting for mifki to finish his rewrite for twbt integration. I think it will be easier to do then.

Hm... What I was going to do is mostly internal stuff related to handling overrides and shouldn't make much difference to you. However, I'm also thinking that eventually, I need to move to shader-based rendering and _that_ maybe will make it easier to add visual effects. Although I don't see how twbt+rendermax can co-exist as two separate plugins anyway. I'd like to have a visual fx framework, where other developers may provide shader code fragments to be included, and have their C++ plugins feed data to them, but I'm not sure it's worth it when there's only rendermax needing this so far.

Yeah and in any way it would need a c++ part still where it would calculate stuff from map, unit, buildings etc... so only shader would be not enough and passing EVERYTHING into a shader would be insane

On the other hand it still needs some way of knowing that e.g. if it get's called (by render vmethod) that it's a second call this frame (e.g. multilevel 2nd level). I think it could just have "please calculate light for this region(x=0,y=0,z=0,w=10,h=10,d=10) into this array" function that other plugins could call. This would probably make it into a module so that other plugins could see or do we have other ways to call other plugin functions?

[Betrix5068]

Seeing as it's been a while could I ask what the status of this whole thing is? This thing looks amazing and as someone getting back into DF I would love to use it.

[Fenrir]

I'm currently using it, and the only problem I've had so far is FPS. Reducing the number of caverns, setting special.diffuseCount=0 and capping the GFPS at 30 gets me 100 FPS, but it remains to be seen how that will hold up as the fort ages.

I don't know if there's further optimization that can be done – seems most of the taxing stuff is on the dfhack side of the things and can't be moved into another thread.

EDIT: And I'm using a 3x3 fort size. 2x2 would probably be even faster, given that rendermax will have less map to check.
EDIT 2: Actually, fort size probably doesn't matter for rendermax specifically, since it looks like it's just checking the viewport not the whole map.

[Warmist]

I'm currently using it, and the only problem I've had so far is FPS. Reducing the number of caverns, setting special.diffuseCount=0 and capping the GFPS at 30 gets me 100 FPS, but it remains to be seen how that will hold up as the fort ages.

I don't know if there's further optimization that can be done – seems most of the taxing stuff is on the dfhack side of the things and can't be moved into another thread.

EDIT: And I'm using a 3x3 fort size. 2x2 would probably be even faster, given that rendermax will have less map to check.
EDIT 2: Actually, fort size probably doesn't matter for rendermax specifically, since it looks like it's just checking the viewport not the whole map.

Also now that i think about it, it shouldn't recalculate the light as often. It only needs calculation if: view changed, tick passed (i.e. something in world changed) or you moved your cursor and cursor gives off light.

I'll need to remember this when i come back to this...

[Betrix5068]

Is there any chance of seeing multi-level compatability in the near future? The two are mutually exclusive and while it is a shame to forgo these beautiful lights multilevel is much more fundimental than that and thus takes precidence. If you did get that down like you were talking about pre-necro I would be squeeing.

[Warmist]

Nope! Done nothing in this project.

However my other project was very opengl (and shaders) heavy so it might help moving all light propagation to gpu.

[Betrix5068]

well that's a darn shame. But it's good to know that there's a chance, even if it's still distant.

[flbr]

Hey Warmist, is this still being developed? Though even if it's not, what would I have to do to check it out? This looks super cool!