Jump to content

coconut

Founders [premium]
  • Content Count

    2604
  • Joined

  • Last visited

Community Reputation

1374 Excellent

10 Followers

About coconut

  • Rank
    Founder

Profile Information

  • Gender
    Not Telling
  • Location
    Sweden

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I use a fake block with full damage. You might need to make the fake block have a coalition-country, but I'm not sure if that's needed. It worked a year ago, not sure if it still does.
  2. Here is the video in question: I've added a patrol group since, and now working on the escort. Correction: It's almost ready to be deployed for testing, but it will be years before it's "finished"
  3. The probability of being seen by someone is higher than the probability of seeing a particular plane. And increasing the probability of seeing a particular plane will also increase the probability of someone seeing you. But that's not a problem. From a fun perspective, I'd rather see and be seen that be blind amongst the blind. Looking at replays, blind among the blind seems to be the more common scenario. From a realism perspective, I think we would benefit from increasing the probability of spotting/being spotted. I'm not sure if people understand that, but the relatively low resolution of screens (including 4K) with respect to the amount of details that is rendered produces what is effectively noise, which makes it hard to make out silhouettes. Try to force a relatively high detailed model and texture of a tree in 10x10 pixels, and you end up with a forest that looks a bit like lichen, or mould, IMHO. I suspect GPUs, memory and rendering algorithms have gained in power faster than we have gained in pixel density in our screens. People sometimes reflect on how easier it was to spot planes in older sims. This disparity could be the reason. Regarding camouflage: Right, and I think/hope the second image achieves that. I would need to see it animated to get a better idea of whether the blurry area is easily seen when not looked directly at (ideally it wouldn't). For the problem of plane against sky, I think new lighting algorithms might affect the result, and at the point we are, we'd better wait and see. But the noise-on-noise problem isn't going away unless trees are made "smoother".
  4. I'm not fond of playing with contrast and colours of planes, because 1) you can't make it work in all lighting conditions 2) it's hard to maintain, every time you change something in the rendering engine you risk adverse effects and 3) plane looks are important, and good looks are typically achieved by realistic physical light modelling, which all forms of fiddling with colour and contrast risk messing up.
  5. A hot topic these days is the difficulty of tracking planes at relatively close distance. For me, it has always been problematic to follow planes that I have spotted when they fly over a forest. I believe the problem is due to the noise introduced by rendering contrast-rich shapes such as trees at a resolution that can't properly render all details. When the plane and its camouflage become small enough that rendering them also produces noise, it becomes very hard to distinguish the two, as noise blends with noise. Here is an attempt to address this problem by reducing the noise of the background, using blur. First, the original screenshot Then with a small blurred circle around the plane Using a larger circle The proper solution might be to apply a low-pass filter on the textures and shapes to render before rendering them, but I can't easily reproduce the effects of doing that, and I'm not sure how that would be implemented. Applying blur as a post-processing step, but only on the ground, may be easier to implement, and I think it helps. The controllability of this effect using user/server settings is a point I'm intentionally leaving out.
  6. I suggest you turn on "advanced frame timing" (or something similar, not sure of the name) in steamVR. That will show you who is the cause of slow FPS, CPU or GPU. Given your hardware, I would guess it's the CPU, but it could also be the GPU if you are using a very high resolution (say, over 3000 horizontal lines). The version of PiTool matters. With the latest one, I see that GPU frame times reach the limit at 65% or so. Not sure if it's PiTool, SteamVR, NVidia's or the game's fault, or a combination, but that's how it is for me, and I went back to an earlier version V1.0.1.254 of PiTool because of this. If you have smart smoothing on in PiTool, and if your GPU usage gets too close to 50%, the tool will halve your framerate and interpolate, leading to this low GPU usage. Don't read too much into CPU and GPU usage numbers, the upper limit in practice is often well below 100%. It's frustrating if you see your CPU being used at 5% only, but if the most busy thread of the game is already using 100% of the single-threaded capacity of your CPU, that's your limit.
  7. That's true for waypoints, but last time I checked (which was I while ago, I only got back into mission editing recently), a high-prio attack area (air targets) would do the job. The problem is that the plane flies a boring tight circle pattern. I've started working on a group that combines a check zone (further) with a serpentine-patterned low-priority cycle of waypoints. The pattern covers 30x30 km, the check zone has a radius of 30 (so twice the size of the pattern). The check zone is triggered when the fighter enters the pattern (which is inside the zone), and when the fighter leaves the zone, the check zone triggers a medium prio way point (could be high if needed) that brings back the fighter inside the zone, and leads into the pattern again. I haven't tested the thing yet, but I expect it should work. A possible downside is that players could abuse this by dragging the fighter to the edge of the zone, and attack the poor AI when it turns around. But who cares, AIs have no rights. Alternatively, put a high-skilled airfield patrol over the home base to chase intruders away. I suppose that's the way it would normally be done IRL, and the reason why fighters didn't go chase enemies deep into enemy skies. But that only works if the AI is damaged, bingo fuel or ammo. It doesn't prevent terminator behaviour, at least not until the terminator gets a scratch. EDIT: Already addressed in an earlier post:
  8. I have to say the reflection effects are quite subtle, I noticed them first in the bf109. Which is nice, it could be distracting if overdone. It seems they were limited to the cockpit, though. I don't think I could see the terrain or clouds in the reflections on the canopy. Or did I miss them? The thing that jumped at me first was the nice quality of the shadows. Is the deferred renderer going to give use nice shadows for a lower cost than currently? I have to set mine to normal, and naturally they don't look this good.
  9. At 4:16: "le fait que ces graphiques ne sont pas a zero prouve que IL-2 est multicoeur" "The fact that these graphs are not at zero proves that IL-2 is multi-core/multi-threaded" No it does not. Even a single-threaded application can, and normally will, be moved around the cores faster that the sampling interval on the graphs, meaning all cores will look partially busy all the time. That's because the OS/hardware moves the load around, likely to avoid overheating any single core. In any case, nobody who's knowledgeable about programming and multi-threading claims that IL-2 is single-threaded. What is being claimed is that there is much capacity still unused. That is visible on the graphs in this video (the number was about 20% overall), and the reason for that is that there are a couple of threads that perform most of the computation. Split these threads to parallelize their work, or move some of the graphical work from the CPU to the GPU, and we'll likely see better frame rates, and/or improved graphical quality. I'm really looking forward to getting this next update, especially in VR with my ageing CPU.
  10. coconut

    Very Poor ...

    That leaves the door open for unintended changes.
  11. Can we know what the issue was, so that everyone else may benefit from it?
  12. Check how many bytes that gives you. It should be two. I suspect you are getting 4.
  13. I've been having issues too, for quite a while but I'm not sure for how long. Every now and then, my axes freeze. When it comes to buttons spiking, it can happen if all axes (including the ones you don't use) are not properly calibrated, and/or if you have messed up the axis-to-button config and used the same button by mistake more than once. I had that problem, but fixing my duplicate-button issue seems to have made that problem go away for now. Glad to see it's not just me, because until now I hadn't found anyone else with the same issue.
  14. The only use I've had for it was VRSS (Variable Rate Super Sampling), but I did not find the gains very valuable. It has stopped working for me, possibly because a driver update removed the settings, or made them inapplicable? In any case, I don't miss them. Better stay off this tool I'd say, it's easy to introduce graphical glitches with it.
×
×
  • Create New...