Celestia Forums

john71 wrote:

cartrite wrote:If he already has one it may be failing.

So my PC's power supply is failing at Celestia Qt, but it is not failing at Celestia win32?

Not likely.

Qt is slow for many others, so there must be a reason. Maybe more cpu resources. Gpu resources, whatever. Anyhow the system at full load should not exceed 80 % of the capacity of the power supply. Anyhow good luck, I'm out of ideas.

cartrite wrote:Qt is slow for many others, so there must be a reason. Maybe more cpu resources. Gpu resources, whatever.

That's a good lead.

Celestia 1.6.2.2 consumes 15-25% of the GPU resources.

Celestia 1.7 win32 is between 15-30%.

But Celestia Qt can reach 40%.

And where?

At Mars, when the fps is very low.

But I don't get it: 1.7 (both win32 and Qt) does not seem to add any new eye candy, so why are they much more GPU resource demanding?

Added after 2 minutes 4 seconds:
Also: I can play Witcher 3 with full graphics, having no issues, but Celestia 1.7 Qt destroys my GPU?

Added after 25 minutes 48 seconds:
OpenGL Checker can reach 50%-60% of GPU resources and it shows that the graphic card has excellent results in OpenGL.

I don't think it is a GPU resource or graphic card issue on the hardware side.

The installer I uploaded last year is still available on page one of this topic]. Did you try that recently?

@Art Blos

I downloaded Celestia Origin and extracted its Mars virtual textures (mars, mars-normal and mars-topo) and clouds (mars-clouds.dds). I could not find their .ctx files, so I created those myself.

I extracted the Mars definition from the solarsys.ssc included in Celestia Origin, prefixed it by "Replace" and put it in "extras" along with the textures.

I got 60 fps while viewing Mars, but the dtx images were not rendered correctly. Qt looks different from win-32, but both are wrong. See below.
The surface textures also were not rendered correctly by either 1.6.1 or 1.6.2.2. They looked the same as with 1.7 win-32.

Edited to add: the problem might be an interaction between the "mars" VT and the "mars-normal" VT. When I comment out the "mars-normal" VT, Mars looks OK. However, when I enabled "mars-topo", the problem returned. See below. However, mars-topo was drawn correctly when I commented the "mars-normal" declaration from the Alt Surface definition.

Note: Celetia 1.7 did crash frequently, but not always, when starting up.

selden wrote:I could not find their .ctx files, so I created those myself.

Thanks for testing. These files were in the "lores" archive in the textures folder (see attachment, compare with your versions).

selden wrote:The surface textures also were not rendered correctly by either 1.6.1 or 1.6.2.2.

I can guarantee that this bug was not in the 1.6 versions. Otherwise, the CO team or someone else would have noticed him long ago.

But we know that this bug exists in version 1.7 and even informed Gleb. It needs to be fixed urgently, it's much worse than non-working localization. Today I made sure that this is not fixed.

selden wrote:Edited to add: the problem might be an interaction between the "mars" VT and the "mars-normal" VT. When I comment out the "mars-normal" VT, Mars looks OK. However, when I enabled "mars-topo", the problem returned. See below. However, mars-topo was drawn correctly when I commented the "mars-normal" declaration from the Alt Surface definition

We already know that the problem lies precisely in the format *.dxt5nm. Normals in other formats work stably.

john71 wrote:Also: I can play Witcher 3 with full graphics, having no issues, but Celestia 1.7 Qt destroys my GPU?

OpenGL Checker can reach 50%-60% of GPU resources and it shows that the graphic card has excellent results in OpenGL.

I don't think it is a GPU resource or graphic card issue on the hardware side.

We are both using the same program built on the same computer. You obviously have a better computer and graphics. But yet I can run a model with hundreds of thousands vertices, multiple textures, and still I'm getting 60 fps. If you think it's not the hardware, it must be a configuration issue on your system. Maybe your missing a system lib somehow. Just an image using Guillermo Abramson's Milkyway from the Celestia Motherlode, so I do have galaxies off.





Sorry, those images above were using the same commit as the galaxy fix installer but on Linux. This one was using windows qt5 version. FPS was a bit lower but good enough.

I found this text:

https://www.mail-archive.com/interest@qt-project.org/msg36622.html

Hi, I'm using a third party library (Skia) to render custom opengl code in sync
with the QtQuick Scene Graph (Qt 5.15 on Windows 11).
I'm using the QQuickFramebufferObject and QSGRenderNode classes to create
custom QQuickItems to render my scene. The approach works fine, but I've come
across a very strange issue that I'm unable to solve. The problem consists in a
sudden unrecoverable drop in FPS during the rendering of my scene. I've noticed
that the issue presents itself whenever the rendering frame time jumps above a
certain threshold (most of the times my app is able to render at 60fps, but
there are times when there is a lot of content to render). When this happens,
the frame rate no longer jumps back to 60 fps as expected, but instead is
remains weirdly low (less than 10 fps) for the remaning time of the session.
This is despite the fact on subsequent draw calls I render nothing in my opengl
scene.
Doing some logging with the helper logging categories provided by Qt, I can see
that the scene graph that the render time is fine most of the time, but the
logs consistently report an unusally high sync time in the threaded render
loop.

