New Release D3D9Client Development

[dbeachy1]

I agree. git is a real pain in the *** for beginners. I have to use it once in a while and it's always waaaay to complicated.

:hesaid: We migrated to Git at work six months ago, and we're still fighting with it. It's got quite a learning curve, and the constant merging between branches and dealing with multiple repositories for a single product is a pita. Personally, I much prefer SVN or Perforce, but to each his own.

 

[SolarLiner]

I guess that's why both SVN and Git are popular, as I don't like SVN, but to each their own as said. Even as a beginner it's always been easier for me to use Git. Even the simple fact you can add several commits before pushing makes it so much convenient to documents changes in the code. And the PRs makes it so much better for small contributions.

I do agree that this place is the place for D3D9, but is it really built for everything that this project demands? I guess O-F is running on a dedicated server, so something could be made for D3D9, but all those tools were made for the jobs that you guys are asking for. It's not my project, I'm just giving arguments; but I don't think building everything from scratch is the right way to go here.

 

[jarmonik]

D3D9Client 2016 Edition R1 has launched on CodePlex. (Temporary solution)

I have also been working on a documentation for the PBR rendering system and gcAPI but it did not make it (or made it) to R1 release in time due to some problems I discovered in PBR while writing the documentation and some schematics.

So, here are some plans for R2

- Getting an official website for the project operational would be nice. I guess I have to leave it to Kuddel and SolarLiner.
- Properly finishing the PBR and Sketchpad code.
- Level "1" surface micro textures do need separate normal and albedo maps to get the Mars looking better.
- Integration of the Lens flare code.
- Documentation updates for the client.

Any other pressing issues ?

---------- Post added at 23:21 ---------- Previous post was at 23:11 ----------

And the PRs makes it so much better for small contributions.

Doesn't small contributors usually tend to copy-paste the code changes to the forum instead of installing Git and creating accounts.

So, it would seem that we stay with the SVN for now. A change to the Git would require better reasons that has been presented so far.

 

[DaveS]

A possible bug report: This is actually something I started noticing a few releases back for 2010-P1, it's that the diffuse particle streams are abnormally dark, almost to the point that they look soot. Is this the intended appearance or as something gotten broken?

 

[Face]

So, it would seem that we stay with the SVN for now. A change to the Git would require better reasons that has been presented so far.

Also, it should be noted that modern DVCS systems like Git anyway have well functioning two-way bridges. I bet SolarLiner is running a Git clone of the SVN repo just the same as I am running a Mercurial clone of it.
If there ever comes the need to switch, it shouldn't be a big deal.

However, I'd suggest to put up some information for potential contributors, so they know what the preferred way of contributing actually is. Is it patch posting, patch emailing, ZIP exchange, etc. ? Of course you can support all of them, but there really should be some kind of direction you can follow.

A proposal could be like so:

• Present your code change as a post with a small description in thread XYZ here on O-F.
• Depending on the size of your change, either post snippets directly in the presenting post, or put up SVN patches in compressed form (ZIP) as attachments or links, with the patch name being <short_patch_description>_r<SVN_revision_patch_is_based_on>.patch
• If your change gets reviewed and you are asked for adjustments, please re-submit the code change as a whole again, as if it was a new submission. This is because there might have been many development and/or others patches between review and re-submission, and the development team can't always keep track of individual patches.
• Try to base your patch as close to the trunk head as possible.

At least these are the major points of contribution to most old-style open-source projects I've encountered, and so far they're sailing along fairly good with it.

 

[Evil_Onyx]

This may be a Bug or a Feature but, I had a problem with no planet textures showing in the D3D9 Client but it the inline client it was fine.

I had created a folder for the highres textures in the \Textures2 folder with the same structure as the \Textures folder eg. \Textures2\Earth\Archive . But I put the HighRes Textures in \Textures\Earth\Archive in stead and forgot to delete the Tex2 folders but left them empty. I seems that the D3D9 Client does not check to see if a folder has anything in it before defaulting to using the textures in the \Textures2 folder.

Hope it helps.

 

[jarmonik]

