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 12-28-2011, 04:07 PM   #16
Glider
Addon Developer
 
Glider's Avatar
Default

Quote:
Originally Posted by Veterok View Post
 The MFD panels aren't clearing the screen, they just re-write over the previous screen. I noticed my frame rate is over 750fps , could that be related?
750 fps shouldn't be related. I think you just have good hardware. I'm sure this bug is because of ClearRenderTargetView function (works differently on different systems). I'll replace it by quad rendering in the next update.
Glider is offline   Reply With Quote
Old 12-29-2011, 04:09 AM   #17
Veterok
Orbinaut
 
Veterok's Avatar
Default

Mir and ISS are rendering parts that are in back on top of parts that should be closer to the screen, but only when the view distance drops below about 40m.
Veterok is offline   Reply With Quote
Old 01-10-2012, 08:08 PM   #18
asmi
Addon Developer
Default

Hello guys! I was working on my own DX11-based client and until today I had no idea it existed So I took a quick look at the source code and immediately found few issues that I have solved in my client - most important being an issue with processing *.tex files. Here is an essence:
When you're trying to find out a size of the texture in the pack, you use DDSURFACEDESC2::dwLinearSize field, which is wrong. In reality there is no DDSURFACEDESC2 sctructure in DDS files - there is another one called DDS_HEADER. They have the same size, yet certain fields have different meaning. For example in Earth.tex file from the Earth 10-11 lvl package there are quite a few textures which contain multiple mip levels, those tiles will not be processed correctly by the existing code.
I do have a code with that problem fixed and I would be happy to contribute it. So can anyone please explain me what is the process of making changes over there? Shall I ask someone to create a user/branch/whatever in SC? Or I need to send the code somewhere?

Thank you in advance for the answers!
asmi is offline   Reply With Quote
Thanked by:
Old 01-10-2012, 08:45 PM   #19
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by asmi View Post
 I do have a code with that problem fixed and I would be happy to contribute it. So can anyone please explain me what is the process of making changes over there? Shall I ask someone to create a user/branch/whatever in SC? Or I need to send the code somewhere?
Well, Glider had the same question, so I made this post. You see, there is really only one "official" OVP source control, and that is Martin's SourceForge SVN repository. I'm not in the position to control what goes there and what not, so I can't tell you anything about it.

As for the development of D3D11Client, I've started a Mercurial repository on Bitbucket here. I try to keep up with Glider's and jarmonik's ZIP-posts, so you can argue that it is a common OVP devel repository there. Since this is a DVCS, you could clone the repository and hack right away on it. But it is certainly not necessary to go all the way to just contribute a few patches. The way Glider and jarmonik put out the code is good enough.

Since it is evident that I can't keep up with actual coding (Glider is doing a tremendous job!), I already felt back to act as repository manager. So just post your code here, I'll take care of putting it into the repo .

regards,
Face

P.S.: Sorry for taking so long to update Glider's master... kids and Xmas, you know...
Face is offline   Reply With Quote
Old 01-11-2012, 03:17 AM   #20
asmi
Addon Developer
Default

well I did everything as you've described, but the build is failing saying stuff like that:
Quote:
1>c:\games\orbiter2010dev\orbitersdk\d3d11client\R esources.h(10): fatal error C1083: Cannot open include file: 'Headers\OrbiterAPI.h': No such file or directory
1> CloudManager.cpp
1>c:\games\orbiter2010dev\orbitersdk\d3d11client\R esources.h(10): fatal error C1083: Cannot open include file: 'Headers\OrbiterAPI.h': No such file or directory
1> CSphereMgr.cpp
1>c1xx : fatal error C1083: Cannot open source file: 'CSphereMgr.cpp': No such file or directory
I've checked - that's what's actually in .vcxproj file, but those files don't exist in repo. First files are probably from SDK, so this part is fixable, but what about files like CSphereMgr.cpp? There are quite a number of such files - it looks like project file was not updated for a while...

I've never used Hg before (I'm MS guy - so TFS, and sometimes SVN ) so if you would assist me I'd really appreciate it

---------- Post added at 03:17 AM ---------- Previous post was at 01:03 AM ----------

