Irrlicht Engine

BONG

Radikalizm wrote:

ent1ty wrote:I think what he meant is, how will Granyte's implementation look from ground

Yeah, that's what I meant
I'm pretty familiar with atmospheric scattering implementations, having done some prototypes a while back, but although you can combine in-atmosphere (ie. rayleigh/mie on a skydome) and out-atmosphere effects a lot of people separate them, so that's why I asked

my implementation is sean o'neil implementation ported to hlsl so it works from any kind of angle originaly it required two diferent codes to implement in and out of the atmosphere but after looking a little i found that i could combine them with a single if statement
i also reworked the code a bit so that it suport more then one planet

Granyte wrote:

Radikalizm wrote:

ent1ty wrote:I think what he meant is, how will Granyte's implementation look from ground

Yeah, that's what I meant
I'm pretty familiar with atmospheric scattering implementations, having done some prototypes a while back, but although you can combine in-atmosphere (ie. rayleigh/mie on a skydome) and out-atmosphere effects a lot of people separate them, so that's why I asked

my implementation is sean o'neil implementation ported to hlsl so it works from any kind of angle originaly it required two diferent codes to implement in and out of the atmosphere but after looking a little i found that i could combine them with a single if statement
i also reworked the code a bit so that it suport more then one planet

I think the 2 effects option would be better than the if-statement, imo flow control inside shaders should only be used if there's absolutely no other option
The GPU does not handle if-statements like the CPU does, the CPU can do efficient branch prediction which makes if-statements very cheap. The GPU as far as I know does not do this, which make flow control rather expensive

honestly i tested it and irrlicht in it self is to slow for that speed los to mather i get 800 fps when i render the atmospheric scatering without anything else and the if else statement changed nothing

but i was also looking at an option to make the swich statement on the cpu and have the change null some value in the shaders cause anyway i admit that making a calculation 800(fps)*256(vertice per sphere) is FAR from optimised but that will be when i will go into the optimisation part of the project

an other thing is maybe my hardware is uncomon as i have an other shader that make use of more then 8 if else statement and yet it sill run over 250 fps with it (that one will get optimised for sure)


the main reason i went for an if else statement is that a single planet would require 10 diferent material just for the scaterring and it would require keeping track updating them

Waiting for the stencil patch to be reviewed, I implemented the stencil optimization anyway:


It works just fine, and eliminated one branch from the shader, but it's slower. No difference with one light, -5 fps with eight visible. So much for the "optimization" label

Light Space Perspective Shadow Maps are finally working on Irrlicht too!

It has taken me long, quite long... since the times when Blindside told me about these kind of techniques for the first time, but it is finally working. Demo and source soon, i promise.

This is the first implementation, the one from the paper and it is combined with Variance Shadow Maps to soften (somehow...) the final result. . Though, i have to dig more on the LiSPSM internals to optimize more the parameters that allow this to work. And the sampled space isn't optimized at all, it is the viewing volume lean and mean, so it loses quite a lot of precision when you aim directly to the light. That is to be expected.



Its quality can't rival to that of the CSM and PSSM because they are designed make use of the worst approach for shadowmaps (uniform shadow maps) on diferent view volumes, adapting to each position, but my current implementation is quite friendly to these techniques, so, it is in theory posible to combine them to produce an even better shadowmapping algorithm, because, like the CSM and PSSM, Uniform Shadow Maps are the worst case of the LiSPSM too.

But for a single pass shadowmap, this is pretty much the best you will ever have, no PSM singularities, no odd preprocessing, this is it.

No pic this time, just to say that optimizing (with the Forsyth method) the light spheres/cones gave +3% fps.

Well that's clearly a violation of rules in this topic. I vote you are forced to submit a screenshot right now

No, It is simpler than that...!

Eh, fine

The light geometry isn't exactly well tesselated, but still easing the vert load has a measurable effect.

omg Mel really impressive work

Congrats on getting it working Mel, looking forward to seeing how you use it

282 FPS


245 FPS

my current terrain scene node. I worked it from scratch. it's almost 100% done by me. It is basically a LOD based system in wich the detail halves when distance from camera doubles. this grants that all the triangles are drawed almost with the same surface used on the screen. There are few parameters that can be tuned for fit the performance of every machine

-number of LODS (10 in the screen shot)
-minimum distance: disstance is multiplied by the FACTOR for find the next LOD distance.(for the demo is 16. In practice represents the terrain tiles density. A bigger value force the terrain manager to use more tiles in the same LOD)
-maximum distance: maximum distance of view (after that there is the far plane). actually 65536.. so 65 KM. Is not required that a Tile can fit the frustum view (so a tile can be bigger than frustum pyramid. if is smaller nearby tiles are loaded)
-FACTOR: currently is 2 (wich is the best logical approach). can work also with values near 1.41 without showing seams (under that value my algorithm is not able to guess neighbour size and seams starts showing). with Factor = 3 i go down to 80 FPS (same FPS for irrlicht terrain demo at this screen resolution on my machine). Factor = 4 just freeze the machine at 3-4 fps XD


actually i'm going to improve using mesh batchin on the fly (especially for farest terrain tiles wich change less often).
another issue i'm workin on is streaming from HD. I want every LOD editable from external editor. Missing LODS are generated from data of existing lod.
Good point is that many parameters (not all) can be changed in real time to increase/reduce rendering time when needed. Multithreadin is currently working. but I have no editor for such complex system O_O. So what I have done is just reading the same file from the disk wich gives this "nice" result (every file is scaled to fit current tile size.):

That's very nice, I made something similar though since I'm pretty lazy and bad at programming I did it by rendering two terrains in two scenes and overlapping them (rendering the background scene, reset the Z buffer and render the foreground scene) Biggest terrain only has a colormap, and the small terrain has a splat map. (biggest terrain is rendered in the background, and the smaller on the foreground) This way I have a very easy LOD system where low detail objects just dont get rendered when they are near, and high detail objects dont get rendered when they are far.

I was planning on using a fog shader to make the transition less noticeable (instead of it going to a foggy color, it will just suddenly fade to transparency at the edges). Though I haven't worked on it for a while already.

interesting. actually I didn't implemented nothing serious for texturing terrain. My main task now is to get Zbrush working for each LOD. (I wanted to add that functionality to my editor but is probably better write a separate tool for that. is much more simple ). probably a different shader for each 1/2 LOD is needed if I want to get some good looking result.