Project D3D11Client Development

[asmi]

Do you mean me by "they"? I only relayed what was said 2 years ago. This doesn't mean it won't happen.

I see. I didn't mean to insult anyone - it's just my own experience in software development suggests me that it won't happen - because we always have something of medium and high priority
And also please excuse my ignorance as I'm pretty new here - for some reason I thought that you are a part of Orbiter's development team

Either way, my comment that we will have to implement it ourselves is still valid.

 

[Xyon]

Orbiter's core doesn't have a development team; just Martin.

 

[asmi]

Orbiter's core doesn't have a development team; just Martin.

Got it, thanks for the information and I'm sorry about confusion.

Anyways, back to topic

 

[Moach]

let me just put a few words on terrain and cloud rendering, and what I would do if it were up to me...


first off - i'd create a NICE and solid relief mapping shader, this is simple enough to be done in SM3

but then, i'd use it in a way that eliminates the need for geometry shaders to a good extent

say, you wanna render a city with 3d buildings? - you don't need to create meshes for al of them - from above, all you can see is an amount blocks which move in different angular velocity than the ground, wrt your PoV

so this can be implemented by clever maniplation of UV textures, i.e. a cone-stepping lookup plus a special case for rendering textures on the sides of buildings and stuff :hmm:

for rendering forests, or any stretch of dense wood, using meshes is almost a no-go... FSX tries and fails miserably on that - forests aren't thick enough even at max setting, and way before then you already have major lag


since you're not gonna fly UNDER the trees, you might as well achieve a better effect by parallax mapping the top of the canopies -- again, no addditional meshes are needed



clouds - ooh, that is a big one...

using particles is a good old trick, but rather limited.... plus, you need a LOT of them to make it work - and it still looks kinda "papery" when you fly through them

now, i'd suggest a similar approach to the ideas mentioned above, rendering the clouds as a heightfield in the pixel shader - but then, you also position "puffs" around the clouds "surface" at certain locations - much in the same way modern games render fields of grass over terrain.... it should make for a very convincing effect - specially on overcast conditions

lastly, by using two cloud layers on different altitudes, you can render clouds realistically from above, below and from INSIDE as well - without needing to flood the screen full of particles to achieve a similar effect



just brain-farting....

 

[asmi]

let me just put a few words on terrain and cloud rendering, and what I would do if it were up to me...


first off - i'd create a NICE and solid relief mapping shader, this is simple enough to be done in SM3

but then, i'd use it in a way that eliminates the need for geometry shaders to a good extent

We are going to use GS and HS/DS mostly for tesselation, i.e. sending very crude flat geometry into the pipeline, and performing subdivision to display more details right inside GPU. So the first step is exactly what are you talking about, but reality is that we need much more primitives to more or less accurately represent "real" terrain.

say, you wanna render a city with 3d buildings? - you don't need to create meshes for al of them - from above, all you can see is an amount blocks which move in different angular velocity than the ground, wrt your PoV

so this can be implemented by clever maniplation of UV textures, i.e. a cone-stepping lookup plus a special case for rendering textures on the sides of buildings and stuff :hmm:

Well, that will be another thing, as you can think of citys as just a special case of forest It really is the same thing, just different mesh/texture.

for rendering forests, or any stretch of dense wood, using meshes is almost a no-go... FSX tries and fails miserably on that - forests aren't thick enough even at max setting, and way before then you already have major lag


since you're not gonna fly UNDER the trees, you might as well achieve a better effect by parallax mapping the top of the canopies -- again, no addditional meshes are needed

Yes that could work, allthough there is a big problem when you are on the ground or close to it.

clouds - ooh, that is a big one...

using particles is a good old trick, but rather limited.... plus, you need a LOT of them to make it work - and it still looks kinda "papery" when you fly through them