UPDATE:
OK, whatever it was - I've fixed project file, set up Debug configuration to actually perform a debug build , and set up debugging settings so now if you launch app in debug configuration using VS's "Start Debugging" command - it will launch orbiter and attach to it.
Also fixed mess with missing header files too - btw putting a dozen of classes into one file is a bad idea. I'm a .NET developer and there is a nice convention in C# - one file - one class.
And the last update for today (it's still Tuesday here ) - added "Shaders" vfolder into project and added all shader files there - for ease of use. BTW - what do you guys use for editing shaders? I use this plugin for Visual Studio, which offers nice syntax highlighting. Also I'm going to add shaders compilation step into the build later - just like I did for my own project - it really helps to catch stupid errors like typos without a need to launch app and find out that some shader doesn't work

Last edited by asmi; 01-11-2012 at 03:59 AM. Reason: update
asmi is offline   Reply With Quote
Thanked by:
Old 01-11-2012, 07:53 AM   #21
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by asmi View Post
 well I did everything as you've described, but the build is failing saying stuff like that:

I've checked - that's what's actually in .vcxproj file, but those files don't exist in repo. First files are probably from SDK, so this part is fixable, but what about files like CSphereMgr.cpp? There are quite a number of such files - it looks like project file was not updated for a while...
Indeed it is so. If you check Glider's ZIPs, you'll see that he just packages the code, no project files. Therefore, Glider's master is just a dump of his ZIP archive, plus some infrastructure files.

The Face/Glider branch is me fixing solutions and projects for it, but as you can see in the history, I didn't update it for his newest snapshot.

Quote:
Originally Posted by asmi View Post
 I've never used Hg before (I'm MS guy - so TFS, and sometimes SVN ) so if you would assist me I'd really appreciate it
Well, in this case you have to go through a paradigm shift. HG is a DVCS, and as such it works completely different to centralized VCSs like TFS or SVN. With the later, you have only one central repository on some server, with commit permissions for several users. With DVCS, there is no central repository, but copies of the repo on every developer's machine.
Thus you can "clone" the repo to your machine and commit locally without having to ask for permission. Later on you can "push" your new commits to some other repository you have permission to (let's say your own bitbucket repo - it's free there), or you can ask someone to "pull" from you (via the built-in webserver), or you simply send patches or bundles via conventional channels (email, forum).

Unfortunately it is a bit too much to describe it here, but I can give some links: TortoiseHg for the de-facto standard Windows GUI (batteries included) and Joel Spolsky's tutorial.

Oh, by the way: MS uses Mercurial, too .

regards,
Face

---------- Post added at 08:10 ---------- Previous post was at 08:01 ----------

Oh, I see you already forked/cloned it on Bitbucket. So now you can use TortoiseHg to clone it to your machine, commit your changes locally in whatever granularity you like, then push it to your Bitbucket fork. From there, I can pull it into my repository. But as my repository is in no way a blessed one, it wouldn't matter. That's the essence of being distributed.

---------- Post added at 08:14 ---------- Previous post was at 08:10 ----------

...and of course you've done that already . Well, I guess you've got it, then .

---------- Post added at 08:53 ---------- Previous post was at 08:14 ----------

Pulled asmi's changes as Asmi/master branch to my repo and merged it into my Face/Glider branch (with added re-compiled binary). Looks good! Nice work, asmi.
Face is offline   Reply With Quote
Thanked by:
Old 01-11-2012, 07:58 AM   #22
asmi
Addon Developer
Default

I'm a quick learner As any real developer has to be
As I said I've set up project file and made some changes to set up debug build and debugging mode. Now as you build project, make sure you set up desired build config - debug config for development, and release - for release. As you can see from code, there are few differences now in those configs
asmi is offline   Reply With Quote
Old 01-11-2012, 04:21 PM   #23
Glider
Addon Developer
 
Glider's Avatar
Default

Quote:
Originally Posted by asmi View Post
 BTW - what do you guys use for editing shaders? I use this plugin for Visual Studio, which offers nice syntax highlighting.