Added after 2 minutes 9 seconds:
I have to repeat: Celestia 1.7 win32 can achieve 60 fps at the same PC without any problems, but Qt fails? How is it a GPU hardware problem?

john71 wrote:Celestia 1.7 win32 can achieve 60 fps at the same PC without any problems, but Qt fails? How is it a GPU hardware problem?

I can imagine a bug in the card's firmware associated with some specific graphics feature that Qt5 uses only in some circumstances.

At any rate, the problem would have to be investigated by someone familiar with Celestia, the graphics protocol being used and the internals of Qt5 and with the patience necessary to do that kind of debugging.

Added after 39 minutes 24 seconds:

Art Blos wrote:I can guarantee that this bug was not in the 1.6 versions. Otherwise, the CO team or someone else would have noticed him long ago.

Thanks for the CTX files. They were identical to the ones I'd created.

The surface-normal textures fail with 1.6.1 and 1.6.2.2 on my computer. See below. It might be related to the graphics hardware. My understanding is that the DXT formats are passed directly to the hardware.

ImageMagick's "Identify" command claims that the surface-normal VT images include an Alpha channel. I suspect that this is the real problem. Alpha channels are not appropriate in surface normal files. They should contain only R, G and B channels. Alpha channels have always caused problems for Celestia, even when used in PNG files.

selden wrote:The surface-normal textures fail with 1.6.1 and 1.6.2.2 on my computer. See below. It might be related to the graphics hardware. My understanding is that the DXT formats are passed directly to the hardware.

Very interesting case. Tell me in more detail, on what system, what bit depth and what video card did you test? Was it a PC or laptop?

selden wrote:ImageMagick's "Identify" command claims that the surface-normal VT images include an Alpha channel. I suspect that this is the real problem. Alpha channels are not appropriate in surface normal files. They should contain only R, G and B channels. Alpha channels have always caused problems for Celestia, even when used in PNG files.

Format *.dxt5nm is always automatically created with an alpha channel. I didn't come across other versions. Will there be at all dxt5nm-normals work without an alpha channel?

And I also never saw any bugs with lighting, although I tested it on a lot of systems. There is a tendency that a very rare bug has become commonplace in version 1.7.0, but this is not Origin's fault.

It will be a cold day in hell.

OK. Now I can prove, that it is a software bug:



60 fps when there are not too many objects around.



Fps drops dramatically when there are planetary rings around (but why?).



Fps literally dies when the planet feature is on.

Art Blos wrote:by Art Blos » Today, 00:51
Tell me in more detail, on what system, what bit depth and what video card did you test? Was it a PC or laptop?

The framegrabs above were taken on an old Lenovo ThinkStation E31 desktop: Core i3-2120 with Nvidia Quadro 600 GPU at 1080p with 32 bit screendepth. See below for screenshots of details on desktop CPU and GPU from CPU-Z.

Additional screengrabs below (all showing similar problems) were taken on an old Lenovo X131e laptop: Core i3-3227U with integrated Intel HD Graphics 4000 at 1080p with 32 bit screendepth. See below for screenshots of details on laptop CPU and GPU from CPU-Z.

Desktop info:



Laptop info:



Added after 8 minutes 52 seconds:
@john71,

I suspect you'll be "glad" to know that I'm also seeing a slowdown when using the QT5 version of Celestia, but with Intel graphics. QT5 draws Mars at about 30fps, while the Win32 UI draws Mars at 60 fps or better. See the framerates in the screengrabs below.

Here are the screengrabs of Celestia drawing Mars on the laptop. All show defects when drawing the surface normals.

1.7:




1.6.2.2:



1.6.1:

selden < Apparently you have very specific or old laptops. I have a Samsung laptop from 2013 year with integrated graphic "Intel HD Graphics 2000". And everything works great.

Yes, my hardware is old. It does what I need, though. Fortunately, I don't need hires textures.

This was posted in error. I was looking at a different folder.

Updated automatic build installers by Markerz:
https://disk.yandex.ru/d/sUUuZGo7KXO09g

Please test.

A celestia 1.6.3 x86/x64 version appeared on Celestia Home
On a PC, Windows 11 (64 bit), can we install celestia 1.6.3 in 32 bit version?

(To work in lua, I use Decoda (debugger) which only exists in 32 bit.)

That is to say, does the installation program let us choose 32 or 64 bit, and that of the installation directory?

Unfortunately no. Installer doesn't allow selecting target bitness.

Unfortunately no. Installer doesn't allow selecting target bitness.

too bad, I will have to keep the 32-bit version 1.6.1 to be able to work in lua and Decoda