Yes, they do. And it brings the frame-rates back to normal.
New Release D3D9Client Development
- Thread starter jarmonik
- Start date
SolarLiner
It's necessary, TARS.
Could you send your LightBlur.hlsl and LensFlare.hlsl files (found in the /Modules/D3D9Client) ? It shouldn't be darker than the stable release. Furthermore I can't reproduce the issue.
Here you go: https://dl.dropboxusercontent.com/u/24122088/D3D9Client_HLSLs.zip. I verified that these are the ones included in the your zip file. Just for verification purposes here's the details:
And here's a screenshot:
- LensFlare.hlsl - 6 334 b - 20 August 2016, 21:25:47
- LightBlur.hlsl - 3 426 b - 10 May 2016, 01:23:09
And here's a screenshot:
Last edited:
SolarLiner
It's necessary, TARS.
The timestamps check out. The LightBlur is the original one by jarmonik since I worked on it as part of the HDR feature branch.
Also, I don't see the screenshot as dark. Planet glow is certainly cranked quite up but even direct sunlight doesn't seem really dark.
Also, I don't see the screenshot as dark. Planet glow is certainly cranked quite up but even direct sunlight doesn't seem really dark.
SolarLiner
It's necessary, TARS.
As expected the diff between the branch and your HLSL files are empty.
Can you take a screenshot with and without post processing?
---------- Post added at 02:42 ---------- Previous post was at 02:40 ----------
Whoa okay, this is definitely too dark. Does it happen with a brand new install of Orbiter RC4 + this build ?
Can you take a screenshot with and without post processing?
---------- Post added at 02:42 ---------- Previous post was at 02:40 ----------
Whoa okay, this is definitely too dark. Does it happen with a brand new install of Orbiter RC4 + this build ?
SolarLiner
It's necessary, TARS.
A good night of sleep and some fresh eyes later, I found the culprit:
LensFlare.hlsl, line 174:
I had raised the final output to counteract the brightness effect of the Reinhard tonemap. Now that it doesn't exist anymore, all this did was change the gamma down to linear, hence the dark looking result.
The new file is attached.
LensFlare.hlsl, line 174:
PHP:
float3 color = pow(max(0.0, Screen(orig, flare)), 2.2);I had raised the final output to counteract the brightness effect of the Reinhard tonemap. Now that it doesn't exist anymore, all this did was change the gamma down to linear, hence the dark looking result.
The new file is attached.
Last edited:
That fixes the darkness issue. Now the only real issue is the frame rate reduction when the lens flares come into view. It seems dependent on actual sun blockage, IE, the more the sun is blocked by something (most likely a vessel) the more intense the frame reduction is.
SolarLiner
It's necessary, TARS.
Yes. When direct sunlight is blocked, the code does nothing and simply returns the image without doing anything. Else, the whole lens flare code is applied.
One of the first things I'll do is to separate the process into two parts: when the sun is within the camera frustum, and when it's outside. I still want to have the flare appear, but because it is outside of the frame, a simpler code should be executed.
Furthermore, the current setup does the job as a proof of concept, but I want it to be actually beautiful... and more realistic.
So I've closed everything I could to make the room as dark as possible, and took some photos of my phone's flashlight directly (I have a Canon 1100D, and I shot it with a 55-250mm lens, if anyone's asking).
The result is that, well... There's more to them then anyone could have imagined :rofl:
The resulting lens flare are simple (not a lot of components) but quite interesting: the further out to the edge the light source is in the frame, the more "egg shaped" the flare becomes. This is similar to what happens with out of focus blur. Also the glare of the light source is more diffuse at a low aperture (f/4.5 in my shots), but the "light streaks" appear on higher apertures levels (f/22 here). Given the no DoF and the high brightness, I can safely assume the aperture will be set high :lol:
I've already got some code I wrote for "barel distorting" DoF here (set the anamorphic distortion to 0 so better see the effect), surely this could be easily ported to this Lens Flare shader.
Actually, the best thing would be to implement this badboy: http://resources.mpi-inf.mpg.de/lensflareRendering/pdf/flare.pdf :lol:
---------- Post added at 16:03 ---------- Previous post was at 14:03 ----------
Here's a new version of the LensFlare shader. Barrel distortion is pretty much there, and it's now more subtle, and more colorful!
SolarLiner
It's necessary, TARS.
Please test this new version of the Lens Flare feature branch.
Looks good. I really think that the frame rate reduction needs to be dealt with. What good is this if it causes a 60% frame rate reduction?Please test this new version of the Lens Flare feature branch.
SolarLiner
It's necessary, TARS.
I haven't had really got into it yet since I am still in the "making things" phase, but the only time I have frame dropping while Post Process active is while terrain is loading. It drops down to 100 fps before shooting back up to 400. Without post processing I'm at 550-600.
There will undeniably be a footprint because it is a moderately complex shader, but the seemingly random framerate drops sure are bizzare. Especially when you say that the framerate drops when sunlight is blocked - which, in the contrary, blocking sunlight should improve framerate because the whole lens Flare rendering code is bypassed...
Yes. I'm not sure what's going on here. Is there way to enable some sort debug mode to see exactly what's going and when? It might be another bad line hidden in plain sight like the darkness bug.
Edit:
New information: I think that I have it nailed down to mesh complexity. I just ran a test with the default Atlantis and suffered only a slight reduction in FPS (less than 2%). And then I ran a test with SSU which has a much more complex and detailed mesh and I suffered the severe frame rate reduction I had been previously reporting on. I'll run another batch of tests with simple 50x50x50 m cube with various levels of complexities and see if this confirms what I am seeing with the shuttles.
---------- Post added at 05:35 AM ---------- Previous post was at 05:12 AM ----------
The "cube tests" did indeed confirm what the shuttles were showing, that it is the complexity of the occulting mesh that determines the frame reduction.
Last edited:
The lens flare implementation uses a ray-mesh intersection check that's intended to be used with mesh debugger to check which mesh group is clicked by mouse. It works well on that purpose but not with real time graphics. There is a new occlusion check algorithm in the works and it's partially implemented already. But I am currently stuck in a pretty tricky and boring sketchpad implementation to allow to have multiple sketchpad instances open at the same time. Font rendering improvements been made too. I'll need to get that out of my hands first.
But still the frame rate impact from the lens flare is very high. I get 550 fps when viewing DG in "DG Mk4 in Orbit" scenario while the sun being behind the camera. With post processing enabled the framerate drops down to 210 fps. Which suggest that the lens flare is heavier than everything else together. I haven't tried how it runs with my HD Graphics 4000 laptop. But since the lens flare is optional feature the performance doesn't matter that much.
If the sun is occluded by Delta Glider the framerate is about 350 fps
It should be possible to pre-render the flares into a textures and then blit them on screen with a proper blending to archive a smooth transition between different shapes.
But still the frame rate impact from the lens flare is very high. I get 550 fps when viewing DG in "DG Mk4 in Orbit" scenario while the sun being behind the camera. With post processing enabled the framerate drops down to 210 fps. Which suggest that the lens flare is heavier than everything else together. I haven't tried how it runs with my HD Graphics 4000 laptop. But since the lens flare is optional feature the performance doesn't matter that much.
If the sun is occluded by Delta Glider the framerate is about 350 fps
It should be possible to pre-render the flares into a textures and then blit them on screen with a proper blending to archive a smooth transition between different shapes.
Last edited:
SolarLiner
It's necessary, TARS.
That's the "classic" way, and the way most games still do it. Space Engine has a very complex implementation of textured lens flare that allows for easy customization of every part - but it always felt off to me. The parts are that: parts; they don't evolve, they just move on screen.
That being said, it is possible to manipulate the shapes by working on the tex coords...
The thing is, the Lens Flare is arguably the most complex part the GPU card has to render every frame. Besides that, all the GPU does is pushing triangles out of the world into the screen, which it can easily do 2 million of. Assuming forward rendering techniques, every mesh adds load with light calculation. Many cur-gen games have post-processing shaders on top of that, and those are by far the most complex since it has to process the entire shader for each pixel, every frame. The more frames, the more pixels, the more workload. Screen space shaders are expected to be heavy on the GPU anyway.
Hi guys,
I just updated everything to the latest relases and it seems to me that from far away the default atmospheric fog effect of earth and mars is really too much intense. That's my opinion of course, just give a look at the following screenshots I made, I think it could be useful. (took real pictures online)
I just updated everything to the latest relases and it seems to me that from far away the default atmospheric fog effect of earth and mars is really too much intense. That's my opinion of course, just give a look at the following screenshots I made, I think it could be useful. (took real pictures online)
GLS
Well-known member
I just noticed a "bump" in the framerate in SSU exclusively in D3D9 and tracked it down to this:
The frame where this code runs takes about 0.5s, compared with about 0.05s for the previous and next ones.
There's no change between using the "add" or the "set" flags, and the oapiEditMeshGroup calls return 0. No messages show up on any logs. In Orbiter2010 no such "bump" occurs.
Code:
GROUPEDITSPEC grpSpec;
grpSpec.flags = GRPEDIT_ADDUSERFLAG;//GRPEDIT_SETUSERFLAG;
grpSpec.UsrFlag = 0x00000002;
DEVMESHHANDLE hDevMLP = GetDevMesh( vis, msh_idx );
oapiEditMeshGroup( hDevMLP, GRP_LSRB_water_bag, &grpSpec );
oapiEditMeshGroup( hDevMLP, GRP_LSRB_water_bag_water, &grpSpec );
oapiEditMeshGroup( hDevMLP, GRP_RSRB_water_bag, &grpSpec );
oapiEditMeshGroup( hDevMLP, GRP_RSRB_water_bag_water, &grpSpec );There's no change between using the "add" or the "set" flags, and the oapiEditMeshGroup calls return 0. No messages show up on any logs. In Orbiter2010 no such "bump" occurs.
Thanks, I'll try to tune the atmospheric look to be more realistic.
kuddel
Donator
- Joined
- Apr 1, 2008
- Messages
- 2,163
- Reaction score
- 658
- Points
- 113
I fully agree :thumbup:
