Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[BravoFxTrt]

That is more or less what Im interested in changing, but I sure wished we had a simple in game selectable Option rather than adjusting each map to a personal taste.

[Fish40]

Guys you need to check out the available shader tools out there, which are FREE. FXAA and SweetFX are but two. These use a GUI in which you could tweak any graphic setting the way you want. I know SweetFX may not work with OpenGL based games,not sure about FXAA though. They're worth the look.

[Avala]

SweetFX works only with DirectX games, unfortunately. FXAA is just antialiasing feature, which works for OpenGL games, and it is already in the nvidia drivers. Dont know for Ati cards though.

[Herra Tohtori]

Hmm. Apologies in advance, because this is sort of not related to the topic at hand, but sort of is nevertheless.

My question:

Is there a way to make a filter with Z-buffering that basically sets the filter onto the background of everything else in the simulation?

I am, of course, talking about rendering a skybox background, which would be rendered "behind" everything else. The problem is that the camera always needs to be in the centre of this skybox "filter", so the skybox needs to move with the view point; however it needs to be aligned with the world depending on latitude, time of year, and time of day. Mathematically speaking the latitude/month/time of day calculations are reasonably simple and it could even be done so that you could use the stars as navigation aids (at least with Polaris on North), but I'm not sure if it can be done code-wise.


I'm mainly asking because it would be a good way to add a proper starfield night sky background; currently, IL-2 nights are a bit... boring with the low star count they have. I've tried asking about it before, but never really received any replies. You seem to know how to manipulate the rendering depth of things, so I thought I might as well ask if you would know whether it's even remotely possible to do what I'm talking about.


If this can be technically achieved, I would be more than happy to provide the textures for the skybox and provide any information and assistance for the mathematical part of the skybox orientation, but regretfully my coding skills are virtually nonexistent.

[BravoFxTrt]

http://www.pcworld.com/article/2011003/fxaa-post-process-injector.html

[barnesy12]

hi Herra i like the sound of this i wonder  how big would a hemisphere   textured with the stars on it have to be to cover a whole map or at least the flying zone of your plane as it travels across the land scape so when you look out side you can see the stars could use an  invisible texture with just the stars on it just a thought. or maybe  could maybe attach it to your plane not sure how to make it static so it would not roll with the aircraft should be possible certainly food for thought will try some experiments thanks for the idea

[Herra Tohtori]

The stars need to be rendered behind everything else in the game: Ground, planes, atmosphere, clouds, effects etc. etc, so it needs to have the highest (or lowest) Z-value, meaning it has the biggest depth.

Discussing hemisphere size is not really a fruitful topic. If you put a model of finite dimensions "around" the game environment, you will still move relative to it, so unless you make it, like, tens of thousands of kilometres in diameter you will get distortion effects when you move "closer" to one side of the box.

Skybox background is usually defined as a model whose location is fixed to the camera, but orientation is fixed to the game world. That means when camera moves in the scene, it is always at the centre of the background and thus the rendering of the background doesn't change; it remains constant. Thus, the actual dimensions of the starfield model can be anything at all; what matters is the Z-value it is rendered with, because with 3D rendering you can do tricks like render the background first - no matter what DISTANCE it's at, then render all the other stuff in front of it and the background will poke through the "empty bits" denoted by alpha channel.

What I have in mind is basically stars on black background, which would be rendered with Z-value preceding everything else in the game. The game would then render its environment, atmosphere, etc. and ideally during day time, the bright atmosphere would naturally block out the stars just like how it happens in reality. When you climb to higher altitudes and the sky becomes darker you start seeing more stars. When it's night the atmosphere darkens even further.

I have no doubt that if this were possible, it would be absolutely incredible to fly during night-time, evenings, mornings, or high altitude. I have the assets and skills to create the background textures, but applying it on IL-2 is another matter altogether.

Any opinions on whether it's possible to do this way?

A VERY LARGE background model is an acceptable substitute but harder to manage. I have no idea how large models IL-2 supports, either.

[barnesy12]

no me neither but should be able to make a low poly shape and scale it to a massive size so still low poly  so no a drain on the game rendering should not be an issue as your stars would be a tiny texture even if added all together even if rendered at 2048x2048 texture most of the map would be blank so not using a shit load of memory to render the texture tried with the cockpit mod at 10 pixel and the dot is huge close up but if scale up the shader pyramid they looked a little smaller so really depends how big the mesh can go a sphere or hemi sphere placed at a fair distance should be all that's required as the game only sees a very limited distances 10 or twenty ks at most not like real life so making an object thousands of kilometers in size is a waste of time i think i mean it cant even see a tree at 10km so anything we make will have to fall within that sort of range or the game simply wont see it just my thoughts  Herra 

[santobr]

I think it could be a cube, just like they use in First Person Shoters like Counter Strike for example.
360º photos use a cube too.




santobr.

[Herra Tohtori]

Yes, cube is what I had in mind.

And while the polygon count for a simple cube is 12, I would expect problems with very large dimensions. Game engines typically are not designed to deal with objects bigger than certain sizes; you can get all sorts of wonky issues with that. But you won't know until you try!

Let's talk textures then.

I do not recommend using partially blank textures. That would limit the use of skybox depending on the latitude. If you can get the cube into the game, it would be simplest to just use the same cube in every scenario, even if parts of it would be obscured by the ground.

This way, it would be possible to read the latitude and time of year and time of day from mission file, and fix the orientation of the skybox model based on that information. Even better if it can be made dynamic, because then you would really see the cool stuff like the rotation of Earth causing stars to set and rise. In fact if it can be made so that the starfield model rotates at the speed of one revolution per 24 hours, that would be quite perfect - you could set the model rotation matrix based on time of day at mission start, and then leave it be as it would automatically take care of progression of time.

But we're skinning the bear before slaying it here.

For good quality, the textures of the skybox should be at least 2048x2048 per side. This might feel like steep requirements, but there you have it. I doubt it will affect frame rates all that much, though, what with modern GPU's usually having plenty of VRAM, but again, experimentation would be required. Tests could also be done with indexed textures; starfields typically don't suffer much loss with indexing (although milky way would).

[Avala]

Seems that it is already a box:

from the maps load.ini file

[CUBE]
Down  = Cube_bott.tga
East  = Cube_right.tga
North = Cube_front.tga
South = Cube_back.tga
Up    = Cube_top.tga
West  = Cube_left.tga

Of course that could be just for the non-shader (older) version.

I think that rendering and size of the texture wouldn't be a problem, even if it is 4096px, it is still only one texture, so graphic memory is not a problem. It is all probably very doable, but the coding is the problem.

[barnesy12]

will look into this over holidays build cube no issue there just size?  place in game make it an object and place it on map wont affect any thing as no hit boxes attached or anything plane will just fly straight thru it assign 1 texture per side?  can be any size still suggest texture with alpha and stars on it as it will not obscure  anything and the light at different times in game will show as normal your stars will not be visible at say 12 but as day progress sky darkens and slowly stars will appear as when you fly at high altitude. as your star field will actually in game all the time use the normal game lighting to obscure the stars as in real life just what i think can be done without code etc i suppose we could just find the the texture already in game for night and add stars as will only be a mask of day time with holes in it  with the daylight shiniing through for stars so would only have to put some more holes in it at the appropriate place might be alot easier all round