Print

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

[mifki]

Also it does not help any way to twbt-rendermax compatability.

Why? Well, not exactly "compatibility", but if we just pass the required data to the shaders and perform further calculations there, we could combine them in one plugin/set of shaders. Or maybe it could even be separate plugins each adding some data to send to shader stage, and several separate shader source files defining rendering/postprocessing stages.

[Warmist]

Also it does not help any way to twbt-rendermax compatability.

Why? Well, not exactly "compatibility", but if we just pass the required data to the shaders and perform further calculations there, we could combine them in one plugin/set of shaders. Or maybe it could even be separate plugins each adding some data to send to shader stage, and several separate shader source files defining rendering/postprocessing stages.

That might work. Has anyone done any asking around how many people will have the hardware for this?

[mifki]

Also it does not help any way to twbt-rendermax compatability.

Why? Well, not exactly "compatibility", but if we just pass the required data to the shaders and perform further calculations there, we could combine them in one plugin/set of shaders. Or maybe it could even be separate plugins each adding some data to send to shader stage, and several separate shader source files defining rendering/postprocessing stages.

That might work. Has anyone done any asking around how many people will have the hardware for this?

It shouldn't be a problem. OpenGL ES which is sufficient for my needs (and WebGL, see https://www.shadertoy.com/browse) and corresponding desktop OpenGL version are about 8 years old.

[Abadrausar]

Also it does not help any way to twbt-rendermax compatability.

Why? Well, not exactly "compatibility", but if we just pass the required data to the shaders and perform further calculations there, we could combine them in one plugin/set of shaders. Or maybe it could even be separate plugins each adding some data to send to shader stage, and several separate shader source files defining rendering/postprocessing stages.

That might work. Has anyone done any asking around how many people will have the hardware for this?

It shouldn't be a problem. OpenGL ES which is sufficient for my needs (and WebGL, see https://www.shadertoy.com/browse) and corresponding desktop OpenGL version are about 8 years old.

I like this one, impressive modeling of the waves in the sea, with so little code...
But, could this be used to move chosen parts of the actual DF interface pipeline from the CPU to the GPU?
And, if yes, which parts could profit more?

... Shaders is the way to go. In the iOS app I recently changed it to render background colours, tiles, and shadows all with one OpenGL call and just simple shaders. I'd be interesting to finally create a shader-based renderer for desktop DF, so that the shader code could be easily modified for different effects.

I ask this because a full shader-based renderer for desktop DF, could soon become overly ambitious, as lnxt try at it show us, but a more limited in scope project where the easy picks are treated first, have more chances of success or at least, of being interesting enough for the developer, the time required to achieve something ...
In this way, one subsystem at a time, you could end with a whole shader-based renderer for desktop DF, without having noticed it.   
This principle is called the Gandalf´s lemma or also you would better say to Bilbo, little by little, that he has to feed 12 hungry dwarves plus a wizard! or were they hungry philosophers?

[vanatteveldt]

Sorry for the necro, but this looks absolutely awesome and I wanted to try it out. So, I set print mode to STANDARD and ran 'rendermax light' on the dfhack prompt. That worked, but totally kills my FPS.

I'm playing on a laptop (dell xps13) with 4K screen, is that likely to be the problem?

Is there a way to change settings to reduce the burden?

(edit: and I use a tileset, I think Ironhand, with df 43.05)

[Warmist]

Sorry for the necro, but this looks absolutely awesome and I wanted to try it out. So, I set print mode to STANDARD and ran 'rendermax light' on the dfhack prompt. That worked, but totally kills my FPS.

I'm playing on a laptop (dell xps13) with 4K screen, is that likely to be the problem?

Is there a way to change settings to reduce the burden?

(edit: and I use a tileset, I think Ironhand, with df 43.05)

Unfortunately it does not have anything like that.

[Clyybber]

So this is still being worked on?
I could help if there are problems.
Amazing project dare i say

[lethosor]

It's not being actively worked on, but that doesn't mean you can't work on it - it has some performance issues, as mentioned above. Not sure if that's the sort of thing you meant or not.

[Warmist]

So this is still being worked on?
I could help if there are problems.
Amazing project dare i say

