Question to the Dr Schweiger on the subject of the nightlights textures

[fort]

Dr Schweiger,

I am in the circumstance to try to reproduce through local ( ehm...sometimes few dizaines kilometers in all directions ) detailed scenes ( level 14...I think, 38 m by pixel ) what can be seen, from space, flying over a city ( 50 to 200 km above ); including night lights. And, very accessorily, local detailed scenes for bases, including night lights, too. This via meshes.

At first, and as usual, I create a mesh, carrying a texture dds declared explicitly in it's cfg:

BEGIN_OBJECTLIST MESH
FILE Mymesh
POS ..............
TEX Mytexture
END
END_OBJECTLIST

The name of this cfg is "Bourou.cfg".

Mytexture ( Mytexture.dds ), is declared in Base.cfg and possesses a night version Mytexture_n.dds.

But, by the fact that in that context - terrain's meshes - the limits between texture pixels are, as you know, visible ( and i work on a 80 x 50 km's meshe ), I attempted to add a surftile, placed to the same place, accompanied of an alpha channel (256 levels of gray) leaving in transparency/semi transparency only the zones that I wished to see appeared at night.

In a manner rather unexpected, that works ( at least, on my machine ), but under three conditions :

1 ) The surftile must be declared in a different cfg.

2 ) The "name" of the cfg for this surftile imports somewhat and I named it zzzzzzzzzzzzzzzzzzzzzzz.cfg .

3 ) Undershadows must figure in the dedicated cfg for the meshe.

TEX Mytexture
Undershadow

I have somewhat try to understand the conditions of realization of this effect but I knows still too little for about it to speak, if, after a lot of trys since six months of experience with it, i begin to have some ideas.

All this works with the version 2006 as with the current bétas.

Remain a reef and this is the object of this message: while the mipmapping of the texture day ( Mytexture ) is possible and effective ( applied ) it does not work with the night texture ( Mytexture_dds ). I mean that I can attribute mipmaps to it but they do not appears. This is only few importance in the case of simple bases but being a question of cities...

Can that have a solution ?

With my thanks.

( I do not neglect nevertheless that the surftiles are devoted to disappear from here to some years )

 

[martins]

Hi Fort,
I am not entirely sure I understood everything precisely, so let me first recapitulate:

• You want to provide night lighting around surface bases by adding a sphere patch mesh that covers the surface and contains an emissive texture.
• Under certain circumstances this texture disappears under the base's surftiles.
• I didn't understand the point about the two separate cfg files, but maybe that's beside the point.

Ok, first of all, can you tell me if the problem happens in the current Orbiter 2006 version, in the latest Orbiter beta, or in both? If it only happens in the release, there is probably not much point in doing anything about it, since it will become obsolete (hopefully) soon.

It surprises me that the mesh disappears under the surftiles (if that is what you are reporting). The reason is that the surftiles, like the rest of the planet surface, is rendered without z-buffering (it's convex, so doesn't self-cover, and can be rendered without hidden surface removal). After the surface, the shadows are rendered, also without z-buffering. Finally, the base objects are rendered, this time with z-buffering, but they cover everything rendered before (surface, surftiles and shadows). So it shouldn't be possible for any mesh elements to drop below the surftiles. How do you know that your mesh is below the surftiles, rather than just not being rendered at all?

In the standard orbiter distribution the Habana space port contains some taxiways implemented as meshes which should function similarly to your mesh (flat on the ground, with UNDERSHADOWS enabled). Do you see similar problems with those?

Finally, as you mentioned, the surftile mechanism will hopefully be phased out eventually, as the standard surface resolution gets higher. In the next version, the resolution limit is L14 (corresponding to about 80m/pixel for Earth). This already allows for fairly convincing night light rendering (see attached image of synthetic night light textures for St. Petersburg and Tampa, Florida). Maybe this would already be sufficient for your purposes? The only current disadvantage of this method is that the surface textures, including night lights, are covered by base surftiles.

I am not sure if this answered your questions. Maybe a screenshot to document the problem would help me understand it.

 

