Stellarium in Web Browser

[Fabien Chéreau]

Hi!

Guillaume and I have been spending some time working on a prototype web-based version of Stellarium. You can try it there: https://noctuasky.org

The project was originally meant to be just a simple sky viewer that Guillaume developped for Astronomy Magazine. But after some time, we started to use it as a plateform to test new things, like putting all the data inside HIPS structures, or testing HTML-based GUI, and different selected object info.

We are quite happy with the results and it looks a lot like Stellarium, even though it's far from having as many features. So far this is just a proof of concept, but I think it shows that it's possible to have a completely different architecture, solving some of our long standing issues:

 - complexity of QWidget/QGraphicsWidgets GUI code

 - deprectation of some Qt components (QtScript, QGraphicsWidgets, etc..)

 - shortcomings of the current plugin architecture (almost impossible to use dynamical plugins because we don't have a stable API, overhead of coding C++ code even for very simple plugins while a script could be enough)

 - high maintenance costs because of platform specific issues

 - integration of huge online data bases like Gaia DR2 catalog is not natural in the current code where local file is the norm

 - security issues (Stellarium is not sandboxed like a web browser)

 - etc..

This proto is working this way:

 - a light core engine for displaying the sky is done in pure C / OpenGL, and compiled in Javascript/WebAssembly/WebGL (using LLVM, producing a static .js file)

 - an HTML/Javascript GUI is added on the top of it (static HTML/js files)

 - a simple web service serves all the statical data (Hips surveys of Gaia catalog, planets image etc..) and also provides a simple objects search API

Now what's next with this? First we would like to get feedbacks from you guys. Especially we are wondering how we could have all this integrated into the Stellarium project in a way or another.

One possibility would be to call it Stellarium Web or something like that and move all the code on the Stellarium github organisation. In the long run, we could think about merging both code base keeping only the best of both (I have the feeling it would be such a huge task that it could be faster to migrate all current Stellarium features to the new code). We could also just have both sub-projects live next to each other, as they fill different use cases.

In term of code/license: the code is not released yet because it needs some cleanup (there are some passwords/and private API key in the git history!). Once cleaned up, we are thinking of releasing it maybe under a dual AGPL/commercial licence or something like that.

Feedbacks welcomed!

Fabien

[Dave Filipowski]

Greetings Fabia, Guillaume, and all -

Looking very good! Please do continue your good efforts. Looks like a wonderful project quite worthy for many differnt users and uses.

Thank you for sharing this!

Best Wishes,

Dave F

Burlington, Vermont (Dave In Vermont)

--
You received this message because you are subscribed to the Google Groups "Stellarium" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellarium+unsubscribe@googlegroups.com.
To post to this group, send email to stell...@googlegroups.com.
Visit this group at https://groups.google.com/group/stellarium.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellarium/CAFxD46FJQhwA12KN5YyQH%2BMeAmu%2BJUE3fButPYjKD2dbO-zz3A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Georg Zotti]

Dear Fabien,

this looks quite impressive already, although there is quite some
difference with the full Stellarium in appearance, features and likely
also in application.

+ It may solve requests from ChromeBook users.
- It does (obviously) not work offline.

On plugins: I joined in 2010 but was unfamiliar with the concept of
dynamic plugins until 2-3 years later. They never (in my time) worked on
Windows, so I never bothered too much. However, I see some useful
applications. The basic Plugin API seems reasonably stable that at most
a recompile should be necessary to get them running again. But there is
no "howto" or crucially important example which makes the process
attractive enough. Some telescope tinkerers develop extensions which are
mostly out of our view. For those, dynamic plugins should be the easiest
solution. Years after the fact, I found that Bogdan had made a joystick
plugin, which might be completed into the demanded "D-Pad control"
thingy. But we would need somebody with the hardware and interest and
programming skills to complete this.

I am not sure about merging these projects, as you say, they seem to
fulfill different use cases. For the casual stargazer, this is a nice
thing, also for mobile application. However, the current desktop version
is an incredibly feature-rich application which has in parts really
unique features. We receive requests and suggestions from various sides.

- Telescope users (those with time to actually spend outside...) have
some demands for extra hardware.
I feel no obligation to develop anything for hardware which I don't
use, but I understand they want to have it.
- 4k stuff and Touch interfaces? 3D mouse or Joystick interface?
- some 3D/VR groups want VR goggle support (Oculus Rift, VIVE, etc.) I
think Guillaume was involved in that project with Edinburgh.
If possible, such support should be integrated as standard plugin, at
least in a basic version, and not all the energy buried in an unknown
external repository.
- Ethnologists use the unique skyculture feature and contribute a
growing number of nice skycultures. Alex and I have been discussing
requirements for better skyculture support for scientific applicability.
Much can be improved here, not only translations and proper referencing,
but a few non-European concepts about constellations, Lunar mansions,
etc. And maybe some more accurate way to link artwork with the stars
(better than 3-point). On the other hand, the increasing number of
skycultures calls for providing those as extra downloads, because most
observers won't need them.
- my own peers, apart from skycultures, need the historical
applicability, loadable accurate landscapes, and 3D sceneries. On the
other hand, the "Western" skyculture is riddled with a collection of
dubious names which also has to be analyzed and IMHO calls for more
careful selection of names. Of course at some point, I (or somebody
else) should re-write the standard Western description.
- Prof. Frischer asked me if it was possible to have a WebGL Stellarium
with 3D landscapes as outreach tool. Of course, that would be fantastic,
but would require adding a mesh renderer to your WebGL solution. The
application would be online demonstration of archaeological structures
in the surrounding landscape model with astronomical orientation and
shadow simulation. This is much beyond my current skills and time,
however currently I am trying to create a demo app for a link between
Unity and Stellarium based on Spout which I developed with his group. I
would like to put a basic link package online later this year.
- Our RemoteControl plugin enabled using Stellarium on a big video wall
(5 projectors, 25x4m) in a museum. In contrast to a preproduced "dead"
movie, occasionally, the automated show was stopped and a guide (well,
myself...) used a tablet to control the software.
- RemoteSync can be used in another situation where you want to show the
same sky apart from slight changes. E.g., show 5 parallel screens with
differing skycultures. Or maybe 5 HiPS surveys?



Local installations have the advantage of being ... local and
self-contained. No need to be online. Stellarium runs from RaspberryPi3
to GeForce multiscreen setups - absolutely what I need in remote
dark-sky sites, minimal educational installations, or installations
which must work 24/7 (OK, maybe 14/6). Therefore I would welcome an
updated star catalog based on GAIA DR2 only if it is again a local
solution. Any work on a new star catalog should make sure to compute
proper motion in spatial 3D, with changing distance&magnitude&speed, not
missing fast stars like Arcturus in remote times when their "parent"
star field is outside screen, keep double stars orbiting each other etc.
(Solve about 50 star catalog bugs!)


Current Stellarium has still a few open points left.
- Code Documentation. :-| Some parts are really hard to understand. I
admit C++ was a foreign language when I started, and things like
template syntax was new to me. Some higher-level structures are still
underdocumented, and not free from bugs.
E.g. https://bugs.launchpad.net/stellarium/+bug/1026263,
https://bugs.launchpad.net/stellarium/+bug/1716168,
https://bugs.launchpad.net/stellarium/+bug/1174892, ...
- Aberration. I would have liked to work on that this year, but some
other tasks had to be pushed forward. It causes a slight push of
positions (typically under 1 arcminute), and will require a similar
vertex coordinate bending solution like refraction. I hope with this
final refinement, season beginnings will finally be accurate to the
minute, and solar eclipses will also be more accurate.
- Planet axes. Somehow I messed this up in some misunderstanding of the
undocumented Planet::computeTransMatrix(). Should not be as hard as it
appears to me. Again, no time to dive in ATM.
- I may have introduced a little bug
https://bugs.launchpad.net/stellarium/+bug/1723896, must think through
observer position on an ellipsoid planet surface again.
- Scenery3D does not correct for Earth curvature. For huge landscapes
(mountain peaks in 150km distance or so), this should be corrected.
Optimally, this can be computed in the vertex shader program.
- "Skycultures 2.0", the cultural aspects mentioned above.
- I am pretty sure some computations could/should be implemented in
shader code for a big speed gain. (Think of 100.000 asteroid dots on
Kepler orbits visible from the Solar System Observer?) But I am no
expert in GPGPU.
- The sky brightness/color code and all dependencies (star RCmag
"voodoo") is one of the original great features which makes Stellarium's
sky rendition so realistic. Now many GPUs could do much more in shader
code, e.g. real-time twilight effects. And scientific demands ask for
accurate determination of visibility. So also this part "could be"
improved, time permitting. Of course, each shader code improvement from
one project can (hopefully) be re-used in the other.
- QtScript has been declared deprecated. I understand there is a
replacement system, though. This means we should be prepared.
- QML GUI "may" replace the current GUI. Sounds like a huge rewrite,
requires learning new parts of Qt. If GUI loads faster, it may still be
worth investigating.
- You want some better online manual (HTML version). And we still keep
answering the same support questions because people not even read the
FAQ, regardless how many copies there are. Some don't even read the bug
report instructions in the bug report they are filling in.
- The old wiki still has not been moved. It appears I have no editing
rights in many parts of the old wiki. I see issues regarding a
move/rework of the downloadable landscapes. Some have also vanished over
the years. Some repository with extra landscapes, 3D sceneries and
skycultures should be created.

With 2-4 developers, maintaining even one such huge project is not easy,
and time is always short. So, while I say "cool", Stellarium Web is not
something I feel I can involve myself currently in any depth beyond as
casual user/tester. I already put my weekends into my R&D. What I would
find important to say however, is to not sacrifice already existing
accuracy for slight speedup. Refraction, extinction and accurate horizon
panoramas are necessities for cultural astronomy.

One usage scenario which I immediately see and which likely many users
will find great: Is it possible to add at least "my own horizon" into
the foreground? (load a spherical pano, or even old_style? Or the
smartphone cam's panorama? Or at least a polygon file compatible to
CdC.) Then you will read demands to support satellites, Iridium, ...
(maybe direct link to heavens-above?) ... ideas are again unlimited.


Best regards,
Georg

Am 11.06.2018 15:53, schrieb Fabien Chéreau:
> Hi!
>
> Guillaume and I have been spending some time working on a prototype
> web-based version of Stellarium. You can try it there:

> https://noctuasky.org [1]

> --
> You received this message because you are subscribed to the Google
> Groups "Stellarium" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to stellarium+...@googlegroups.com.

> To post to this group, send email to stell...@googlegroups.com.
> Visit this group at https://groups.google.com/group/stellarium.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/stellarium/CAFxD46FJQhwA12KN5YyQH%2BMeAmu%2BJUE3fButPYjKD2dbO-zz3A%40mail.gmail.com

> [2].

> For more options, visit https://groups.google.com/d/optout.
>
>

> Links:
> ------
> [1] https://noctuasky.org/
> [2]
> https://groups.google.com/d/msgid/stellarium/CAFxD46FJQhwA12KN5YyQH%2BMeAmu%2BJUE3fButPYjKD2dbO-zz3A%40mail.gmail.com?utm_medium=email&utm_source=footer

--
Dipl.-Ing. Dr. Georg Zotti
Ludwig Boltzmann Institute for
Archaeological Prospection and
Virtual Archaeology
(LBI ArchPro)
Hohe Warte 38
A-1190 Wien

[Hans]

Hi Fabien and Guillaume,

Fabien Ch??reau wrote on 20180611:
> Guillaume and I have been spending some time working on a prototype web-based
> version of Stellarium. You can try it there: https://noctuasky.org

This is awesome !

> The project was originally meant to be just a simple sky viewer that
> Guillaume developped for Astronomy Magazine. But after some time, we
> started to use it as a plateform to test new things, like putting all the
> data inside HIPS structures, or testing HTML-based GUI, and different
> selected object info.
>
> We are quite happy with the results and it looks a lot like Stellarium,
> even though it's far from having as many features. So far this is just a
> proof of concept, but I think it shows that it's possible to have a
> completely different architecture, solving some of our long standing issues:
> - complexity of QWidget/QGraphicsWidgets GUI code
> - deprectation of some Qt components (QtScript, QGraphicsWidgets, etc..)
> - shortcomings of the current plugin architecture (almost impossible to
> use dynamical plugins because we don't have a stable API, overhead of
> coding C++ code even for very simple plugins while a script could be enough)
> - high maintenance costs because of platform specific issues
> - integration of huge online data bases like Gaia DR2 catalog is not
> natural in the current code where local file is the norm
> - security issues (Stellarium is not sandboxed like a web browser)
> - etc..

I would not want to replace Stellarium with a web-based version anytime soon.
Having both OTOH, hell yes !

> This proto is working this way:
> - a light core engine for displaying the sky is done in pure C / OpenGL,
> and compiled in Javascript/WebAssembly/WebGL (using LLVM, producing a
> static .js file)
> - an HTML/Javascript GUI is added on the top of it (static HTML/js files)
> - a simple web service serves all the statical data (Hips surveys of Gaia
> catalog, planets image etc..) and also provides a simple objects search API

Cool.

> Now what's next with this? First we would like to get feedbacks from you
> guys. Especially we are wondering how we could have all this integrated
> into the Stellarium project in a way or another.

I welcome synergy.

> One possibility would be to call it Stellarium Web or something like that
> and move all the code on the Stellarium github organisation.

Sounds fine.

> In the long run, we could think about merging both code base keeping only the
> best of both (I have the feeling it would be such a huge task that it could
> be faster to migrate all current Stellarium features to the new code).

Sounds very interesting and daunting at the same time.

> We could also just have both sub-projects live next to each other, as they
> fill different use cases.

If we see no synergy options, then that could be plan-B.

> In term of code/license: the code is not released yet because it needs some
> cleanup (there are some passwords/and private API key in the git history!).
> Once cleaned up, we are thinking of releasing it maybe under a dual
> AGPL/commercial licence or something like that.

Makes sense.

-- Hans

[Fabien Chéreau]

Hi all,

On Mon, Jun 11, 2018 at 6:16 PM Georg Zotti <georg...@univie.ac.at> wrote:

Dear Fabien,

this looks quite impressive already, although there is quite some
difference with the full Stellarium in appearance, features and likely
also in application.

+ It may solve requests from ChromeBook users.
- It does (obviously) not work offline.

Actually, it should not be much work to make an offline version of it, by creating an app with just a QWebEngine bundled with a limited set of data together with the app in a kind of cache. But I don't know if makes much sens to do that really.

On plugins: I joined in 2010 but was unfamiliar with the concept of
dynamic plugins until 2-3 years later. They never (in my time) worked on
Windows, so I never bothered too much. However, I see some useful
applications. The basic Plugin API seems reasonably stable that at most
a recompile should be necessary to get them running again. But there is
no "howto" or crucially important example which makes the process
attractive enough. Some telescope tinkerers develop extensions which are
mostly out of our view. For those, dynamic plugins should be the easiest
solution. Years after the fact, I found that Bogdan had made a joystick
plugin, which might be completed into the demanded "D-Pad control"
thingy. But we would need somebody with the hardware and interest and
programming skills to complete this.

One of the problem with plugins is that they have to be compiled together with the main application if you want them to be compatible with the core. This is because we don't have a well defined API, and also because it's very difficult to guarantee a stable ABI with C++ interfaces. This could be solved with js plugins.

 

I am not sure about merging these projects, as you say, they seem to
fulfill different use cases. For the casual stargazer, this is a nice
thing, also for mobile application. However, the current desktop version
is an incredibly feature-rich application which has in parts really
unique features. We receive requests and suggestions from various sides.

That's fine for me to keep the project separated. Merging is very hard indeed, and as you say the goals are different. I personally tend to agree with users who complain that the GUI has become too complex because too many advanced features appear by default. For example, something like ocular plugin is very useful for amateur astronomer, but I think 95% of the users will never need it, so it should be hidden for them. Same thing for many other details, like color setting dialogs etc.. For these users, this new version of Stellarium could maybe fill this gap.

That's a long list of various usages :) Yes Stellarium is currently used in so many different way that it's arguably difficult to keep one version fit all. Plugins are good for most of the extensions, but for something like VR or WebGL version, the changes are too wide to be encapsulated in simple plugins, at least as we have now.

Current Stellarium has still a few open points left.
-  Code Documentation. :-| Some parts are really hard to understand. I
admit C++ was a foreign language when I started, and things like
template syntax was new to me. Some higher-level structures are still
underdocumented, and not free from bugs.
    E.g. https://bugs.launchpad.net/stellarium/+bug/1026263,
https://bugs.launchpad.net/stellarium/+bug/1716168,
https://bugs.launchpad.net/stellarium/+bug/1174892, ...
-  Aberration. I would have liked to work on that this year, but some
other tasks had to be pushed forward. It causes a slight push of
positions (typically under 1 arcminute), and will require a similar
vertex coordinate bending solution like refraction. I hope with this
final refinement, season beginnings will finally be accurate to the
minute, and solar eclipses will also be more accurate.

In the online prototype, we used the erfa library (https://github.com/liberfa/erfa) for all astronomical computations, so aberration is included.

 

- Planet axes. Somehow I messed this up in some misunderstanding of the
undocumented Planet::computeTransMatrix(). Should not be as hard as it
appears to me. Again, no time to dive in ATM.
- I may have introduced a little bug
https://bugs.launchpad.net/stellarium/+bug/1723896, must think through
observer position on an ellipsoid planet surface again.
- Scenery3D does not correct for Earth curvature. For huge landscapes
(mountain peaks in 150km distance or so), this should be corrected.
Optimally, this can be computed in the vertex shader program.
- "Skycultures 2.0", the cultural aspects mentioned above.
- I am pretty sure some computations could/should be implemented in
shader code for a big speed gain. (Think of 100.000 asteroid dots on
Kepler orbits visible from the Solar System Observer?) But I am no
expert in GPGPU.
- The sky brightness/color code and all dependencies (star RCmag
"voodoo") is one of the original great features which makes Stellarium's
sky rendition so realistic. Now many GPUs could do much more in shader
code, e.g. real-time twilight effects. And scientific demands ask for
accurate determination of visibility. So also this part "could be"
improved, time permitting. Of course, each shader code improvement from
one project can (hopefully) be re-used in the other.

For starlight simulation, the best would be to use HDR rendering with real PSF convolutions and tone mapping. This can be done using fragment shaders, and HDR is supported on most new devices, but I think it would be still slower than what we have currently.

 

- QtScript has been declared deprecated. I understand there is a
replacement system, though. This means we should be prepared.

I already tried to update, but the "replacement" lacks many many features of the old QtScript. Basically it's not possible to have the same features as what we have now.

 

- QML GUI "may" replace the current GUI. Sounds like a huge rewrite,
requires learning new parts of Qt. If GUI loads faster, it may still be
worth investigating.

I already tried to start migrating to QML (even twice!). Each time, I finally stopped. The biggest issue was that the javascript environment in which QML runs is far from being as powerful as the one in a web browser. It's actually very difficult to get javascript libraries developed for the web working in QML. Moving to QML makes sense only if in the long run we can also move most of the non CPU intensive code also in javascript. Because this is difficult, I am now not convinced that QML is the way to go. Instead, I found regular HTML/css/js based GUI to be more flexible.

 

- You want some better online manual (HTML version). And we still keep
answering the same support questions because people not even read the
FAQ, regardless how many copies there are. Some don't even read the bug
report instructions in the bug report they are filling in.
- The old wiki still has not been moved. It appears I have no editing
rights in many parts of the old wiki.  I see issues regarding a
move/rework of the downloadable landscapes. Some have also vanished over
the years. Some repository with extra landscapes, 3D sceneries and
skycultures should be created.

Yes.

With 2-4 developers, maintaining even one such huge project is not easy,
and time is always short. So, while I say "cool", Stellarium Web is not
something I feel I can involve myself currently in any depth beyond as
casual user/tester. I already put my weekends into my R&D. What I would
find important to say however, is to not sacrifice already existing
accuracy for slight speedup. Refraction, extinction and accurate horizon
panoramas are necessities for cultural astronomy.

I understand. 

 

One usage scenario which I immediately see and which likely many users
will find great: Is it possible to add at least "my own horizon" into
the foreground? (load a spherical pano, or even old_style? Or the
smartphone cam's panorama? Or at least a polygon file compatible to
CdC.) Then you will read demands to support satellites, Iridium, ...
(maybe direct link to heavens-above?) ... ideas are again unlimited.

Yes, ideas are unlimited unlike our time :) one of the reason we started doing tests with Stellarium Web is precisely that developping on Stellarium has become very slow. Moving most of the non intensive logic (like GUI, management of collections of landscapes or other online resource etc..) to javascript really makes developing such features much faster. However, the downside is that changing the C code of the engine is probably more difficult than in Stellarium. So all in all the development time will heavily depend on the feature.

In any case, if you all agree with that, we'll push our code in the Stellarium's organisation github, and time will say if we can do something out of it or not beyond a nice demo website.

Fabien

To view this discussion on the web visit https://groups.google.com/d/msgid/stellarium/def0e2e5d664e62f8537d348ff9944b5%40univie.ac.at.

[Georg Zotti]

Am 12.06.2018 10:21, schrieb Fabien Chéreau:
> Hi all,
>
> [...]

>
> One of the problem with plugins is that they have to be compiled
> together with the main application if you want them to be compatible
> with the core. This is because we don't have a well defined API, and
> also because it's very difficult to guarantee a stable ABI with C++
> interfaces. This could be solved with js plugins.

Probably. I see as larger problem that of course most 3rd-party plugins
are out of our eyes. (StarsightVR, or some PushTo-Arduino-projects.) And
I think some other people cannibalize Stellarium into their own projects
(GPL or not), obviously we never get contributions from those. So we
don't even see what people are doing, and these developments may look
great in some "VR labs" and "Visualisation Centers", but cannot be
enjoyed by more.

Compilation is still not that much of a problem, once you know how to
integrate a plugin either into the project, or know how to build a
dynamic plugin after building Stellarium, if this process is reasonably
well documented and works. I think more Linux users would "naturally"
build everything from source when it's just "apt-get install <whatever
build requires>; cmake, make, make install". On Windows, you must
download&install lots of tools, probably create a dev. account with
Microsoft, etc, which apparently intimidates some folks. And as I said,
dynamical plugins are broken anyhow.

> That's fine for me to keep the project separated. Merging is very hard
> indeed, and as you say the goals are different. I personally tend to
> agree with users who complain that the GUI has become too complex
> because too many advanced features appear by default. For example,
> something like ocular plugin is very useful for amateur astronomer,
> but I think 95% of the users will never need it, so it should be
> hidden for them. Same thing for many other details, like color setting
> dialogs etc.. For these users, this new version of Stellarium could
> maybe fill this gap.

An attempt to reduce complexity for the users would be an optional
"light" menu. But the menu grew mostly from users' requests, so it's
hard to say what to leave away, e.g. from coordinates. Maybe
Supergalactic coordinates? All the others have their immediate value
already for beginners.

Maybe light time correction can be simply taken out (i.e., always
applied). But then you lose the capability of demonstrating just that,
and Stellarium is simply great for demonstrating things. So I am not
sure a light menu makes much sense.

Maybe the default selection of plugins can be reinvestigated. If
"naked-eye" and "beginner level" is the guide, Satellites are necessary,
telescope and oculars are not. Novae&Supernovae should be on, Quasars,
exoplanets, pulsars not. But then exoplanets are highly popular....

Another question would be immediate storing of settings versus the
current "save preferences". Most users learned to live with "Save
preferences", others never found it and complain in external forums.
Alexander fears that immediate storing of each setting change will lead
to more confusion and missettings. It's a matter of taste.



>> [long list of amazing features...]

Indeed, a few new libraries have appeared since Stellarium started which
could be put into Stellarium to immediately get the latest computational
models. I should have a closer look again.

Yes, there are quite a few interesting developments here.

>
>> - QtScript has been declared deprecated. I understand there is a
>> replacement system, though. This means we should be prepared.
>
> I already tried to update, but the "replacement" lacks many many
> features of the old QtScript. Basically it's not possible to have the
> same features as what we have now.

That's very bad then. I had understood talking to QObject classes (with
signals&slots) would be possible, and it was just some glue code
missing. I have understood QtScript will be kept as deprecated module in
Qt5. At the latest with Qt6 we must find some solution.

