[water_wip.gif]

I actually plan a feature like this. The problem is, that this would need multiple sets of FFT textures depending on the wind and a proper way to blend them. Maybe something just lowering the displacement amount and normal impact might be a simple solution.  

Also at shores it should blend from the ocean to more shallow waves. As the wave behavior changes with the depth of the water.

[Ibl Texture Generator for UltraEngine]

Added Panorama-Import with support for hdr images:

Next stop: finishing the cli

[small_optimization]

I got a first version with reprojection working. it is not fine tuned, but in general the algo is very basic. 

This gif shows the debugging of the reprojection.

Red shows the pixels which went offscreen and needs to be rerendered as well.  In the non red area only every 16th pixel is rendered per frame, the others are reprojected from the previous frame.

 

[small_optimization]

ok, doubled the raysteps and reduced the raycasts per frame to 1/16 as a first step to reprojection: and this is the result (with the old raystep range (32-64) i even get around 700-800fps):

[small_optimization]

@Josh, that would be interessting. I have seen some parameters for the screen velocity, but is there already a posteffect texture i can use for that, like albeado or depth?

[small_optimization]

in theory yes,  I still need to figure out the bet weathermap format to support all of them. some systems use just the rgb and some 4 channels with the alpha map. 

[small_optimization]

Not directly, the clouds system is based on a weather texture, where red is used for the overall coverage of  clouds, green is used for the cloud type and blue is used for the cloud wetness.  So if you modify one of the channels it will reflect on the clud rendering. In this case i just pasted "UltraEngine" Logo directly in the red channel. Also you may notice, that currently a plain texture is used which leads to repition, i later will also support cubemaps which can then be used to create individual weather for whole planets.

[small_optimization]

and just to show something how the cloudshape can be modified by an artist or so: 

[small_optimization]

Implemented the downscaling: Maybe some additional AA needs to be added, but all in all it is a big performance increase.

[sneak_peak_clouds]

Yes, this is first basic implementation without nearly no optimizations. E.g the clouds are raymarched at full resolution. Also it uses 128 to 256 steps per ray multiplied by 6 lightcone raymarches per step. What disturbed me more is the high culling time and the useless shadow render and high instance count. But this is something I will investigate further and file a bug report on that later.

[Terrain editing WIP]

I really like the fill button  I was always missing this from the LE-Editor. 

[pfx_pow.png]

3 hours ago, SpiderPig said:

Do you have plans to sell any of your work?  I'd be interested to buy your pre-computed sky

Indeed i plan to sell it, but before that i need to resolve some things. A lot of refactoring, making it easier to use and i need to wait for some engine refinements, so that it will actually work really fast.

[Some fixes and expermental features added to the Scintilla (SyntaxEditor) Widget]

I am using a small helper method to check if the interface is native or not (maybe something like this could make it into the Widget class) and to decide if i could use textures or must use pixmaps:

bool IsNativeInterface(shared_ptr<Interface> i)
{
    return i->GetWindow() != NULL;
}

If the interface is not native and you want or need to interact with the window you need to get it with ActiveWindow() and not use ui->GetWindow().

[Some fixes and expermental features added to the Scintilla (SyntaxEditor) Widget]

The rendering is done by a combination of gdi+ and the basic win32 api. I will send you some code tomorrow. But the keyword is PrintWindow() and getdibits().

[Some fixes and expermental features added to the Scintilla (SyntaxEditor) Widget]

The Airspace problem is a description for mixing different GUI technologies. In this case, the scintilla control uses natively gdi+ and its own window class and HWND. this window is rendered by gdi+ while the rest of the ui is rendered by UltraEngine.  So to show the scintilla control, it must always been on top of the Ultra Engine-Widgets, which means that the z-Index or order doesn't matter and in the gif you can see that the red overlay is clipped by the scintilla control, while with the redirection to the pixmap this is no problem, because i render the pixmap natively in UltraEngine and the original Scintilla Window is hidden. The term mostly comes from WPF and WinForms: https://adityaswami89.wordpress.com/2014/02/24/airspace-problem-wpf/

[Who wants non-square terrain?]

Without voxel-based terrain it would be nice to have the LE2 feature back, where you could mark parts of the terrain invisible. this would allow at least some cave entries and portals to caves. 

[VXRT WIP]

You might consider to port this to the GPU using Computeshaders, i would assume, that you can reach a higher resolution with lower impact than calculating it on the cpu. Keep in mind that Computeshaders can execute parallel so you just need to wait for the last shader. https://github.com/bridgekat/vxrt

[OceanProgress]

No, this is Leadwerks engine. But it is more or less a preparation for ultraengine.