[fort]

Dr Schweiger,

I will try to explain this a little differently; but the day of today is very occupied by my work. I will prepare some screenshot and I will post them here tomorrow or Friday, at the latest Saturday. I think that this will be a good complement to my post.

 

[unknown_orbiter]

Mon amie, peut-être c'est plus bon si tu demandes ton question en francais, ainsi il y a moins perte de communication.

 

[fort]

Thank you unknown orbiter,

This is of course a problem. I speak only very very imperfectly English and when the syntax becomes complex and that I must call upon certain words rather specific, I use a language translator.

I am nevertheless able to perceive, in most of the cases, the errors that commits this translator, and I rectify them consequently. But to the final one, this gives a body (?) that can lend itself to errors of interpretation. And the subject in cause here is not, at first sight, simple.

I think well effectively that some screen captures can allow clarifying my explanations. I began preparing this yesterday and I probably would have finished Saturday.

 

[fort]

Dr Schweiger,

Want to be sorry me for my delay to reply you. All this took more time that foreseen.

I modified the content of my first message to return it more concise and more legible, while eliminating some information that were not can be useful with respect to it's object - my question in the message end - which evoked essentially a problem of mipmapping (if my text did equally mention of the "pixelisation" of meshes's associated textures).

"- You want to provide night lighting around surface bases by adding a sphere patch mesh that covers the surface... "

Yes, But I think currently rather to cities, if what I do applies, and even well more easily, to simple bases.

Note:this is a canevas. I did not envision, to the final one, a so vast area, and I probably would have to make a détourage (?) on it to do a good transition with the environment

"- ...a sphere patch mesh that covers the surface and contains an emissive texture. "

I do not know if my meshe behaves an emissive texture...

I texturize (?) this meshe in anim8or in "two sided/front" and I apply to my texture the values by default of ambient, diffuse, specular, emissive. But I have not need in this meshe, to the final one, of these information. I can leave them or to remove them; the result is the same.

"- Under certain circumstances this texture disappears under the base's surftiles."

Yes. This is what I tried to obtain. It is stable on my machine. I test this since six months.

"- I didn't understand the point about the two separate cfg files, but maybe that's beside the point."

No. This is one of the three necessary conditions, as much as I know today, to the realization of this effect.

"It surprises me that the mesh disappears under the surftiles"

This surprised me all as much; even if I had not any a-priori in this respect.

"How do you know that your mesh is below the surftiles, rather than just not being rendered at all ?"

For this reason that, at night, the lights are visible and appear only to the only places where I have creates transparencies in the alpha chanel of the surftile.

Note:

These two pictures are divided in two . Right and left, corresponding to the joint of two tiles for wich one I used two different processes to attempt to create the night lights, from a little different days pictures, also.

"In the standard orbiter distribution the Habana space port contains "

This is not the same device, I believe, but I suppose that if i créate an alphachanel in the taxiway1.dds i'll see the ground through it.

"In the next version, the resolution limit is L14 (corresponding to about 80m/pixel for Earth). This already allows for fairly convincing night light rendering (see attached image of synthetic night light textures for St. Petersburg and Tampa, Florida)..."

What to say?

I think that I did not be involved myself here, with this assembly tile/meshe, on the better way. The most durable one.

I thought about Pltex as an alternative, here a long time, and I did some essays in the intention notably to give some additional nights lights to KSC, in the Orbiter betâ version.

But as you mention it:

"The only current disadvantage of this method is that the surface textures, including night lights, are covered by base surftiles."

And there are surftiles on the beta....

I did not nevertheless abandon the pltex idea and I there would return surely.

It seemed to me, also, that the file weight. tex, increased very quickly as early as the the resolution level rose, which could, little by little, to render inaccessible such additions to average users, by the fact, notably, that I did not think realize a city but some more.

Some screen captures of what I obtain. They have a big size: the night scenes are difficult to convert towards of the portable formats on the web. They will be can be, therefore long to appear. One here: this is the King's Georges reservoir, to the north of London.