>> - QML GUI "may" replace the current GUI. Sounds like a huge rewrite,
>>
>> requires learning new parts of Qt. If GUI loads faster, it may still
>> be
>> worth investigating.
>
> I already tried to start migrating to QML (even twice!). Each time, I
> finally stopped. The biggest issue was that the javascript environment
> in which QML runs is far from being as powerful as the one in a web
> browser. It's actually very difficult to get javascript libraries
> developed for the web working in QML. Moving to QML makes sense only
> if in the long run we can also move most of the non CPU intensive code
> also in javascript. Because this is difficult, I am now not convinced
> that QML is the way to go. Instead, I found regular HTML/css/js based
> GUI to be more flexible.

OK. I had tried one project, but never found the "intuitive" way of
interfacing C++ with QML until the thing was canceled. So it seems
indeed harder...

Hmm, to be frank, a project asymptotically reaching perfection of course
seems to develop slower than a new one. It also depends where the energy
(effort) goes. 90% into the final 10% or so? I really hope for somebody
with access to modern equipment taking over and improve whatever can be
done for Telescope&Oculars plugin, and maybe add satellite tracking or
such? Or some way to overlay a "live view" from a night vision camera?
Or a "HiPS generator" where you could align your own image collection?
All kinds of nice ideas. I even have a few crazy ideas for acoustic
engineers (but I cannot pay them of course...) We also still have a few
tens of bugs open from Launchpad....