One low hanging fruit that i can think of: it uses multithreading to fill out the light values. However it does not use it to propagate the sun. It was just because i was stupid and thought that we are doing this while df is running, but we are not. So that could be moved and it should speed up quite nicely.

On things that would be bit higher - there was an idea by Elone to process world in chunks. Maybe somehow mark which chunks changed, etc. This way it potentially can be very fast (even unnoticeable). However there are no good way to detect that. You could just limit how many chunks to update each iteration but it might be ugly (not sure though).

Next on things i would like to see (and probably no one else) is a better light transport system. Something that would bounce light around. However this was very slow in any form i tried.

Other thing i played around: HDR. Basically setting sun to be 10000 and simulating eye adaptation. This way when you are looking in caves lit by magma it looks okay, outside looks okay and if you see both outside and inside it looks dark inside. All the cool kidsgames use it nowadays. Easyish to do...

Imho lack of last two points this makes forts very dark.


Oh and BIG thing that is missing: TWBT compatibility. I tried to make it happen but i forget what was the problem. Also new twbt exists (twbt-next?) maybe mifki does it in different way? I personally only use the multi-level rendering but it would be nice to have everything from both mods.

Edit: also - shaders. Basically think of a way to best push everything to gpu and let it do the work. This way we could easily (comparatively) have full light ray tracing (imagine having shafts for light to come down, and then silver floor to bounce the light around in the throne room). This of course would depend on gpu and there is (was?) shader based renderer in df itself. So it could even integrate nicely.
I imagine full fort in gpu memory might not fit (i.e. now it only has light sources (3*float per tile) and opacity (3*float) for visible portion and hacks for sunlight) but somebody needs to think about this

[Warmist]

So i've had some time to work on this, and made a new light calculation method. It's loosely based on shadow casting. Idea is that you don't need to visit any cell more than once, whereas old algo(s) were visiting too many cells. Other things good about this method is that it only needs stack and is perfect for shaders.

So it works like this:

Code: [Select]

3->....
 2->.#.
  1->..
      X

You visit cells in rows from 1 to 3 (left to right). If you encounter an obstacle you add it's "shadow" to final layer. To color each point you get the slope of a line from source (here "X") to the cell and sample last layer.

[Clyybber]

So im a bit confused. Is this light plugin also in the official dfhack repo or only in your fork? And if the latter: Would i only need to replace rendermax.lua in my current df setup?

[lethosor]

It's in the official DFHack repo: https://github.com/DFHack/dfhack/tree/master/plugins/rendermax
I think you would have to recompile the plugin if that part wasn't in the repo.

[Warmist]

It's in the official DFHack repo: https://github.com/DFHack/dfhack/tree/master/plugins/rendermax
I think you would have to recompile the plugin if that part wasn't in the repo.

But if you want to see newest changes, they are in my repo under dev-rendemax. However they are not very impressive... I still need to redo everything in shaders, and do a lot of stuff for this to payoff. E.g. now it has some artifacts if you allow for ambient fog. This is apparent e.g in water.

[Warmist]

I cast this spell of necromancy!

So i've been working on this again. Mostly rewrote EVERYTHING (well 70%) to allow for other future uses (like you could ask someday for a full fort "render") better thread support and finally: opencl!

So what is opencl. For those who don't know it's toolkit/thing/driver that allows writing very parallel code. In our case each cell in world could calculate it's own light on it's own "thread" (well it's not exactly a thread) but it's on gpu and very very fast. And if we have more resources to run these light calculations then we could either include more of the map, have more correct light calculations (e.g. atmospheric effects?) or have light bounces (then you would have a use for those metal walls!)

Other thing i sort of stumbled upon is that of light adaptation effect. E.g. if you suddenly see an explosion, first the explosion will look too bright, then the rest of the scene will look dark until your eyes readjust. This allows for more real light simulation (e.g. sun is 100000 lux on avg day, while office lights is 320-500 so you can't display both in non-hdr display) and fun effects, like if you scroll to outside while it's day you would see stuff too bright for a moment.

[Fleeting Frames]

Pretty fast adaptive lights, huh.

Atmospheric effects...I suppose a larger embark might be big enough to have mirages, but wouldn't that amount to roughly same as metal surfaces, given the top-down view?

The "future uses" could be interesting. Don't know yet, but that example sounds like to-be-not-theoretical, given your other work.