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-13-2012, 05:58 PM   #61
asmi
Addon Developer
Default

Quote:
Originally Posted by orb View Post
 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.
Thanks for the info. For the implementation point of view, there doesn't seem to be a lot of issues - for instance RP_ISTLDEVICE doesn't make sence in our case since we don't have fixed pipeline, and as far as I understand DX11 doesn't care about texture's requirements, so RP_REQUIRETEXPOW2 is also not applicable.

Ok, I'm going to see if I can fix this over the weekend...
asmi is offline   Reply With Quote
Old 01-13-2012, 06:15 PM   #62
orb
O-F Administrator
Ninja
 
orb's Avatar

Default

Quote:
Originally Posted by asmi View Post
 Ok, I'm going to see if I can fix this over the weekend...
Even if there are no changes in the code, there needs to be made a separate build of graphics client for Orbiter beta users (using binary builds, and not compiling the client from sources), because of changed class interface, which is the basic reason why the graphics client built for Orbiter 100830 doesn't work in Orbiter beta.
orb is offline   Reply With Quote
Old 01-13-2012, 06:31 PM   #63
asmi
Addon Developer
Default

Quote:
Originally Posted by orb View Post
 Even if there are no changes in the code, there needs to be made a separate build of graphics client for Orbiter beta users (using binary builds, and not compiling the client from sources), because of changed class interface, which is the basic reason why the graphics client built for Orbiter 100830 doesn't work in Orbiter beta.
Yes, I understand that. I wonder if there are any breaking changes, i.e. the ones that would prevent graphics client from being compilable against both SDKs (public release and current beta build) at the same time... Do you have any information on that?
asmi is offline   Reply With Quote
Old 01-13-2012, 07:24 PM   #64
orb
O-F Administrator
Ninja
 
orb's Avatar

Default

Quote:
Originally Posted by asmi View Post
 Yes, I understand that. I wonder if there are any breaking changes, i.e. the ones that would prevent graphics client from being compilable against both SDKs (public release and current beta build) at the same time... Do you have any information on that?