now, i'd suggest a similar approach to the ideas mentioned above, rendering the clouds as a heightfield in the pixel shader - but then, you also position "puffs" around the clouds "surface" at certain locations - much in the same way modern games render fields of grass over terrain.... it should make for a very convincing effect - specially on overcast conditions

another idea, by using two layers, you can render clouds realistically from above, below and from INSIDE as well - without needing to flood the screen full of particles to achieve a similar effect

Two layers is the way it's implemented right now. It looks good enough well above or below them, but inside honestly in looks like crap and something definetly have to done to fix it up.

just brain-farting....

Thanks for your input anyways!

 

[Moach]

(...)
Yes that could work, allthough there is a big problem when you are on the ground or close to it.

in a space simulator - if that ever happens then you have even more serious problems at hand :lol:


but anyways - it would look rather weird up close, UNLESS - you do the old but clever trick from Pilotwings64 - and add a textured "fence" around such areas, so when viewed from the sides (e.g. when landed) - it looks like the entrance to a forest, even tho there's no mesh for the "middle" of it

they didn't have parallax mapping back in the n64 days, so they just used an extrusion of the terrain mesh to fill in between the borders....



as for the two cloud layers - my mistake, we do have two of them already (for above and for below) -- i was meaning to suggest using FOUR, so you can have above and below on two different levels, which you can fly between



just an idea.... i'm quite curious to how this project is gonna turn out

my only real "request" would be to allow custom shaders to be loaded from addon modules, so we can put the GPU to render our exhaust/reentry effects and/or to paint displays on our DVC's

i guess what i'm hoping for is a cblkGraphicsRedraw we could tap into and run our own show when needed... but mostly, for a simple way to determine that a certain material on a given mash should be drawn with a specific shader, etc...


keep it up - this is gonna be legen.... wait for it.... dary! :thumbup:

 

[asmi]

in a space simulator - if that ever happens then you have even more serious problems at hand :lol:


but anyways - it would look rather weird up close, UNLESS - you do the old but clever trick from Pilotwings64 - and add a textured "fence" around such areas, so when viewed from the sides (e.g. when landed) - it looks like the entrance to a forest, even tho there's no mesh for the "middle" of it

they didn't have parallax mapping back in the n64 days, so they just used an extrusion of the terrain mesh to fill in between the borders.... :

Well there is an obvious problem with that - Orbiter allows to land anywhere in the planet, so fence in the middle of nowhere (like in the middle of the jungles) would look a bit out-of-the-line, don't you think?

as for the two cloud layers - my mistake, we do have two of them already (for above and for below) -- i was meaning to suggest using FOUR, so you can have above and below on two different levels, which you can fly between



just an idea.... i'm quite curious to how this project is gonna turn out

Well the problem is - no matter how many layers you've got, you are going to fly through one. If you've ever flown through clouds inside a real plane - you know what it looks like - they actually are just behind the window, it almost feels like you can touch them. The only reasonable way to simulate that would be using some sort of particle system...

my only real "request" would be to allow custom shaders to be loaded from addon modules, so we can put the GPU to render our exhaust/reentry effects and/or to paint displays on our DVC's

i guess what i'm hoping for is a cblkGraphicsRedraw we could tap into and run our own show when needed... but mostly, for a simple way to determine that a certain material on a given mash should be drawn with a specific shader, etc...

Yes that's what I have in mind too. I'm going to create a dedicated shader for vessel rendering anyways, so there should be no problem with using separate shaders for different vessels - the only thing being that you'll have to confirm to certain restrictions (like vertex format, constant buffers' formats) that are coded into application, otherwise it's not gonna work, or it will, but will look so crappy that you'd prefer it wouldn't

keep it up - this is gonna be legen.... wait for it.... dary! :thumbup:

We'll see At least now there are several devs, so if some will lose their interest, the project won't become abandoned

 

[Glider]

If you remember there is a support for heightmaps in current TILEDESC's - it just isn't implemented atm. This makes me think that Martin is(was) planning to implement it at some point...