I use the same thing for HLSL. Also I use "Highlighterr" (http://highlighterr.codeplex.com/) for additional highlighting of macros/#defines and class/struct/function names in C++ code.

Currently I'm working on extended TileManager class (TerrainManager), with support of heightmaps, normal maps and LCC maps for planets and other features. TileManager code was significantly modified (I removed L8-L14 vertex buffers and created only 1 VB with 2 kinds of tile meshes. And then I use vertex sahder to create needed resolution level using heightmap texture and ilat, nlat, ilng, nlng, lvl. It should remove L14 limitation and allow simplier code. Also it will be needed for other features I want to add. ), so first I will try to get this new class working. If it will work correctly, I will merge my code with asmi's, fork Face's repo and upload my changes there.
Glider is offline   Reply With Quote
Old 01-11-2012, 04:49 PM   #24
asmi
Addon Developer
Default

Quote:
Originally Posted by Glider View Post
 I use the same thing for HLSL. Also I use "Highlighterr" (http://highlighterr.codeplex.com/) for additional highlighting of macros/#defines and class/struct/function names in C++ code.

Currently I'm working on extended TileManager class (TerrainManager), with support of heightmaps, normal maps and LCC maps for planets and other features. TileManager code was significantly modified (I removed L8-L14 vertex buffers and created only 1 VB with 2 kinds of tile meshes. And then I use vertex sahder to create needed resolution level using heightmap texture and ilat, nlat, ilng, nlng, lvl. It should remove L14 limitation and allow simplier code. Also it will be needed for other features I want to add. ), so first I will try to get this new class working. If it will work correctly, I will merge my code with asmi's, fork Face's repo and upload my changes there.
I had similar plans, however instead of bump-mapping I was going to use tesselation as "real" geometry looks way better then whatever you can simulate with bump/normal mapping. But this requires us to stick to shader model 5, and, therefore, feature level 11 (FL11) only - as hardware tesselation doesn't work in SM4 (or, more accurately have severe restrictions as the only way to that is to use geometry shaders, while with the use of Hull and Domain shaders we can achieve amazing detail with very little performance drawback). I'm using Alienware M17R3 laptop with 3D monitor so my hardware is SM5-compliant
I think what we really need to do is to settle down a list of things we're going to implement, otherwise it will very quickly become just a mixture of "feats" completely unrelated to each other, which will serve the purpose of a hobby projects, yet will not be anything useful for anyone other than author.
And to give this discussion a kickstart, here is what I suggest:
1. Property implement beacons for vessels, including proper lighting by them - I've already implemented that in my project, so I will take care of transferring it to this project - consider it done for now
2. Adaptive tesselation for planet rendering - currently specular highlights looks very bad at close distance due to large size of trianges. And/or properly implemented Phong per-pixel lighting for terrain.
3. After (1) is done, we'll need to come up with some way of implementing per-pixel lighting for vessel, that would also support variable lights count. There is a prioblem that you can't pass an array between pipeline stages, so I'd suggest to remedy this problem again with adaptive3 tesselation - if primitives are small enough you can't tell the difference between per-vertex and per-pixel lighting.
4. After (3) is done, we'll need to come up with some way to provide a self-shadowing parts of the vessel - like a central body of the vessel occluding a wing for the beacon that's on another wing. Shadow maps sounds unpractical due to multiple passes neccessary to create map (one pass - one light source), so I'd suggest applying Parralax Occlusion Mapping or similar approach to fix it up.
5. Add some post-processing effects like lense glare and such - it will improve realism.
6. Design some sort of API for vessel developers so they would be able to take advantage of great array of new possibilities that were brought by D3D11. Possibly custom shaders, advanced particle effects.
7. I'd move computing particle systems' state propagation into compute shaders to free up CPU for the simulation itself. Again FL11 only.

That is what I've got in mind - please comment/add your thoughts on the subject.

Oh, and one more thing - please please please give variables some more meaningful names than "aux" - especially in shaders. And comments!

Last edited by asmi; 01-11-2012 at 04:51 PM.
asmi is offline   Reply With Quote
Old 01-11-2012, 06:13 PM   #25
Glider
Addon Developer
 
Glider's Avatar
Default

Quote:
Originally Posted by asmi View Post
 I had similar plans, however instead of bump-mapping I was going to use tesselation as "real" geometry looks way better then whatever you can simulate with bump/normal mapping. But this requires us to stick to shader model 5, and, therefore, feature level 11 (FL11) only - as hardware tesselation doesn't work in SM4 (or, more accurately have severe restrictions as the only way to that is to use geometry shaders, while with the use of Hull and Domain shaders we can achieve amazing detail with very little performance drawback). I'm using Alienware M17R3 laptop with 3D monitor so my hardware is SM5-compliant
Actually, I intended to use normal mapping only for high-orbit views and then switch to real geometry based on heightmaps. I understand that normal mapping doesn't look good on spherical planets at low altitudes. Also, there's one big problem:
Large % of users doesn't have DX11 hardware.

Quote:
Originally Posted by asmi View Post
 1. Property implement beacons for vessels, including proper lighting by them - I've already implemented that in my project, so I will take care of transferring it to this project - consider it done for now
yes, that should be nice.

Quote:
Originally Posted by asmi View Post
 2. Adaptive tesselation for planet rendering - currently specular highlights looks very bad at close distance due to large size of trianges. And/or properly implemented Phong per-pixel lighting for terrain.
I think much more important thing is to turn current large planet balls into something that have terrain. So, I suggest add support of heightmaps, + add heightmap generator for planets without heightmap files. Large ball with PPL and tesselation doesn't differ much from a large ball with PVL.

Quote:
Originally Posted by asmi View Post
 3. After (1) is done, we'll need to come up with some way of implementing per-pixel lighting for vessel, that would also support variable lights count. There is a prioblem that you can't pass an array between pipeline stages, so I'd suggest to remedy this problem again with adaptive3 tesselation - if primitives are small enough you can't tell the difference between per-vertex and per-pixel lighting.
FL11...

Quote:
Originally Posted by asmi View Post
 4. After (3) is done, we'll need to come up with some way to provide a self-shadowing parts of the vessel - like a central body of the vessel occluding a wing for the beacon that's on another wing. Shadow maps sounds unpractical due to multiple passes neccessary to create map (one pass - one light source), so I'd suggest applying Parralax Occlusion Mapping or similar approach to fix it up.
Yes, shadows from local lights would be nice feature.

Quote:
Originally Posted by asmi View Post
 5. Add some post-processing effects like lense glare and such - it will improve realism.
Also, good feature.

Quote:
Originally Posted by asmi View Post
 6. Design some sort of API for vessel developers so they would be able to take advantage of great array of new possibilities that were brought by D3D11. Possibly custom shaders, advanced particle effects.
I don't think addon devs will use that... May be when this client will have some really impressive features they will, but not at first.

Quote:
Originally Posted by asmi View Post
 7. I'd move computing particle systems' state propagation into compute shaders to free up CPU for the simulation itself. Again FL11 only.
It shouldn't create much difference... but it doesn't seems to be very hard to add. And why only FL11 ? CS works on FL10/10_1 with some restrictions though...

Quote:
Originally Posted by asmi View Post
 That is what I've got in mind - please comment/add your thoughts on the subject.
Features I suggest to implement first:
1.Since you have already implemented beacons as point-lights it would be nice to add them first.
2.real terrain on planets + heightmap generation + vessel/tile collisions
3.shadow mapping for vessels + shadows for beacons/local lights
4.Better clouds
5.lens glare
6.better atmosphere
7.vegetation (and other details on terrain)
8.may be some hdr lighting ?

Then, I think we should start work on features that require FL11.
Glider is offline   Reply With Quote
Old 01-11-2012, 07:07 PM   #26
asmi
Addon Developer
Default

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. Again as a fall-back technique for SM4 we can leverage GS.
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
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.
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.
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.

Now to your things:
1. As I said - consider it done I will add this in a matter of days.
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. Collision detection is a physics engine feature, so there is no way we can implement it - we have to ask Martin to do so
3, 4 Agreed
5. See my notes above about PP effects in general
6 agreed
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.
8. That's a PP effect as well, so see above.

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

Last edited by asmi; 01-11-2012 at 08:11 PM. Reason: typos :(
asmi is offline   Reply With Quote
Old 01-11-2012, 07:15 PM   #27
Zatnikitelman
Addon Developer
 
Zatnikitelman's Avatar
Default

Quote:
Originally Posted by Glider View Post
 I don't think addon devs will use that... May be when this client will have some really impressive features they will, but not at first.
Speaking as an addon developer, I have to agree with this point. Once the DX11 client is up and going at least where the DX9 client is now in terms of stability, end-user features (eye-candy), etc. then looking at an API to let developers implement vessel-specific features might be good.
Zatnikitelman is offline   Reply With Quote
Old 01-11-2012, 07:24 PM   #28
Jarod
Orbinaut
Default

Do you plan to add self shadowing terrain ?

Jarod is offline   Reply With Quote
Old 01-11-2012, 07:38 PM   #29
asmi
Addon Developer
Default

Quote:
Originally Posted by Zatnikitelman View Post
 Speaking as an addon developer, I have to agree with this point. Once the DX11 client is up and going at least where the DX9 client is now in terms of stability, end-user features (eye-candy), etc. then looking at an API to let developers implement vessel-specific features might be good.
Yes I absolutely understand that. As for eye-candy looks - I'd argue it already looks better than stock graphics client, and if we'll implement everything mentioned above - it will add a lot in terms of visual quality. Allthough I do realize that we've got quite a long run ahead of us before in can be declared as "stable" - I envision at least several months, since we all do that in our spare time...

Quote:
Originally Posted by Jarod View Post
 Do you plan to add self shadowing terrain ?

{image}
That would certainly be on our TODO list after we'll implement terrain one way or another. BTW stream-out feature of GS 5 would be extremely helpful as we can do a miltiple passes without a need to re-calculate terrain for a shadow maps.
asmi is offline   Reply With Quote
Thanked by:
Old 01-11-2012, 08:26 PM   #30
asmi
Addon Developer
Default

Glider,

Take a look at the screenshot to see what tesselation is all about (click to enlarge):
Click image for larger version

Name:	tesselation.png
Views:	93
Size:	52.9 KB
ID:	8985

This was generated from a single square (4 vertices + 4 indices) using tesselation factor of just 20 (up to 64 is available), and then morphed in Domain shader to a sphere patch using parametric sphere equation. If you want - I can give a source code for that so you can play around with it - it's really very simple. In our case we can accurately morph mesh according to heightmap + possibly use some spline interpolation algorithm like smooth Bezier curves to produce very impressive results.
asmi 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 04:59 PM.

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.