> Moving most of the non intensive
> logic (like GUI, management of collections of landscapes or other
> online resource etc..) to javascript really makes developing such
> features much faster. However, the downside is that changing the C
> code of the engine is probably more difficult than in Stellarium. So
> all in all the development time will heavily depend on the feature.
>
> In any case, if you all agree with that, we'll push our code in the
> Stellarium's organisation github, and time will say if we can do
> something out of it or not beyond a nice demo website.

Sure, no objection to that. "Local installation" for offline use is also
possible with the usual servers available on Linux or something like
xampp on Windows.

Best regards,
Georg

[Fabien Chéreau]

Yes, in the repo, I will add the necessary files to easily start a local server using Docker.

 

Best regards,
Georg

--
Dipl.-Ing. Dr. Georg Zotti
Ludwig Boltzmann Institute for
   Archaeological Prospection and
   Virtual Archaeology
   (LBI ArchPro)
Hohe Warte 38
A-1190 Wien

--
You received this message because you are subscribed to the Google Groups "Stellarium" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellarium+...@googlegroups.com.
To post to this group, send email to stell...@googlegroups.com.
Visit this group at https://groups.google.com/group/stellarium.

To view this discussion on the web visit https://groups.google.com/d/msgid/stellarium/03c7bc96510ff111f699fbd269f73aac%40univie.ac.at.

