SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

[DaveS]

BTW, what is the limit in MOGE? Why not go with that?

I don't know. I'm starting to think this is all about the capabilities of the GPU and not the client/engine. That could explain why it is working right out of the box with my GTX 1070 (twice the VRAM and nearly 500 MHz faster core clock than a stock GTX 970).

 

[GLS]

Resized to 2048 and it looks decent enough... yes, it doesn't have the quality of the original, but maybe 10 meters away the difference is negligible. :shrug:

---------- Post added at 08:03 PM ---------- Previous post was at 08:02 PM ----------

I don't know. I'm starting to think this is all about the capabilities of the GPU and not the client/engine. That could explain why it is working right out of the box with my GTX 1070 (twice the VRAM and nearly 500 MHz faster core clock than a stock GTX 970).

Not everyone has your hardware... probably not even the majority...

---------- Post added at 09:58 PM ---------- Previous post was at 08:03 PM ----------

Going thru the orbiter log I see tons of outputs related to switch positions, etc... IMO all good things to be deleted or at least wrapped in #if _DEBUG to only have those outputs in debugging.

 

[DaveS]

So what kind of conclusion have we reached here? Use the textures or not?

 

[Wolf]

So what kind of conclusion have we reached here? Use the textures or not?

I will have a look at the 2048 textures and come back to you guys, but I am afraid the difference between 8192 and 2048 will be quite noticeble..

1) Even at 2048 dpi the textures don't load here (my card specs are not top notch but still avarage I would say)

2) More important: sorry but 2048 looks really bad compared to 8192. Her a shot taken some 40 meters away from the Orbiter nose (58 mt from the CG) so we are not even at a close zoom in situation. You can judge yourself

Hi Res


2048 dpi


I am not happy to release those textures. All the details (which BTW took 90% of the time spent to do the textures) are totally blurry if not invisible.

 

[DaveS]

I will have a look at the 2048 textures and come back to you guys, but I am afraid the difference between 8192 and 2048 will be quite noticeble..

1) Even at 2048 dpi the textures don't load here (my card specs are not top notch but still avarage I would say)

2) More important: sorry but 2048 looks really bad compared to 8192. Her a shot taken some 40 meters away from the Orbiter nose (58 mt from the CG) so we are not even at a close zoom in situation. You can judge yourself

Hi Res
View attachment 15923

2048 dpi
View attachment 15924

I am not happy to release those textures. All the details (which BTW took 90% of the time spent to do the textures) are totally blurry if not invisible.

GLS did mention that he did get the full resolution textures working by removing the mip-maps and using DXT-5 compression. Could this be an acceptable solution?

 

[Wolf]

GLS did mention that he did get the full resolution textures working by removing the mip-maps and using DXT-5 compression. Could this be an acceptable solution?

My understanding was he did it with 2048 dpi and that is what I ve done.
Textures at 2048, no mip-maps and DXT-5
The inline engine shows me a white shuttle and the result (see screenshot) is what it is....

 

[DaveS]

My understanding was he did it with 2048 dpi and that is what I ve done.
Textures at 2048, no mip-maps and DXT-5
The inline engine shows me a white shuttle and the result (see screenshot) is what it is....

I think the best solution is to let us use the lower resolution so you can focus on the full resolution pack. Ours would be a static, occasionally updated version while yours would be the optional hi-res pack. This set up is fully Orbiter compliant as that's how Orbiter itself is distributed, the low-res textures are required but the full resolution packs are optional.

 

[Wolf]

I think the best solution is to let us use the lower resolution so you can focus on the full resolution pack. Ours would be a static, occasionally updated version while yours would be the optional hi-res pack. This set up is fully Orbiter compliant as that's how Orbiter itself is distributed, the low-res textures are required but the full resolution packs are optional.

It makes no sense to use high res textures at low res. Would you buy a Porsche and then derate the engine at 50 hp?
SSU already has low res textures, there is no need for a second set.
I will keep working as long as it is doable on my textures as an addon then

 

[DaveS]

It makes no sense to use high res textures at low res. Would you buy a Porsche and then derate the engine at 50 hp?
SSU already has low res textures, there is no need for a second set.
I will keep working as long as it is doable on my textures as an addon then

