Page 5 of 6

Posted: 17.12.2019, 16:15
by Janus
@wmurphy

This is from the VS version, I ignore the QT version.
I have not used the navigation menu, but a quick glance shows a pattern.

'Select Sol' is intended to be a quick go home.

'Tour guide' is a hard coded tour of (sol) our solar system.
This should be fixed, replaced by a dynamic list like solar system browser is.
As well, the ssc & stc files, which should be amended with blurbs for this purpose.
Check on Celestia Origins, those blurbs may be in there already.

Select & Goto both work in current solar system.

The next section all work based on current view/solar system.

'Solar System Browser' displays a list based on current solar system

'Star Browser' while based on current solar system, needs work.
More filters, better sorting, the ability to (un)mark selections.

Perhaps some labels could be cleaned up, but the tour is the only one that really needs real work.
While the browser just needs finishing.

Janus.

Posted: 17.12.2019, 19:58
by onetwothree
wmurphy wrote:Continuing the idea of using alternate galaxies, is it possible to replace the references in the navigation menu from Sol to Origin?

In this case you need additional changes to make a new origin, H key and appropriate menu entries use Sun exclusively.

Posted: 18.12.2019, 04:08
by wmurphy
Thanks for the info and pointers.

Posted: 06.04.2020, 07:54
by Janus
Okay, been a while, been busy.
With all the fun lately, I have finally caught up.
Also, lots of free time, I mean lots of free time.
Been trying to make good use of it.

As per a request, here is commit 5772, with some of my tweaks.
The first shows Ra, Dex & Dist.
The second, as above, but also has all greeking disabled.
Their names demark them.

I will also be working on my other tweaks, and bringing them forward as I can.
If anyone is interested:

Spoiler

Code: Select all


   // Janus 200406 : Display Ra Dec & now Dist at the bottom of everything not earth.
   Selection Sol_Object = u->find("Sol");
   Selection EarthObject = u->find("Earth", &Sol_Object, 1);
   Body* earth = EarthObject.body();
   if (sel.body() != EarthObject.body())
      {
      UniversalCoord SelPos = sel.getPosition(sim->getTime());
      Vector3d v = sel.getPosition(sim->getTime()).offsetFromUly(Selection(earth).getPosition(sim->getTime()));
      v = XRotation(astro::J2000Obliquity) * v;
      displayRADec(*overlay, v);
      double dist = SelPos.offsetFromUly(EarthObject.getPosition(sim->getTime())).norm();
      *overlay << "Dist:: " << DistanceLyToStr(dist / 1000000) << "\n";
      }

      overlay->endText();
      glPopMatrix();


This goes in /src/celestia/celestiacore.cpp:celestiacore::renderoverlay
After 'case selection:type_location', but before the end of the switch statement.

Once I find the hud detail variable, the RaDecDist will be selectable.

For anyone who cares, enjoy.


Janus.

Posted: 06.04.2020, 14:10
by selden
Thanks!

Posted: 06.04.2020, 17:50
by onetwothree
Janus, in the nearest future we drop dependency on GLEW and will switch to libepoxy because it supports GL ES. But be aware that libepoxy can't be linked statically because it does a lot of things in its DllMain.

Posted: 06.04.2020, 19:21
by Janus
@onetwothree

Thanks for the warning.
A quick look indicates there is a static link option.
However, I will likely have to create a VS sln/vcxproj for it in order to do anything with it.
The reason is the default build is with mingw.
Which I will not be able to use until I finish making a wxwidgets frontend for celestia in codeblocks.
Chosen because it is multiplatform.

Are you going to a single context of open/glew?
I am so far unable to compile the dome shader outside of the shader manager, and getting frustrated with it.
Having the dome projection available is a goal.

I always run into problems with opengl, so I am not surprised.
I have never been able to do matrix math, and since all opengl discussions use them, I get lost.


Janus.

Posted: 07.04.2020, 05:21
by onetwothree
Yes, it looks like it's possible to build a static version, but I'm totally unfamiliar with Meson. I also have no idea how to generate source files with VS projects.

Janus wrote:Are you going to a single context of open/glew?
I don't understand the question.

Janus wrote:I am so far unable to compile the dome shader outside of the shader manager, and getting frustrated with it.
That standalone shader is not required. All changes are applied in shadermanager.cpp. Standalone one is just a reference implementation.

Posted: 07.04.2020, 06:03
by Markerz
I use

Code: Select all

meson --buildtype=release --default-library=static --prefix=`pwd`/output -Dtests=false
to configure a static build of libepoxy

Posted: 07.04.2020, 06:19
by Janus
@onetwothree

Sorry, I should have been specific.
I have been trying to get the celestia-dome code to compile.

I got the 1.4.1 code to compile in VS2015.
However, I am unable to do the same with the dome code.

A shader is compiled in initsim using some external library (glx?) in a context I am unable to duplicate.
I can compile it just fine, however, it crashes on run.
I traced it, and it crashed because the address for the shadercompile was null.
Tried initglew, but that didn't work.
Study goes on.
I am patient.


Janus.

Added after 8 hours 52 minutes:
@MarkerZ

Thank you.


Janus.

Posted: 17.04.2020, 00:58
by Janus
Okay, here is a new one.
Big difference this time is in celx.

For people like me, here is a new tool.
celestia:RaDec(RA, Dec); (Degrees only, not hour minute second.)
There is a third optional parameter, 'Type', which is not implemented yet.

Right now it searches stars, returning the closest one to the RA & Dec you put in.
It also selects it in addition to returning the index number.