Yes, it seems that Martin already thought about terrain, but it doesn't mean he will add terrain and tile/vessel collisions in Orbiter core/default client/D3D7Client soon. AFAIR, he didn't say that it will be in the next Orbiter, only that he would like it to be implemented. So, I think that the client should add at least primitive tile/vessel t.d.p collisions if it will have terrain.

We can just use HLSL intrinsic "noise" to generate it right inside shader

I don't think it has enough parameters to generate interesting terrain. Though may be there's a way to do this by using many noise() with different parameters...

We can get hi-poly tree model from 3D Max (there is a tree/vegetation meshes generator), we can find a model online or create it ourselves - it's not that much of a problem. Also, billboard approach might be a bit problematic 'cause we are going to see it from above AND from long distances. So we need to be smart about what kind of texture to apply - likely we'll need several ones for different viewing angles...

I meant that in the case of instancing there's a problem to find out should be a tree placed in a point on surface, or should it be a rock, or different type of tree/a bush... Though, it should be solvable. Of course, there's no problem to get a 3D model.

Ok then, I think we'll leave this whole terrain thing for you as you're already working on it I will be working on vessel-related things - specifically will try to figure out a way to improve the way beacon lighting looks, after that I can take care of ground base-related stuff as I've already done some research on that. PP effects can be implemented completely independent of everything else, so whoever will get there first will take it

OK. I'll be implementing the terrain thing, while you will work with vessels...

 

[asmi]

Here is another update from the frontlines:

Hmm, how it goes... Ah, here - "I've got two news for you - one good one and one ...mmm... not so good one". Actually I've got three "not so good" news, but whatever Here is a good news - I have implemented per-pixel lighting for vessel's beacon lights, and to me it looks amazing! Check it out yourself (make sure you watch it in HD!): [ame="http://www.youtube.com/watch?v=f3UtR-g-BR0"]Orbiter 2010 + D3D11Client per-pixel beacon lighting demo - YouTube[/ame]
When you note FPS, keep in mind two things - I was recording it with CSAA 16xQ enabled, and recording itself severly impairs performance. Still 180 FPS is not so bad

Now, bad news are coming

1. I actually a bit cheated during making this video. Then problem is - there is something wrong with rendering beacons themselves - they are just not being displayed. I've tried to debug it in PIX and it has shown me that they are not visible because they fail Z-test. So for the purpose of this video I've temporary disabled Z-test Moreover, I've observed that at certain camera positions some of them are indeed being displayed with Z-test turned on, which makes me think that there is a z-fighting issue... Whatever it is - we need to fix it somehow. If anyone have any idea on that or if anyone would like to try fixing it himself - I'm all for it

2. Second one - current implementation use 28 output registers in vertex shader, so unfortunately it doesn't work in FL 10.0 as the latter has only 16 output registers. However it does work in FL 10.1 as it's got 32 output registers in vertex shader (btw FL 11 also has 32 output registers). So I'm sorry guys, but no show unless someone will come up with clever idea about how to modify shader so it would require less registers. Right now shader supports up to 8 beacon lights (the same amount that Orbiter itself supports), and each beacon eats up 2 registers, so just beacons require 16 registers in total, and 12 registers are being used for other purposes.

3. And the last news in completely unrelated to anything I was talking about above. Today when I was debugging application, I've noticed some pretty pad output from DX debug layer. I don't quite know how, but we've gotta fix it. Here it is - I'm gonna post just summary, as whole thing is very large and I don't think a lot of readers are really interested in it:

D3D11: WARNING: Live Device Child Summary: Device Addr=0x00179948
Using ID3D11Debug::ReportLiveDeviceObjects with D3D11_RLDO_DETAIL will help drill into object lifetimes. Objects with ExtRef=0 and IntRef=0 will be eventually destroyed through typical Immediate Context usage. However, if the application requires these objects to be destroyed sooner, ClearState followed by Flush on the Immediate Context will realize their destruction.
Live Context: 1
Live Buffer: 74
Live Texture1D: 0
Live Texture2D: 174
Live Texture3D: 0
Live ShaderResourceView: 166
Live RenderTargetView: 8
Live DepthStencilView: 1
Live VertexShader: 16
Live GeometryShader: 1
Live PixelShader: 21
Live InputLayout: 11
Live Sampler: 7
Live BlendState: 4
Live DepthStencilState: 6
Live RasterizerState: 9
Live Query: 1
Live Predicate: 0
Live Counter: 0
Live CommandList: 0
Live HullShader: 0
Live DomainShader: 0
Live ClassInstance: 0
Live ClassLinkage: 0
Live ComputeShader: 0
Live UnorderedAccessView: 0
[ STATE_CREATION WARNING #2097298: LIVE_OBJECT_SUMMARY ]

So that's it for now. Face - as usualy please merge it into your project, and any thoughts, opinions, suggestions are very welcomed as usual.

Cheers!

 

[Face]

Face - as usualy please merge it into your project, and any thoughts, opinions, suggestions are very welcomed as usual.

Done. The Wiki is activated with a first draft of the roadmap here. Please update it as you see fit.

 

[Glider]

So I'm sorry guys, but no show unless someone will come up with clever idea about how to modify shader so it would require less registers.

Everything works good, but Why not to:
1. remove everything from VS buffer and VS output structs
3. create cbuffer for PS with 8-element array of beacon params (with color, PosW and etc.)
2. in vVessel.cpp calculate PosW for each active beacon once, and update beacon params in PS cbuffer for active number of beacons.
3. do some PP lighting in PS using PosW of pixel, PosW of beacon, NormW of pixel, color and other beacon's params for active number of beacons.

Why calculate mul() of constant PosL of each beacon for all mesh vertexes in VS, fill VSOut of all vertexes with the same constant data from cbuffer that you currently have in VS and reduce compatibility to FL11 ?

 

[asmi]

Everything works good, but Why not to:
1. remove everything from VS buffer and VS output structs
3. create cbuffer for PS with 8-element array of beacon params (with color, PosW and etc.)
2. in vVessel.cpp calculate PosW for each active beacon once, and update beacon params in PS cbuffer for active number of beacons.
3. do some PP lighting in PS using PosW of pixel, PosW of beacon, NormW of pixel, color and other beacon's params for active number of beacons.

Why calculate mul() of constant PosL of each beacon for all mesh vertexes in VS, fill VSOut of all vertexes with the same constant data from cbuffer that you currently have in VS and reduce compatibility to FL11 ?

Well, you're half-right We CAN move colors and falloffDistance to PS cbuffer, but we can't do this for positions since different mesh groups can have different world matrices. This would force us to update this cbuffer once per group instead of once per vessel, and this could affect performance - remember that stock DG has 117 meshes, so 1 update vs 117 updates sounds like quite a difference.
The problem is - even if we'll do that (move color and falloffDistance to cbuffer), we still need to calculate PosW for each vertex and pass it along to PS, so we still won't fit within 16 registers restriction (remember 12 registers are already used by other stuff, plus 8 gives us 20).
The bottom line is - yes, we CAN make it FL10 compatible, but at the price of performance. Maybe that's a good place to create two versions of shader - one for FL10.1+, which will calculate PosW per-vertex inside VS, and another one for FL10 which will calculate PosW once per group anhd pass it straight to pixel shader.
I actually did profile this shader and found out that calculating worldMatrix * lightPosition per each vertex is faster than caclulating it once per group and updating cbuffer for each group - I think that's so because GPU doesn't have to wait for memory exchange between system memory and video memory, and so it can execute the whole pipeline in parallel...

 

[luki1997a]

Will this work on latest beta? For me- no luck Great work btw:tiphat::thumbup:

 

[asmi]

Will this work on latest beta? Great work btw:tiphat::thumbup:

I'm using Orbiter 2010 P1 public release.

BTW - how do I get my hands on the beta? As a graphics client developer, I'd like to know what's coming before it came

 

[luki1997a]

I'm using Orbiter 2010 P1 public release.

BTW - how do I get my hands on the beta? As a graphics client developer, I'd like to know what's coming before it came

What's coming? Wind, new UI, new planet appearance from far distance, and more...
You can get it there:
http://sourceforge.net/apps/mediawiki/orbitervis/index.php?title=OrbiterPublicBeta

 

[Glider]

Well, you're half-right We CAN move colors and falloffDistance to PS cbuffer, but we can't do this for positions since different mesh groups can have different world matrices. This would force us to update this cbuffer once per group instead of once per vessel, and this could affect performance - remember that stock DG has 117 meshes, so 1 update vs 117 updates sounds like quite a difference.

Groups ? I mean
D3DXMatrixMultiply( &Beacon_PosW, &Beacon_PosL, &mWorld );
where mWorld is world matrix for vessel. it transforms local coords => world space. groups have T*mOffset*mWorld. i.e. matrix that animates group + matrix to shift mesh to its offset + world matrix for object, it is first animated then moved to it's offset in local space than it gets transformed to world space.

we need calculate beacon_PosW once with mWorld of object and put it into PSCB.it will be in the same space that pixels are.

The problem is - even if we'll do that (move color and falloffDistance to cbuffer), we still need to calculate PosW for each vertex and pass it along to PS, so we still won't fit within 16 registers restriction (remember 12 registers are already used by other stuff, plus 8 gives us 20).

you have CamW in PS (direction to camera from pixel). it is -PosW. You can get PosW from it before it gets normalized.

Will this work on latest beta? For me- no luck Great work btw:tiphat::thumbup:

No. It doesn't work with latest beta. Martin have modified 2D functions there (for D3D9Client) and it now works differently. I need to change 2D code to make it compatible with it.

 

[asmi]

Groups ? I mean
D3DXMatrixMultiply( &Beacon_PosW, &Beacon_PosL, &mWorld );
where mWorld is world matrix for vessel. it transforms local coords => world space. groups have T*mOffset*mWorld. i.e. matrix that animates group + matrix to shift mesh to its offset + world matrix for object, it is first animated then moved to it's offset in local space than it gets transformed to world space.

we need calculate beacon_PosW once with mWorld of object and put it into PSCB.it will be in the same space that pixels are.

Oh yes, you're right - we pass beacons coordinates in vessel space, so yes - I will do that tonight.

you have CamW in PS (direction to camera from pixel). it is -PosW. You can get PosW from it before it gets normalized.

True, it will save us one register You see - that's why I asked to give variables more meaninful names

No. It doesn't work with latest beta. Matrin have modified 2D functions there (for D3D9Client) and it now works differently. I need to change 2D code to make it compatible with it.

Care to fix it up? I'd like to check out this beta

 

[Glider]

Care to fix it up? I'd like to check out this beta

I think I can fix it after I get some result with terrain. But of course, you can fix it too if you want.

 

[asmi]

I think I can fix it after I get some result with terrain. But of course, you can fix it too if you want.

Can you brief me in what the actual problem is? So I won't have to dig it out myself

 

[orb]

Can you brief me in what the actual problem is? So I won't have to dig it out myself

I can only speak for what was changed in the graphics interface:

There were added clbkLoadSurface, clbkCreateSurfaceEx, clbkBeginBltGroup and clbkEndBltGroup callbacks (and surfBltTgt handle) to the graphics client interface, and additionally RP_ISTLDEVICE, RP_REQUIRETEXPOW2 parameters retrievable from clbkGetRenderParam callback.

You can find more information about these changes in GraphicsAPI.h header file.