Ours would be the required textures just like the low-res textures are for Orbiter. These lower resolution textures would replace our current ones, there would be any "second set". Yours would the equivalent to optional engine tuning if you will to use your car analogy. For computers, that tuning is called "overclocking".

 

[GLS]

GLS did mention that he did get the full resolution textures working by removing the mip-maps and using DXT-5 compression. Could this be an acceptable solution?

Yes, the main texture loaded that way, but then there's the problem of resource usage... :facepalm:
Like I said before, the graphics are already the long pole in SSU's tent... for example, launches are not that far from being a slide show, and there's a new pad in the works which I'm sure will look great but won't help the performance... plus having these large textures by default... :compbash:
Wolf don't get wrong, they look really really really good, but I think we need to be practical here.
We can always say "oh, but it looks so much better with this model/texture", but that way we will end up modelling each tile in the OV and it will look super duper good, but it will only run on half-dozen PCs. :thumbsdown:

I don't see what the issue is with SSU using a scaled 2048 version of your textures, and I'll put a link in the manual for the future "SSU Photoreal rev2" were the full scale versions will be available.

 

[DaveS]

It would be nice if we could set up something like the Project Apollo wiki. That could act as a central hub for our project and link to optional items like high resolution textures.

 

[GLS]

It would be nice if we could set up something like the Project Apollo wiki. That could act as a central hub for our project and link to optional items like high resolution textures.

Who would maintain those pages?

 

[DaveS]

Who would maintain those pages?

We would. They wouldn't need to be updated that often, only when the situation would require it (such as the addition of a new system, corrections to a previous one). Also if you loom at the Project Apollo wiki, it is rather barebones but still fully functional.

 

[GLS]

We would. They wouldn't need to be updated that often, only when the situation would require it (such as the addition of a new system, corrections to a previous one). Also if you loom at the Project Apollo wiki, it is rather barebones but still fully functional.

I simply don't have the time... :shrug:
I'm already flat out getting the landing part to work, and even so that is a few months away.

 

[Wolf]

My understanding was he did it with 2048 dpi and that is what I ve done.
Textures at 2048, no mip-maps and DXT-5
The inline engine shows me a white shuttle and the result (see screenshot) is what it is....

I am confused now, what resolution did GLS use in his testing with DXT-5 and no mip-maps: 8192 or 2048?


Also, what about the fact that on my end those resized textures do not work with DX7, hence they might not be working for many others? (I tested a 2048 dpi with DXT-5 and no mip-maps)

 

[GLS]

I am confused now, what resolution did GLS use in his testing with DXT-5 and no mip-maps: 8192 or 2048?

8192

Also, what about the fact that on my end those resized textures do not work with DX7, hence they might not be working for many others? (I tested a 2048 dpi with DXT-5 and no mip-maps)

Could the current SSU textures be in DXT-3, and might that make a difference?

 

[Wolf]

8192


Could the current SSU textures be in DXT-3, and might that make a difference?

Nope, since I used the exact same thing you did: DXT-5 and no mip-maps.

Tested with 8192. Same thing, no textures..
BTW what is the loss if we use DXT-5 and no mip-maps?

 

[Donamy]

I am confused now, what resolution did GLS use in his testing with DXT-5 and no mip-maps: 8192 or 2048?


Also, what about the fact that on my end those resized textures do not work with DX7, hence they might not be working for many others? (I tested a 2048 dpi with DXT-5 and no mip-maps)

Wolf,
Did you try saving your 8192x8192 textures to 2048x2048 bitmap, then save them as .dds, using the DXT converter in the utilities folder. I've had to do that before.


Also, I think the low-res ones look fine. Way better than the stock ones.

 

[Wolf]

Wolf,
Did you try saving your 8192x8192 textures to 2048x2048 bitmap, then save them as .dds, using the DXT converter in the utilities folder. I've had to do that before.


Also, I think the low-res ones look fine. Way better than the stock ones.

This is what i do:

1) 8192 .psd textures converted into .jpg (to allow later dds conversion)

2) .jpg resized to 2048

3) .jpeg 2048 saved in .dds


Outcome with DX7: no textures
Same if I use 8192

 

[GLS]

One item I'm not sure I asked about: the drive angle for the RSB animation and mesh don't appear to match. Don't know which one (if any) is correct.

BTW: any solution for the tickets?