It respects the clock by using the same rotation math as displayradec does.
Once I have expanded it to other catalogs, you will be able to set the date, then search for the closest thing to a given set of coordinates at that time.
This is not happening over night, but I wanted to get some feedback on whether other people liked it.

The code is ugly, I keep telling people, I am not a real C/C++ programmer.
Stuff this abstracted, indirect, or high level, is a pain.
I spent FAR!! more time fighting C++ abstraction than anything else.

Let me know what you think.


Janus.

EDIT: Clarified that new command uses degrees only, no H:M:S format.
EDIT: Please disregard this archive, use the next a few messages past here, it has optimizations turned on.

Posted: 17.04.2020, 04:57
by jujuapapa
Downloaded and installed this morning.
Sorry but more 4 times slow ! :eek: :fie:

I don't keep it...

Posted: 17.04.2020, 05:24
by Janus
Sorry about that, I forgot to turn optimizations back on.
Debugging with them on doesn't work very well.
Besides, this was about tinkering with a new function, seeing if people like it.
The following should take you to Arcturus.

Code: Select all

local qst
qst = celestia:RaDec(214,19)
celestia:print("qst:" .. qst, 5)


Below is same as above, only with optimizations turned on.
I look forward to feedback from people trying the extra celx command.
I find it useful, but I am not everyone.


Janus.

EDIT: This archive superseded, please use later post.

Posted: 17.04.2020, 06:59
by selden
Do you want to hear about other problems?
For example, when the Sun is selected, its distance is shown twice in its HUD display but with different values.
Also, in the highest verbose mode, two of the entries seems to be missing their descriptive labels. See the attached screengrab, which shows the Sun as seen from the Earth.

Posted: 17.04.2020, 09:38
by jujuapapa
Janus wrote:Sorry about that, I forgot to turn optimizations back on.
...
Janus.

OK, it's better ! :wink:

Posted: 17.04.2020, 14:41
by Janus
@selden

I always want to hear about problems.
I can't fix what I don't know is broken.

First, this is an alpha test, perhaps beta, on a celx function written from scratch.

The 1st distance value is not from the earth, it is from the observer, move forward or back and it changes.
In my private fork(s) for making recordings or other things, I move it to the lower left or right, though I have tried it under the clock a few times.
I have never understood why it is in the upper left in the first place.

The 2nd distance value is the proper Ra:Dec:Dist value, which does not change when you move around.

The 1st unknown value is star catalog index number, used during development.
The 2nd unknown value is geometric error tracking, needed while figuring out rotation.
Both of these will go away once I am sure RaDec works properly.

My next step is to add searches for planets, asteroids & comets, the solar system stuff.


Janus.

Posted: 17.04.2020, 14:53
by selden
Thanks for the clarification!

Posted: 18.04.2020, 19:08
by Janus
The question raised by SamwiseBrave in the 1.70 development thread got me thinking.
After getting my RaDec command working finally, A thought occurred to me.

In /src/celengine/marker.h Symbol is defined as an enum.
It along with size, color & label are what define the visible marker attributes.

The Symbol enum defines values 0->12 which are the normally used styles.
I would like to propose adding value 13, 'Texture', that would instead of using a geometric figure, use the texture of the object instead.
While retaining the label as a possible source of an alternate texture, perhaps one designed specifically for that use.

Not quite sure how to do it yet, but I think I might be able to fake something together.
Opinions?


Janus.

Posted: 23.04.2020, 16:33
by Janus
Okay, here we are with some more fun.
Still in the beta stage, so glitches are expected.
Once I am sure everything works, I will be removing the extra verbage from the data, but for now, I use it.

My RaDec function now searches solar system bodies.
Uses closestsolarsystem function, be careful where you search from.
I have not implemented DSOs yet, and may not as they do not move on our time scale.
In addition, I have implemented filters & limits.

Star searches are +- 5 degrees, Body searches are +- 10 Degrees.
Those will both be adjusted based on testing and usage.
The large range on bodies is because they move.

All results are also based on Simulation time, so you can adjust the date, then search to what is/was/will be there then.

Code: Select all

ClosestMatch = celestia:RaDec(Ra, Dec, "Type")

Same return as find: Type can be any of the following, or blank, or left out:

Code: Select all

("STAR")
("PLANET")
("DWARFPLANET")
("MOON")
("MINORMOON")
("ASTEROID")
("COMET")
("UNKNOWN")
("ALL")

A blank or unsent type defaults to Star.
They can also be combined, as long they are separated by a space.
Moon will give you moon and minormoon, I may not fix that, or I may combine them.
Planet will give you planet and dwarfplanet, I may not fix that either, or I may combine them.

Here is a script to illustrate and test with.
I have used only the default dataset, those with more stuff will get different results that I do.

Code: Select all

local qst
qst = celestia:RaDec(214,19)
celestia:select(qst)
celestia:print("qst:", 5)
wait(5)

qst = celestia:RaDec(300,-21,"Planet")
celestia:select(qst)
celestia:print("qst:", 5)
wait(5)

qst = celestia:RaDec(125,3,"Comet")
celestia:select(qst)
celestia:print("qst:", 5)
wait(5)

qst = celestia:RaDec(125,3,"Asteroid")
celestia:select(qst)
celestia:print("qst:", 5)
wait(5)

qst = celestia:RaDec(125,3,"All")
celestia:select(qst)
celestia:print("qst:", 5)
wait(5)

All I can do is hope people find this useful.


Janus.

Posted: 23.04.2020, 16:56
by onetwothree
Janus wrote:I would like to propose adding value 13, 'Texture', that would instead of using a geometric figure, use the texture of the object instead.
While retaining the label as a possible source of an alternate texture, perhaps one designed specifically for that use.

hmm, i just unable to understand this :)