[ranganath s]

Hello,

    Does this( https://noctuasky.org) support connectivity with StellariumScope like Stellarium does?

Regards,

RS

[Fabien Chéreau]

Not yet.

Eventually, we would like to work on a system to allow controlling a telescope from the web page, going through a kind of telescope server.

Fabien

--

You received this message because you are subscribed to the Google Groups "Stellarium" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellarium+...@googlegroups.com.
To post to this group, send email to stell...@googlegroups.com.
Visit this group at https://groups.google.com/group/stellarium.

To view this discussion on the web visit https://groups.google.com/d/msgid/stellarium/b654cb88-5f76-4238-93b1-f07b5fc2b5aa%40googlegroups.com.

[ranganath s]

Hello,

     Are there any other existing free app/webpage which connects to the stellariumscope?

Regards,
RS

[Georg Zotti]

StellariumScope is a 3rd-party product. We would have to google
ourselves to find any answer for this.

G.

Am 20.06.2018 08:09, schrieb ranganath s:
> Hello,
>
> Are there any other existing free app/webpage which connects to
> the stellariumscope?
>
> Regards,
> RS
>
> On Tuesday, June 19, 2018 at 7:22:57 PM UTC+5:30, Fabien Chéreau
> wrote:
>
>> Not yet.
>>
>> Eventually, we would like to work on a system to allow controlling a
>> telescope from the web page, going through a kind of telescope
>> server.
>>
>> Fabien
>>
>> On Tue, Jun 19, 2018 at 3:42 PM ranganath s <rao.ran...@gmail.com>
>> wrote:
>>
>> Hello,
>>

>> Does this( https://noctuasky.org [1]) support connectivity with

[Georg Zotti]

One last time: Google for a solution to your problems, and come back when you have working code. Or relax and enjoy life and come back when the expert who has been working on it for months now and has already shown promising progress will finish.

IF WE HAD THE TIME TO TEACH YOU HOW TO SOLVE THIS ISSUE, WE WOULD USE THIS TIME TO SOLVE THE ISSUE. 

STOP WASTING BANDWIDTH.

STOP WASTING OUR TIME.

STOP SENDING PRIVATE MAILS TO TEAM MEMBERS.

STOP MOLESTING US!

We will continue to delete further messages from you. It is a waste of time. Do not reply. Farewell!