Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Visualization Project
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Orbiter Visualization Project Orbiter external graphics development.

Reply
 
Thread Tools
Old 01-12-2012, 05:01 PM   #46
Moach
Crazy dude with a rocket
 
Moach's Avatar
Default

Quote:
Originally Posted by asmi View Post
 (...)
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


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!
Moach is offline   Reply With Quote
Old 01-12-2012, 06:57 PM   #47
asmi
Addon Developer
Default

Quote:
Originally Posted by Moach View Post
 in a space simulator - if that ever happens then you have even more serious problems at hand


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?

Quote:
Originally Posted by Moach View Post
 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...

Quote:
Originally Posted by Moach View Post
 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

Quote:
Originally Posted by Moach View Post
 keep it up - this is gonna be legen.... wait for it.... dary!
We'll see At least now there are several devs, so if some will lose their interest, the project won't become abandoned
asmi is offline   Reply With Quote
Old 01-12-2012, 07:53 PM   #48
Glider
Addon Developer
 
Glider's Avatar
Default

Quote:
Originally Posted by asmi View Post
 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.

Quote:
Originally Posted by asmi View Post
 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...

Quote:
Originally Posted by asmi View Post
 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.

Quote:
Originally Posted by asmi View Post
 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...
Glider is offline   Reply With Quote
Old 01-13-2012, 04:38 AM   #49
asmi
Addon Developer
You Tube

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!):

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:
Quote:
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!
asmi is offline   Reply With Quote
Thanked by:
Old 01-13-2012, 01:24 PM   #50
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by asmi View Post
 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.
Face is offline   Reply With Quote
Old 01-13-2012, 02:34 PM   #51
Glider
Addon Developer
 
Glider's Avatar
Default

Quote:
Originally Posted by asmi View Post
 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 ?
Glider is offline   Reply With Quote
Old 01-13-2012, 02:53 PM   #52
asmi
Addon Developer
Default

Quote:
Originally Posted by Glider View Post
 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...

Last edited by asmi; 01-13-2012 at 03:04 PM.
asmi is offline   Reply With Quote
Old 01-13-2012, 03:15 PM   #53
luki1997a
Orbinaut
 
luki1997a's Avatar
Default

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

Last edited by luki1997a; 01-13-2012 at 03:18 PM.
luki1997a is offline   Reply With Quote
Old 01-13-2012, 03:17 PM   #54
asmi
Addon Developer
Default

Quote:
Originally Posted by luki1997a View Post
 Will this work on latest beta? Great work btw
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
asmi is offline   Reply With Quote
Old 01-13-2012, 03:21 PM   #55
luki1997a
Orbinaut
 
luki1997a's Avatar
Default

Quote:
Originally Posted by asmi View Post
 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/mediawik...iterPublicBeta
luki1997a is offline   Reply With Quote
Thanked by:
Old 01-13-2012, 03:32 PM   #56
Glider
Addon Developer
 
Glider's Avatar
Default

Quote:
Originally Posted by asmi View Post
 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.

Quote:
Originally Posted by asmi View Post
 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.

Quote:
Originally Posted by luki1997a View Post
 Will this work on latest beta? For me- no luck Great work btw
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.

Last edited by Glider; 01-13-2012 at 04:05 PM. Reason: typos...
Glider is offline   Reply With Quote
Old 01-13-2012, 03:40 PM   #57
asmi
Addon Developer
Default

Quote:
Originally Posted by Glider View Post
 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.

Quote:
Originally Posted by Glider View Post
 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

Quote:
Originally Posted by Glider View Post
 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
asmi is offline   Reply With Quote
Old 01-13-2012, 03:59 PM   #58
Glider
Addon Developer
 
Glider's Avatar
Default

Quote:
Originally Posted by asmi View Post
 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.
Glider is offline   Reply With Quote
Old 01-13-2012, 04:16 PM   #59
asmi
Addon Developer
Default

Quote:
Originally Posted by Glider View Post
 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
asmi is offline   Reply With Quote
Old 01-13-2012, 05:48 PM   #60
orb
O-F Administrator
Ninja
 
orb's Avatar

Default

Quote:
Originally Posted by asmi View Post
 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.
orb is offline   Reply With Quote
Reply

  Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Visualization Project


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 05:00 AM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.