Well, from looking at sources of D3D7Client and D3D9Client, I think you need to define at least clbkCreateSurfaceEx in graphics client for Orbiter beta, which isn't defined for Orbiter 2010-P1, but you can use conditional compiling for that without duplicating sources, with for example:
Code:
#ifdef RP_REQUIRETEXPOW2
(as I can't see Orbiter version defined anywhere in the SDK headers)
orb is offline   Reply With Quote
Old 01-13-2012, 07:29 PM   #65
Glider
Addon Developer
 
Glider'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
Current 2D code of D3D11Client works this way:
There're 2 types of textures;
1."Texture". these textures have mipmaps number specified by user and no restrictions to format (D3DX11GetImageInfoFromFile() decides what format a texture will have, usually it is same format that was in file) These textures are being used as vessel mesh textures and can be created only by loading from file.They can work only as SRs.
2."Surface" can be used as SRs as well as RTs in 2D code. They must have B8G8R8A8_UNORM format only, have no mipmaps, have GDI-compatibility flag, and must have SampleCount == 1. These "surface"s are being used as HUD, MFD, any 2D buffers, GDI-buffer for back buffer etc."surface"s can be created by conversion from "texture"s, by clbkCreateSurface() or from bitmap. "surface" can be used as mesh texture. (examples: HUD/MFDs)

Blit/Fill and similar functions works only with "surfaces" and if they encounter "texture" they create "surface" of the same size, render "texture" to "surface", and switch these 2 objects with memcpy(). then original "texture" (that have pointer of new "surface") is deleted. (See TextureMgr::ConvertSurfaceToTexture() function ).

in new beta there're:
render params:
RP_ISTLDEVICE or T&L. since it is ancient thing, and FL10/FL11 devices doesn't have problems with it, we may set it to 1 always
RP_REQUIRETEXPOW2 I didn't encouner any problems with power of 2 (all sizes works), so we don't need this.

clbkCreateSuraceEx()
if by CPU access is meant GDI then:
OAPISURFACE_RO all "surface"s can be rad by both CPU & GPU.
OAPISURFACE_RW all "surface"s can be updated by GPU as well, and may work as RTs
OAPISURFACE_GDI all "surface"s can be read by GPU and be blit()'ed to other "surface"s
OAPISURFACE_MIPMAPS "surface" can't have mipmap it is required for D3D11/GDI compatibility
OAPISURFACE_NOALPHA we can't choose format for "surface" it B8G8R8A8 required

clbkLoadSurface()
we can add a method for Texture class to do this, or just create "texture" that will be converted to "surface" anyway.

clbkBeginBltGroup and clbkEndBltGroup
we don't need this. current blitting is done by ID3D11DeviceContext::CopySubresourceRegion() that doesn't require such params.

So, I think in order to make D3D11Client compatible with 2010P2 we need to recompile it and just connect new functions to old 2D code. I see in debugger that the client currently CTDs on things like tex->bTex where tex is NULL (FillSurface()). may be it is because new functions aren't implemented or Orbiter want to fill entire back buffer with some color.
Glider is offline   Reply With Quote
Old 01-14-2012, 04:27 AM   #66
asmi
Addon Developer
Default

Ok, so I've changed shader - now it should run on FL10 without any issues. I've also added specular lighting - now it looks even more beautiful For now I've hardcoded specular power of 30, which assumes medium to high reflective material, which covers much of real metals.
I think that's it for vessel beacons lighting - I think self-shadowing can wait a bit - so we can check off first item in TODO list as completed Now I'm going to try to convert it to latest beta and make it work
Source code is as always in my fork: https://bitbucket.org/asmi/ovp Looks like this will be the last version that is built against and so compatible with 2010 P1 build, next one (hopefully ) will work with the beta.

---------- Post added at 21:47 ---------- Previous post was at 20:44 ----------

Ok, here is the first problem - comment for method clbkCreateSurfaceEx reads:
Quote:
* \note The attribute flag can contain one of the following main attributes:
* - OAPISURFACE_RO: create a surface that can be read by the GPU pipeline, and that can be updated from system memory.
* - OAPISURFACE_RW: create a surface that can be read and written by the GPU pipeline, and that can be updated from system memory.
* - OAPISURFACE_GDI: create a surface that can be read and written from the CPU, and can be blitted into an uncompressed RO or RW surface without an alpha channel
* In addition, the flag can contain any combination of the following auxiliary attributes:
* - OAPISURFACE_MIPMAPS: create a full chain of mipmaps for the surface if possible
* - OAPISURFACE_NOALPHA: create a surface without an alpha channel
In reality first two flags are not defined, instead we have this:
Quote:
#define OAPISURFACE_TEXTURE 0x0001 ///< Surface can be used as a texture (e.g. by associating it with a mesh)
#define OAPISURFACE_RENDERTARGET 0x0002 ///< Surface can be rendered to by the graphics device
#define OAPISURFACE_GDI 0x0004 ///< A HDC context can be requested from the surface for GDI drawing
#define OAPISURFACE_SKETCHPAD 0x0008 ///< A Sketchpad context can be requested from the surface for Sketchpad drawing
#define OAPISURFACE_MIPMAPS 0x0010 ///< Create a full chain of mipmaps for the surface. If loaded from file, add any missing mipmap levels
#define OAPISURFACE_NOMIPMAPS 0x0020 ///< Don't create mipmaps. If loaded from file, ignore any mipmap levels present
#define OAPISURFACE_ALPHA 0x0040 ///< Create an alpha channel for the surface. If loaded from file, add an alpha channel if required
#define OAPISURFACE_NOALPHA 0x0080 ///< Don't create an alpha channel. If loaded from file, strip any existing alpha channel
#define OAPISURFACE_UNCOMPRESS 0x0100 ///< Create an uncompressed surface. If loaded from file, uncompress if required.
#define OAPISURFACE_SYSMEM 0x0200 ///< Create the surface in system (host) memory
#define OAPISURFACE_RENDER3D 0x0400 ///< Create a surface that can act as a target for rendering a 3D scene
So for now I'm going to work with flags that are actually defined, and looks like we've gotta wait for next beta update to get those new flags covered...

---------- Post added at 23:27 ---------- Previous post was at 21:47 ----------

Ok, guys, I did a conversion using very "naive" approach - see code diff for details, and to test is has decided to take it for a ride. I took off KSC runaway and reached LEO without any problems:

However as I've tried to land, it did crash at some point during "ducking" (bouncing off atmosphere during reentry), stack trace suggested that it had something to do with GDI. So I'd appreciate if anyone can give it a try to see how things are. Glider, I'm going to need your assistance with this fix as I have very little knowledge about workings of 2D in the client.

Also there is one more thing that I've noticed - Sun is displayed only if "Planetaruim mode" is enabled. Not sure if this is a new bug, or an old one - since I never tried to get to space before "upgrade"

Last edited by asmi; 01-14-2012 at 04:29 AM.
asmi is offline   Reply With Quote
Thanked by:
Old 01-14-2012, 10:37 AM   #67
Xyon
Puts the Fun in Dysfunctional
 
Xyon's Avatar


Default

I've no log or trace yet (haven't run it in the debugger yet) but all I got on my testbed install was a CTD. And Windows' dead helpful "this isn't working" message.
Xyon is offline   Reply With Quote
Old 01-14-2012, 03:28 PM   #68
asmi
Addon Developer
Default

Quote:
Originally Posted by Xyon View Post
 I've no log or trace yet (haven't run it in the debugger yet) but all I got on my testbed install was a CTD. And Windows' dead helpful "this isn't working" message.
Well, thanks for giving it a ty anyways
Did you build it from sources or just used dll that is in the source control? I've just added *.pdb file that can help with diagnosis in this case. Also I'm not sure how app would react to missing config file - so did you configute a settings for the module in the "Video" tab?
asmi is offline   Reply With Quote
Old 01-14-2012, 03:56 PM   #69
Glider
Addon Developer
 
Glider's Avatar
Default

Quote:
Originally Posted by asmi View Post
 Ok, so I've changed shader - now it should run on FL10 without any issues.
Looks great, especially with enabled normal maps in the night.

Quote:
Originally Posted by asmi View Post
 In reality first two flags are not defined, instead we have this:
I think it doesn't change much:
OAPISURFACE_TEXTURE any "surface" can be used as texture
OAPISURFACE_RENDERTARGET any "surface" works as render target
OAPISURFACE_GDI any "surface" works with GDI
OAPISURFACE_SKETCHPAD any "surface" works with sketchpad. both GDIPad and D3D11Pad.

OAPISURFACE_MIPMAPS and OAPISURFACE_NOMIPMAPS we can't create mip maps for "surface". D3D11/GDI compatibility requirement.

OAPISURFACE_ALPHA and OAPISURFACE_NOALPHA we have only B8G8R8A8 format available for "surface". Another D3D11/GDI compatibility requirement.

OAPISURFACE_UNCOMPRESS "surface" cannot be compressed. D3D11/GDI compatibility requirement also.

OAPISURFACE_SYSMEM it is D3D9 specific thing. though, may be in the case of DX10/11 it means STAGING usage. Anyway we don't need STAGING textures for 2D. all "surface"s have DEFAULT usage.

OAPISURFACE_RENDER3D all "surface"s have RT bind, so they all can work as render targets.

So, it seems that your code is correct. + see comment below.