I put two others, with the intention of not to overload this page, on a topic that I had created some months ago.

http://www.orbiter-forum.com/showthread.php?t=8181

For what concerns the mipmapping. Here is a screencap of a dds in which I modified the mipmap. Their values In my context (size of the scene, size, object size, focal) are of 0-37 km; 18-75 km; 37-150 km;75-300 km etc. I can note here the presence of the mipmapping on the "day" texture reach by the meshe. With this same transformed texture in "night" texture, this mipmapping disappears.

As I try to have the butter and the butter money, I would have wished to install night mipmap having a good looking to distance but equally nearby land.

There is besides, but this is another subject, a little confusion in my mind concerning the resolution values.

Here, two pictures. The one extract of a document coming with Orbiter. The other take I no longer know where but that I completed for my trys and that appears in coherence with the first one.

You say that the level 14 correspondent to 80m/pixels for the earth: Are the data of my table false?

With all my thanks.

 

[vejiita]

Btw guys, I'm from Canada and I'm (mostly) fluent in both french and english so if you would like me to help with translating I would be happy to. Just send me the text in PM and I'll post it here

En passant, je viens de Montréal au Canada alors je suis pas mal bilingue français/anglais alors si vous avez besoin d'aide pour une traduction vous n'avez qu'a demander Envoyez moi le text par PM (message personnel dans ce forum) et je vais me faire un plaisir de le posté dans ce forum (une fois traduit bien-sur !)

 

[fort]

Btw guys, I'm from Canada and I'm (mostly) fluent in both french and english so if you would like me to help with translating I would be happy to. Just send me the text in PM and I'll post it here

Merci vejiita. Ceci pourrait me rendre service de temps en temps, en effet.
Je garde cette proposition en mémoire. Merci vraiment et bonne journée.

Thank you vejiita. This could help me from time to time i think. I'll remember your offer. Thank you again and good day.

 

[martins]

You say that the level 14 correspondent to 80m/pixels for the earth: Are the data of my table false?

I will probably need some time to work through this information. For now, let me just answer the quoted question:

Your table is correct. From level 8, the higher resolution levels are simply constructed by quad-tree subdivision. This means that each new level doubles the resolution, requiring 4 times the number of texture patches of the previous level. So to continue your table:

[math]
\begin{array}{lrr}
\mathrm{Level} & \mathrm{Resolution} & \mathrm{Mesh\;patches} \\ \hline
10 & 32768 \times 16384 & 5824 \\
11 & 65536 \times 32768 & 23296 \\
12 & 131072 \times 65536 & 93184 \\
13 & 262144 \times 131072 & 372736 \\
14 & 524288 \times 262144 & 1490944
\end{array}
[/math]

Therefore, at an equatorial circumference of Earth of
[math]s = 2\pi R = 4.003\cdot 10^7\, \mathrm{m}[/math],
the pixel resolution at level 14 is
[math]s / 524288\, \mathrm{px} = 76.3\, \mathrm{m}/\mathrm{px}[/math]

You can also see that resolution level 14 corresponds to a surftile resolution level of 2. So surftiles of resolutions 0, 1 and 2 can now be replaced by standard surface textures.

 

[fort]

Dr Schweiger,

Thank you. I had a doubt and had read, and kept of your preceding message, by error, a value of 89 m by pixels, which surprised me.

For the remainder, while I progress, I always do and do again verifications of the solutions or difficulties that I met earlier. I probably would resume these essays with the mipmapping. Certain interactions between day and night textures, reaches by the meshe, are not so evident to test. I have not for the moment noted anything excepted that which concerns the transparency, but there is maybe some others.

In the absence of mipmapping with the night texture, I always can find a compromised between vision from afar and closed vision for the zones that are not destined to land. The essential problem being the one of the roads, to which one I begin to find responses.

I have also, and surely, something to understand, very generally, in the relations between meshes and meshes's textures for what concern the question of the pixels and level of detail..

Voilà for the moment.