This may be a Bug or a Feature but, I had a problem with no planet textures showing in the D3D9 Client but it the inline client it was fine.

That, sounds like a bug. We probably should implement our own bool TexturePath (const char *fname, char *path) const; function to gain little more control of what's happening there. I am currently busy with the actual rendering code and documentation so let's take a look if Kuddel can handle it.

 

[kuddel]

I'll take a look at this on the weekend.
It's all about calls to this API function:

	/**
	* \brief Load a texture from a file.
	* \param fname texture file name
	* \param dynamic allow dynamic modification
	* \return Surface handle for the loaded texture, or NULL if not found.
	* \note Textures loaded by this function should be in DDS format and conform to the
	*  DirectX restrictions for texture surfaces, typically square bitmaps with
	*  dimensions of powers of 2 (128x128, 256x256, etc.).
	* \note File names can contain search paths. Orbiter searches for textures in the
	*  standard way, i.e. first searches the HitexDir directory (usually Textures2),
	*  then the TextureDir directory (usually Textures). All search paths are relative
	*  to the texture root directories. For example, oapiLoadTexture()
	*  ("myvessel\mytex.dds") would first search for Textures2\\myvessel\\mytex.dds, 
	*  then for Textures\\myvessel\\mytex.dds.
	*/
OAPIFUNC SURFHANDLE oapiLoadTexture (const char *fname, bool dynamic = false);

This is what I expect:
"Orbiter searches for textures in the standard way, i.e. first searches the HitexDir directory (usually Textures2), then the TextureDir directory (usually Textures). All search paths are relative to the texture root directories. For example, oapiLoadTexture("myvessel\mytex.dds") would first search for Textures2\\myvessel\\mytex.dds, then for Textures\\myvessel\\mytex.dds."

But anyway, I'll take a look and give you results later.

 

[JMW]

Hi Guys.
While you're on the subject of textures, presume that base tiles are still suppressed.
Understand the reasoning but would it be possible to have an option under Advanced to enable them so user could choose please?

 

[kuddel]

Fix for issue 1214 (probably)

Hi DaveS,

here's the build mentioned in the issue report thread...
Could you try this one? I've included the changes Martin did in the D3D7Client in this D3D9Client build.

It's just the DLL

 

[DaveS]

Hi DaveS,

here's the build mentioned in the issue report thread...
Could you try this one? I've included the changes Martin did in the D3D7Client in this D3D9Client build.

It's just the DLL

No issues and things look good. I think the issue can be closed.

 

[Eduard]

Hi Jarmonik,

Here some notes about your new atmosphere and haze related changes.
There are some points that still feel a bit strange / unnatural to me.

I compared a scenario (I was flying around Habana), by starting Orbiter in paused mode:
By D3D9ClientRC1_forOrbiter2016.zip that you posted here on aug 27:


By your latest build D3D9Client2016-R1.zip downloaded from the website:


In my opinion, the first one is clearly better.
> Look at the coastline close to the horizon. The first image looks more natural, because of how the haze hides the coastline there more realistic.
> Also, look at the water on the right. In the second image, it's almost like ice/snow or something, to much white there. It's like an overexposed photograph.

Then about Mars:

How realistic is it that the atmosphere is so yellow compared to the red surface?
Also, especially when looking at the planet from a large distance, the yellow "halo" around the looks a bit to extreme. Same problem.
Maybe that this is a consequence of the haze reduction, I can understand that. But then some color corrections may also be needed I think.

 

[jarmonik]

Here some notes about your new atmosphere and haze related changes.There are some points that still feel a bit strange / unnatural to me.

I have tuned the martian atmosphere a bit towards red.

The things that has change with the Earth between the two screen shots is the specular lobe seen on the water. It's wider and less intense now when viewed from a higher altitude. How is it supposed to be ?

---------- Post added at 04:28 ---------- Previous post was at 04:21 ----------

I'll take a look at this on the weekend.
It's all about calls to this API function:

But anyway, I'll take a look and give you results later.

That functions gives a SURFHANDLE to our virtual surface interface. We would need a native DX9 texture.

 

[Eduard]