Quote:
Originally Posted by asmi View Post
 Ok, guys, I did a conversion using very "naive" approach - see code diff for details, and to test is has decided to take it for a ride. I took off KSC runaway and reached LEO without any problems:
{image}
However as I've tried to land, it did crash at some point during "ducking" (bouncing off atmosphere during reentry), stack trace suggested that it had something to do with GDI. So I'd appreciate if anyone can give it a try to see how things are. Glider, I'm going to need your assistance with this fix as I have very little knowledge about workings of 2D in the client.
I updated my 2010P2 version of the project with latest code from your fork, compiled it and tested. I tried XR2, XR5, default DG, with debug and release builds(speed optimizations enabled + SSE2, attached to this message). I took DG and flew to orbit, made 1 orbit and landed somehere in ocean. Also tried a bit fly XR2 and XR5. There were no CTD. (only bug with ClearRTV() when MFD doesn't redraw itself) When does this CTD happens and what it has to do with GDI ? I used 111105 Orbiter beta.

Quote:
Originally Posted by asmi View Post
 Also there is one more thing that I've noticed - Sun is displayed only if "Planetaruim mode" is enabled. Not sure if this is a new bug, or an old one - since I never tried to get to space before "upgrade"
I didn't saw it too. Sun worked correctly.
Attached Files
File Type: zip Modules.zip (287.2 KB, 21 views)
Glider is offline   Reply With Quote
Old 01-15-2012, 12:29 AM   #70
asmi
Addon Developer
Default

Got it just now. Texture.cpp:59.
D3D11: ERROR: ID3D11Device::CreateTexture2D: Returning E_OUTOFMEMORY, meaning memory was exhausted. [ STATE_CREATION ERROR #105: CREATETEXTURE2D_OUTOFMEMORY_RETURN ]
LOL Something has requested a "texture" with following parameters:
W: 1438129258
H: 3893313765
data: 0x0002b9a6
Stack trace:
Quote:
ntdll.dll!76ec15de()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!76ec15de()
ntdll.dll!76eb014e()
d3d11.dll!173b8506()
d3d11.dll!173b9c80()
D3D11SDKLayers.dll!0f3e215d()
D3D11Client.dll!Texture::Texture(unsigned long w, unsigned long h, void * data) Line 59 + 0x25 bytes C++
cccccccc()
Look at the top frame - looks like there is a bigger problem somewhere

---------- Post added at 11:11 ---------- Previous post was at 11:05 ----------

UPDATE:
I've loaded symbols and got more useful stack trace:
Quote:
ntdll.dll!_ZwRaiseException@12() + 0x12 bytes
ntdll.dll!_ZwRaiseException@12() + 0x12 bytes
d3d11.dll!CDevice::CreateTexture2D_Worker() + 0x144 bytes
> D3D11Client.dll!TextureMgr::CreateTextureFromBitma pRect(HBITMAP__ * hbm, int x, int y, int dx, int dy) Line 972 + 0x37 bytes C++
D3D11Client.dll!TextureMgr::CopyBitmap(Texture * tex, HBITMAP__ * hbm, int x, int y, int dx, int dy) Line 483 + 0x1c bytes C++
D3D11Client.dll!D3D11Client::clbkCopyBitmap(void * pdds, HBITMAP__ * hbm, int x, int y, int dx, int dy) Line 506 C++
orbiter.exe!00433565()
[Frames below may be incorrect and/or missing, no symbols loaded for orbiter.exe]
orbiter.exe!004293bb()
orbiter.exe!0045633e()
D3D11Client.dll!D3D11Client::clbkRenderScene() Line 202 + 0x1a bytes C++
orbiter.exe!00418203()
orbiter.exe!0041b77f()
orbiter.exe!0041b978()
orbiter.exe!004b176f()
kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes
ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes
ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes
Still have to clue what's going on...
UPDATE2:
Quote:
First-chance exception at 0x0403a023 (D3D11Client.dll) in orbiter.exe: 0xC0000005: Access violation reading location 0x00000000.
Unhandled exception at 0x76ec15de in orbiter.exe: 0xC0000005: Access violation reading location 0x00000000.
Looks like we've got a classic "memory-run-through"

---------- Post added at 19:29 ---------- Previous post was at 11:11 ----------

Just tried to do the same thing again - and everything went just fine... Odd thing...
Allthough I've seen a bunch of fist-chance COM exception in debug window when I switch to VC, so maybe it's somewhere in that area.

Last edited by asmi; 01-14-2012 at 04:16 PM.
asmi is offline   Reply With Quote
Old 01-15-2012, 11:55 AM   #71
Glider
Addon Developer
 
Glider's Avatar
Default

Oh, sorry, it seems I didn't look at this problem close enough...
I'm getting the same exceptions in VC modes and 2 access violations after exit, but in my case I don't get any CTDs during simulation.
commenting vVessel::RenderVC() completely fixes it, so I think it definitely has to do something with HUD/MFD/Mesh.fx/Vessel.fx. I will try to find exact reason for this bug now.

UPDATE:
I've fixed com exceptions by changing code of clbkReleaseSketchpad:
Code:
if( cfg->SketchPadMode == 1 ) {			//GDI for surfaces, D3D11Pad for backbuffer	[mode 1]
		SURFHANDLE surf = Skpad->GetSurface();
		if( surf ) {
			if( surf == HUDTEX ) {
				d3d11_pad = (D3D11Pad*)Skpad;
				delete d3d11_pad;
				return;
			}
			gdi_pad = (GDIPad*)Skpad;
			clbkReleaseSurfaceDC( gdi_pad->GetSurface(), gdi_pad->GetDC() );
			delete gdi_pad;
			return;
		}
		else {
			d3d11_pad = (D3D11Pad*)Skpad;
			if( cfg->RThread ) {
				LeaveCriticalSection( &Resources );
				SetEvent( ResourceReleased );
			}
			delete d3d11_pad;
			return;
		}
	}
and in the clbkGetSketchpad:
Code:
if( HUDTEX && HUDTEX == tex ) {
		SC->PBuffers_counter++;
		if( cfg->RThread ) {
			SetEvent( ResourceRequest );
			EnterCriticalSection( &Resources );
		}
		return new D3D11Pad( surf );
	}

Last edited by Glider; 01-15-2012 at 03:26 PM.
Glider is offline   Reply With Quote
Thanked by:
Old 01-15-2012, 04:32 PM   #72
asmi
Addon Developer
Default

Quote:
Originally Posted by Glider View Post
 I've fixed com exceptions by changing code of clbkReleaseSketchpad:
and in the clbkGetSketchpad:
You are genious! I've incorporated your fix & committed it to my fork - it seems to be working just fine now!

---------- Post added at 11:32 ---------- Previous post was at 11:05 ----------

Also I've updated project's Wiki to reflect current state of affairs.

Last edited by asmi; 01-15-2012 at 04:36 PM.
asmi is offline   Reply With Quote
Old 01-17-2012, 11:58 PM   #73
asmi
Addon Developer
Default

Just to give you guys an update, I'm working on HDR lighting and some related effects (like gloom). Don't have ETA at this point as it's quite a complicated thing (especially since I'm limited to FL10, which rules out some really useful features)...

Last edited by asmi; 01-18-2012 at 02:38 AM.
asmi is offline   Reply With Quote
Old 01-18-2012, 09:02 PM   #74
RacerX
Donator
 
RacerX's Avatar
Default

So will this make it so I don't pass through the ISS or other ships now when docking?
RacerX is offline   Reply With Quote
Old 01-18-2012, 10:49 PM   #75
asmi
Addon Developer
Default

Quote:
Originally Posted by RacerX View Post
 So will this make it so I don't pass through the ISS or other ships now when docking?
No, this is completely unrelated thing, allthough this could be doable too...
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 05:45 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.