First I'm going to comment on your replies
1. For terrain we can use heightmaps to generate geometry right on the GPU - in Domain shader you have total control over all vertex properties and you can position them whatever way you see fit. This technique will also greatly decrease memory requirements for storing all this geometry, as all details will be generated inside the pipeline. As a fallback solution for SM4 I'd suggest geometry generation using GS - allthough its' abilities are limited compated to full-blown HS/Tesselator/DS, it's still better than nothing. The benefit of this approach is still the same - we can use current "flat" surface as input and generate everything on the fly. So don't worry about balls
And heightmap generation is a very good idea - allthough it might have to be pre-calculated, manually verified and shipped with the plugin to rule out possible artefacts like having Everest mountain in the middle of KSC's runaway
2. For terrain - pls see my comment above about tesselation - no need to eat up memory with that stuff that can be generated on the fly.
Then may be make terrain in that way:
L1-L7 works same way they work now, but with normal maps (and PP lighting + increased vertex number for L1-L3).
L8-LMAX works this way:
there's small buffer with 1 L8 32x32 tile mesh and 1 L8 polar tile (+IB for them).
Then in the case of FL10:
VS copies everything to GS
GS will set needed vertex positions, normals and tangents for resolution level that we have to generate, compute Sun Color for each vertex + may be it can do some limited tesselation
PS will use computed in VS Sun color + PP lighting (+ normal map, if it exist for the planet and we have L8-L10).
In the case of FL11:
VS copies all to HS
HS/tesselator/DS sets correct vertex positions and tesselates originally 32x32 tile mesh if needed + compute Sun Color
GS does nothing
PS does same thing that was for FL10
So, no level higher than L7 will consume memory for mesh, + it will be possible to get L > L14.
Collision detection is a physics engine feature, so there is no way we can implement it - we have to ask Martin to do so
I don't think that terrain without any collisions will be useful... Besides, How Martin is supposed to do this if only the client has access to heightmap information (and, since tile meshes will be generated in GS or HS ) ? Also, there's VESSEL::AddForce() function that can be used to push vessel from terrain + VESSEL::SetTouchdownPoints and VESSEL::GetTouchdownPoints that IMO, can be used to allow landed vessel be stable on high time accelerations.
BTW, about heightmap generation: there's "libnoise" library that can generate Perlin and other types of noise. It can work fast enough to dynamically generate heightmap tiles (33x33 or 65x65), is open source and very easy to use...
May be it is possible to create a heightmap generator (with generation in separated thread of course) with it.
2. Again as a fall-back technique for SM4 we can leverage GS.
Or just use it for FL11 only...
3. Vessel self-shadowing - we need to think about plausable approach. It has to look good and at the same time work fast - as vessel is the thing that we stare at most of the time during flight
I don't have good ideas about this right now. Indeed, we should think about best approach;
5. Post-processing effects include a wide variety of things - lense glare, HDR to name a few - and that's where Compute Shaders will become extremely handy - as almost all PP effects require (quazi-)random access to original image and are computationally heavy, but can be parallelyzed to hundreds of processing cores we've got on GPU.
Yes, CS is usefull for this things. I agree that CS definitely should be used for that. (at least in FL11, not sure how it will work on CS_4_0)
6. Well the needs of API might affect some design decisions we make as we progress with our development. Also we might just take some open-source vessel and add all these cool features, and other devs amazed by the possibilities might just jump on the train
I don't mean that we'll heave to implement it right now - all I'm saying is that we have to keep that in mind.
Keep in mind - yes, but implement after the client will be stable and have enough advanced features.
7. Particle systems - moving them onto CS will allow us to tremendously increase particle density (GPUs are hundred times more powerful than CPU because there are hundreds of them
) and so greatly increase visual quality.
Well, if we're going to increase particle density, then, yes usage of CS will be good. I meant that CS isn't required for current number of particles.
7. That's as easy as 1-2-3 with instancing. Could be added any second right after we figure out a plausable algorithm for positioning them.
May be vegetation/details can be done that way:
1. LCC map can be used as a source of information about vegetation type in some place of Earth. (with IGBP encoding)
2. As a simpliest model we can use forest microtexture in pixel shader (when some tile is being rendered) and find correct forest type of some pixel from LCC map in PS, then sample it from texture array and add to tile texture.
3. As a average model is possible to use a vertex buffer with random points on surface with dimensions of L15 (or other) tile and turn them into many tree billboards in GS.(tree/grass/bush type can be sampled from LCC) Then PS use Tree/Bush/Grass/Rock texture arrays and vegetation type that billboard have from GS.
4.As a most detailed model may be some simple mesh can be used with instancing (and may be use positions of points from average resolution points-tile to position these meshes). But there's a problem to find out correct tree/whatever mesh type that should be in some point...
In the case of a planet other than Earth it is possible to use 2-3 types of rocks on surface.
Also there is one more feature that is absolutely needs to be implemented and that I've forgotten to mention - we need to add rendering/animating ground base objects like runaway lights. That actually is the subject that brought me to this forum in the first place
May be Martin will add this in the next version of Orbiter's grphics API...
So it seems that list of features now looks like this:
2. terrain + hmap generator + collisions (see comments above)
3,4,
5. lens glare or something (with CS if needed)
6.
7. see comments about vegetation above
8. may be some hdr, terrain shadows, runway lights (and etc.) or something else...
I think that minimal supported FL of all this features must be FL10 (at least those features that can be done with FL10), but we may create improved FL11 versions of the same features too.
If you want - I can give a source code for that so you can play around with it - it's really very simple.
Yes, this would be great. I actually, don't use much these FL11-only things, so source code would be interesting.