The things that has change with the Earth between the two screen shots is the specular lobe seen on the water. It's wider and less intense now when viewed from a higher altitude. How is it supposed to be ?

Ok, alright, maybe it's better. I also don't know how it should be. I just noticed the difference. The first image seemed better. But of course things are highly depending on altitude.
Maybe it's a good idea to look at some real scientific information about these things, if available (and if you haven't already done that of course).

But there is onother more important thing I have noticed and which I am much more certain about that it needs correction:

That is that colors during sunrise/sunset really look to yellow. It should be more orange/red, with less yellow/green in it.
Of course I can change settings with Ctrl+F4->Atmosphere controls. Adding a bit more red and lowering the green helps. But it also changes the color of the blue daylight sky. So i think there is a problem with the defaults.

Real sky colors are much like a so called "black body". Black body colors range from red/orange to blue, with white in between, depending on what whe refer as the color termperature.
Black body colors contain no yellow or green.
That's also why there are no green or yellow stars (for example sun is called "yellow star", but is is not really yellow, it's completely white).

 

[Abloheet]

Also, is the Sun from the Martian Surface supposed to look so blue? Isn't the Sun supposed to be yellowish or white? From Earth's surface, it looks perfect. With the post processing enabled. The post processing enables HDR, right?

 

[kash01]

HI

I've installed D3d9client and activated it in modules but when I run open a scenario it says "graphic card doesnt meet minimum requirements to run D3DD3d9client" what should I do? Help

 

[SolarLiner]

Also, is the Sun from the Martian Surface supposed to look so blue? Isn't the Sun supposed to be yellowish or white? From Earth's surface, it looks perfect. With the post processing enabled. The post processing enables HDR, right?

The "normal" release does not provide HDR with post processing enabled. My Lens Flares build provide a, well, lens flare effect, but no HDR yet. Properly achieving HDR would mean having to rework a major part of the graphics engine.

 

[kuddel]

IThat functions gives a SURFHANDLE to our virtual surface interface. We would need a native DX9 texture.

That was just a (very) quick thought I posted there

Now weekend is getting closer and I might take a real look into it :thumbup:

---------- Post added at 19:59 ---------- Previous post was at 19:47 ----------

@jarmo BTW:
I wanted to point to this declaration:

	/**
	 * \brief Return the full path for a texture file.
	 *
	 * Returns the fully qualified path for texture file 'fname' in
	 * 'path', relative to the orbiter root directory.
	 * The search method conforms to the standard orbiter convention (first
	 * search under Textures2, then under Textures directory)
	 * Example: for fname="mypath\\tex1.dds", this may return
	 * ".\Textures2\mypath\tex1.dds" or ".\Textures\mypath\tex1.dds"
	 * Return value is false if no file is found in either directory
	 * \param fname texture file name (with path relative to an Orbiter
	 *   texture directory)
	 * \param path string into which the full path is copied
	 * \return true if file was found, false otherwise.
	 */
	bool TexturePath (const char *fname, char *path) const;

...
Now my question:
I've noticed that you've changed some places where this is called in a way, that you provided two different char buffers for fname and path.
The method however returns false in case the path is not valid (anymore).
I know that the content is changed, but as long as we respect the return value it was O.K. on my tests.
Have you experienced any unexpected results in that case? I can not see why/where.
Anyway I'll take a look in how a "specialized" version of TexturePath might benefit in cleaner and easier to maintain application code...
It needs to be thread-save, right?

 

[DaveS]

I'm not sure if this was missed or not: http://www.orbiter-forum.com/showthread.php?p=540562&postcount=4109

 

[Eduard]

Also, is the Sun from the Martian Surface supposed to look so blue? Isn't the Sun supposed to be yellowish or white?

Yes.

Search in google for: mars sunset
And you will see photographs token by the spacecraft/rovers landed on mars.

The dust particles in Mars' atmosphere couse the long wavelengths of light to be scattered more than the short wavelengths, causing the sky to be red and the sunset to be blue.
Pretty much opposite of the situation on Earth, which has a much denser atmosphere, so that the air molecules itself cause much Rayleigh scattering.