Jump to content

havok2

Members
  • Posts

    63
  • Joined

  • Last visited

Everything posted by havok2

  1. Example with Planes Different LODs on left and right display I also noticed the whole thing today when I wanted to change the LOD distances for the aircraft models so that many aircraft do not have such massive FPS collapses. Using SteamVR with Valve Index +1
  2. Hey, Snake, as I said I only adapted the driver/emulator. The control is as specified by DCS for the Valve Index Controller. I use it for knobs like I use it with the head controller. I use the switch and keep the "left mouse button" pressed. Now I can look left and right with my head and turn the knob. So with the emulator you have to do the gun gesture and then aim the switch. Now you trigger the knob with your index finger and move your hand to the left or right. Some switches like the DDI brightned always require a trigger with your index finger to turn the knob. Here the whole thing does not work. Some of them seem to only turn when you move the mouse wheel or a mapped button. But here the problem lies in the implementation by DCS. I think that it basically accesses the Capto Glove implementation. Try and error - if you have try it first with real valve index controllers.
  3. Thanks for your input!
  4. Sorry there was music in the background... I uploaded a version without sound. You can see it now.
  5. Hey exactly I was thinking how great it is that there is an emulator and then the hands were completely far away from my real hand position. So it was absolutely useless. I corrected that. Yes the gestures were actually quite well recognized. Here is the driver from me with fix, but without adaptation for DCS. So grabbing is not the same as pressing key A and grabbing. https://workupload.com/file/wZmDQPRq2YA I had tried it with my Valve Index Controllers in the beginning - which is of course crazy with Hotas. There I had to hold button A pressed to activate the hand. Then you saw this "laser". If you now touch one of the buttons or switches in the cockpit with your virtual finger, a left mouse button click is executed. If you turn your hand around, no collision triggering worked. Here you had to use the trigger to press the right mouse button. I just haven't figured out how to pull the lift to fold the wings. Mouse wheel is not used. Because I often use the cockpit with the head I have one button for right click, one for left click and two for the mouse wheel. So I can go with my hand to the switch and use the mouse wheel on the joystick to pull the lever. With CTRL+O / CTRL+P you can also disable or enable the left and right hand. I use most times only the left hand. Here are the complete controls for the Emulator: https://github.com/SDraw/driver_leap/blob/master/README.md#valve-index-controllers-emulation
  6. Hello, Snake122, I just fixed the offset. With the SDraw driver the hands are rotated by about 45°. The only "optimization" is that you now press and hold the A Button with the "gun gesture" and activate the hand to use it. This seemed to be more intuitive than pressing the thumb and middle finger together and triggering the buttons with the index finger. A friend of mine was able to use his hands with the Pimax 5k with my variant. He used SteamVR for that. Best regards.
  7. for the sake of completeness Here you find my fix for the emulator + video. Have fun testing it. https://forums.eagle.ru/showthread.php?t=275731
  8. Hello, pilots, I'm reporting back with a project I got involved in after my LeapMotion Unit with the Valve Index Emulator just didn't work properly in DCS and in general. For all who don't know, the LeapMotion module costs about 90€ and can be mounted and operated directly on the Valve Index or other glasses with a MicroUSB adapter and tape. You can also order a version with an adhesive mount. The module tracks your hands with infrared stereo cameras. With an Emualtor your hands become Valve Index controllers and are theoretically compatible with many games. Unfortunately the Emualtor is not really maintained anymore and the fact that Visual Studio 2013 has to be used for editing doesn't make things easier. But thanks to virtual machines with Windows 7 I was able to edit the code and made it fit for DCS! Also, the hands are no longer shown twisted with rotation offset. Enclosed you have a video how the hands look in DCS and what you can do. Basically the native engine of DCS is used. This engine is already compatible with the index controllers. I have modified the driver minimally. To activate the hand you have to form a pistol. Now you can simply tap against the button. This always corresponds to a left click (darkgreen) with the mouse. If you turn your hand 180° on its back, you can do a right click (blue). To click, you will have to trigger your index finger as you would trigger a gun. The interaction works quite well for me, but is also FPS dependent. Here is the link to the actual driver: https://github.com/SDraw/driver_leap Install the driver and replace the files in the installation path with my customized driver. DCS has to run in SteamVR mode - if you don't have one with link to dcs.exe and parameter --force_steam_Vr Also attached are the edited source code files. SDraw_driver_leap_sourcecode.zip SDraw_driver_leap_patch.zip
  9. Hey, I have finally found the parts of the driver where I can anchor an appropriate offset of the hands. In DCS it works quite well. Now I have to do some fine tuning. Furthermore you have to press A or B for the left mouse button or the right mouse button in the beta. But you have to put your thumb and middle finger or your thumb and pinky finger together for a gesture for A or B. More intuitive will be the trigger gesture with the index finger and middle finger with thumb. When the whole thing is more suitable, I will open a separate thread for this. The advantage of this method is that it works direct in dcs.
  10. Hello Kariyann71, I tried DCLeap today. Thank you for your work! I have a question about the position of the course and the resolution of the VR glasses. I use the Valve Index at 160% resolution (2548x2832px). I have also shown the hand models, because I find this super intuitive. Unfortunately the Courser is completely beside the hands and also not 1:1. Is there anything else to consider here? Thanks a lot!
  11. But it do nothing sadly. I tried it. I tried values from 0.0-1.0 and 0.0-360. Nothing changes here. And I will try DCLeap later this day. Thanks!
  12. If you start the Steam version of DCS and choose SteamVR version, I think it is the same as --SteamVR. I finally managed to install Visual Studio 2013 in a Windows 7 VM and compiled the driver successfully. Now I just have to implement an offset and compensate the existing one. I hope it is not too complicated...
  13. Hello, pilots, the other day during a multiplayer session I made this screenshot (a little bit more contrast) - it says something on the back of it? We think: I'M AMAZING I'M A WINGMAN I'M A WINNER What are you reading here?
  14. Yes, the recognition of gestures only makes everything more complicated. Basically, only the position is needed.
  15. Hey, I've been following the thread for a while now and just want to share something I found across the board. There is a Valve Index Emulator driver for the LeapMotion:https://github.com/SDraw/driver_leap I just disabled all buttons and other gestures in the settings and can now easily press the buttons in DCS. At least in 2.5.5. 2.5.6. you don't just "press it" but press the B key, which is very unintuitive. The driver has only one small quirk - the hands have a rotation offset. I already tried to fix that myself, but the driver was compiled with Visual Studio 2013. Under Windows 10 I only run VS 2017&2019 and there are a lot of errors. The thing is really 1A, except for this twist. I will try to set up Win7 in a virtual machine with VS2013 soon.
  16. Thanks Baldrick33, I did a special search before, but for the wrong terms. I guess I'd rather live with the bug than disable the MSAA. DCS looks way too good with MSAA for that. But I will test it again, if the workarround works. Thank you!
  17. Hello, first - thanks for the very successful Supercarrier Update! I have found a problem in VR. Some black thing appear when looking towards the center of the carrier. Only appears when close to the carrier. Using Valve Index at 90Hz with 160% Resolution and max. details. Ryzen 3900x, 2080s, 32GB Ram. Here is a recorded video: Thanks ED Possible Workaround
  18. Thanks! We are eagerly waiting.
  19. Hey, guys, thanks for the input. I've got an SSD in there, the cockpit's there too - sort of. When I look around, sometimes it seems like it's deep in the fog. But it seems that the depth value is not read out pixel by pixel. So I have analyzed a replay in more detail. The motionblur is calculated correctly. You can see it by the different orientations of the blur in the background. The problem is that this strong motion blur is calculated on the movement of the geometry, but is applied to an "image". As a result, the aircraft is also blurred at the corresponding points. This is then seen as ghosting. To compensate for this, you would have to add motion blur and edge fill to different depths in the image only up to their edges and compose everything back together. There is certainly a way to filter the whole thing, but it will probably be very complex to program and will eat up FPS. I'm gonna go check it out. Thanks! -> Game will not start. I have now reduced the blur strength a bit and adapted the kernels. So the image is not so ghosty anymore. See the difference: Compared MotionBlur V2.0.zip
  20. Looks like the last 15 years as a visual effects supervisor were not in vain. Thanks! :pilotfly: Well, I'm desperate. I think I'm not that far from the goal, but unfortunately without a debugger or experience with C++ in the game engine area it's really hard. I think I was successful in reading out the depth values, but unfortunately every time I try to multiply the value read out for this pixel by the speed vector for motion blur, the image gets like this: I already tried to find out if the depth takes any absurd values like -1, 0, 1 or 1000000. Unfortunately, I can't reach this error with any manually entered value. So it seems that the depth has an incorrect value or is NULL or something like that. The question is why. Does anyone know someone who can help? Thank you! Here is the code. I excluded Line 83 where the problem appears. But I also made a few small adjustments, so if you want to test it. At Line 77 simply change the multiplier from 8 to a value you want to increase or decrease the ammount of blur. #include "common/states11.hlsl" #include "common/context.hlsl" #include "deferred/Decoder.hlsl" #include "deferred/DecoderCommon.hlsl" #include "common/context.hlsl" //added to get access to some camera values out of the game float4 g_ColorBufferViewport; float2 g_ColorBufferSize; float4x4 invProj; //copied from DOF.fx float focalDistance, focalWidth; //copied from DOF.fx uint2 dims; //copied from DOF.fx TEXTURE_2D(float4, ComposedTex); //That is the Part from ED that was already here - but unused... //float LoadDepthBuffer(float2 uv) { // return SampleMap(DepthMap, uv, 0).r; //} static const float2 quad[4] = { float2(-1, -1), float2(1, -1), float2(-1, 1), float2(1, 1), }; struct VS_OUTPUT { float4 pos: SV_POSITION; float2 projPos: TEXCOORD0; }; VS_OUTPUT VS(uint vid: SV_VertexID) { VS_OUTPUT o; o.pos = float4(quad[vid], 0, 1); o.projPos = o.pos.xy; return o; } //copied from DOF.fx V2.0 and renamed it float getDepthFactor(float dist) { float zoom = gNearFarFovZoom.w; float3 camOrigin = gOrigin; float3 camPosition = gCameraPos; float focalLength = (1/zoom)-0.41667305; float3 d = camOrigin-camPosition; float cameraDistance = sqrt((d.x * d.x)+(d.y * d.y)+(d.z * d.z)); cameraDistance = cameraDistance/100000; float aperture = 4.0; aperture = aperture*aperture; return focalLength * cameraDistance * abs(focalDistance - dist) / dist / aperture; } //copied from DOF.fx V2.0 and renamed it float getDepth(float2 uv) { #ifdef MSAA float depth = DepthMap.Load(uint2(uv*dims), 0).r; #else float depth = DepthMap.Load(uint3(uv*dims, 0)).r; #endif float4 p = mul(float4(uv*2-1, depth, 1), invProj); float f = getDepthFactor(p.z/p.w); return pow(f, 2.0); } float2 transformColorBuffer(float2 uv) { return (uv*g_ColorBufferViewport.zw+g_ColorBufferViewport.xy)*g_ColorBufferSize; } static float kernel[] = { 0.095478, 0.095002, 0.093587, 0.091276, 0.088137, 0.084259 }; float4 PS_MOTION_BLUR(const VS_OUTPUT i, uint sidx: SV_SampleIndex): SV_TARGET0 { float2 v = (SampleMapArray(GBufferMap, i.pos.xy, 5, 0).xy-127.0/255.0)*8; // restore velocity //looks like only one Point is used to calculate the motionblur of the wohole image... thats bad v.y=-v.y; //Flip Motion in Y Direction because it is false otherwise float2 uv = i.pos.xy; //float xy_depth = getDepth(uv); //get a depth value for the uv Point //v = v*xy_depth; //Here I want multiply the velocity with the depth - and the image goes wents bluish... testet with values like 0, -1,1, 1000000. Nothing shows that bluish look... Is the depth value something like NULL, NA and invalid - why? float3 acc = SampleMap(ComposedTex, uv, sidx).rgb * kernel[0]; for (uint j = 1; j < 6; ++j) acc = (SampleMap(ComposedTex, uv + v*j, sidx).rgb + SampleMap(ComposedTex, uv - v*j, sidx).rgb) * kernel[j] + acc; return float4(acc, 1); } float4 PS_COPY(const VS_OUTPUT i, uint sidx: SV_SampleIndex): SV_TARGET0 { return SampleMap(ComposedTex, i.pos.xy, sidx); } technique10 MotionBlur { pass P0 { SetVertexShader(CompileShader(vs_5_0, VS())); SetGeometryShader(NULL); SetPixelShader(CompileShader(ps_5_0, PS_MOTION_BLUR())); SetDepthStencilState(disableDepthBuffer, 0); SetBlendState(disableAlphaBlend, float4(0.0f, 0.0f, 0.0f, 0.0f), 0xFFFFFFFF); SetRasterizerState(cullNone); } } technique10 Copy { pass P0 { SetVertexShader(CompileShader(vs_5_0, VS())); SetGeometryShader(NULL); SetPixelShader(CompileShader(ps_5_0, PS_COPY())); SetDepthStencilState(disableDepthBuffer, 0); SetBlendState(disableAlphaBlend, float4(0.0f, 0.0f, 0.0f, 0.0f), 0xFFFFFFFF); SetRasterizerState(cullNone); } } By the way, the DOF shader does not seem to be called in the cockpit. But the Motionblur Shader is. Maybe it is possible to install a backdoor here and thus activate DOF in the cockpit, as the Motion Blur Shader also has to calculate DOF.
  21. Hello JumboJBT here you find the new file for the heat effect on the engines: Heatair V2.0 I made the noise from the distortion smaller and faster. As always, it is natural in the eye of the beholder. Unfortunately it's also a bit difficult to make a screenshot of it. Currently I am working on making the motionblur dependent on the depth in the picture. I had noticed that unfortunately I had only reduced the strength of the blur. Which, of course, has no added value. As I found out, the motionblur is calculated for the whole picture. That's why the parts of the plane become so extremely blurred when flying past. There is also a commented and deactivated code part in which this depth map is loaded. Unfortunately it seems to be completely black. I will try to take the code from the DOF.fx to get a correct depth indication. So you could then multiply the motion blur depending on the distance of the camera's target point in relation to the depth mask. Here ED seems to have already started, but not continued. When the camera is moving, the blur in the background should be higher, because the relative speed is higher. The current blur of ED is not able to do more than that. In 3D software samples are really rendered in between, but with 8 samples it would mean that the GPU has to deliver 90x8 FPS in VR. So it makes no sense. Post Effect Blur is also not uncommon in the film industry, especially on greenscreen where the exposure time is kept extra short. Reel Smart Motion Blur does something like this. Have a nice weekend! I have already searched for DOF in the interior view, but so far I have not found a file where you could edit anything. I keep my eyes open! Heatair V2.0.zip
  22. Hey JumboJBT, thank you! Programming and modding are not completely foreign to me. I first built a mod for myself in the game Morrowind 2002. At Oblivion, the German translation was really bad at that time and my German mod was on many magazine CDs and was loaded several hundred thousand times. Unfortunately, real life grabbed me when my youth was over, but thanks to the crisis I have some time again. By necessity. My daily work also revolves around After Effects and 3D rendering. So it should be useful. I've even adjusted the heat effect and the motion blur a little bit, if you're interested in watching it, I can post the files as well. Currently, however, after 50 flying hours with takeoff and landing training on land and on the aircraft carrier, I concentrate on learning the weapon systems of the F-18. However, the adaptation of the DOF.fx was a need for me =D
  23. Thanks Morpheus, I didn't know the tool before, but I'm still quite new in the DCS universe.
  24. New Version Hey pilots, I have done a lot of testing and try and error. Now it is little bit more correct in some points and the code is cleaner. Try yourself - just copy & paste: You can edit line: 48 for your own DOF strength and line: 71 to increase or decrease visual quality and performance impact. Don't forget to make a backup file :thumbup: #include "../common/samplers11.hlsl" #include "../common/states11.hlsl" #include "common/context.hlsl" //added to get access to some camera values out of the game Texture2D Source; #ifdef MSAA Texture2DMS<float, MSAA> DepthMap; #else Texture2D<float> DepthMap; #endif uint2 dims; float4 viewport; float4x4 invProj; float focalDistance, focalWidth; float aspect, bokehAmount; struct VS_OUTPUT { noperspective float4 pos: SV_POSITION0; noperspective float2 texCoords: TEXCOORD0; }; static const float2 quad[4] = { float2(-1, -1), float2(1, -1), float2(-1, 1), float2(1, 1), }; VS_OUTPUT VS(uint vid: SV_VertexID) { VS_OUTPUT o; o.pos = float4(quad[vid], 0, 1); o.texCoords = float2(o.pos.x*0.5+0.5, -o.pos.y*0.5+0.5)*viewport.zw + viewport.xy; return o; } float getBlurFactor(float dist) { //get game camera values float zoom = gNearFarFovZoom.w; //get fov value of the camera float3 camOrigin = gOrigin; //get camera origin float3 camPosition = gCameraPos; //get camera pos //calculations float focalLength = (1/zoom)-0.41667305; //I added this, so the distance will be a multiplier of the blur strengh. The smallest value that zoom can have is the golden angle defined in line 67. This is 180° FOV and then the DOF is Zero. float3 d = camOrigin-camPosition; //calc absolut values of x,y,z - distance float cameraDistance = sqrt((d.x * d.x)+(d.y * d.y)+(d.z * d.z)); //calc absolut direct distance aka focalDistance (Pythagorean theorem) cameraDistance = cameraDistance/100000; //I divded the camera distance with 100000 (cm? so its 1km?) so at minimal zoom we get nearly the lowest DOF - this is not physical based, but approximately good enough - have tried and error this value. //USER CAN EDIT THIS VALUE BELOW. USE lower Values for more DOF and higher values for less. 1, 1.4, 2.0, 3.5, 4, 5.6, 8 - of course you can use every number you want when you like pi for example float aperture = 4.0;//the standard blur looks like aperture 1 - this multiplier reduces the heavy blur (https://en.wikipedia.org/wiki/Aperture) aperture = aperture*aperture; //calc the size of the bokeh with this aperture. The aperture² gives you the ammount of reducing light. Also its the ammount the bokeh decreases. For example 1 = 1. Maximum Bokeh. At Aperture 1.4 you have the half ammount of light and the half size of bokeh. //output return focalLength * cameraDistance * abs(focalDistance - dist) / dist / aperture; //default -> focalWidth * abs(focalDistance-dist)/dist; | I cannot delete focalDistance, then you see extreme blur. In theory that means that my calculation of cameraDistance is wrong. I'm pretty sure it is, but hey at this moment it works. } float getRadius(float2 uv) { #ifdef MSAA float depth = DepthMap.Load(uint2(uv*dims), 0).r; #else float depth = DepthMap.Load(uint3(uv*dims, 0)).r; #endif float4 p = mul(float4(uv*2-1, depth, 1), invProj); float f = getBlurFactor(p.z/p.w); return pow(f, 2.0); //does the boke effect really grow exponentially with distance? - but this does enlarge the area where it is sharp. Default 1.5. } #define ONEOVER_ITR 1.0 / ITERATIONS #define PI 3.141596 // This is (3.-sqrt(5.0))*PI radians, which doesn't precompiled for some reason. #define GOLDEN_ANGLE 2.39996323 #define NUMBER 150.0 #define ITERATIONS_STEP 8//increasing this value means more fps because of less calculations. But also the look is different. Less iterations creates smaller and "worser" bokeh and sometimes dotted star looking bokeh. There is something in the loop down. Some values are a sweet spot. #define ITERATIONS (GOLDEN_ANGLE * NUMBER) // This creates the 2D offset for the next point. // (r-1.0) is the equivalent to sqrt(0, 1, 2, 3...) float2 Sample(in float theta, inout float r) { r += 1.0 / r; return (r-1.0) * float2(cos(theta), sin(theta)) * .06; } float3 Bokeh(Texture2D tex, float2 uv, float radius, float amount) { float3 acc = float3(0,0,0); float3 div = float3(0,0,0); float2 pixel = float2(aspect, 1.0) * radius * .025; float r = 2.5; //default = 1.0 - this is smootging the bokeh what is neccessary because of less samples for (float j = 0.0; j < ITERATIONS; j += ITERATIONS_STEP) { //using here ITERATIONS_STEP instead of GOLDEN_ANGLE float2 s = Sample(j, r); float2 tuv = uv + pixel * s; // rebuild tuv float nr = min(getRadius(tuv), radius); tuv = uv + pixel * s * (nr/radius); float3 col = tex.Sample(ClampLinearSampler, tuv).rgb; float3 bokeh = float3(5.0, 5.0, 5.0) + pow(col, 9.0) * amount; acc += col * bokeh; div += bokeh; } return acc / div; } float4 PS(const VS_OUTPUT i): SV_TARGET0 { return float4(Bokeh(Source, i.texCoords.xy, 0.5, bokehAmount), 1.0); } technique10 LinearDistance { pass P0 { SetVertexShader(CompileShader(vs_4_0, VS())); SetGeometryShader(NULL); SetPixelShader(CompileShader(ps_4_0, PS())); SetDepthStencilState(disableDepthBuffer, 0); SetBlendState(disableAlphaBlend, float4(0.0f, 0.0f, 0.0f, 0.0f), 0xFFFFFFFF); SetRasterizerState(cullNone); } } Some Screenshots, because DCS is so beautyful:
  25. Hey Fri13, thanks for your input. Are you sure there's no effect from the distance? I briefly unpacked my Canon 77D and took photos with 25mm, 50mm, 100mm and 200mm at aperture 2.8. Here is the series of pictures with the same distance. 25mm 50mm 100mm 200mm Here is the row of pictures with different distances to compare the Bokeh Close Mid Far The greater the distance, the greater the sharpness range. This of course also reduces the bokeh in the background. For example, when I take a landscape photo with my 11mm lens everything is in focus. But if I take a close up photo of a flower, this landscape will appear completely out of focus at the same focal length and aperture. But how exactly now the mathematical connections are... I would have to read a lot or do a small test series at home and measure everything correctly.
×
×
  • Create New...